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)

15.03.2014, 21:55
 

FPC 2.6.4 released! (Announce)

New version. This is the last of a fixes branch, so little work done on the compiler. Most work done on db units.

No Dos specific details known atm (except that there is a dos released).

Hopefully the next release we have two DOS targets :-)

--------------------------
FPC 2.6.4 has been released! Free Pascal 2.6.4 is a point release from the 2.6.0 fixes branch.

Some highlights are:

Packages:
Lots and lots fixes and improvements for fcl-db
web and json packages synchronized.
improvements to the chmcmd compiler.
Several fixes for winunits (and winceunits)
Documentation:
Many additions
fpjson documented

See the changelog for the list of reported bugs which have been fixed in this release.

Downloads are available from the download page (mirrors should follow soon).

Some archives are still being uploaded

A list of changes that may require changes to existing code is also available.

ron(R)

Homepage E-mail

Australia,
15.03.2014, 23:27

@ marcov

FPC 2.6.4 released!

Link for DOS version:

http://www.freepascal.org/down/i386/go32v2.var

Rugxulo(R)

Homepage

Usono,
17.03.2014, 08:14

@ ron

FPC 2.6.4 released!

> Link for DOS version:

Mirrored to iBiblio (well, not everything, only the obvious choices).

Rugxulo(R)

Homepage

Usono,
17.03.2014, 08:39

@ marcov

FPC 2.6.4 released!

> New version. This is the last of a fixes branch, so little work done on the
> compiler. Most work done on db units.
>
> No Dos specific details known atm (except that there is a dos released).

Better than nothing, so thanks (to whomever, presumably you and Tomas Hajny).

> Hopefully the next release we have two DOS targets :-)

Dunno, haven't looked at snapshots since our fpctris kludge last September. A quick glance (but no testing) only shows a Win32 ppcross386.exe build and three (!) i8086 compilers, one for each memory model (eh??).

> --------------------------
> FPC 2.6.4 has been released! Free Pascal 2.6.4 is a point release from the
> 2.6.0 fixes branch.

The IDE shelling out / compile + run bug seems fixed. Context-sensitive help via CHM still works (once added), which is better than a billion .HTML files. Forgot to check about DiskFree on FAT32.

I guess the real test is what Laaca thinks of this release! :-P

marcov(R)

17.03.2014, 09:54

@ Rugxulo

FPC 2.6.4 released!

> > No Dos specific details known atm (except that there is a dos released).
>
> Better than nothing, so thanks (to whomever, presumably you and Tomas
> Hajny).

I think Pierre, Tomas, me. In that order. Tomas and I keep tabs on what happens with dos somewhat, Tomas a bit more since sfn issues etc are shared with OS/2 that he maintainers.

Pierre does the bulk of the work.

> > Hopefully the next release we have two DOS targets :-)
>
> Dunno, haven't looked at snapshots since our fpctris kludge last September.
> A quick glance (but no testing) only shows a Win32 ppcross386.exe build and
> three (!) i8086 compilers, one for each memory model (eh??).

Yes, I chatted with that with Nikolay and he was aware of the issue. Unless sb knows watcom tools linked with djgpp, we are stuck with crosscompiling.

Sb mentioned running the crosscompiler with HX as an option to.

> The IDE shelling out / compile + run bug seems fixed.

> Context-sensitive
> help via CHM still works (once added), which is better than a billion .HTML
> files.

(for that latter thing I do take partial credit, together with Andrew of course)

> Forgot to check about DiskFree on FAT32.
> I guess the real test is what Laaca thinks of this release! :-P

Certainly. And since major versions usually cause upheaval that breaks minor platforms, I hope this one is worthwhile enough to last a while.

There will be a beta for the major version (2.8.0 it is going to be I think) though.

P.s. Nikolay says he has started larger memory model support, but that is going to take a while

Rugxulo(R)

Homepage

Usono,
19.03.2014, 11:48

@ marcov

FPC 2.6.4 released!

> > > No Dos specific details known atm (except that there is a dos
> released).
> >
> > Better than nothing, so thanks (to whomever, presumably you and Tomas
> > Hajny).
>
> I think Pierre, Tomas, me. In that order. Tomas and I keep tabs on what
> happens with dos somewhat, Tomas a bit more since sfn issues etc are shared
> with OS/2 that he maintainers.
>
> Pierre does the bulk of the work.

Dunno who does what. I don't even really read the online mailing list archives regularly.

> > > Hopefully the next release we have two DOS targets :-)
> >
> > Dunno, haven't looked at snapshots since our fpctris kludge last
> September.
> > A quick glance (but no testing) only shows a Win32 ppcross386.exe build
> and
> > three (!) i8086 compilers, one for each memory model (eh??).
>
> Yes, I chatted with that with Nikolay and he was aware of the issue. Unless
> sb knows watcom tools linked with djgpp, we are stuck with crosscompiling.

1). Extenders must play nice (or else have yet another neutral front end / driver, maybe called from real mode??), I think Causeway would maybe cooperate okay.
2). LFNs are a problem too, but at least Japheth's forked tools (JWlinkd, JWlibd) support that, IIRC. (Otherwise we need another kludge. But see #5 below, maybe problem is already solved??)
3). Long cmdlines are a problem, my workaround was to manually "dir /b fpctris.sl\*.o > fpctris.rsp" and manually use response files (this is in lieu of DJGPP handling it for you behind the scenes), otherwise wildcard support or similar needs to be added to the Watcom tools ... if FPC generated such response files automatically, it would avoid the issue.
4). I'm quite skeptical about honestly getting Wlink / JWlink etc. to build with DJGPP, even though it probably builds with GCC on Linux. At least JWasm used to claim to build with DJGPP, but the others I dunno. I doubt Japheth (or OW devs) care enough to waste time on this.
5). I've not kept up with OpenWatcom development. See unofficial (?) GitHub or 2.0-pre SourceForge builds (even DOS!). Maybe they work better, dunno.

> Sb mentioned running the crosscompiler with HX as an option to.

When I tried last in September, it didn't work. (Though who knows, maybe it was my error.) Since 2.2.x supposedly used to run on HX, I naively guess FPC upstream has added too many XP APIs that aren't supported. But I'd have to try again. In other words, unless somebody explicitly tries this and succeeds, I just assume that's not going to work at all. Again, I doubt Japheth cares enough to waste time fixing this.

The current FPC snapshot says (ppcross386 -iD) 2014/02/05 but -iSO and -iTO both say "win32". A weak try (atop Win7 64-bit) to compile fpctris (-Fuunits/go32v2/rtl) says, "PPU is compiled for another target".

> > The IDE shelling out / compile + run bug seems fixed.

Haven't tried the built-in debugger, that's what I always associated Pierre with, mainly (for good or bad).

> > Context-sensitive
> > help via CHM still works (once added), which is better than a billion
> .HTML
> > files.
>
> (for that latter thing I do take partial credit, together with Andrew of
> course)

Well, 48 MB of 13,000 files for the .HTML archive is a bit excessive!

> > I guess the real test is what Laaca thinks of this release! :-P
>
> Certainly. And since major versions usually cause upheaval that breaks
> minor platforms, I hope this one is worthwhile enough to last a while.

Dunno, probably. It's not like we have much choice in the matter, too low on manpower.

> There will be a beta for the major version (2.8.0 it is going to be I
> think) though.
>
> P.s. Nikolay says he has started larger memory model support, but that is
> going to take a while

Good luck.

P.S. I see that there is a wiki page about the DOS 8086 target now.

marcov(R)

19.03.2014, 21:28

@ Rugxulo

FPC 2.6.4 released!

> 1). Extenders must play nice (or else have yet another neutral front end /
> driver, maybe called from real mode??), I think Causeway would maybe
> cooperate okay.

Trouble is that must be weighted against modifying and validating the assembler (and linker) backend.

> 2). LFNs are a problem too, but at least Japheth's forked tools (JWlinkd,
> JWlibd) support that, IIRC. (Otherwise we need another kludge. But see #5
> below, maybe problem is already solved??)

No idea, haven't revisited. But yes it is increasingly a problem.

> 3). Long cmdlines are a problem, my workaround was to manually "dir /b
> fpctris.sl\*.o > fpctris.rsp" and manually use response files (this is in
> lieu of DJGPP handling it for you behind the scenes), otherwise wildcard
> support or similar needs to be added to the Watcom tools ... if FPC
> generated such response files automatically, it would avoid the issue.

It might with -s. It did long, long ago.

> 4). I'm quite skeptical about honestly getting Wlink / JWlink etc. to build
> with DJGPP, even though it probably builds with GCC on Linux. At least
> JWasm used to claim to build with DJGPP, but the others I dunno. I doubt
> Japheth (or OW devs) care enough to waste time on this.

I also wouldn't waste too much time switching assemblers. That can be better invested in an internal asm that is generally more stable, crossplatform, has no LFN issues etc.

> > Sb mentioned running the crosscompiler with HX as an option to.
>
> When I tried last in September, it didn't work. (Though who knows, maybe it
> was my error.) Since 2.2.x supposedly used to run on HX, I naively guess
> FPC upstream has added too many XP APIs that aren't supported.

The next major versions is going to be unicode. So yes. It will call -W functions pretty much exclusively (trunk, the branch with 8086) already does.

> But I'd have
> to try again. In other words, unless somebody explicitly tries this and
> succeeds, I just assume that's not going to work at all. Again, I doubt
> Japheth cares enough to waste time fixing this.

So I assume that means that HX is not long term viable anyway, ok, option dropped.

> The current FPC snapshot says (ppcross386 -iD) 2014/02/05 but -iSO and -iTO
> both say "win32". A weak try (atop Win7 64-bit) to compile fpctris
> (-Fuunits/go32v2/rtl) says, "PPU is compiled for another target".

FPC compilers are per architecture. So any 32-bit x86 compiler can generate go32v2 code. The target OS can be changed with -T.

But for 16-bit you need a 16-bit arch compiler

> > > The IDE shelling out / compile + run bug seems fixed.
>
> Haven't tried the built-in debugger, that's what I always associated Pierre
> with, mainly (for good or bad).

True. It seems that the debugger was left out, and he was planning to upload an add-on package to fix that.

> > > Context-sensitive
> > > help via CHM still works (once added), which is better than a billion
> > .HTML
> > > files.
> >
> > (for that latter thing I do take partial credit, together with Andrew of
> > course)
>
> Well, 48 MB of 13,000 files for the .HTML archive is a bit excessive!

If I test plain dos, I do so on a P-II 233. The extracting of such archive is enlightening :_)

Rugxulo(R)

Homepage

Usono,
20.03.2014, 04:24

@ marcov

FPC 2.6.4 released!

> > 1). Extenders must play nice (or else have yet another neutral front end
> /
> > driver, maybe called from real mode??), I think Causeway would maybe
> > cooperate okay.
>
> Trouble is that must be weighted against modifying and validating the
> assembler (and linker) backend.

