Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
marcov(R)

20.11.2011, 17:07
 

32-bits dos binaries on 64-bit windows (Users)

It is probably already known, but just to make sure here an observation I just made:

On my vista/64 workstation, I was decrunching some old dos archives, and these are compressed using the "quantum" (.q) compressor. The archive is available on garbo.

The archive contains two programs. A dos program, and a windows compressor I had some hopes for. The windows program (QWIN, NE, so older win16) failed, and just to be sure I ran the dos version, and it RAN.

File identifies them as
32RTM.EXE: MS-DOS executable, MZ for MS-DOS
DPMI32VM.OVL: MS-DOS executable, MZ for MS-DOS
PAQ.EXE: PE32 executable for MS-DOS, 32rtm DOS extender Intel 80386 32-bit
QUANTUM.DOC: ASCII English text, with CRLF line terminators
QWIN.EXE: MS-DOS executable, NE for MS Windows 3.x
READ.ME: ASCII English text, with CRLF line terminators
UNPAQ.EXE: PE32 executable for MS-DOS, 32rtm DOS extender Intel 80386 32-bit
WINDPMI.386: MS-DOS executable, LE executable for MS Windows (VxD)

So they are PE32, but for dos, probably of Borland (C++?) origin, and they run on win64.

RayeR(R)

Homepage

CZ,
20.11.2011, 17:41

@ marcov

32-bits dos binaries on 64-bit windows

Interesting, but it makes some sense. The PE part seems to be like win32 console app and RTM extender allows it ro run under DOS like HXDOS. But there muse be some 16bit stub that loads RTM extender so I wonder in run under win64 without NTVDM.

Maybe it would be possible to modify other stubs for 32bit DOS compilers (DJGPP and OWC and maybe others) to be compatible with win64.

---
DOS gives me freedom to unlimited HW access.

marcov(R)

20.11.2011, 17:42

@ RayeR

32-bits dos binaries on 64-bit windows

> Interesting, but it makes some sense. The PE part seems to be like win32
> console app and RTM extender allows it ro run under DOS like HXDOS. But
> there muse be some 16bit stub that loads RTM extender so I wonder in run
> under win64 without NTVDM.

That might be in the 16-bit code that in normal PE32 bins shows "This program requires microsoft windows to run" or something like that.

As for DJGPP, the 32-bit code must be fully running windows programs. It seems more that the RTM.EXE is something like wdosx or Japeth's HX* PE loader.

RayeR(R)

Homepage

CZ,
20.11.2011, 17:44

@ marcov

32-bits dos binaries on 64-bit windows

> That might be in the 16-bit code that in normal PE32 bins shows "This
> program requires microsoft windows to run" or something like that.

You're right. Also Japheth has some tool to modify win32 apps stub to automadically load HXDOS... Windows skip this.

---
DOS gives me freedom to unlimited HW access.

Rugxulo(R)

Homepage

Usono,
23.11.2011, 04:21

@ marcov

32-bits dos binaries on 64-bit windows

> It is probably already known, but just to make sure here an observation I
> just made:
>
> On my vista/64 workstation, I was decrunching some old dos archives, and
> these are compressed using the "quantum" (.q) compressor. The archive is
> available on garbo.

http://en.wikipedia.org/wiki/Quantum_compression

> The archive contains two programs. A dos program, and a windows compressor
> I had some hopes for. The windows program (QWIN, NE, so older win16)
> failed, and just to be sure I ran the dos version, and it RAN.
>
> So they are PE32, but for dos, probably of Borland (C++?) origin, and they
> run on win64.

PE is just an .EXE header, COFF is just an object format, Win32 is just an API. So yeah, any OS can mix and match those, and several have indeed used them. I'm not sure why you're surprised. Maybe you forgot, or maybe just the fact that it existed circa 1995 is impressive. Remember that backwards compatibility is usually due to easier transitions, tool reuse, etc. Nothing is born in a vacuum, so they try to reuse things as much as possible (e.g. 16-bit real mode compiler tools -> 16-bit pmode). Dunno why NT uses COFF, perhaps because of its architect's VMS history.

