Hi,   
      
   On Tuesday, August 29, 2017 at 12:29:52 PM UTC-5, Robert Prins wrote:   
   > On 2017-08-25 22:07, rugxulo@nospicedham.gmail.com wrote:   
   > >   
   > > On Wednesday, August 23, 2017 at 4:05:47 AM UTC-5, Robert Prins wrote:   
   > >> On 2017-08-22 19:38, rugxulo@nospicedham wrote:> On Monday, August 21,   
   > >>   
   > >> The files that you need is "lift-snapshot@2017-08-20.rar" To stop Google   
   > >> from falsely claiming that it contains a virus   
   > >   
   > > I see lots of sources, but nothing obvious on how to compile with FPC.   
   > > (What's the main .PAS ? Where's the diff/patch? .BATs are for VP only.   
   > The main.pas'es are:   
   >   
   > chkdat.pas   
   > lift.pas   
   > dayform.pas   
   > h-h2rtf.pas   
   > h-h2html.pas   
   >   
   > No diffs, just make the change.   
      
   If you had {$ifdef}s for FPC (or an actual patch for Patch), it'd   
   be loads easier. Or even a separate, FPC-only version, that'd be nice.   
   I can sorta kinda get it compiled now, but ....   
      
   > > You keep saying that FPC won't work, but all I hear is how many changes you   
   > > have to make to even get it to compile. It shouldn't be this hard.   
   >   
   > Only one hard change, the four longint's in hhcommon.pas (write_time)   
   > need to be changed into word. After that it compiles, but due to FPC   
   > optimizing out the xxxx_top pointers none of the executables actually runs.   
      
   Adding "-gl" seems to show that the problem is in "readfile".   
      
   Not entirely sure what low-level pointer stuff is going on behind   
   the scenes (that you're referring to here).   
      
   > > BTW, not to defend bad antivirus heuristics, but it might go easier if you   
   > > kept sources (plain text) separate from binary blobs in a different   
   archive.   
   >   
   > Because this way everything is in one place. Will give it some thought.   
      
   Heuristics are definitely bad, for the most part, and shouldn't be enabled   
   by default. That's their bug, not yours. Too many false positives isn't   
   fair, and honestly I'm also tired of dealing with it.   
      
   > >>>> The source files contains both Pure Pascal and assemblerised sections,   
   > >>>> and, with one small tweak, FPC actually compiles the Pure Pascal   
   > >>>> version.   
   > >>>   
   > >>> I find that unlikely. FPC is highly compatible with TP.   
   > >>   
   > >> No, unlike TP/BP/VP, FPC will not honour the convention that three   
   > >> variables in a const declaration are kept together as packed, i.e.   
   > >>   
   > >> const lift_ptr: liftptr = nil; lift_top: liftptr = nil; lift_end: liftptr   
   =   
   > >> nil;   
   > >   
   > > Not sure why you're relying on that specific layout. All system- specific   
   > > code should be separated (or avoided). Otherwise, as you've noticed,   
   there's   
   > > little gain in HLLs.   
   >   
   > Why this layout? See update_list_pointers in hhcommon.pas Basically been   
   using   
   > this since TP 3.01a (and on z/OS, using PL/I) and it should not break!   
      
   But TP3 was thirty years ago, back when TP still supported CP/M and   
   .COM output. TP4 was the new one with .EXE support. So yes, things do   
   change (obviously).   
      
   FPC didn't even have a 16-bit target until two years ago! Here I'm   
   actually assuming Go32v2 (32-bit), but maybe we should try i8086-msdos   
   instead?   
      
   > >> Will download 3.0.2 (last tried version was 2.6.?), and give it one more,   
   > >> and absolutely final try.   
   >   
   > As I already wrote, Crash, Boom, Bang, and code that looks as if it came   
   > straight out of TP 1. Thanks, but no thanks, no more!   
      
   I think you're overreacting, to say the least. It's still very very good.   
   But if you can write better pure assembly, go ahead!   
      
   > ISO 7185 is a language to teach programming. Turbo Pascal is a language   
   > to actually write working programs.   
      
   ISO 7185 died with either Extended Pascal (ISO 10206) or Modula-2 or   
   maybe Oberon. It's still good, but only for historical reasons.   
      
   Turbo Pascal died with Delphi, which has had dozens of releases (and   
   tons of changes). Even FPC prefers Delphi these days but still keeps   
   faithful to {$mode tp} for all the legacy (which is good, IMHO).   
   FPC's ISO support isn't quite perfect yet.   
      
   > >> And next to that I have little interest in installing GCC...   
   > >   
   > > Well, for DOS, it's only five .ZIPs, unpack, set two env. vars,   
   > > and you're ready. Extremely easy, even under a VM. And GPC also   
   > > supports {$borland-pascal} mode.   
   >   
   > I don't use DOS, and the whole reason for going from BP7 to VP was   
   > to remove any space constraints, and be able to code in-line assembler   
   > without loads of db overrides.   
      
   Okay, but DOS is simple to setup, easy to install atop, free, so that   
   is my personal preference here.   
      
   But since you direly want inline assembly, GCC (GPC) "probably" isn't   
   going to be your cup of tea. FPC is probably somewhat easier (although   
   BinUtils has also supported .intel_syntax for almost two decades).   
      
   There are no space constraints in 32-bit pmode (DPMI) atop DOS.   
   So FPC and GPC have no 16-bit real-mode limits. (Heck, I sometimes   
   run VPC under DOS + HX, too.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)