That sounds like tons more work (esp. internal linker) than just fixing a few things "as is".

> > 2). LFNs are a problem too, but at least Japheth's forked tools
> (JWlinkd,
> > JWlibd) support that, IIRC. (Otherwise we need another kludge. But see
> #5
> > below, maybe problem is already solved??)
>
> No idea, haven't revisited. But yes it is increasingly a problem.

I know this isn't top priority. But, as is, I'd suggest:

1). drop DOS4GW in lieu of CWSTUB (aka Causeway, which mostly cooperates okay with GO32v2 extender, I think?)
2). use Japheth's forked tools: JWlib, JWlink (LFN support, though J- tools use his own built-in HX-derived extender, I think??)
* or maybe?? use OW 2.0-pre DOS tools snapshot (which claim to have fixed the lack of LFN support)
3). modify FPC to generate response files automatically instead of super long cmdlines

> > 4). I'm quite skeptical about honestly getting Wlink / JWlink etc. to
> build
> > with DJGPP, even though it probably builds with GCC on Linux. At least
> > JWasm used to claim to build with DJGPP, but the others I dunno. I doubt
> > Japheth (or OW devs) care enough to waste time on this.
>
> I also wouldn't waste too much time switching assemblers. That can be
> better invested in an internal asm that is generally more stable,
> crossplatform, has no LFN issues etc.

