Win32 API utterly and irredeemably broken

[Sarevok]

This is old news that came to my attention recently. http://www.theregister.co.uk/content/4/26561.html

Windows programmers, especialy C++ programmers will understand what the article is talking about. Let me explain in the lay mans terms.

In the DOS era applications had direct access to hardware. Windows changed all that. In Windows all interaction with hardware and windows is done through an interface called the win32 API.

The win32 API communicates with programs using messages. All messages are directed to a specific windows. Each window has a specific window procedure function assigned to it.

This function is defined as LONG CALLBACK WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam); hWnd is the handle to the window which received the message, Msg is an unsigned integar containing the message value, wParam and lParam contain message specific data.

For example the WM_KEYDOWN message is sent whenever a key is pressed. The wParam contains the virtual key code of the key pressed.

Windows messages are usualy sent by Windows. But other programs can also send messages. This is normaly not abused by programmers but if someone does abuse it the implications can be bad,

[Xon]

Your just posting this now?!?

A patch was released fixing the WM_Timer Expliot with in days of the expliot being published.

But yes it sucks there is no way to trust the message pump. It would be trivial for the OS to inforce a 'sender' field stating who actually send the damn message.

But it isnt irredeemable, just a minor issue. You should not trust any input, and always validate, no matter the source. This is a fundemental of computer security.

[Einhander Sn0m4n]

WTFH? Why wouldn't there be a damn 'sender' field in which each program uses its MD5 sum hashed through its process ID? I don't know how hard it would be to implement or spoof, but it's certainly better than what's going on now...

And yes, I *just* woke up!

[Crazy_Vasey]

WTFH? Why wouldn't there be a damn 'sender' field in which each program uses its MD5 sum hashed through its process ID? I don't know how hard it would be to implement or spoof, but it's certainly better than what's going on now...

And yes, I *just* woke up!

Because it's never had a sender field, and the Win32 API is backwards compatible to the year dot. We're talking about the API which has incorrect hungrarian notation to maintain absolute backwards compatibility here remember.

[Einhander Sn0m4n]

WTFH? Why wouldn't there be a damn 'sender' field in which each program uses its MD5 sum hashed through its process ID? I don't know how hard it would be to implement or spoof, but it's certainly better than what's going on now...

And yes, I *just* woke up!

Because it's never had a sender field, and the Win32 API is backwards compatible to the year dot. We're talking about the API which has incorrect hungrarian notation to maintain absolute backwards compatibility here remember.

Oh GODS, I pray to thee. Smite the Evil Lord of Microsoft, the Pigopolist Bill Gates, and his Lieutenant the Fat Pig Ballmer straight to Hell, and liberate all his minions so they can see The Light of Open Source...

[Crazy_Vasey]

To be fair, they are trying to get away from the Win32 API now. It's a bit of a case of too little, too late, but I don't think the .NET framework will suffer from this type of thing.

[phongn]

The .NET framework is supposed to be much more secure, but only time will tell to see how good of a job Microsoft does.

[Sarevok]

WTFH? Why wouldn't there be a damn 'sender' field in which each program uses its MD5 sum hashed through its process ID? I don't know how hard it would be to implement or spoof, but it's certainly better than what's going on now...

And yes, I *just* woke up!

No. The send message function is SendMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM); There is no sender ID parameter.

[Sarevok]

To be fair, they are trying to get away from the Win32 API now. It's a bit of a case of too little, too late, but I don't think the .NET framework will suffer from this type of thing.

The .NET framework is not replacing Win32 programming. The framework exists for managed applications which can not run on a native win32 enviroment without the .NET intrepeter. .NET programs are like Java applets - they are slow and inflexible. They were never meant to compete with traditional applications.

[Crazy_Vasey]

To be fair, they are trying to get away from the Win32 API now. It's a bit of a case of too little, too late, but I don't think the .NET framework will suffer from this type of thing.

The .NET framework is not replacing Win32 programming. The framework exists for managed applications which can not run on a native win32 enviroment without the .NET intrepeter. .NET programs are like Java applets - they are slow and inflexible. They were never meant to compete with traditional applications.

Have you read anything about Longhorn? The Win32 API is effectively deprecated in favour of .NET now.

Linky

Programming in Longhorn is based on managed code

[Sarevok]

To be fair, they are trying to get away from the Win32 API now. It's a bit of a case of too little, too late, but I don't think the .NET framework will suffer from this type of thing.

The .NET framework is not replacing Win32 programming. The framework exists for managed applications which can not run on a native win32 enviroment without the .NET intrepeter. .NET programs are like Java applets - they are slow and inflexible. They were never meant to compete with traditional applications.

Have you read anything about Longhorn? The Win32 API is effectively deprecated in favour of .NET now.

Linky

Programming in Longhorn is based on managed code

Longhorn is not there yet. Currentl versions of Windows all support win32 programming. Also traditional win32 programming (unmanaged code) is supported by Visual Studio.NET.

[Crazy_Vasey]

Longhorn is not there yet. Currentl versions of Windows all support win32 programming. Also traditional win32 programming (unmanaged code) is supported by Visual Studio.NET.

Indeed, but I think it's fairly obvious that MS wants to get people using .NET instead of Win32 now. I can't really see them ever disabling Win32 support, for backwards compatibility, but .NET does seem to be the way they want things to go.

[Einhander Sn0m4n]

Solution: Open.NET. With PowerPenguin Technology!

[phongn]

Solution: Open.NET. With PowerPenguin Technology!

There is a partial open implementation of .NET via the Mono project, but it is unlikely to be as good as Microsoft's in-house implementation.

[Dahak]

Solution: Open.NET. With PowerPenguin Technology!

Not everything with an "Open" slapped in front of it will be better than the original technology.

[Pu-239]

