Fog Creek Software
Discussion Board




Win32 apps will stop after Longhorn


I was itching to ask this question over a month ago, but because it wasn't in my list of priorities, I held it back. And I doubted the appropriateness of the question.

That Joel's recent article is about the same subject, I am thinking it might be an opportune time to put forward the question.

With the advent of Longhorn, will the applications that were written in Win32 API stop running on the new API? I am not talking of Visual Basic applications that were written around and made use of Windows API, but more strictly of applications written completely in Win32 API.

Sathyaish Chakravarthy
Wednesday, June 16, 2004

No.

Mr. O
Wednesday, June 16, 2004

Windows API is a generic name which was first used for Win16  API, and then for Win32 API.

So, you can't say "Windows API is not Win32 API" or "Win32 API is not Windows API".

Windows API is a generic concept which means Win32 API or Win16 API, depending on the context.



People buy Windows because it runs millions of applications,  including:

- Win32 applications

- Win16 applications

- DOS applications

- some POSIX applications

For Microsoft cutting off the Windows API applications would mean suicide.

MX
Wednesday, June 16, 2004

I recommend reading "Developer Guide to Migration and Interoperability in Longhorn", a free guide published by MS to demystify Longhorn.

According to its third chapter (http://msdn.microsoft.com/library/en-us/dnlongmig/html/intmiglongch03.asp), Win32 will never die. Actually, Win32 APIs are going to be supported and Longhorn specific features will be based on this API. But specific Longhorn things will only be available using the new Managed Code calling conventions.

GinG
Wednesday, June 16, 2004


>Windows API is a generic name which was first used for Win16  API, and then for Win32 API.

Yes, it is. The whole of the OS itself is built on the API. It wouldn't be wrong to say that Windows itself is the API. But my question is:

Right now the managed code libraries in .NET still make calls to the native API. With Longhorn the .NET runtime will be integrated with the OS and there will be a manged API. Will the managed API or whatever that layer that Longhorn manifests itself into still make calls to an underlying native API. In other words, will managed libraries still be using, say, kernel64.dll to make a call to a CopyMemory instruction?

Or there will be a complete new set of API and so if I've written an application in Win32 API, I will either have to:

(1) port the source code by changing the data types to the new 64-bit ones and call a completely new set of API

(2) thunk the executable to adapt to the new platform?

Sathyaish Chakravarthy
Wednesday, June 16, 2004

My understanding is that, in future versions of Windows (Longhorn+), the Win32 API will be _emulated_, running on top of the .NET framework.

So, for non-performance-intensive code, continuing to call the Win32 API will be no big deal. But, when CPU cycles are precious, it seems as though it will be more efficient to use the Avalon API.

Benji Smith
Wednesday, June 16, 2004

"My understanding is that, in future versions of Windows (Longhorn+), the Win32 API will be _emulated_, running on top of the .NET framework."

Do you have some links to validate this? It sounds completely unlikely to me.

Dennis Forbes
Wednesday, June 16, 2004

Try this one on for size:

http://www.longhornblogs.com/abudja/archive/2003/11/04/1139.aspx

....and I'll keep looking for more links. (I don't remember where I originally heard about the Win32 wrappers around WinFX, so I'm having to re-research it now.)

Benji Smith
Wednesday, June 16, 2004

That doesn't say that Win32 is emulated, it says that some of the _new_ services will be implemented in managed code, and thus you have to use interop to communicate with them. Seems reasonable to me, just as I can write a text parsing script in perl and use "interop" (fork, stdin and stdout) to use that functionality from my C++ app.

Dennis Forbes
Wednesday, June 16, 2004

"For Microsoft cutting off the Windows API applications would mean suicide. "

I wouldn't go so far as to say it is suicide.  I think that to some degree Microsoft is counting on prohibitive migration costs to keep people loyal (if begrudgingly) to the platform, even if the odd API breaks here and there as new versions of the OS come out.

www.ChristopherHawkins.com
Wednesday, June 16, 2004

"I think that to some degree Microsoft is counting on prohibitive migration costs to keep people loyal (if begrudgingly) to the platform, even if the odd API breaks here and there as new versions of the OS come out.
"

There's not cost to STICK with what you already have (Winxp, etc.)

So, if there is any significant cost to upgrading to the next Win version (like the "odd api breaking here and there") then corporations won't upgrade unless there is a compelling reason.

I venture that if Win XP had broken things it wouldn't have ever gotten widespread adoption by corporate IT.

Mr. Analogy
Wednesday, June 16, 2004

Win XP did break things.  Corporations upgrade anyway because NT support is running out.  Individuals seldom upgrade per se, they just buy a new system with XP on it and keep using the old system for old programs that won't work on XP, or dual-boot with the old OS.

NoName
Wednesday, June 16, 2004

Of course Win Api will still be available.

Does any here really believe that Microsoft is going to rewrite Office in managed code? (and IE, and outlook, exchange, sql server, IIS, etc, etc)  Microsoft probably has more code that calls the WinApis than any other single company.  Sure they are rich and huge but can you see them re-writing all of their apps?

I made much the same argument when people started to tell me that Java apps would take over the world.  There is a large code base of working code.  To throw that away and start again is corporate suicide.

Billy Boy
Wednesday, June 16, 2004

From the horse's mouth:

"WinFX is neither a wrapper around Win32 (because most of the API is written from scratch, though it does use some Win32 functionality that’s not being replaced) nor is it an actual replacement, in the sense that we aren’t removing Win32 from the OS. WinFX and Win32 will coexist side-by-side, but parts of Win32 will be considered “legacy” starting with Longhorn, just like Win16 was “legacy” with Windows 95." (see http://msdn.microsoft.com/longhorn/support/lhdevfaq/default.aspx )

I did a pilot project at ExxonMobil on migration to .NET from C/C++ and Java.  We were pleasantly surprised to find that Microsoft had not tried to create "God's Platform" where everything must be written for .NET using Language X and if you have legacy stuff, well, good luck trying to get it to work well (if at all) or without a lot of work (e.g., Java).  One of Microsoft's long-standing policies with their own software products is to avoid rewriting code as much as possible.  Therefore, the path they have taken with .NET, including it's stellar interop features, is not surprising.

Kurt
Thursday, June 17, 2004


Thanks, guys. That answers it.

Sathyaish Chakravarthy
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home