CPU Detection (16 or 32 bit)

[SlikRik]

I'm trying to write a program that will determine whether or not the system a person is using is a 16-bit or 32-bit system (I only want people running a 32-bit system to be able to use the program). Unfortunately, using Borland's built-in _osmajor and _osminor variables will not work because the user could defeat this by running SETVER. I read some earlier posts regarding looking at the size of ints or void*'s, however this will not work because it's compile-time dependent. Does anyone have any way of determing the version number or processor type (16/32 bit) that is fraudproof? Thanks in advance.

[Paul McKenzie]

Go to http://www.naughter.com/dtwinver.html

Regards,

Paul McKenzie

[NMTop40]

just went to your site - didn't know it was that complex.

What does it make Windows 95? 16 or 32 bit? And that wonderful Win32S (I used to work on that!)

how does the size of the CPU compare to sizeof(void *) and sizeof(int)?




The best things come to those who rate

[cpitis]

You don't have to worry about size of integer types, if you are using a recent compiler. The standard C++ specs say that int is 32 bits wide on any platform, short is 16 bits wide, long is 32 bits wide, too.

[Paul McKenzie]

Well, P.J. Naughter has found out that getting the actual OS is not as cut and dry as calling a simple function. I would think that Windows 95 is 32-bits.

Regards,

Paul McKenzie

[NMTop40]

I seem to recall that when they brought in Windows 98, they claimed that 95 wasn't "true" 32-bit. I know that old MS-DOS systems were traditionally 20-bit, giving 1MB of memory, with 640MB of RAM and the rest was ROM/BIOS.

The FAR pointer was used to extend the normal 64MB of RAM but it was not a true 32-bit address, as they overlapped. Thus 0x12345678 was actually 0x12340 + 0x5678, which is actually 0x179b8

You will see this if you use the old DOS-prompt debug command on a file.



The best things come to those who rate

[NMTop40]

Not true. int is at least 16 bits, short is at least 16 bits, long is at least 32 bits. Not exactly those lengths.

I have worked in companies where they never use the standard types at all but use macro-versions, because they can define these according to the machine on which the application runs.

And I have encountered problems on AIX etc. where for example long is 64-bit. Something as innocent as this:

unsigned long x = ~0;



can cause a problem as 0 is 32-bit ( needs to be 0L) and therefore is 0xFFFFFFFF, which is not -1, the value you'd expect it to be in 64-bit.


The best things come to those who rate

[SlikRik]

So then is there a way to accurately determine whether or not a machine is 16-bit or 32-bit?

Thanks.

[NMTop40]

Paul McKenzie posted a link to a web-site where they had a solution.

Actually, the bug occurred similar to the way I mentioned above - I think I innocently subtracted 2 from an unsigned long, only to find the compiler had decided to add 0xFFFFFFFE, which in 64-bits is not the same thing...


The best things come to those who rate

[Paul McKenzie]

I already answered your question by posting the link to a class that returns all the information, and more.

Regards,

Paul McKenzie