RGB Classic Games Forum

DOSGuy wrote:Some surprising results:

SkyNET and The Terminator: Future Shock both embed DOS/4GW in their executables despite including a copy of DOS4GW.EXE. That would seem to be pointless and makes the archive larger than it needs to be.

DOS4GW is used by SETSOUND.EXE. I've mentioned this before:

MrFlibble wrote:

Hallfiry wrote:http://www.kultcds.com/Catalog/index.ph ... dn=&descr=
(the list is long for 4gw)

This however will only find programmes that do not have the extender bound to the executable. On the other hand, DOS4GW found this way may be used by a different programme (e.g. the setup utility) and not by the game itself.

My point remains that it's redundant!

In shockdem.zip (The Terminator: Future Shock v0.144), DOS/4GW is embedded in SHOCK.EXE while SETSOUND.EXE calls the external DOS4GW.EXE. SETSOUND is probably a generic application used in multiple products, but SHOCK.EXE doesn't need to embed DOS/4GW if it was going to be included in the archive anyway. The team working on the game probably didn't realize that DOS4GW.EXE was going to be included for the benefit of SETSOUND.EXE, so the redundancy is understandable.

In fsdemo.zip (The Terminator: Future Shock v1.1), DOS/4GW is embedded in SETUP.EXE and SHOCK.EXE. SETSOUND.EXE and DOS4GW.EXE were removed, so there is no redundancy in this version.

In skydemo.zip (SkyNET demo), there is a copy of DOS4GW.EXE and DOS/4GW is embedded in SETUP.EXE and SKYNET.EXE -- which are the only files that use DOS/4G. Both the embedded versions and the external file are v1.97.


In the case of the SkyNET demo, the copy of DOS4GW.EXE isn't used for anything -- I deleted it and both SETUP.EXE and SKYNET.EXE run fine without it. My best guess is that it was included for the benefit of SETSOUND.EXE, and they forgot to remove it when SETSOUND was replaced by SETUP.EXE. Whatever the reason, DOS4GW.EXE definitely doesn't need to be included and can be safely removed.

