Instruction Set detection for 32 bit Operating Systems

[Gunther]

Alex,

it should run now on older processors without problems, I hope. I've to figure out, how to link the right CRT.

Gunther

[Gunther]

Hi Steve,

Hi Alex,

   Here is the result of the program from Reply #56 from my
P-MMX laptop.

Code: [Select]

                Supported Features
                ==================

Vendor String: GenuineIntel
Brand  String: Not supported.

                Instruction Sets
                ----------------

MMX

                Supported Special Instructions
                ------------------------------


Please, press enter to end the application ...


is that the machine, which crashed? If not, try the cpu.exe generated by Alex. Thank you.

Gunther

[Antariy]

Hi Steve, thank you for test! Also for dump info which helped to locate the fault :t

[Antariy]

Gunther, yes it should run now on older machines, not sure about 386 but exactly PPlain. Probably 386-486 too, because I used CRTDLL.DLL as a runtime which is shipped with every Win32 version since WinNT 3.x, not MSVCRT.DLL which is shipped with Win98 and later, and must be installed separately for Win95 (early versions). I'm not sure this DLL is shipped with modern Windows versions, the EXE runs on your machine, it's Win7 x64 isn't it? Then this dll is shipped with Win7 too, interesting if it is shipped with Win8

[Antariy]

Gunther, if the GCC linker supports "Microsoft type" of import libraries then you may try to use the tool
\masm32\tools\makecimp
to create the CRTDLL import library and then use it when linking.
Just rename all the files in the directory MSVCRT.* to CRTDLL.* and edit makevcrt.bat appropriately to change filenames, and then run the bat file and you'll get the import library. But the library will be without the standard startup code, which, for example, provedes the arguments for main(), and causes a fault which has discussed here. If the linker of GCC provides a way to change the entry point, then you may, for your program, just specify the entry as a name of main() as well as add into main() the exit(0); instead of return 0; and the program will be independed from startup code, i.e. it will be smaller and faster to run, and will import only 3 functions from the DLL.

If you would like to have the fully workable replacement of the startup code for the console-type programs (i.e. with standard main(argc, argv, environment) for MSVCRT and CRTDLL then I may find and post them, I posted the replacement for MSVCRT startup code in your thread with Monte-Carlo program which was recompiled with MSVC10.

Probably this post requires to be set as a different thread about CRT libraries

[FORTRANS]

Hi Gunther,

is that the machine, which crashed?

   Yes it is.  Using the version from Alex.

Hi Steve, thank you for test! Also for dump info which helped to locate the fault :t

   You are welcome.

   Also I tried it with a Win32S system, which did not work.
Probably a good thing as I would have had to put a Pentium
(plain) system back together.

Regards,

Steve N.

[Gunther]

Steve,

   Also I tried it with a Win32S system, which did not work.
Probably a good thing as I would have had to put a Pentium
(plain) system back together.

that would be great.  :icon_cool:

Gunther

[Antariy]

Steve, which is the version of your Win32s subsystem? And how does it refuse the program to run - any messages? Also I'm not very understand the phrase about PPlain, complex tenses - I have problems with them You mean the program is not working because of PPlain and not PMMX? But the EXE doesn't contains MMX instructions, so it should work on PMMX, too, probably the problem is with compatibility with Win32s, maybe with the version of it (if the version is lower than 1.15 then the EXE will not be workable due to subsystem version in the PE file).

[Antariy]

Gunther, I have posted the info about startup replacement which may interest you, here: http://masm32.com/board/index.php?topic=3167.msg32861#msg32861

[hutch--]

Win32S was a hybrid that will not run proper Win32 PE files.

PPLAIN = very early Pentium that did not have MMX.

From about 200 MH the Early Pentiums supported the MMX instruction set. I owned a 166 Pentium long ago that did not support MMX.

[FORTRANS]

Hi,

Steve, which is the version of your Win32s subsystem?

   Version 1.25 in an OS/2 VDM.

And how does it refuse the program to run - any messages?

   Yeah, an error number and "Wrong Format".  I can get the
exact words next time I boot it up.

Also I'm not very understand the phrase about PPlain, complex tenses - I have problems with them You mean the program is not working because of PPlain and not PMMX?

   No.  I ran your program on a P-III with Win32S.  The Pentuim
with Win32s is not active at the moment.

But the EXE doesn't contains MMX instructions, so it should work on PMMX, too, probably the problem is with compatibility with Win32s, maybe with the version of it (if the version is lower than 1.15 then the EXE will not be workable due to subsystem version in the PE file).

   Yes, it worked on the P-MMX as reported above.  That was
using Win98.  It failed on a P-III with Win32s 1.25.

Regards,

Steve N.

[Antariy]

Win32S was a hybrid that will not run proper Win32 PE files.

PPLAIN = very early Pentium that did not have MMX.

From about 200 MH the Early Pentiums supported the MMX instruction set. I owned a 166 Pentium long ago that did not support MMX.

Hi Steve, yes I understand what was meant under PPlain, the proggie I posted will work on PPlain, too, since it doesn't contain MMX instructions. What was not understandable is the "Probably a good thing as I would have had to put" - many tenses in a mix

Win32S may properly run decently complex programs, too, even written in "too high level languages" like earlier version of 32 bit Delphi compilers, but the subsystem is crazy ::) Probably Gunter's program should run on Win32s if it will be "sharpened" for it (playing with subsystem version of PE file etc) as it has very modest requirements from the OS. But probably optimizing the program for the such a hybrid is not useful.

[Antariy]

Hi,

Steve, which is the version of your Win32s subsystem?

   Version 1.25 in an OS/2 VDM.

And how does it refuse the program to run - any messages?

   Yeah, an error number and "Wrong Format".  I can get the
exact words next time I boot it up.

Steve, thank you for detailed information :T
I have no experience with Win32s running on OS/2 at all, only some on Win3.1 so it's hard to say what is wrong with the format.
When and if you would like, may you change the subsystem of the EXE to 3.1, using the linker:

LINK /EDIT /SUBSYSTEM:CONSOLE,3.1 cpu.exe

to change the subsystem, and then dump the exe

LINK /DUMP cpu.exe

to check if the subsystem had changed. If it changed then try it with Win32s again, but not sure it will change something. Of course this is for your decision of it's not bother you, just out of curiousity.

[FORTRANS]

Hi Alex,

   Interesting idea, but something went wrong.

Code: [Select]

G:\masm32\bin>LINK /EDIT /SUBSYSTEM:CONSOLE,3.1 A:CPU.EXE
Microsoft (R) COFF Binary File Editor Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


G:\masm32\bin>LINK /DUMP A:CPU.EXE
Microsoft (R) COFF Binary File Dumper Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Dump of file A:CPU.EXE
A:CPU.EXE : warning LNK4048: Invalid format file; ignored

  Summary

And the program crashed the VDM with windows.

Regards,

Steve

[Antariy]

Thank you, Steve!

The program with changed subsystem was not dumped, and when it was run it crashed the VM which has run windows?

I have attached some files more, playing with the format a bit, if you would like to check them in sometime, try them in the descending order. Some of them may crash the VDM, too, probably. Also for your decision as it is just out of curiousity.