16-bit FPC snapshot (Announce)
> > 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?
Yes. But note that I have a go32v2-i8086 crosscompiler. It just fails to compile the 8086 RTL.
> > 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?).
Yes, make3 is unused. I tried to use it while compiling the RTL using the go32 crosscompiler. I solved that by using a win32-crosscompiled RTL.
> 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.
go32v2 or DJGPP libc?
Anyway, your problem descriptions are more or less what I expected. There is some ! and @ in go32v2 I guess, that will probably have to be ported to call the i8086 backend files.
Since afaik nobody is working on a binwriter (internal assembler+archiver/librarian) yet, we'll probably have to do with these suboptimal solutions a while longer. (though maybe it is not as bad under pure dos as under WinXP. IIRC NTs are noticably slower to start dos binaries. It might be worthwhile testing under dosbox even)
Internal linkers are considerably more complicated, and are only secondary (wrt speed) to the internal assembler/linker. This goes doubly for Dos, since the binaries won't be big, but smartlinking is paramount.
An alternate avenue might be using some more efficient form of smartlinking supported by the nasm-watcom combination. (so that you don't have an nasm invocation per symbol)
> 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
Not really an option. That only brings in more alien tools, and the idea is too reduce them in time, not inflate them. Effort can be better spent eliminating nasm-wlink altogether.
> Of course, an easier solution might just involve the compiler driver
(I don't know what you mean with compiler driver. I know GCC is spread out over more binaries, but FPC isn't. fpc.exe could be seen as a driver, but it is more something for make and to have multiple compiler versions and architectures (crosscompilers) in the path. It doesn't contain real functionality (like relating to compiling/assembling/linking))
> 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.
Yes, in the compiler there used to be support for that (-al/-s) before most targets got the binwriter. (-al/-s<x> etc). Worth a try. Still doesn't solve wlib though (since the cmdline would be too long anyway). Will have to look it up, it is over 10 years ago that I used such kludges. (I assume the go32v2 linker still does, but that is probably pretty invariant and hidden)
> > I tried shortening paths (not in zip) but that didn't help
>
> %PATH% can only be approx. 128 bytes long.
(I thought LFN api under windows allowed 255 char limits? Maybe the lfn driver under pure dos too?)
> > 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.
That's pretty why I posted the whole lot here, hoping sb could try to compile in pure dos.
> 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.
Well. Under WinXP, one can use the win32 variant. It is just that I didn't have anything else to prepare the go32v2 snapshot.
> Your .BAT files aren't DOS-shell friendly anyways, they use non-portable
> Win32-isms:
They are more meant as examples and reflect my local build systems. Feel free to customize;-0
Complete thread:
- 16-bit FPC snapshot - marcov, 27.08.2013, 18:46 (Announce)
- 16-bit FPC snapshot - Laaca, 27.08.2013, 22:37
- 16-bit FPC snapshot - marcov, 28.08.2013, 20:58
- 16-bit FPC snapshot - marcov, 04.09.2013, 22:37
- 16-bit FPC snapshot - Rugxulo, 05.09.2013, 19:37
- 16-bit FPC snapshot - marcov, 05.09.2013, 21:48
- 16-bit FPC snapshot - Rugxulo, 05.09.2013, 23:52
- 16-bit FPC snapshot - Laaca, 05.09.2013, 21:51
- 16-bit FPC snapshot - marcov, 19.09.2013, 12:21
- 16-bit FPC snapshot - marcov, 05.09.2013, 21:48
- 16-bit FPC snapshot - Rugxulo, 05.09.2013, 19:37
- 16-bit FPC snapshot - marcov, 04.09.2013, 22:37
- 16-bit FPC snapshot - marcov, 28.08.2013, 20:58
- 16-bit FPC snapshot - Laaca, 27.08.2013, 22:37