No, I know that, I meant that JWasm was the only tool that 100% claimed to support being bootstrapped itself with DJGPP (see JWasm211as.zip's GccDos.mak). I've not noticed nor heard any attempt for other tools, though. I don't recommend replacing the assembler (esp. since syntax is different), though JWasm indeed is "stable, fully cross-platform, has no LFN issues etc."

> > But I'd have
> > to try again. In other words, unless somebody explicitly tries [FPC+HX] and
> > succeeds, I just assume that's not going to work at all. Again, I doubt
> > Japheth cares enough to waste time fixing this.
>
> So I assume that means that HX is not long term viable anyway, ok, option
> dropped.

It's not viable unless somebody (either FPC or HX) is willing to pick up any slack. Sure, HX works great, but it can't support everything. So if FPC is gung ho about using every API in the book (without testing HX first), that's going to be a problem. It's probably not reasonable to expect Japheth to do everything himself (or anything at all, dunno his plans, I expect nothing).

> > The current FPC snapshot says (ppcross386 -iD) 2014/02/05 but -iSO and
> -iTO
> > both say "win32". A weak try (atop Win7 64-bit) to compile fpctris
> > (-Fuunits/go32v2/rtl) says, "PPU is compiled for another target".
>
> FPC compilers are per architecture. So any 32-bit x86 compiler can generate
> go32v2 code. The target OS can be changed with -T.
>
> But for 16-bit you need a 16-bit arch compiler

Dunno, maybe I got the wrong snapshot.

> > > > The IDE shelling out / compile + run bug seems fixed.
> >
> > Haven't tried the built-in debugger, that's what I always associated
> Pierre
> > with, mainly (for good or bad).
>
> True. It seems that the debugger was left out, and he was planning to
> upload an add-on package to fix that.

Laaca will have your head. :-P

Rugxulo(R)

Homepage

Usono,
23.03.2014, 06:33

@ Rugxulo

FPC 2.6.4 released!

> > So I assume that means that HX is not long term viable anyway,
> > ok, option dropped.
>
> It's not viable unless somebody (either FPC or HX) is willing to pick up
> any slack.

An unstable backend (msdos/i8086) of an unstable snapshot (2.7.x) on an unpopular OS (DOS) with a relatively limited Win32 subset emulation (HX) is just asking for something to break.

> > But for 16-bit you need a 16-bit arch compiler
>
> Dunno, maybe I got the wrong snapshot.

I thought only the i8086 compiler was a cross-compiler. I remember older go32v2 snapshots being self-hosted, but nowadays that isn't the case. Hence my confusion.

Anyways, it actually seems that yesterday's i8086 (WmTiny) snapshot "mostly" works okay under HX (DPMILDR=128). I say "mostly" because I didn't fully automate the testing process (due to aforementioned unincorporated kludges), nor yet compare binaries' md5sum made atop proper modern Windows. So I'll have to try testing more properly later this week.

Some minor details have changed but not much. FPCTRIS was like 2 kb smaller than before, so it's not going to match your previous build. And there is a bug (or unimplemented feature?) that makes every program say "Nil pointer assignment" on exit (even something as banal as "Hello, world!").

Rugxulo(R)

Homepage

Usono,
23.03.2014, 10:50

@ Rugxulo

FPC 2.6.4 released!

> Anyways, it actually seems that yesterday's i8086 (WmTiny) snapshot
> "mostly" works okay under HX (DPMILDR=128). I say "mostly" because I didn't
> fully automate the testing process (due to aforementioned unincorporated
> kludges), nor yet compare binaries' md5sum made atop proper modern Windows.
> So I'll have to try testing more properly later this week.

Here is the automated script I wrote and tested (kludge warning!):


@echo off
REM Sunday, March 23, 2014

if "%DOSDIR%"=="" set DOSDIR=c:\fdos
if "%GSED%"=="" set GSED=gsed
if "%RAMDRIVE%"=="" goto end
%RAMDRIVE%:
md \pp16
cd \pp16

md \others
ctty nul
for %%a in (cwstub wlib wlink) do copy /b c:\c\watcom19\binw\%%a.exe \others
for %%a in (nasm unzip gsed cwsdpmi) do copy /b c:\utils\%%a.exe \others
ren \others\cwstub.exe dos4gw.*
ctty con

REM ... LFNs are mandatory, but OW 1.9 doesn't use them (but 2.0-pre???) ...
ctty nul
c:\utils\doslfn
ctty con

REM ... HX is mandatory, this is a Win32-hosted (PE) cross-compiler ...
if not exist c:\hx\bin\hdpmi32.exe goto end

set F1=c:\temp\fpc\8086\fpc-2.7.1-WmTiny.msdos.zip
if not "%1"=="" if exist %1 set F1=%1
if exist %F1% goto unzipit
set F1=
goto end
:unzipit
unzip -q %F1%
set F1=

:begin
set OLDPATH=%PATH%
path %RAMDRIVE%:\others;c:\hx\bin;%RAMDRIVE%:\pp16\bin\i386-w~1
hxldr32 -q
set DPMILDR=128

REM ... "-s" generates ppas.bat script (still necessary, for now)
unzip -qCj c:\temp\fpc\8086\fpc-i8086-msdos-go32v2hosted.old "*demo\*"

REM 2.7.1 2014/03/22 win32 msdos
echo on
ppcross8086 -iV -iD -iSO -iTO
ppcross8086 -CX -XX -Xs -Fuunits\msdos\rtl-console -s fpctris
@echo off

set DPMILDR=

%GSED% -i -e "s/rtl-console/rtl-co~1/" link.res

REM ... begin sed hack for fpctris_ppas.bat here ...
echo #n>>make.sed
echo s/.*\(wlib\.exe -q -fo -c \)\(.*\)\.a.*/cd \2.sl\>>make.sed
echo "dir \/b *.o > \2.rsp\"|%GSED% -e "s/^.//" -e "s/.$//" >>make.sed
echo \1 -n ..\\\2.a @\2.rsp\>>make.sed
echo del \2.rsp\>>make.sed
echo cd../>>make.sed
echo /echo Assembling/s/^/REM />>make.sed
echo s/.*\(wlink\.exe\)  */\1 op q />>make.sed
echo w make.bat>>make.sed
REM ... end sed hack for fpctris_ppas.bat here ...

%GSED% -f make.sed ppas.bat

if not exist make.bat goto end

:make
echo ... Press Ctrl-C if you need to edit MAKE.BAT manually first! ...
pause

call make.bat
if not exist fpctris.exe goto end
dir fpctris.exe | %DOSDIR%\find /i "exe"
set W=c:\temp\fpc\8086\fpctris.win
for %%a in (comp md5sum) do call %DOSDIR%\%%a fpctris.exe %W%
set W=
%RAMDRIVE%:

REM DOS = f4f4c345dce1c949d021115ed04611b1  fpctris.exe
REM WIN = f4f4c345dce1c949d021115ed04611b1  fpctris.exe

:end
if "%GSED%"=="gsed" set GSED=

ctty nul
hxldr32 -u
c:\utils\doslfn -u
ctty con

set THEFILE=
path %OLDPATH%
set OLDPATH=

:adios


The main problems are PPAS.BAT running WLIB with one really long cmdline (or, worse, splitting into two [fpctris 91..11, 10..1], which makes my kludge run twice unnecessarily). The longest line there is 2064 bytes, which is way beyond reasonable. Again, if FPC was smart enough to make the response files itself, that would solve this problem. As is, it's a very tedious kludge just to get things to work. Oh, and sometimes, depending on where WLIB + WLINK are found, it puts their full path in quotes, which breaks my kludge.

ppas.bat :

g:\others\wlib.exe -q -fo -c gameunit.a gameunit.sl\GameUnit0s36.o gameunit.sl\GameUnit0s35.o gameunit.sl\GameUnit0s34.o ... gameunit.sl\GameUnit0s1.o
if errorlevel 1 goto linkend

make.bat :

cd gameunit.sl
dir /b *.o > gameunit.rsp
wlib.exe -q -fo -c -n ..\gameunit.a @gameunit.rsp
del gameunit.rsp
cd..
if errorlevel 1 goto linkend

Rugxulo(R)

Homepage

Usono,
30.03.2014, 10:08

@ Rugxulo

FPC 2.6.4 released!

> > > Haven't tried the built-in debugger, that's what I always associated
> > > Pierre with, mainly (for good or bad).
> >
> > True. It seems that the debugger was left out, and he was planning to
> > upload an add-on package to fix that.
>
> Laaca will have your head. :-P

Just FYI, if anyone here wants to test, it seems that Pierre has made a temporary build of fpgdb.zip (9.3 MB ZIP'd) as of two days ago, see fpc-pascal mailing list thread.

> Lubomir : "Thank you very much, now I am happy because everything
> works including the possibility of debugging. I'll do more tests but I
> assume that everything will be fine."
>
> Pierre : "Great, please report all findings!"

marcov(R)

30.03.2014, 12:14

@ Rugxulo

FPC 2.6.4 released!

> > Lubomir : "Thank you very much, now I am happy because everything
> > works including the possibility of debugging. I'll do more tests but I
> > assume that everything will be fine."
> >
> > Pierre : "Great, please report all findings!"

If I understood correctly, the problem was cwsdpmi r7. r5 worked fine with gdb.

nickysn(R)

03.04.2014, 13:51

@ Rugxulo

FPC 2.6.4 released!

> Some minor details have changed but not much. FPCTRIS was like 2 kb smaller
> than before, so it's not going to match your previous build. And there is a
> bug (or unimplemented feature?) that makes every program say "Nil pointer
> assignment" on exit (even something as banal as "Hello, world!").

That sounds like you got either the units or the startup code for different memory models mixed up. If the correct startup code for tiny (prt0t.o) is linked, you should never get a "Nil pointer assignment" error, because nil pointer checking can only work in the small and medium memory models (which have a separate data segment, so that we can initialize the first few bytes at DS:0000 with a preset pattern and then check it at the end of program execution), so it is simply ifdef'd out in the startup code for tiny.

Rugxulo(R)

Homepage

Usono,
05.04.2014, 23:55

@ nickysn

FPC 2.6.4 released!

> > there is a bug (or unimplemented feature?) that makes every program
> > say "Nil pointer assignment" on exit (even something as banal as
> > "Hello, world!").
>
> That sounds like you got either the units or the startup code for different
> memory models mixed up.

AFAIK, the ppcross8086.exe is the same for both Tiny, Small. The only difference is the compiled units, etc. Yes, I just confirmed it, latest snapshot .EXE is same size, same CRC32 in both .ZIPs.

> If the correct startup code for tiny (prt0t.o) is
> linked, you should never get a "Nil pointer assignment" error, because nil
> pointer checking can only work in the small and medium memory models (which
> have a separate data segment, so that we can initialize the first few bytes
> at DS:0000 with a preset pattern and then check it at the end of program
> execution), so it is simply ifdef'd out in the startup code for tiny.

I'm atop Win64 right now and just tested a simple hello world with latest Tiny snapshot.

ppcross8086 -XX hello -oa.exe
ppcross8086 -XX -WmTiny hello -ob.exe

Here's what DOSBox says:

C:\TMP\BLA>a
Hello, world!
Nil pointer assignment

C:\TMP\BLA>b
Hello, world!

FYI, both .EXEs contain the string "Nil pointer assignment", so it's not totally ifdef'd out. But beyond that, I don't know. Maybe it's a mistake to assume the Tiny build always builds tiny. But I just blindly assumed it wasn't necessary to tell it. Though of course the compiler .EXE probably doesn't know any better if it's the same for each. Maybe there is no default memory model. Dunno if that's a bug or (more likely) user error.

In short, we should probably always explicitly specify a memory model when compiling. Maybe it should error out if none is specified by default.

Rugxulo(R)

Homepage

Usono,
06.04.2014, 00:14

@ marcov

FPC 2.6.4 released!

> > > Lubomir : "Thank you very much, now I am happy because everything
> > > works including the possibility of debugging. I'll do more tests but I
> > > assume that everything will be fine."
> > >
> > > Pierre : "Great, please report all findings!"
>
> If I understood correctly, the problem was cwsdpmi r7. r5 worked fine with
> gdb.

r5 has some bugs of its own, depending on which r5 you're talking about (2000, 2002, 2008). Yes, r7 has some other bugs, but CWS has been too busy to make another full release. (If you think it's due to 4 MB pages, you can disable that via CWSPARAM.) However, in this case, without having had more testers, I don't know if this is really a bug or just something specific to Lubomir's particular machine setup. For all we know, it's some bug in his EMM386 or TSR or similar. I'm not saying it isn't r7's fault, but I wouldn't recommend downgrading to r5 at all (esp. since r7 is recommended as default for all users these days, e.g. DJ's Zip Picker). If you're that paranoid, include both r5 and r7 in next FPC release. But it's probably low priority for everyone involved.

