DOS ain't dead

I've uploaded a new hx release: http://www.japheth.de/dwnload4.html

For the "end-user" there are no big changes visible. Most tools of the new PellesC v5.0 (including PoASM) should run now (PoLink v5 still doesn't), though.

In hxdev there were more changes, the samples have been extended and there are now some - for MSC, OW and CC386 - showing how to statically link the Win32 emulation to a DOS binary. Also, a new stub for PE binaries has made the MZ support obsolete.

---
MS-DOS forever!

> Also, a new stub for PE binaries has made the MZ support obsolete.

What does this mean? Is it important for ming32 binaries?

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

> I've uploaded a new hx release:

Thanks You're great ...

> For the "end-user" there are no big changes visible.



> PellesC v5.0 (including PoASM) should run now

Will retest Could you please drop a few words about what pieces of HX it can compile, and how (Win-Inc required ?) ?

> PoLink v5 still doesn't

There is VALX ... but does it support COFFee also ?

> Also, a new stub for PE binaries has made the MZ support obsolete.

Great ...

               size   supports  PE-loader    HDPMI     cwsdpmi
  Name         in kB    dlls?   included?  included?  compatible?
 ----------------------------------------------------------------------
  DPMIST32.BIN  0.5      yes       no         no         no
  LOADPE.BIN    1.25      no      yes         no         yes
  LOADPEX.BIN   35        no      yes        yes         yes
  DPMILD32.BIN  14       yes      yes         no         no
  HDLD32.BIN    48       yes      yes        yes         no

Also DPMIST32.BIN has the "10h-bug" fixed and is optimized ... my port was NOT waste of time only

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Also, a new stub for PE binaries has made the MZ support obsolete.
>
> What does this mean? Is it important for ming32 binaries?

No. "obsolete" is the opposite of "important"

---
MS-DOS forever!

>                size   supports  PE-loader    HDPMI     cwsdpmi
> Name         in kB    dlls?   included?  included?  compatible?
> ----------------------------------------------------------------------
> DPMIST32.BIN  0.5      yes       no         no         no
> LOADPE.BIN    1.25      no      yes         no         yes
> LOADPEX.BIN   35        no      yes        yes         yes
> DPMILD32.BIN  14       yes      yes         no         no
> HDLD32.BIN    48       yes      yes        yes         no

I did some test with MSVC RTLs. Both MSVC TK 2003 and VC++ Express 2005 need dll support, so it won't work to use LOADPE(X).BIN and link the Win32 code statically (both run with DPMILD32, though). OTOH, MSVC V6 and V5 do work with LOADPE(x).BIN.

> Also DPMIST32.BIN has the "10h-bug" fixed and is optimized ... my port was
> NOT waste of time only

No, it was appreciated. There is now some free space in the stub, but it might be too small to skip the "overlay" loading and load dpmild32.exe manually. Perhaps if the "insufficient memory" test is skipped as well ... it's not really needed, this test can be done by DOS itself.

---
MS-DOS forever!

> I did some test with MSVC RTLs. Both MSVC TK 2003 and VC++ Express 2005
> need dll support, so it won't work to use LOADPE(X).BIN and link the Win32
> code statically (both run with DPMILD32, though). OTOH, MSVC V6 and V5 do
> work with LOADPE(x).BIN.

VC Toolkit 2003 works with LOADPE after a slight modification. Here's a version of FTE (v0.49.13), created with HXDEV and VC TK 2003, linked with LOADPEX.BIN. Result is a nice and small stand-alone DOS binary, which uses a true flat memory model and therefore will give you a much better feeling than the DGPJJ one:

http://www.japheth.de/Download/fte-hx.zip

---
MS-DOS forever!

> Could you please drop a few words about what pieces of HX it can compile, and how (Win-Inc required ?) ?

it can assemble 2 of the samples in HXDEV.

Hope this helps!

---
MS-DOS forever!

> VC Toolkit 2003 works with LOADPE after a slight modification. Here's a
> version of FTE (v0.49.13), created with HXDEV and VC TK 2003, linked with
> LOADPEX.BIN. Result is a nice and small stand-alone DOS binary, which uses
> a true flat memory model and therefore will give you a much better feeling
> than the DGPJJ one:
>
> http://www.japheth.de/Download/fte-hx.zip

There is a newer version (0.50.1), however, compiled from CVS (by DJGPP, heh), if you want the latest / greatest: FTE 0.50.1 for DOS/DJGPP

---
Know your limits.h

> > what pieces of HX it can compile, and how (Win-Inc required ?) ?
> it can assemble 2 of the samples in HXDEV.
> Hope this helps!

2 of the 3 MASM samples ?

I had hoped for PESTUB of the emulation DLL's but it lacks those INC files

> Most tools of the new PellesC v5.0 (including PoASM) should
> run now (PoLink v5 still doesn't), though.

POASM starts ... and successfully runs through some sources and reports 1'000'000's of bugs also POLINK starts ... but I can't really challenge it to find out what exactly doesn't work

Yeah ... HX 2.14 is great ... no regressions found, many "kernel"-bugs fixed:

another PIT timer fix. Now the timer counter is just read again
if a wrap occured during the read.

The famous PITfall of the PIT

Dysfunctional "fix" with corrupting MZ header of DPMIST32.BIN reverted

bugfix: cursor movement might have polluted screen.

Very old bug

There are OTOH a few bugs and problems not yet fixed ... I might report and re-report them occasionally

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> There is a newer version (0.50.1), however, compiled from CVS (by DJGPP,
> heh), if you want the latest / greatest:
> FTE 0.50.1 for
> DOS/DJGPP

Thanks for this hint, but the purpose of my post wasn't to provide another "fantastic" and "most up-to-date" DOS editor, but to prove

- that VC TK 2003 works with - slightly modified - HXDEV 2.14.
- that linking with HX's static Win32 code works for real-life apps as well, not just artificial samples.
- that DGPJJ is inferior and heavily bloated compared to MSVC. The VC binary is just 510 kB and includes a 34 kB DPMI host, while the original DGPJJ binary is 680 kB without DPMI host.

---
MS-DOS forever!

> Thanks for this hint, but the purpose of my post wasn't to provide another
> "fantastic" and "most up-to-date" DOS editor, but to prove
>
> - that VC TK 2003 works with - slightly modified - HXDEV 2.14.

Yes, good to know (even if I don't use it, and it's reputedly a huge download).

> - that linking with HX's static Win32 code works for real-life apps as
> well, not just artificial samples.

Very good to know!

> - that DGPJJ is inferior and heavily bloated compared to MSVC.

Depends on how the DJGPP one was compiled. It probably still has everything enabled (e.g., globbing, env. file) as well as support for response files, LFN support, POSIX support, etc. And the default DJGPP libc.a library was compiled with -O2 (which is not optimized for size).

> The VC binary is just 510 kB and includes a 34 kB DPMI host, while
> the original DGPJJ binary is 680 kB without DPMI host.

The old 0.49.13 DJGPP binary is actually 687,616 bytes (unpacked) while the 0.50.1 DJGPP binary is UPX'd (by UPX 2.03, so that means it could be even smaller with later version's LZMA!): 307,788 bytes (825,856 bytes unpacked). It'd be even larger if compiled via DJGPP 2.04 (much better symlink support). It's not that you can't decrease the size, it's just that nobody does out of convenience, indifference, ignorance, etc. (Really, only us bootable floppy users can really be affected. Everybody else has plenty of space, heh.)

Japheth wrote in other thread:

> (the superior, fine and free MS VC 2003 Toolkit for example)...

Really ? For what use ? Just want to be safe, King Hutch wrote:

> Legality is not a negotiable matter

Japheth wrote:

> Thanks for this hint, but the purpose of my post wasn't to provide another
> "fantastic" and "most up-to-date" DOS editor, but to prove
> - that VC TK 2003 works with - slightly modified - HXDEV 2.14.

YES.

> - that linking with HX's static Win32 code works for real-life apps as
> well, not just artificial samples.

YES.

> - that DGPJJ is inferior and heavily bloated compared to MSVC. The VC
> binary is just 510 kB and includes a 34 kB DPMI host, while the original
> DGPJJ binary is 680 kB without DPMI host.

1. You forgot to boast that your binary is 510 BEFORE UPX'ing

2. It indeed starts in DOS and does something ... but either it's unusable or I don't know how to use it ... same as with the D port

3. The D guys should notice this

4. For me, still, the only 2 usable editors are KINESICS (requires HX) and INFOPAD (minor bugs left). Even both FASM IDE's failed my S&R tests

5. Maybe you could also port/hack also KINESICS this way ? It couldn't "directly" compete against a D port since there is none, but it could compete against all the buggy / premature "DOS" editors compiled with D ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Really ? For what use ? Just want to be safe,

the EULA of VC TK 2003 is significantly better than the one included in "free" MASM. No limitation as far as the type of binary you create with it is concerned.

> King Hutch wrote:

I think you should read some of the insanities in

http://www.masm32.com/board/index.php?board=6.0

first before citing things from that source.

> 2. It indeed starts in DOS and does something ... but either it's unusable
> or I don't know how to use it ... same as with the D port

please provide a detailed bug report! I have no problems with this binary.

In fact, I use it permanently. Unlike the "release" version of FTE, created with DGPJJ, it runs stable even in NTVDM - on my machines at least.

---
MS-DOS forever!