DOS ain't dead

> > 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.

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.

> > 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! 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".