nickysn(R)

06.04.2014, 00:26

@ Rugxulo

FPC 2.6.4 released!

> > > there is a bug (or unimplemented feature?) that makes every program
> > > say "Nil pointer assignment" on exit (even something as banal as
> > > "Hello, world!").
> >
> > That sounds like you got either the units or the startup code for
> different
> > memory models mixed up.
>
> AFAIK, the ppcross8086.exe is the same for both Tiny, Small. The only
> difference is the compiled units, etc. Yes, I just confirmed it, latest
> snapshot .EXE is same size, same CRC32 in both .ZIPs.
>
> > If the correct startup code for tiny (prt0t.o) is
> > linked, you should never get a "Nil pointer assignment" error, because
> nil
> > pointer checking can only work in the small and medium memory models
> (which
> > have a separate data segment, so that we can initialize the first few
> bytes
> > at DS:0000 with a preset pattern and then check it at the end of program
> > execution), so it is simply ifdef'd out in the startup code for tiny.
>
> I'm atop Win64 right now and just tested a simple hello world with latest
> Tiny snapshot.
>
> ppcross8086 -XX hello -oa.exe
> ppcross8086 -XX -WmTiny hello -ob.exe
>
> Here's what DOSBox says:
>
> C:\TMP\BLA>a
> Hello, world!
> Nil pointer assignment
>
> C:\TMP\BLA>b
> Hello, world!

Strange, it doesn't happen on my machine. I'm using linux (x86_64), openwatcom 1.9, nasm 2.10.07 and dosbox and it works fine. How did you build the snapshot?

>
> FYI, both .EXEs contain the string "Nil pointer assignment", so it's not
> totally ifdef'd out.

The string exists in both, but it's only printed after a function call to the startup code, which checks the byte pattern in the beginning in the of the data segment. See the FPC_CHECK_NULLAREA label in:

http://svn.freepascal.org/svn/fpc/trunk/rtl/msdos/prt0comn.asm

> But beyond that, I don't know. Maybe it's a mistake to
> assume the Tiny build always builds tiny. But I just blindly assumed it
> wasn't necessary to tell it. Though of course the compiler .EXE probably
> doesn't know any better if it's the same for each. Maybe there is no
> default memory model. Dunno if that's a bug or (more likely) user error.
>
> In short, we should probably always explicitly specify a memory model when
> compiling. Maybe it should error out if none is specified by default.

