WinAPI 32 is here to stay!

[esposito]

I am impressed (and I couldn't agree more with) by what Marco Cantù -- one of the most important Italian experts on Delphi -- recently wrote in his blog:


Native COM and Win32 code is here to stay and using it properly doesn't compromise security. This is not surprising, given the amount of new native (COM and Win32) features in Windows Vista and (even more) Windows 7. There is nothing new in recent operating systems you cannot use in a native application.

Contrary to what Microsoft envisioned or hoped or simply told us, the Windows ecosystem is not moving towards a .NET centric solution, but .NET is only a powerful and sophisticated execution and development environment on top of Windows . Which is what Delphi and the VCL are, even if at a much smaller extent due to the highly different R&D budget behind it.


The thread above is entitled "Microsoft, Native Code and Security". If you want to take a look at Marco's original post, here's the link:

http://blog.marcocantu.com/blog/microsoft_nativecode_security.html

I personally believe that what Marco says makes a lot of sense. Am I wrong?

[RobDog888]

Yes and no if i read it right. Windows is and always will be native c language authored and exposed via win32 apis. Windows will never be written in anything else. Now using api callls or .net method/functions are only different ways to get to the same destination. This is how its always been.

[esposito]

Yes and no if i read it right. Windows is and always will be native c language authored and exposed via win32 apis. Windows will never be written in anything else. Now using api callls or .net method/functions are only different ways to get to the same destination. This is how its always been.

Yes, but the real question is, will the future versions of Windows guarantee or break compatibility with native COM and Win32 code? Will there always be more than one way to skin a cat, i.e. using api calls or .net method/functions, as long as Windows is alive?

[RobDog888]

Things will break on os versions where moving it forward is required but usually an api will remain the same and never change. Now there is the scenerio where depreciating a call will happen but usually its because a more advanced api will be added. The depreciated api will still be supported for some time as MS always tries to give several os versions before dropping support for anything depreciated. This gives u a chance to utilize the new call when u can to make smooth transitions. I know there are thousands of dlls but i cant think of any that have been removed since windows 2000 but that was because the os "merged" with the NT os platform.

[dilettante]

I don't think there was ever any plan to make a future Windows "based on .Net" and I don't think it was ever even suggested by anybody knowledgeable. The closest thing may have been an experimental mini-OS that used a small, low-level CLR implementation to build an OS services layer on top of a small kernel. As far as I know this is a long dead experiment.

Windows 2000 didn't "merge" with anything. Windows 2000 was simply NT 5.0, an evolution of the platform just as NT 3.5/3.51 had been reworked into NT 4.0 earlier. Win9x died out with Me, which was the last gasp of DOS-based Windows. Today we have Windows 7, which is NT 6.1 if you look past the marketing label. One of the biggest changes going from NT 4 to NT 5 was reworking DTC, MTS, and DCOM to create COM+ as a core system service. Another was making Unicode the native format instead of the mishmash of ANSI and Double-Byte Character formats in NT 4 and earlier.

It is true that various calls are deprecated over time. However there are a large number of deprecated API calls that are only present in Windows because they made it easier to port Windows 3.x programs to the Win32 platform. By rights nobody should be using these calls today, but they do still work.


The biggest loss may be in terms of COM support for new features. While many new APIs are COM-based or have COM interfaces, you don't always get full ActiveX support for them. This makes them hard to use from Windows Script, VB6, or VBA and similar 3rd party tools. But they still use COM at a level supported by C++. Quite often the missing key is a lack of typelib information either within the DLL or externally in TLB files.

Instead of the necessary ActiveX support you may find only a managed wrapper.


The non-core layers on top of the OS are where you'll run into more obsolescence. Stuff like DirectX has undergone some radical shifts. Other high-level layers like MSXML and WIA continue to evolve as well, and often without full upward compatibility. You can see more blatant examples when you look at automating Office programs, where early binding will get you in trouble right away, and even with late binding you may find that new versions don't support features of old Office versions' object models.

Occasionally Microsoft has just plain screwed up, breaking old programs. Vista's DAC 6.0 initially omitted support for typelib information matching the ClassIDs for pre-6.0 ADOX. Any existing program that used early binding with ADOX prior to Vista would fail on Vista. This was remedied in Vista SP2 though, using a technique like the one used for ADO since ADO 2.5 was released.