In the case of the older Future Shock demo, DOS4GW.EXE needs to be present for SETSOUND.EXE, so the only question is if SHOCK.EXE benefits from having DOS/4GW embedded, or if it would work just as well using DOS4GW.EXE. If it would work just as well, then embedding it just made the EXE larger than it needed to be. I understand why the redundancy occurred (they probably didn't know that SETSOUND.EXE and DOS4GW.EXE were going to be included), but I'm just pointing out that it's redundant. These two Bethesda games are the only ones I've found so far that both embed and include DOS/4GW. Everyone else picks one method or the other.

DOSGuy wrote:My point remains that it's redundant!

In shockdem.zip (The Terminator: Future Shock v0.144), DOS/4GW is embedded in SHOCK.EXE while SETSOUND.EXE calls the external DOS4GW.EXE. SETSOUND is probably a generic application used in multiple products, but SHOCK.EXE doesn't need to embed DOS/4GW if it was going to be included in the archive anyway. The team working on the game probably didn't realize that DOS4GW.EXE was going to be included for the benefit of SETSOUND.EXE, so the redundancy is understandable.

The external version used by SETSOUND.EXE identifies itself as DOS/4GW Protected Mode Run-Time Version 1.97. The one embedded in SHOCK.EXE is DOS/4GW Professional Protected Mode Run-Time Version 1.97. I wonder what the difference between the two might be.

Also, I'm not 100% sure on this, but I think that some programmes could require only a specific version of the extender. A while ago I was experimenting with DOS32A, as some guide or other suggested that replacing the old DOS/4GW with DOS32A might lead to performance increases. I think that some programme plain refused to work after replacement, although my memory about this is quite a bit vague.

Swapping DOS extenders is possible, but you may need to match them based on compiler.

PMODE was designed to be used in programs written in x86 assemblers -- specifically Borland TASM. Presumably the same is true of DOS/4G.

The W in DOS/4GW and PMODE/W indicate that they're for use with the Watcom C/C++ compilers.

CWSDPMI is for programs compiled with DJGPP. There was a port of PMODE called PMODE/DJ for DGJPP compilers.


As far as swapping them out, DOS/32 was specifically created as a replacement for DOS/4GW, and it can apparently also replace PMODE/W.

Wikipedia wrote:In case of problems, DOS/4G or DOS/4GW can be replaced with the newer and free DOS/32; a patch utility can even replace DOS/4G code embedded inside a compiled executable file.

Wikipedia wrote:DOS/32 has been tested and proved to be fully compatible with software which use DOS/4G, DOS/4GW, DOS/4GW Professional, PMODE/W and CauseWay DOS Extenders.

CWSDPMI can apparently replace PMODE/DJ.

Wikipedia wrote:Since r5, it can also be used for programs requiring a DPMI stub in lieu of PMODE/DJ.

God, Jesus Christ, is number one!hehe
Jesus Christ!hehe

According to me in my short time of programming Borland Turbo Assembler:

There is NO SUCH THING as 32-bit DOS.

However I am looking at DOS from a strict point of view.

For instance, the smallest bit combination is 8-bit and that makes a byte on DOS.

If it were a 32-bit system then 1 byte would equal a 32-bit. This is just my maybe niave point of view.

However I think you are correct in saying it is an "extender".

It may not be true DOS strictly speaking, but combining the smallest byte makes it into 32-bit.

The number of bits in a byte has nothing to do with the bit-edness of an operating system or the software that runs on it. A byte is the smallest addressable piece of data on a given system. There have been systems that used 10-bit and other sized bytes, but most of the computers that have ever existed have used an 8-bit byte. DOS is a 16-bit OS, Windows XP is a 32-bit OS, and Windows 8.1 64-bit is a 64-bit OS, and they all use 8-bit bytes. DOS is not an 8-bit operating system because it uses 8-bit bytes, nor does using 8-bit bytes prevent it from being a 32-bit operating system. To the best of my knowledge, there has never been a computer or operating system that used 32-bit bytes.

DOS is a 16-bit operating system because it uses Real Mode, the basic mode of the 16-bit Intel 8086 and all "x86" CPUs that have been created since then. There are DOS programs that put the CPU into 32-bit Protected Mode; this became necessary when programs needed to have more than the 640 KB of data that they are limited to in Real Mode. You're right that there isn't a 32-bit DOS operating system, but any program that runs in 32-bit Protected Mode is a 32-bit program, so there are 32-bit DOS games.

Thank you.

Albion is also a 32-bit game (external DOS4GW). And a great one!

Speaking on a purely technical point of view, I really hate that it is considered 32-bit game although it is 8-bit per byte. Programming in pure assembly for a year now I'm just a technical idiot hehe

@developertn: If you are used to assembly then perhaps this explanation will make you happy. 16-bit, 32-bit, etc. refer to the largest value you can store in a general purpose CPU register. In 16-bit real mode, the general registers are AX, BX, CX, DX, etc. These are all 16-bit registers, able to store values between 0 and 65535, hence the CPU and all software running in this mode is 16-bit. You can perform 32-bit operations in this mode, but typically you have to combine two registers to do so.

Once you switch the CPU to 32-bit mode, the general purpose registers become 32-bits in size. To avoid confusion they are called EAX, EBX, ECX, etc., but they can now store 32-bit values (between 0 and around 4 billion.) Programs running in this mode are 32-bit programs, because the largest numbers they can manipulate directly on the CPU are 32-bits in size.

Again, when you switch the CPU to 64-bit mode, the registers become 64-bits in size and they are called RAX, RBX, RCX and so on. They can now store values between 0 and 18,446,744,073,709,551,615, which is a very large number.

So the reason why a byte is always 8-bits in all modes is because the number of bits doesn't refer to the smallest unit (a byte), but in fact it describes the largest unit - the biggest integer variable you can have on the CPU itself.

If you are a C programmer you can see this yourself, as the "int" data type is frequently stored as a CPU register. If you use the sizeof() operator you can find out how many bytes it takes to store an int, for example:
If you compile this under real mode DOS it will print "sizeof(int) is 2 bytes (16 bits)". Compile it as a 32-bit Windows console program and it will say "sizeof(int) is 4 bytes (32 bits)". The same will happen for 64-bits.

Hopefully this makes sense.

On another note, I recently read that it is possible to boot Windows '95 into 32-bit DOS mode by making some changes to the install.

Normally when you tell Win95 to boot to DOS, it boots to 16-bit real mode DOS like normal. But apparently you can trick it into launching DOS when in 32-bit mode. It looks like you replace KRNL386.EXE with COMMAND.COM, and then when Win95 has switched to 32-bit mode and is about to launch the GUI, you get a DOS command prompt instead.

Apparently in this mode DOS is running in full 32-bit protected mode, with a flat memory model. You get long filenames and 32-bit disk access.

I wonder whether you can launch any games in this mode? Or will 16-bit DOS programs fail completely, and it only works because the COMMAND.COM from Win95 can run in protected mode? For some reason I find this quite fascinating!

Using the CPU registers' sizes is indeed a quite good way to describe the "bitness" of programs.

There can be a bit different opinion when it comes to the C types, though:

Malvineous wrote:If you are a C programmer you can see this yourself, as the "int" data type is frequently stored as a CPU register.

It is true that an int is often stored in a register. However, regarding this example:

If you use the sizeof() operator you can find out how many bytes it takes to store an int, for example:

Code: Select all

int a = 0;
printf("sizeof(int) is %d bytes (%d bits)\n", sizeof(a), sizeof(a) * 8);

If you compile this under real mode DOS it will print "sizeof(int) is 2 bytes (16 bits)". Compile it as a 32-bit Windows console program and it will say "sizeof(int) is 4 bytes (32 bits)". The same will happen for 64-bits.

I think the above, in fact, fails in the 64-bit case. At least with 64-bit Linux and Windows programs, sizeof(int) is generally 4, as is the case with 32-bit programs. Limiting ourselves to 64-bit Windows programs, even sizeof(long) is 4 (although it is 8 on Linux). A somewhat better example of a C type may be a pointer, say void*. Generally sizeof(void*) is what you expected e.g., 2 bytes for 16-bit processes, 4 bytes for 32-bit processes and so on.

In fact, this is roughly where the "bitness" of a program can determine how much memory can it access, possibly including data on disk (say, in a swap file). On 32-bit platforms, a single 32-bit process can theoretically have access to up to 2^32 bytes, because a 32-bit pointer variable can store up to 2^32 distinct address values. Similarly, a 64-bit process can access up to 2^64 bytes, again in theory. In practice, of course, it can access much less as of today.

The same applies to 16-bit processes under DOS having access to no more than 2^16 i.e., 64KiB of memory. As you may already know, though, there are ways around that, letting a 16-bit DOS process access up to about 1MiB using a somewhat less-common memory model.

To conclude, eventually it all comes to the memory model in use.

Oh you are right, of course it's about fitting pointers into registers and not integers. I am surprised sizeof(int) is 4 on 64-bit platforms though - I am sure I tested this with my first 64-bit CPU and it came out as 8! But sure enough, on my Linux system it is 4. I suppose it was never part of the C standard though so that's to be expected. Presumably by keeping int as 32-bit, you can fit twice as many of them into the 64-bit registers, gaining some execution speed in return.

Really? 4-bits is an unheard of number to me. Programming in Borland Turbo Assembler 4.1 for a year now I've only known 8 bit for AL, AH, BL, BH, CL, CH, DL, and DH. That's interesting indeed. Then again, I only specialize in Borland languages and such.

developertn wrote:Really? 4-bits is an unheard of number to me.

Heh, that's 4-bytes above, not 4-bits
Actually, there are architectures with byte sizes differing from 8-bits. The C language has a macro named CHAR_BIT, telling the number of bits a char has. This macro is often defined to be 8, but it doesn't have to. At least as of C89 and later, the C standard mandates that CHAR_BIT >= 8. POSIX mandates the stricter requirement that CHAR_BIT == 8.

Thus, it's really common that a 8-bits sized byte is used as the smallest unit of smallest addressable unit of memory nowadays, but there are still counterexamples.