The default memory model is 'small'. There are also some flags in the .ppu header which indicates for which memory model the given unit was built. But it doesn't matter for small and tiny, because the .ppus are compatible and these flags are identical in those two memory models. The only difference is the startup code - prt0s.o is for small, while prt0t.o is for tiny. The appropriate one is chosen by the compiler and put in the linker script according to the -Wm option.

Rugxulo(R)

Homepage

Usono,
06.04.2014, 02:13

@ nickysn

FPC 2.6.4 released!

> > I'm atop Win64 right now and just tested a simple hello world with
> latest
> > Tiny snapshot.
> >
> > ppcross8086 -XX hello -oa.exe
> > ppcross8086 -XX -WmTiny hello -ob.exe
> >
> > Here's what DOSBox says:
> >
> > C:\TMP\BLA>a
> > Hello, world!
> > Nil pointer assignment
> >
> > C:\TMP\BLA>b
> > Hello, world!
>
> Strange, it doesn't happen on my machine. I'm using linux (x86_64),
> openwatcom 1.9, nasm 2.10.07 and dosbox and it works fine. How did you
> build the snapshot?

I didn't build FPC at all, just grabbed the precompiled Win32 build from FPC's FTP. So somebody is building these regularly, but it isn't me! :-P That's half the point, that I'm testing their builds, not mine.

I don't think the other details matter here, but I've got OW 1.9, NASM 2.11, DOSBox 0.74.

> > In short, we should probably always explicitly specify a memory model
> when
> > compiling. Maybe it should error out if none is specified by default.
>
> The default memory model is 'small'. There are also some flags in the .ppu
> header which indicates for which memory model the given unit was built. But
> it doesn't matter for small and tiny, because the .ppus are compatible and
> these flags are identical in those two memory models. The only difference
> is the startup code - prt0s.o is for small, while prt0t.o is for tiny. The
> appropriate one is chosen by the compiler and put in the linker script
> according to the -Wm option.

Dunno, too many memory models, so it's very easy to be confused (at least for me).

The only reason I bothered with "Tiny" in these cases is because that's what MarcoV used when originally (re)compiling FPCTRIS, and I wanted to be byte-exact to his version (though too much has changed since then for that to stay the same anyways). I guess from now on I'll stick to "Small".

nickysn(R)

06.04.2014, 11:21

@ Rugxulo

FPC 2.6.4 released!

> > > I'm atop Win64 right now and just tested a simple hello world with
> > latest
> > > Tiny snapshot.
> > >
> > > ppcross8086 -XX hello -oa.exe
> > > ppcross8086 -XX -WmTiny hello -ob.exe
> > >
> > > Here's what DOSBox says:
> > >
> > > C:\TMP\BLA>a
> > > Hello, world!
> > > Nil pointer assignment
> > >
> > > C:\TMP\BLA>b
> > > Hello, world!
> >
> > Strange, it doesn't happen on my machine. I'm using linux (x86_64),
> > openwatcom 1.9, nasm 2.10.07 and dosbox and it works fine. How did you
> > build the snapshot?
>
> I didn't build FPC at all, just grabbed the precompiled Win32 build from
> FPC's
> FTP.
> So somebody is building these regularly, but it isn't me! :-P That's
> half the point, that I'm testing their builds, not mine.

I'll check them out. These automated builds are Pierre's work, but there could be a bug in the build process. I'll have to check.

Meanwhile, I have added build instructions and how to setup your fpc.cfg for multiple memory models in the fpc wiki:

http://wiki.freepascal.org/DOS#Building_a_snapshot_manually

That's what I use and it works perfectly.

>
> I don't think the other details matter here, but I've got OW 1.9, NASM
> 2.11, DOSBox 0.74.
>
> > > In short, we should probably always explicitly specify a memory model
> > when
> > > compiling. Maybe it should error out if none is specified by default.
> >
> > The default memory model is 'small'. There are also some flags in the
> .ppu
> > header which indicates for which memory model the given unit was built.
> But
> > it doesn't matter for small and tiny, because the .ppus are compatible
> and
> > these flags are identical in those two memory models. The only
> difference
> > is the startup code - prt0s.o is for small, while prt0t.o is for tiny.
> The
> > appropriate one is chosen by the compiler and put in the linker script
> > according to the -Wm option.
>
> Dunno, too many memory models, so it's very easy to be confused (at least
> for me).
>
> The only reason I bothered with "Tiny" in these cases is because that's
> what MarcoV used when originally (re)compiling FPCTRIS, and I wanted to be
> byte-exact to his version (though too much has changed since then for that
> to stay the same anyways).

Well, byte exactness to that version is long gone, due to many code generator changes (bug fixes and optimizations).

> I guess from now on I'll stick to "Small".

If you follow the instructions in:

http://wiki.freepascal.org/DOS#Building_a_snapshot_manually

and

http://wiki.freepascal.org/DOS#Updating_your_fpc.cfg

You should be able to use 5 memory models - tiny, small, medium, compact and large (keep in mind though that compact and large are new and thus not as stable as the other three).

nickysn(R)

08.04.2014, 17:17

@ nickysn

FPC 2.6.4 released!

> >
> > I didn't build FPC at all, just grabbed the precompiled Win32 build from
> > FPC's
> >
> FTP.
> > So somebody is building these regularly, but it isn't me! :-P That's
> > half the point, that I'm testing their builds, not mine.
>
> I'll check them out. These automated builds are Pierre's work, but there
> could be a bug in the build process. I'll have to check.