XAML isn't new- seems similar to Mozilla XUL or the glade xml stuff. That multiple languages and one output seems similar to GCC and it's frontends, which produce a intermediate representation which is then compiled into a binary, except that it produces bytecodes, which are inferior, since they have to be interpreted and aren't fully cross platform anyway (what is the point of making C# interpreted bytecode anyway? MS's delusion that it can get this stuff running and well adopted on cellphones, pdas, etc?).

How much progress has Mono made relative to those Java clones (which haven't gotten anywhere- too many projects- kaffe, gij, kissme, sablevm, japhar, ikvm, etc, + libgcj and classpath vs only Mono and gnu.NET, which hasn't gotten anywhere)?

[Sarevok]

Indeed, but I think it's fairly obvious that MS wants to get people using .NET instead of Win32 now. I can't really see them ever disabling Win32 support, for backwards compatibility, but .NET does seem to be the way they want things to go.

Good point. Currently only Visual C++ can produced umanaged code (traditional applications). The other compilers can only build intrepeted .NET apps. In the long run I guess .NET will take over. However they will retain the ability to write unmanaged code because intrepeted code is after all very slow compared to machine code.

[Xon]

WTFH? Why wouldn't there be a damn 'sender' field in which each program uses its MD5 sum hashed through its process ID? I don't know how hard it would be to implement or spoof, but it's certainly better than what's going on now...

And yes, I *just* woke up!

No. The send message function is SendMessage(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM); There is no sender ID parameter.

Nope the problem isnt that.

The OS should fill in the sender ID anyway, thus guarantying the source of the message can be trusted.

The problem is the reciever!

Code: Select all

LRESULT CALLBACK WindowProc(
    HWND hwnd,	// handle of window
    UINT uMsg,	// message identifier
    WPARAM wParam,	// first message parameter
    LPARAM lParam 	// second message parameter
   );

See? There is no way the reciever can get the sender of a message.

[Xon]

XAML isn't new- seems similar to Mozilla XUL or the glade xml stuff. That multiple languages and one output seems similar to GCC and it's frontends, which produce a intermediate representation which is then compiled into a binary, except that it produces bytecodes, which are inferior, since they have to be interpreted and aren't fully cross platform anyway (what is the point of making C# interpreted bytecode anyway? MS's delusion that it can get this stuff running and well adopted on cellphones, pdas, etc?).

.Net codechunks are not interpreted!.

Do you read that? It is not interpreted!!

The .NET bytecode is crossplatorm compadible, and is dynamically compiled to native code on 1st use or using pre-compiled chunks.

Unlike Java, there is no Virtual Machine to run .NET bytecode. It runs 100% natively once you run it.

To get .NET bytecode to run on a platform you just need to retarget the JIT compiler to output different native code. While the bytecode is crossplatorm compadible, misc libraries exposed to the code probable arent. Aka WinForms & DirectX

[Pu-239]

XAML isn't new- seems similar to Mozilla XUL or the glade xml stuff. That multiple languages and one output seems similar to GCC and it's frontends, which produce a intermediate representation which is then compiled into a binary, except that it produces bytecodes, which are inferior, since they have to be interpreted and aren't fully cross platform anyway (what is the point of making C# interpreted bytecode anyway? MS's delusion that it can get this stuff running and well adopted on cellphones, pdas, etc?).

.Net codechunks are not interpreted!.

Do you read that? It is not interpreted!!

The .NET bytecode is crossplatorm compadible, and is dynamically compiled to native code on 1st use or using pre-compiled chunks.

Unlike Java, there is no Virtual Machine to run .NET bytecode. It runs 100% natively once you run it.

To get .NET bytecode to run on a platform you just need to retarget the JIT compiler to output different native code. While the bytecode is crossplatorm compadible, misc libraries exposed to the code probable arent. Aka WinForms & DirectX

Is it completely compiled to native on first use, or does it do so each time like a java JIT or perl or python "interpreted" languages which fully compile before execution? And the crossplatform claim is BS. The APIs developers want to use will not be available on all platforms, so you become very limited.


BTW, with GCJ, one can compile Java to native. It sucks though, since it can only use OSS clones of Sun's classes, which are incomplete.

[Sarevok]

Is it completely compiled to native on first use, or does it do so each time like a java JIT or perl or python "interpreted" languages which fully compile before execution? And the crossplatform claim is BS. The APIs developers want to use will not be available on all platforms, so you become very limited.

CLR is is a hybrid between machine code and intrepeted code. It is uses JIT compiler technology. CLR code is pseudo-machine code which is closer to actual machine code making it simpler and easier to execute. When a CLR program is run JIT technology is used to compile parts of the program as they are needed. This means a .NET application is much fast faster than Java applications.

[Xon]

Is it completely compiled to native on first use, or does it do so each time like a java JIT or perl or python "interpreted" languages which fully compile before execution? And the crossplatform claim is BS. The APIs developers want to use will not be available on all platforms, so you become very limited.

While the program is running, the runtime detects when you invoke a function/method which hasnt been compiled. This then invokes the Just In Time Compiler which converts the bytecode into native machine code on the fly using machine specific optimizations.

These assembles are then cached, so next time the method/function is invoked which can be next time the application is run or next time the method is called in the same instance it runs natively the 1st time.

You can also pre-compile it from bytecode to machine code as well.

All the lowlevel & runtime framework stuff is crossplatform compatible. Its the high level stuff like WinForms which isnt crossplatform compatible. Its up to the developer to use crossplatform API to allow the application to be crossplatform capible. But there is nothing intrinsic about the .NET framework which make in non-crossplatform compatible.

I said the framework enviroment presented to the application is crossplatform compatible, not that every application written with it is magically crossplatform compatible like Java tries to make the claim of.