Many windows applications especialy 16 bit ones make extensively use of the dos api still present in win3.1 95/98 (that's why wine has to emulate a large subset of dos as well).

I think those cause problems (aside from the hardware acces restrictions) as we all know that the dos emulation provided by the NT family is far from perfect and complete.

hi folks!

i did it!
now the windows version works perfectly.

it was simple: i thought the problem is some exe header windows doesn't feel right about. so, how can i change the exe header to a valid one? simple, i took UPX and compressed the exe file.
now it works!
so, when getting the "no valid win32 executable" error, try it with the EXE compressed using UPX, it may work...

Good.

As far as I know UPX doesn't support 16-bit Windows NE files. So the file you compressed must be a 32-bit one (PE). I don't know why Qbix was talking about 16-bit executables, because i have been unable to understand him fully. I get the whole point, though. I use UPX very much and i just love it. Bad thing Windows doesn't have native support for compressed executables at core level (like OS/2 had with its LX portable executables).

another option is the following program:
PE Validator by LaZaRuS

get it here:
http://protools.anticrack.de/files/utilities/pevalid.zip

this one is made for exactly this problem. it corrects the header of such files which win2k/XP report as "this file is not a valid Win32 Executable"...
//EDIT: haven't test it, though.

perhaps this can be added to the "places to start" post...

Also a new relatively new compression program called PE Compact 2.40.
There is a freeware/student version. That should be Linked on his site but it isn't. I know how to get it though.
It is specifically designed though for Win32 files and dlls.

Which is why I have both UPX 1.92 Beta and PE Compact 2.40 at my finger tips when I want to compress. 😁

Personally, I don't see the safety benefit to limit a program from touching the sound card directly,

In DOS this was no problem because there was only one program running at a time. However in Windows you can have many programs running at once, so normally Windows takes care of requests for hardware access and gives each program their turn. With Windows 9x this isn't a rule and old programs can try to access hardware directly; this can result in programs fighting for the same resources, resulting in a resource conflict and a frozen operating system. This is just one of the reason NT based systems are so much more reliable. When an old program tries that now XP just tells it to p*ss off. 😀