I checked them and they look fine. The problem appears to be that you're using the tiny rtl to build a small model program, which causes the 'Nil pointer assignment' error. The opposite (using the small rtl to build a tiny model program) works correctly.

nickysn(R)

10.04.2014, 18:37

@ nickysn

FPC 2.6.4 released!

> > >
> > > I didn't build FPC at all, just grabbed the precompiled Win32 build
> from
> > > FPC's
> > >
> >
> FTP.
> > > So somebody is building these regularly, but it isn't me! :-P
> That's
> > > half the point, that I'm testing their builds, not mine.
> >
> > I'll check them out. These automated builds are Pierre's work, but there
> > could be a bug in the build process. I'll have to check.
>
> I checked them and they look fine. The problem appears to be that you're
> using the tiny rtl to build a small model program, which causes the 'Nil
> pointer assignment' error. The opposite (using the small rtl to build a
> tiny model program) works correctly.

FYI, I just committed a change to fpc trunk, which makes the tiny and small units incompatible with each other. The reasons:

- the bug you mentioned - while tiny programs using the small rtl work fine, the opposite - small programs, using tiny rtl don't really have the correct small model memory layout and print out a "Nil pointer assignment" error
- I'm planning a bug fix for interrupt procedures for the tiny model, which will make them different between small and tiny
- other differences between the two models may also be introduced in the future

Rugxulo(R)

Homepage

Usono,
22.04.2014, 02:18

@ Rugxulo

FPC 2.6.4 released!

> The main problems are PPAS.BAT running WLIB with one really long cmdline
> (or, worse, splitting into two [fpctris 91..11, 10..1], which makes my
> kludge run twice unnecessarily). The longest line there is 2064 bytes,
> which is way beyond reasonable. Again, if FPC was smart enough to make the
> response files itself, that would solve this problem. As is, it's a very
> tedious kludge just to get things to work. Oh, and sometimes, depending on
> where WLIB + WLINK are found, it puts their full path in quotes, which
> breaks my kludge.
>
> ppas.bat :
>
> g:\others\wlib.exe -q -fo -c gameunit.a gameunit.sl\GameUnit0s36.o
> gameunit.sl\GameUnit0s35.o gameunit.sl\GameUnit0s34.o ...
> gameunit.sl\GameUnit0s1.o
> if errorlevel 1 goto linkend
>
> make.bat :
>
> cd gameunit.sl
> dir /b *.o > gameunit.rsp
> wlib.exe -q -fo -c -n ..\gameunit.a @gameunit.rsp
> del gameunit.rsp
> cd..
> if errorlevel 1 goto linkend

Some of these compiler switches get confusing fast. This kludge isn't always 100% necessary just to compile. I mistakenly thought -CX (compiling units) smartlinking was required for everything here, but apparently not. In fact, for simple stuff like fpctris and samegame, it seems to make almost no size difference at all. (Presumably units other than gameunit are much more bloated.)

But I guess? that -XX is always required since (linking) smartlinking makes a difference in whether it looks for libs or objects, and the pre-compiled units are all smartlinked (by necessity?). BTW, I'm not sure if "-Xs" (strip) even does anything here (intentionally or otherwise).

But just for simple stuff, I can get away with "ppcross8086 -XX -O3 samegame", and it'll compile (in DOS) okay, by default, no kludges needed. At least with latest Win32-hosted snapshots (run under HX).

Then I got the "bright" idea to build a helper frontend tool (in 16-bit real mode, using TP55 or FPC itself) to workaround this kludge for me (using -s and tweaking the .BAT output). Or maybe you really expect me to "svn co" trunk (under Linux) and weakly try to fix it there? I just assumed using "chdir blah.sl" and "dir /b *.o > blah.rsp" was still portable to Windows, but I forgot that somebody might want to cross-compile from Linux. Though I guess it still makes sense for "-st" (target). Or maybe only {$ifdef DOS-hosted}.

Dunno, I just hate that it seems to be so close to being DOS-hosted but not quite there yet. Oh well.

P.S. I guess you heard what was the SourceForge April Community Choice Project of the Month. :-)

marcov(R)

30.04.2014, 20:42

@ Rugxulo

FPC 2.6.4 released!

>
> Some of these compiler switches get confusing fast. This kludge isn't
> always 100% necessary just to compile. I mistakenly thought -CX (compiling
> units) smartlinking was required for everything here, but apparently not.
> In fact, for simple stuff like fpctris and samegame, it seems to make
> almost no size difference at all. (Presumably units other than gameunit are
> much more bloated.)

That's because those two games use everything in gameunit, so there is no code to smartlink out. But those games don't use everything in RTL units, so those need to be compiled with.

> But I guess? that -XX is always required since (linking) smartlinking makes
> a difference in whether it looks for libs or objects, and the pre-compiled
> units are all smartlinked (by necessity?). BTW, I'm not sure if "-Xs"
> (strip) even does anything here (intentionally or otherwise).

I've no idea how that works with watcom linker. Either of them.

> But just for simple stuff, I can get away with "ppcross8086 -XX -O3
> samegame", and it'll compile (in DOS) okay, by default, no kludges needed.
> At least with latest Win32-hosted snapshots (run under HX).
>
> Then I got the "bright" idea to build a helper frontend tool (in 16-bit
> real mode, using TP55 or FPC itself) to workaround this kludge for me
> (using -s and tweaking the .BAT output).

Go ahead.

