DPMI and Programs Made with FBC?

[Aaronm82]

Hello everyone,

I have a question about DPMI (DOS Protected Mode Interface) and the .exe files produced by FreeBASIC.

My question is, when is it necessary to use DPMI, and what particular parameters are needed to run my programs with it?

I ask because my DOS programs made with Freebasic all run fine under Windows ME. But, if I boot with a floppy disk and go straight to DOS (at least, Windows ME's crippled version of it), it says my program requires DPMI.

Contrast that with the programs I compiled with QuickBasic 4.5, which do work when booting with a floppy disk.

I understand that QuickBasic only produces 16-bit executables, whereas FreeBASIC only makes 32-bit executables.

Therefore, do my FreeBASIC programs really work under plain old DOS? Or do I need to worry about including some type of "extender" in the programs I distribute?

[marcov]

IIRC in the go32 distribution (the extender from DJGPP), there is a cwsdpmi.exe which is a minimal dpmi provider for plain dos.

You might also need to load himem.sys, and maybe you also need go32.exe

IIRC win9x doses load himem.sys by default, so it might be a matter of putting cwsdpmi.exe in your PATH so that the exe can find it.

[Aaronm82]

thanks for the reply, Marcov.

Windows ME isn't quite the same as either Windows 98 or 95 in that regard. Those both have the option of restarting the computer in DOS mode, and therefore the possibility of adjusting the Autoexec.bat and the path.

Not so with Windows ME. The only way to get to DOS is booting from floppy disk, and even then, you basically have to do everything yourself... because the autoexec.bat in the root directory is only for looks, and doesn't actually do anything. Windows ignores it. If you need to change the path it has to be done in windows by running Msconfig. This is a particular Windows ME issue, which I don't believe is shared by the earlier 9x versions. It makes running DOS more difficult in this case. Then again, I could just copy the csdpmi file into the Windows directory. (I will try doing this.)

Anyways, I will track down that csdpmi file and give it a shot for the fun of it.

I guess I'm not worried about it, as it seems my FreeBASIC compiled programs work totally fine under Win9x. And if anybody is actually working with something older, I can merely point them to the csdpmi file.

Rather than messing with any autoexec file, I might just make a batch file that loads the csdpmi before it's loads my program. Might be easier that way for people using my program. Simply have them start a "runme.bat" type of thing.

That's assuming csdpmi works that way? What's the deal with DOS4GW? Is that the same type of thing, or they similar?

[Aaronm82]

I just found another thread on this forum that deals with this issue:

http://www.freebasic.net/forum/viewtopic.php?t=3752

The XP user is describing something similar to my experience with Windows ME.

One of the persons says to simply place the extender in the same directory as your FBC compiled program. Sounds good.

[Aaronm82]

I got it to work when booting from floppy!

All I had to do was copy the CWSDPMI.EXE to the same folder as my program. Easy as that :-)

http://www.delorie.com/djgpp/dl/ofc/sim ... pmi5b.zip/

[rugxulo]

I have a question about DPMI (DOS Protected Mode Interface) and the .exe files produced by FreeBASIC.

My question is, when is it necessary to use DPMI, and what particular parameters are needed to run my programs with it?