Remember EMX? It combined DOS (MZ) and OS/2 (LX) into one "family mode" (?, blended?) .EXE. (Not the same as two separate .EXEs bound together a la [DOS MZ] "STUB=blah.exe" in *.def.) And RSX.EXE was the DPMI/DOS "extender" that let it run when VCPI or raw wasn't available (e.g. Win 3.1 / 386 Enhanced mode). That guy (Rainer S.) also made RSX/NT, which was DOS + WinNT (instead of OS/2). This was all before Cygwin and MinGW got stable and popular, of course. It basically used DJGPP (COFF) "host" with a few extra things to "cross" compile for Win32 target. I think it was also a way of overcoming LFN issues in NT 4.0 (or such), since that didn't have LFNs for DOS (yet). (There's some old GCC built with that too, on Hobbes also, IIRC.)

My 7zdecode package includes an RSX/NT .EXE, which will run in either DOS (w/ RSX.EXE + CWSDPMI.EXE) or Win32/Win64 (w/ a few of his .DLLs). Unlike 32RTM, RSX/NT is open source, so you can take a look if super curious (doubt it).

Rumor has it that early Delphi beta had support for dual DOS / Win32, but they removed that at the last minute for unknown reasons. No idea about BCC itself, 5.01 had DOS support (with optional PowerPak?), but 5.5 was exclusively Win32 (though with relocations). WDOSX (PE-based DOS extender) worked with Delphi up through 6 (?) and BC55 because of that.

So I guess the moral of the story is that DOS extenders (and esp. DPMI circa 1989) first introduced 386 software to the masses, OS/2 was the big 286 behemoth, but Win95 was when 32-bit became ubiquitous. Linux or *BSD will probably claim first to support AMD64 (decently). Unfortunately, you can't use 64-bit stuff in 32-bit mode, sadly.

P.S. Nowadays, it's probably just easier to use bytecode or raw scripting files across platforms.

Marton(R)

17.12.2011, 04:12

@ Rugxulo

32-bits dos binaries on 64-bit windows

Awesome explanation, Rugxulo! That IS knowledge. Worth the read.

Arjay(R)

05.05.2012, 20:06

@ Rugxulo

32-bits dos binaries on 64-bit windows - Delphi for DOS

> Rumor has it that early Delphi beta had support for dual DOS / Win32, but
> they removed that at the last minute for unknown reasons.

See: Merlyn: Delphi for DOS + hitekev.com: Creating Turbo Pascal files for DOS using DCC.EXE

Rugxulo(R)

Homepage

Usono,
06.05.2012, 00:40

@ Arjay

32-bits dos binaries on 64-bit windows - Delphi for DOS

Also see ye olde "DWPL" (Delphi WDosx Project Library) pages (etc):

http://dwp42.org/dwp/en/index.htm

http://sourceforge.net/projects/dwpl/files/dwpl/2.6.0/

Laaca(R)

Homepage

Czech republic,
06.05.2012, 08:52

@ Arjay

32-bits dos binaries on 64-bit windows - Delphi for DOS

Modifying Delphi 1 for DOS is not trivial.
However two year ago I did it and put on my site.
Download package from here: http://www.laaca.borec.cz/soubory/delphdos.rar

---
DOS-u-akbar!

Arjay(R)

06.05.2012, 12:02

@ Rugxulo

32-bits dos binaries on 64-bit windows - Delphi for DOS

> Also see ye olde "DWPL" (Delphi WDosx Project Library) pages (etc):
>
> http://dwp42.org/dwp/en/index.htm
> http://sourceforge.net/projects/dwpl/files/dwpl/2.6.0/

Thanks for other links. Personally as I mostly use DOS targeted compilers to generate DOS programs rather than cross-compiling with the exception of some of my own test compilers; I have never bothered to try these Delphi tricks.

However this discussion re DOS compatibility and the RTM discusson made me think about issues like compiler availability for others and compatibility issues.

e.g. Yesterday out of passing interest related to the above I took a look at the Swallow Pmode DOS extender and realised I could easily eliminate its use of OBJECTS.PAS for PtrRec/swallow.drv loading using my own unreleased equivalents - if I released some internal source or compiled a replacement TPU. I also realised that I could also provide the ability to not need swallow.pas under Pascal to use of any external files.

However personally I have no current need for any of this myself and I also have a desire pickup work on my major project (RJDOS) into which I'm rolling a lot of stuff. [On that note I want to release the now 2 year old v0.01d]

So in terms of thinking of solutions for others I tend to ask myself:
1)Someone probably has already done it but I am personally unaware as I've not needed it. Do I want to invest time looking into existing options etc?
2)If no solution, is there still demand if I was to invest time on this?
3)What would others want in an ideal world? e.g. which replacment extender?
etc

Back to the board
Thread view  Mix view  Order
15108 Postings in 1358 Threads, 246 registered users, 14 users online (0 registered, 14 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum