Fog Creek Software
Discussion Board




Long-term prospects of Win32 development

Just read this InfoWorld preview of VS.NET 2005.  I found it very interesting that MS seems to want to re-enhance the place of Visual C++ within its stable of compilers. Perhaps .NET won't bring an end to Win32 development.  (Of course Win32 development will end sometime, I'm just suggesting that .NET is not going to be what brings it about.)

http://www.infoworld.com/article/04/05/28/22FEvs2005_1.html?s=feature

A quote:

"Microsoft is putting Visual C++ 2005 back at the top of the food chain. When Microsoft released VS .Net, it assumed that C++ developers would jump to C# en masse. Unmanaged — compiled to machine instructions — code was deemed primitive, dangerous, and exploitable. VS .Net derailed Visual C++ to encourage C++ developers to evolve into more civilized and enlightened C# beings. "

"New efforts on behalf of Visual C++ 2005 suggest that Microsoft has backed off the C# hard-sell. C++ libraries have been cleaned up, with potential security holes plugged and new features added. Optional language extensions, which Microsoft has submitted for standards consideration, wire .Net-essential capabilities such as garbage collection (automatic deallocation of memory) into Visual C++ 2005. An implementation of the C++ Standard Template Library will provide a portable and transparent wrapper layer around .Net. "

Herbert Sitz
Thursday, June 03, 2004

Maybe even more interesting is that it appears that the name of the product will not be Visual Studio .NET Version 2005, but rather just Visual Studio 2005.  And that (non .NET) Visual Basic 2005 and Visual Interdev 2005 will reappear as supported langauges along with VC++, VB.NET, and C#.

Herbert Sitz
Thursday, June 03, 2004

Great! If I sit on my ass and do nothing long enough, everything that I know will become valuable again.

Just like fat and skinny ties.

:-)

PS: I'm not being sarcastic. I'm serious.

Bored Bystander
Thursday, June 03, 2004

Another example of their new extended-support policy?

Paulo Caetano
Thursday, June 03, 2004

Whoops, before some corrects me I should say it's not clear from the article that VB 2005 will be non-.NET.  On rereading it looks like maybe it's just going to be a stripped down VB.NET with a few other differences.  (And, of course, I shouldn't have said that Visual Interdev was "a language.")

Herbert Sitz
Thursday, June 03, 2004

I think there's an inverse relationship between the developer skill level for a language and the amount of effort that Microsoft puts toward marketing the tools for it.

The strange thing is that MS has put forth a great effort to raise the bar for VC++.  They've hired a some heavyweights (e.g., Stanley Lippman, Herb Sutter) and have made great improvements to the compiler (ISO and STL compliance), yet they've really failed to market it much.

Makes no sense.

yet another anon
Thursday, June 03, 2004

This should surprise no one. 

There is a real need for unmanged code in the Windows world.  Yes a lot of people can get by with managed code.  BUT the managed code needs to ride on top of something.

Hank
Thursday, June 03, 2004

"Not surprisingly, Visual C# and Visual J# pick up new features."

Someone actually programs in J#?  Who is he?

Kyralessa
Thursday, June 03, 2004

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnreal/html/realworld06012004.asp

Dennis Forbes
Thursday, June 03, 2004

And yet the unix community forges ahead with tools that Microsoft would call archaic, while continuing to produce more secure stable code.

What up?

Mike
Thursday, June 03, 2004

I used VJ# once...I pried a function out of an applet that happened to do some insurance calculations that I needed, and shoved it into a VJ# dll. 

About two weeks later, I got irritated by having that extra dll just for one function, and thought it was silly that my users should have to install the VJ# runtime in addition to the .NET Framework, so I finally converted it to C#.

I'd have to agree that it's more of a MS marketing strategy to pull in Java developers than a first-class development tool.

Joe
Thursday, June 03, 2004

Win32 is the rock that .NET is built on.  It will never go away.  It may come in different incarnations, it may be exposed through different abstractions, but it will never ever go away.

What is all of this hoopla about the demise of the Win32 API?  Nothing more than talk.

Until full functionality of the Win32 API is exposed in some form or another it will not go away.

Please tell me how you create a DBMS using C# or VB .NET?

Please tell me how you create contect creation systems like Adobe Photoshop, Indesign, Illustator, QuarkXPress and a million others without full access to the Win32 API?  How do you build these on .NET?

Please tell me how you do anything significant in .NET?  The answer is that you don't.

I read somewhere that the PrintShop team is doing a bunch of stuff to convert parts of the PrintShop to .NET.  They have to go through layer after layer of abstraction and create "junky" hacks just to use the damn thing?  Why? Just so they can claim to have used the .NET?  You know how much their customers care about this?  They don't.  It just ads bulk.  If they were smart they would refactor the C++ and call it good.

I was helping a friend of mine learn PrintShop.  I commmented that I was surprised it used .NET.  She didn't know what .NET was and didn't really care.  Did it make PrintShop easy to use or install?  No.  It just bloated the damn thing.

.NET is for corporate programmers doing database apps and web sites/services.  Other than that it is just a bunch of fluff.  It's a puff ball waiting to go poof.

It is not a rock.  It is built on a rock, but there is a difference.  You can't remove the rock and still have a solid platform.

If MS were to take C++ away and not leave us with anything that exposed the full Win32 API (not a hack to declare API calls in managed code) there would be lawsuits gallore from companies that make the "real software."

Dear Microsoft:

  Please place a small API declarations app in the next version of VS so that we can actually put API calls in managed code without a lot of hassle.

Thank you and have a nice day.

Anon
Thursday, June 03, 2004

Anon's post begs the question: Isn't Win32 "supposed" to go away at some point and be replaced by a compatibility layer?

My understanding was that .Net or CLR  is supposed to replace Win32 as the system API at some future time. I thought that was part of the intent of Longhorn.

I suppose Win32 could be "degraded" in status by making system permission to run native Win32 applications an option controlled by an administrator or by someone anointed with that "right."

Bored Bystander
Thursday, June 03, 2004

>> "Isn't Win32 "supposed" to go away at some point and be replaced by a compatibility layer?" >>

Here's the problem.  You can't have a "compatibility layer" or an "abstraction layer" or whatever you want to call it, if it limits functionality.  Expose all functionality and you will be ok, but don't abstract away functionality.

Microsoft cannot and will not meet everyones need by abstracting away functionality and replacing it with what they deem as "necessary."

Take GDI+ for example.  It's a piece of junk IMO.  It doesn't expose the levels of functionality that TextOut, DrawText, ExtTextOut, GetGlyphOutline etc etc...  Sure its great if you just want to DrawText here or there but if you want fine control of how the text is rendered and drawn then you need the functionality of the underlying API.  It's that simple.

Functionality.  That's the keyword.  When Microsoft abstracts something they abstract away functionality.  The key is to abstract it, making it easier to use, while providing the same functionality.  Obviously this is not possible as proved by .NET.

Having complained enough, I will say that, yes, a "compatiblity layer" as you put it can and should take the place of the Win32 API as long it exposes complete functionality.  That's the catch, however.  How many abstractions of a lower level API have you written that expose all of the functionality contained there-in.  Probably not many.  Why?  Because it's difficult if not impossible.

Anon
Thursday, June 03, 2004

Another example of abstracting away functionality is DirectX.  I don't know how many people on this board are familiar with DirectX, but MS decided to take away direct access to video memory after v7.  Fine.  They want us to go through their API calls so as to better utilize hardware.  Good idea.  Except they forgot something?  What about my custom routine that "drains" the screen?  What about my screen blurring routine?  Hey I need direct access to video memory for these.  I'm sure there's a million more.

Save the memory manager for corporate users who write db apps and let the guys who have to/want to/know what they're doing take on the responsibility of managing their own resources like it's always been.

Anon
Thursday, June 03, 2004

"Isn't Win32 "supposed" to go away at some point and be replaced by a compatibility layer? "

Ultimately .NET is built atop a binary infrastructure, and for that infrastructure to deny any accessibility to enforce a marketing decision would be questionable. .NET has to interact with the system somehow, so it seems logical that a lower binary layer will remain. (Furthermore this isn't a security issue - we've had process isolation since the mid-80s).

As far as "Microsoft" foretelling doom, I think it needs to be considered that Microsoft is a very large company with a very disparate set of views (there are groups in MS that use exclusively C and make, for instance. Apparently they haven't heard that the "Whole company is behind .NET"), but every now and then the marketing engine lets a couple of blowhards have a very loud voice. As an example, I was watching a .NET Show talking about XAML, and they were sincerely claiming that XAML would supplant HTML in the near future. While the Microdroids surely eat this up and start ordering thier XAML For Dummies books, this betrays such an enormous ignorance of recent history that it boggles the mind. That someone could say this with a straight face amazes me.

Dennis Forbes
Thursday, June 03, 2004

Anon and Dennis, everything you say makes sense. .Net as the system API makes about as much sense as using a VB runtime DLL or the UCSD P-Code interpreter for the core operating system.

But I heard the marketing BS and I was confooosed... However, the job and contract markets are reacting as though .Net is the core of everything.

Bored Bystander
Thursday, June 03, 2004

Alyosha`s conjecture: the prejudice against managed code will never be overcome.  I predict in the 25th century, we will have everything we see in Star Trek -- space vessels, phaser beams, transporters, replicators -- the only difference is that we will still be finding memory leaks and buffer overruns with hex debuggers.

Serious.

The prejudice is due to three reasons: first, we're acclimatized to the headaches of programming "to the metal".  Second, the binary API, which has been dogfooded for decades, will always appear superior and more complete than the emerging managed code API.  Hence grumbles about "leaky abstractions".  Lastly, since managed code is admittedly slower than compiled code, people will assume that it's too slow for their purposes (which is rarely true).  It's almost as ludicrous as someone rejecting C in the modern day because they can't hope to achieve the performance and tightness of assembly language.  *cough*  *cough* * http://grc.com/smgassembly.htm * *cough*

Alyosha`
Thursday, June 03, 2004

>> "The prejudice is due to three reasons: first, we're acclimatized to the headaches of programming "to the metal".  Second, the binary API, which has been dogfooded for decades, will always appear superior and more complete than the emerging managed code API.  Hence grumbles about "leaky abstractions".  Lastly, since managed code is admittedly slower than compiled code, people will assume that it's too slow for their purposes (which is rarely true)." <<

This is simply not true.  I love managed code and if I could get all of the functionality I needed from managed code I would use it.  Moore's law takes care of the "slower than compiled code" part.  Really I think .NET is fast enough.  I am not used to the headaches of "programming to the metal".  But I am used to having the functionality I need.

It is very simple and not as complex as you make it out to be.

Second I would like to comment on Boreds comment.  .NET is the ultimate marketing scheme by Microsoft.  It answers the ever present question of "What's new and what's next?"  It's easy in this industry to buy into these new things especially with promises of productivity gains.  What can I say .NET does make me more productive for certain things.  When .NET makes me more productive for all Windows applications then give me a call (555) 555-1212.

Where are the new jobs coming from?  Where would the new jobs come from if it were not for "new" technology like .NET.  This stuff is inevitable and profitable, but as with anything it takes time to "make it right."  And making it certainly does not mean abstracting away functionality.

Anon
Thursday, June 03, 2004

err... last sentence should read "making it right"

Anon
Thursday, June 03, 2004

I think as most win16 appz works on windows 2000. Win32 appz will work on longhorn and any other future OS.

Somorone
Thursday, June 03, 2004

"the only difference is that we will still be finding memory leaks and buffer overruns with hex debuggers"

Managed code doesn't cure bugs. More than once I've seen on here something akin to "I don't need to worry about going out of array bounds anymore!"...uh, okay. If your program crashed because you can't handle array sizes then that's the _least_ of your worries - "I might be putting the incorrectly calculated deposit in the wrong account, I have the wrong imperative security checks, but I ain't got no memory leaks!". (BTW: Memory leaks are such a non-issue nowadays that each time it gets referenced it implies desperation).

Interesting aside: The archaic, obsolete UNIX execution model is that many tasks are spawned as processes, with those processes having minimal permissions. If the process tries to do something the system won't allow, or to access the wrong memory, it is killed, and the automatic memory management goes in and frees all of the memory that the process allocated (indeed if you're writing a short-life unix forked process you needn't bother calling delete/free because the "garbage collection" will release all of the memory soon enough). It was interesting how voraciously this model was attacked as inefficient and bloating by the same people who are now pimping .NET.

Dennis Forbes
Thursday, June 03, 2004

Keep in mind the vision of .NET (and its name) were born at the height of .dot mania, when all worldwide computers were going to be seamlessly connected and your personal "agent" such as clippy the paperclip would scour the NET for you overnight and present you with a customized "newspaper" in the morning, etc.

Once that fizzled and all content turned to spam, .NET still had all that momentum so they had to hype it just to save face. But I think gradually-- starting now with their re-focus on unmanaged C++ -- it will disappear entirely.

Jeve Stobbs
Thursday, June 03, 2004

I'm a bit late to this party, but the original linked article is flawed in that it suggests Microsoft didn't do much in the way of supporting C++ development with the initial versions of Visual Studio .Net, which is bullshit.  The C++ compiler in 2002 was much better than that of VS6.0 in terms of code generation and standards compliance.  The C++ compiler in 2003 is better still.  Just because the C++ compiler enhancements they made were stuff that is behind the scenes and not up front like GUI builders and such doesn't mean it isn't there.

Mr. Fancypants
Thursday, June 03, 2004

"(BTW: Memory leaks are such a non-issue nowadays that each time it gets referenced it implies desperation)."

Sorry, this is wrong. I recently worked for a 100 million dollar company whose flagship product was riddled with memory leaks. Oddly enough they ended up selling the product after it was released (almost two years late) and "refocusing" the company in a different market.

This product would have been much better if 80-90% of it had been written in C# rather than C++.

Jorel on Software
Thursday, June 03, 2004

"Managed code doesn't cure bugs".

Firefighters can't stop all fires, either.  Still, would you rather have a fire station in your neighborhood, or not?

Managed code brings you three benefits: first of all, if you have a buffer overrun, you know about it immediately, and you know exactly where it is.  Secondly, it eliminates the entire possibility of buffer overrun vulnerabilities (notoriously difficult to find and fix), giving the coder the ability to focus on other security threats (elevation of priviledge, injection attacks).  Thirdly, although memory leaks can occur, you have to work a lot harder to create them (and yes, if you expect to have an uptime of anything longer than a week, you MUST address the problem of memory leaks).

Alyosha`
Thursday, June 03, 2004

"your personal "agent" such as clippy the paperclip would scour the NET for you overnight and present you with a customized "newspaper" in the morning, etc. "

But that's happened: look at RSS aggregators.

Akilesh Ayyar
Thursday, June 03, 2004

In 1993, or thereabouts, there was an agent that would scour the net looking for whatever task you'd given it.  The name escapes me but it was something like Bloodhound.

For all the reasons that Alyosha gave, along with Bored B. and all there's a fundamental reason for keeping tools like Visual C++ sharp and the Win32 API running.  .NET has to run on something.

And if that were not that sufficient reason there's all the kernel code, driver code, heavy metal lifting code and so on that still needs support and maintenance.

Plus, can you really imagine all the existing apps being rewritten to have what at best looks like a UI made out of string just for the sake of being able to hire cheaper programming talent?

Simon Lucy
Thursday, June 03, 2004

Though, actually the concept of C++ having an automatic garbage collector gives me the screaming hab dabs.

Simon Lucy
Thursday, June 03, 2004

That's good they're restoring Win32 development to first class status. It was the secret of their success in the 1990's.

Perhaps the intention of marginalising that sector with .Net can go down as another MBA idea.


Thursday, June 03, 2004

"Managed code brings you three benefits...."

You know for virtually anyone who programs, or has programmed, in C++, the ".NET brings an end to buffer overflows and memory leaks" selling point is incredibly weak (and I suspect that it's a selling point that is pandering to the VB crowd) -- buffer overflows, while seemingly common in Microsoft software, are a relic of __HORRIBLE__ code (but in their defense I'm sure most have been the result of old code when it really didn't matter and most inputs were trustable). Buffer overflows are so trivial to discover, so easy to fix, and so rudimentary to avoid in the first place that it's generally a non-issue. Of course "unmanaged" code has plenty of code-watching techniques to catch unexpected buffer overflows in the field, so it's not like there aren't defenses.

Regarding memory leaks, my comment wasn't that memory leaks don't matter, but that memory leaks simply aren't that big a problem in the field, and there are a plethora of great tools that can narrow in on every single memory leak to make it a no-brainer finding and removing. Again, unmanaged code isn't without programmer supports.

Dennis Forbes
Thursday, June 03, 2004

When discussing managed vs native code, it's important to recognize which tool is suited to which job.  Obviously if you're writing code that really does need to run close to the metal, like device drivers, os kernels, etc, you need native code.

But if you're writing DB frontends, the greatest new version of Yahtzee!, or an email client, you probably don't.  People writing these kinds of apps tend to focus more on business requirements than hardcore programming knowledge, which is exactly what .NET is intended to let them do.  It's not a bad thing.

Some apps fall in the middle.  If you're writing Photoshop, you'll need some native code to do things with graphics.  But if you can package that up in a library and deal with it from .NET, you'll end up with a better product, because your GUI design team (meaning the people constructing the pretty menubars, tool boxes, and dialogs) won't be dealing with memory management issues and the like.

Also, there is nothing inherent in .NET that requires apps to look like their GUIs were designed by a color-blind, hyperactive 12yo.  It is true that the controls included in the box (of the Framework and VS.NET) leave a lot to be desired, but they're just components...replace them if you don't like them.

Joe
Thursday, June 03, 2004

"Buffer overflows are so trivial to discover, so easy to fix, and so rudimentary to avoid in the first place that it's generally a non-issue".

Wow.  Could it be that I'm the only one who disagrees vehemently with this statement?

Given: one million LOC of code.  Find: all buffer overflows.  Hint: there's a lot more involved than locating every strcpy in the code.

Please tell me I'm not the only one who thinks this is a nightmare task?

Alyosha`
Thursday, June 03, 2004

"Please tell me I'm not the only one who thinks this is a nightmare task?"

Let's keep this in perspective - if you have a million LOC, you probably have a bit of manpower that can spend the time to go through the code and identify possible buffer overflow exploits (hint: Lots of teams have done this very successfully with lots of very large projects. See OpenBSD). Don't superimpose "poor single developer" with a huge project and pretend like it's an onerous task. The reality it hasn't been done on most projects is simply because it isn't a priority.

Of course if you developed appropriately in the first place (which most organizations are nowadays) you don't have to go back over your code.

Dennis Forbes
Thursday, June 03, 2004

> I think as most win16 appz works on windows 2000. Win32 appz will work on longhorn and any other future OS.

Will Win16 apps run on Longhorn and any other future OS?

.
Friday, June 04, 2004

Somewhere, I don't remember exactly where. Bill Gates was demonstrating how VisiCalc works even on Longhorn. If they can support DOS, they should support Win16 too.

Green Pajamas
Friday, June 04, 2004

We have a million lines of ANSI C, and no buffer overflow problems.  As it's been said, it was made a priority to avoid / fix them.  It's a matter of product quality.

Sassy
Friday, June 04, 2004

... no buffer overflow problems ...

... that you know of.

As you know, it's hard to prove a universal negative.

Alyosha`
Friday, June 04, 2004

"As you know, it's hard to prove a universal negative."

Prove that there is no way that now or ever a given piece of .NET code can't exploit a fault in the CLR to supercede permissions?

Dennis Forbes
Friday, June 04, 2004

Win32 will probably go away around the same time as x86.

Jim Rankin
Friday, June 04, 2004

Now that we're in sillyland ...

Prove that there is no way, now or ever, that a C++ program can't exploit a fault in the Win32 API to supercede permissions?

Alyosha`
Friday, June 04, 2004

While we're at it, let's try to prove that there is no conceivable way, now or ever, for the Win32 API to do something illegal with memory or other hardware, thereby causing a GPF or BSOD...oh, wait.....

Joe
Friday, June 04, 2004

*  Recent Topics

*  Fog Creek Home