> Or maybe you really expect me to
> "svn co" trunk (under Linux) and weakly try to fix it there?

No, I would expect you to fix it in a strong way, obviously.

> P.S. I guess you heard what was the SourceForge
> April
> Community Choice Project of the Month. :-)

I knew yes. Your remark make me check download stats, but they don't seem to be noticably higher than normal.

Rugxulo(R)

Homepage

Usono,
08.05.2014, 00:18
(edited by Rugxulo, 08.05.2014, 01:22)

@ marcov

FPC 2.6.4 released!

> > BTW, I'm not sure if "-Xs" (strip) even does anything here
>
> I've no idea how that works with watcom linker. Either of them.

Dunno, I haven't really looked, but I suspect (OMF) debug info isn't generated at all for FPC's "msdos" target yet.

Probably easier to not worry with that for now!

> > Then I got the "bright" idea to build a helper frontend tool (in 16-bit
> > real mode, using TP55 or FPC itself) to workaround this kludge for me
> > (using -s and tweaking the .BAT output).
>
> Go ahead.

This is a horrible attempt, but I'm sure your expectations were low. :-P

EDIT: Oops, my bad, that was my bug, not Exec. It works better now.


{$ifndef FPC}
unsupportedCOMPILER
{$else}
{$if FPC_FULLVERSION < 20701}
{$fatal unsupportedCOMPILER}
{$endif}
{$H+} // we need really really really long lines!
//{$assertions on}
{$endif}

program kludge;

uses dos;

var filein,fileout: text;
    line,module,link: string;
    linenum,lastlink: longint;
    fullname: record dir,name,ext: shortstring end;

const
    pascalsource: string = 'fpctris.pp';
    compiler: string = 'ppcross8086.exe'; // 'ppcros~1.exe'
    pflags: string = ' -CX -XX -O3 -s';
    unitdir: string = '-Fu\pp16\units\msdos\*'; // find 'crt.a/.ppu', etc.
    // or 'set MSDOSUNITS=g:\pp16\units\msdos\*' in advance

procedure fix_wlib;
var start,finish: longint;
begin
    // don't run twice, though -n (create new) would maybe still work
    if lastlink=linenum-2 then exit;

    finish := pos('.a ',line)-1; start := finish;
    repeat dec(start) until (start=0) or (line[start]=' '); inc(start);

    module := line[start..finish];
    link := line[1..start-1] + '..\' + module + '.a @' + module + '.rsp';

    writeln(fileout,'cd ' + module + '.sl');
    writeln(fileout,'dir /b *.o > ' + module + '.rsp');
    writeln(fileout,link);
    writeln(fileout,'cd..');
    writeln(fileout,'del ' + module + '.sl\' + module + '.rsp');

    lastlink := linenum
end; {fix_wlib}

procedure runme(cmd1,cmd2: string);
begin
  SwapVectors;
  writeln(cmd1,cmd2);
  Exec(cmd1,cmd2);
  SwapVectors
end; {runme}

function found(this,that: string): boolean;
begin
  found := pos(this,that) <> 0
end; {found}

// ********************************************************

begin {main} linenum := 1; lastlink := 0;

  if paramcount=1 then pascalsource := paramstr(1);

  if getenv('MSDOSUNITS') <> '' then unitdir := '';

  with fullname do fsplit(pascalsource,dir,name,ext);

  case upcase(fullname.ext) of
    '.PP','.DPR','.PAS': ; // writeln('okay.')
    else begin
      writeln(pascalsource + ' : not valid Pascal source!');
      halt
    end
  end;

  compiler := fsearch(compiler,getenv('PATH'));

  RunMe(compiler,' ' + unitdir + pflags + ' ' + pascalsource);

  assign(filein,'ppas.bat'); assign(fileout,'make.bat');
  {$I-} reset(filein); {$I+}
  if ioresult <> 0 then begin
    writeln('echo PPAS.BAT not found! Run this first: ' + #13#10);
    writeln(compiler,' ' + unitdir + pflags + ' ' + pascalsource);
    halt
  end;

  rewrite(fileout);

  while not eof(filein) do begin
    readln(filein,line);

    // don't use quotes, probably not necessary for DOS users
    if getenv('NOQUOTES') <> '' then
      while pos('"',line) > 0 do delete(line,pos('"',line),1);

    // Rmdir with trailing subdir backslash fails
    if (pos('Rmdir',line)=1) and (line[length(line)]='\') then
      delete(line,length(line),1);

    if pos('echo Assembling',line)=1 then
       // don't report upon assembling every single .s file
       writeln(fileout,'if not "%DEBUG%"=="" ' + line)
    else if not (found('wlib.exe',line) or found('.a ',line)) then
       writeln(fileout,line)
    else fix_wlib;

    inc(linenum)
  end;

  close(filein); close(fileout); erase(filein);

  RunMe(getenv('COMSPEC'),' /c make.bat');

  writeln('Done!')

end.


> > Or maybe you really expect me to
> > "svn co" trunk (under Linux) and weakly try to fix it there?
>
> No, I would expect you to fix it in a strong way, obviously.

That sounds much more complicated, so for now I've not attempted it.

> > P.S. I guess you heard what was the SourceForge
> >
> April
> > Community Choice Project of the Month. :-)
>
> I knew yes. Your remark make me check download stats, but they don't seem
> to be noticably higher than normal.

Marco, if I may be frank (hi, Frank!), never ever check statistics. Even if they're true (unlikely), they always point you in the wrong direction. Unless you think the popular choice is always the best, it's not worth paying attention.

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