I ask because my DOS programs made with Freebasic all run fine under Windows ME. But, if I boot with a floppy disk and go straight to DOS (at least, Windows ME's crippled version of it), it says my program requires DPMI.

Contrast that with the programs I compiled with QuickBasic 4.5, which do work when booting with a floppy disk.

I understand that QuickBasic only produces 16-bit executables, whereas FreeBASIC only makes 32-bit executables.

Therefore, do my FreeBASIC programs really work under plain old DOS? Or do I need to worry about including some type of "extender" in the programs I distribute?

FreeBASIC for DOS is based upon DJGPP v2 (2.04 libc plus their ports of GNU BinUtils), which is "DPMI only" (386+). A separate DPMI server is normally not needed if you run in an environment (like 32-bit Windows or 32-bit OS/2 or DR-DOS 7.03) that already has one available and active. If for some reason one isn't found, the stub tries (by default) to run CWSDPMI.EXE. Only if it can't find that file nor anything else will it complain. There is no separate "extender" anymore because all of that goop is built into the libc. It's pure DPMI (0.9), which is a standard, which was actually invented by and for Windows 3.0 back circa 1990, meant to be a better replacement to VCPI (which was an extension of EMS). DPMI always requires either a 286 or 386. DJGPP is 386+ only. It uses COFF (but not PE/COFF), which is loaded by the small default MZ stub, hence why its .EXEs can be much larger than the normal 16-bit DOS MZ limit.

The Windows DPMI server (DOSX.EXE) isn't active under raw DOS. So you have to use something else. The default mentioned in the DJGPP v2 stub is CWSDPMI.EXE, current at version "r7" circa 2010. You can grab this from any DJGPP mirror under /current/v2misc/csdpmi7[bs].zip . If you are worried about distributing a self-contained .EXE, that's easy to fix. Normally, under DJGPP, you run "exe2coff myprog.exe", then "copy /b cwsdstub.exe + myprog blah.exe", and then "blah.exe" will be what you redistribute. Though keep in mind that "most" users already know this and prefer to only have a single instance of a separate TSR (CWSDPMI.EXE) instead of always binding a 20 kb stub to each .EXE. IIRC, the stub version was first supported in r5 back in 2000. Other DPMI servers exist too, either as TSR or built-in stub or both, e.g. PMODE/DJ, HDPMI32, D3X, WDOSX.

EDIT: Typo.

[rugxulo]

IIRC in the go32 distribution (the extender from DJGPP), there is a cwsdpmi.exe which is a minimal dpmi provider for plain dos.

You might also need to load himem.sys, and maybe you also need go32.exe

IIRC win9x doses load himem.sys by default, so it might be a matter of putting cwsdpmi.exe in your PATH so that the exe can find it.

DJGPP doesn't use an external extender (GO32.EXE) anymore. It hasn't since v1, which was circa 1994. Even Quake 1 (circa 1996) used a beta version of v2 (2.0.0 beta 3) and old CWSDPMI r1. Ever since 1996 when v2 (2.0) was released, it's been strictly DPMI only. Latest /current/ (stable) is 2.03p2 and /beta/ is 2.04 (which is what FBC uses). Actually, FBC uses a newer improved 2.04 from CVS, since that was never finalized, so it's really something like 2.04++. But more or less we just call it /beta/ 2.04.

DJGPP's development package (DJDEV*.ZIP) doesn't come with any DPMI host included. All it has is C headers and libraries (libc, libm) and a few secondary tools. CWSDPMI is available separately in /current/v2misc/ , as already mentioned. There is GO32-V2.EXE, but that isn't needed in 99% of cases (and even then still calls CWSDPMI). Just to be clear: you don't need any GO32*.EXE files for FBC at all.

CWSDPMI is a TSR that provides the DPMI API in pure DOS (which normally doesn't support it by default). Some environments have their own DPMI server, which you can't override, e.g. DOSEMU or FreeDOS-32 or NTVDM or similar. But pure DOS has nothing, so you have to have a separate util to provide it. It uses whatever is available behind the scenes to emulate DPMI. No, you don't always need XMS (HIMEM.SYS) at all. In fact, most so-called "DOS extenders" can support (usually) raw (no memory managers), XMS (HIMEM.SYS or equivalent), VCPI (aka, EMM386), and/or DPMI (usually CWSDPMI). There are a few tradeoffs and quirks related to each, though. But usually it should (in theory) "just work" with any setup.

Yes, you can put CWSDPMI.EXE in your %PATH%, and the DJGPP stub will find it. Or you can put it locally in the same subdir as your program, and that one will be preferred to all others. Usually that's a bad idea, though, as older versions have bugs, and sometimes the program won't run because of that (e.g. M3/PC '96 on my 6 GB desktop chokes with old buggy r3).

Actually, part of the problem may be that FreeBASIC's DOS distribution doesn't seem to come with CWSDPMI.EXE at all. I guess they figured everybody already knew where to find it (which I normally agree with, but I guess we've proved that isn't always the case).

[rugxulo]

Windows ME isn't quite the same as either Windows 98 or 95 in that regard. Those both have the option of restarting the computer in DOS mode, and therefore the possibility of adjusting the Autoexec.bat and the path.

Not so with Windows ME. The only way to get to DOS is booting from floppy disk, and even then, you basically have to do everything yourself... because the autoexec.bat in the root directory is only for looks, and doesn't actually do anything. Windows ignores it. If you need to change the path it has to be done in windows by running Msconfig. This is a particular Windows ME issue, which I don't believe is shared by the earlier 9x versions. It makes running DOS more difficult in this case. Then again, I could just copy the csdpmi file into the Windows directory. (I will try doing this.)

As far as Microsoft is concerned, DOS is obsolete. ME was the last version to be based upon it. Everything since (esp. XP for home users) was fully 32-bit NT-based. Hence all you get is a (slightly buggy, or worse in newer versions) NTVDM. A few months ago, on my Win7 64-bit, I did make a system bootable floppy via Explorer, which has MS-DOS (from ME) on it, but it's not complete and you can't install (no SYS). That's as close as you'll find it these days (outside of 32-bit editions NTVDM, which I know is very buggy even compared to XP). Honestly, IMHO, the best way to run DOS is probably FreeDOS (via RUFUS on USB) these days. Either that or dual boot with a separate bootable FreeDOS/FAT32 partition. Or use emulators (QEMU, VirtualBox, etc).

I'm not sure what "copy the csdpmi file into the Windows directory" means. You can't use CWSDPMI in Windows, only their native (buggy) DPMI host. In pure DOS, perhaps you're putting your Windows (system?) directory in your %PATH%? I wouldn't really copy CWSDPMI.EXE there, personally, but I guess it's not the end of the world.

Anyways, I will track down that csdpmi file and give it a shot for the fun of it.

I guess I'm not worried about it, as it seems my FreeBASIC compiled programs work totally fine under Win9x. And if anybody is actually working with something older, I can merely point them to the csdpmi file.

Rather than messing with any autoexec file, I might just make a batch file that loads the csdpmi before it's loads my program. Might be easier that way for people using my program. Simply have them start a "runme.bat" type of thing.

That's assuming csdpmi works that way? What's the deal with DOS4GW? Is that the same type of thing, or they similar?

You don't need RUNME.BAT at all. The DJGPP stub (also used by FBC) automatically tries to load (by default) CWSDPMI.EXE if no other DPMI host is detected. You just run "myprog" and it will take care of everything, assuming CWSDPMI.EXE is in the current dir or somewhere on your %PATH%. If that isn't good enough, bind CWSDSTUB.EXE to it. The only reason to run it manually is if you want to set some options, e.g. "lh cwsdpmi -p -s-" to load permanently (thus avoiding having to manually load and unload itself upon every program execution, which is faster but less safe) and disable swapping (which I don't recommend). You could also try third-party "hdpmi32" (single session) or "hdpmi32 -r" (permanently) from Japheth's HX. I'm just mentioning that for completeness, you don't really need it. The point is that you can mix and match different DPMI servers if desired or truly needed, which is rare.

DOS/4GW.EXE 1.97 is the ancient freeware (royalty free) DOS "extender" (using non-standard int 21h etc. extensions required by Watcom .EXEs). OpenWatcom still comes with it (and a few others) these days. It's quite old and bloated and limited and has no sources, hence the various replacements (e.g. DOS/32A, which is recommended by DOSBox dudes for old games). It is not a DPMI server, and thus you can't really mix and match DJGPP stuff with it since DJGPP is DPMI only. Also, OpenWatcom uses the LE format while DJGPP uses COFF, so they are totally incompatible .EXE formats.

There are "extenders" that (separately) support both DJGPP and Watcom .EXEs, but usually it just means a separate "stub" for each (e.g. WDOSX or D3X). HDPMI32 has (unofficial) "int 21h extensions", so it supports both. CWSDPMI has no such buggy extensions, it's DPMI only, so it's not useful for Watcom stuff.

Long story short, DOS/4GW isn't what you're looking for here. FBC and DJGPP don't (and can't) use it.

[rugxulo]

I got it to work when booting from floppy!

All I had to do was copy the CWSDPMI.EXE to the same folder as my program. Easy as that :-)

http://www.delorie.com/djgpp/dl/ofc/sim ... pmi5b.zip/

I know I'm beating this into the ground here, but just for completeness ....

For the record, like I said, latest is r7 from 2010. This is the version currently promoted by DJGPP's Zip Picker, thus available on its mirrors. (r5 from 2000 was most popular for a long time but has a few bugs and lacks, comparatively.) There is a separate CWSDPMI home page as well. There are also various FAQs and other resources which might prove interesting if you're still curious.

http://www.delorie.com/djgpp/zip-picker.html
http://homer.rice.edu/~sandmann/cwsdpmi/index.html

http://www.delorie.com/djgpp/v2faq/
http://www.freebasic.net/wiki/wikka.php?wakka=FaqDOS

http://www.delorie.com/djgpp/doc/dpmi/
http://www.delorie.com/djgpp/doc/rbinter/
ftp://ftp.lanet.lv/pub/mirror/x2ftp/msd ... index.html

http://na.mirror.garr.it/mirrors/djgpp/deleted/v1/
http://na.mirror.garr.it/mirrors/djgpp/current/v2/
http://na.mirror.garr.it/mirrors/djgpp/beta/v2/

https://groups.google.com/forum/#!forum ... sdos.djgpp
http://www.delorie.com/djgpp/mail-archi ... pp-workers
http://www.ludd.luth.se/~ams/djgpp/cvs/

N.B. Sorry again for such lengthy posts, and I'm not a core developer for any of these, just an enthusiast. :-)

[marcov]

There is no separate "extender" anymore because all of that goop is built into the libc.

(afaik 16to 32-bit initialization is part of the startup file, and mostly in assembler. Comments in the FPC version seem to indicate it is in crt0.o, not in libc.a or what's comparable to that. libc is already 32-bit. Maybe djgpp is atypical and links crt into libc)

[Aaronm82]

Thanks for the response Rugxulo, it was very informative.

It's been a long time since I've used DOS 6.22 or Windows 95/98. My only exposure to DOS nowadays is under Windows ME, either using the command-line (running "Command.com") or simply double clicking on a DOS program in Explorer. And that's about all. Been a while since I've edited an Autoexec.bat or Config.sys file, or what have you.

I was vaguely familiar with these extenders, having downloaded programs in the past that required their use, and I guess I took them for granted that they even existed. But now that I'm creating DOS programs I've had to educate myself on all this DPMI stuff.

I'm not a professional programmer, just somebody who is self-taught and has been dabbling in QBasic for a number of years off and on. Thanks to FreeBasic I've been able to compile some of my programs I made with Qbasic 1.1

Again, thanks.

[DOS386]

> Therefore, do my FreeBASIC programs really work under plain old DOS?
> Or do I need to worry about including some type of "extender" in the programs I distribute?

http://www.freebasic.net/wiki/wikka.php?wakka=FaqDOS :-)

> My only exposure to DOS nowadays is under Windows ME

Maybe you can check out FreeDOS occasionally.