Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

16-bit FPC snapshot (Announce)

posted by Rugxulo(R) Homepage, Usono, 05.09.2013, 19:37

> I may run into problems. Like dos watcom tools not running on win64 ;)

Note that I've not studied your buildfaq nor tried rebuilding FPC myself. Also, the Win32 ("XP") build apparently does not run under HX, no surprise. I guess building with older FPC that did still work (2.2.x?) is out of the question?

> I tried to do something similar for go32v2 but failed.
> The trouble is that wlib bombs out with ... [snip]

There are apparently three distinct types of .EXE in there: FPC/GO32V2/COFF (nasm and most everything), Watcom/LE (wlib,wlink), and Win32/PE (make3, not needed?).

These do not by default play well together. The problem is probably passing long cmdlines to each other, e.g. GO32V2-only "!PROXY" (via direct memory address?), which Watcom doesn't support.

Well, and the second problem is incompatible extenders (although GO32V2 is really just pure DPMI only, no DOS extensions). You can't really mix Watcom and DJGPP .EXEs without crashes unless you use "HDPMI32 -r" first or similar. (Maybe Causeway or D3X would play well too, based upon limited experience, but others like DOS/4GW and WDOSX? Not so much.)

Unlike DJGPP, Watcom output .EXEs don't by default support certain features: passing long cmdlines (response files or env. vars) or LFN support. The OpenWatcom compiler and associated select essential tools themselves do manually support passing long cmdlines (see WLIB) via '@env_var' or '@cmd_file'. You can use wmake to work around cmdline limits for some of those select tools (via env_var) if you prefix the tool with '*'. E.g., quoting from NASM's Mkfiles/openwcom.mak (which did build in pure DOS, last I checked, but only with this feature) :

CC = *wcl386

And yes, this means that you can build NASM via OpenWatcom, but like I said, that won't help you here. On Linux, allegedly (I've never tried, but so I've heard) you can bootstrap all of the tools with GCC, so maybe this problem could be indirectly solved by building WLIB and WLINK with DJGPP.

Of course, an easier solution might just involve the compiler driver writing an explicit .BAT file of what individual (non-mixed .EXE !) steps are needed to build the entire project, esp. if it uses response files only (no !PROXY via direct memory access). Not sure of what can be done already, I'm only vaguely aware of -sh and -st and similar switches.

> I tried shortening paths (not in zip) but that didn't help

%PATH% can only be approx. 128 bytes long. Actually, for DOS/4GW .EXEs (whose stub call external DOS4GW.EXE or similar extender), it might be even lower, like 126 or 122.

> Nasm sometimes also exits (run too quickly in succession, memory problems?)
> Testing was done under Windows XP.

I once encountered some oddball errors trying to run (can't remember) either DOS NASM within subshell of Win32 program or maybe vice versa. Though that's probably not an issue here.

As much as NTVDM (and v86 mode) were successful, MS just didn't keep it up, so there are some known major bugs, which can cause problems, even in (best environment) WinXP. (I don't have barely any access to XP anymore.) E.g. DOS/4GW tools sometimes hung the console for me when run under XP, sadly. (DJGPP tools work better overall, due to CWS' hacks.) Though this can't be that big a shock, even you previously said GO32V2 was only for DOS and didn't care about any known regressions under NTVDM (and such GO32V2 binaries don't run at all under DOSEMU, last I checked, dunno why).

> I uploaded the snapshot anyway for more knowledgable people.
> Note that the pp16\dopp16.bat file sets some paths for compiling, and the
> pp16\bin\i386-go32v2\pp16.bat should also be checked.
> After that it should be running pp16\dopp16.bat, changing to \pp16\demo
> and running
> pp16 fpctris
> should do the trick.

Your .BAT files aren't DOS-shell friendly anyways, they use non-portable Win32-isms:

REM pp16.bat
REM (this file doesn't have any line ending, last byte is '*')
REM ppc8086 -XX -CX -XP %*
REM normal DOS shells don't support %* (except maybe 4DOS)
ppc8086 -XX -CX -XP %1 %2 %3 %4 %5 %6 %7 %8 %9
REM if you want more than nine, you'll have to "shift" and
REM manually handle saving the parameters for later use

REM dopp16.bat
REM (thankfully does end in CR+LF, most DOS shells don't accept otherwise)
@echo off

if "%MYDRIVE%"=="" set MYDRIVE=d

Rem we save oldpath only once, so we can always revert to it.

REM if "%OLDPATH%" neq "" goto :nosave
if not "%OLDPATH%"=="" goto nosave
REM ... but then you just overwrite it? oops ...
REM ... LFNs assumed? ...
PATH %MYDRIVE%:\pp16\bin\i386-go32v2;%MYDRIVE%:\pp16\binw;%PATH%
REM ... expect user to manually restore OLDPATH later?


Complete thread:

Back to the forum
Board view  Mix view
15112 Postings in 1359 Threads, 247 registered users, 15 users online (0 registered, 15 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum