DOS ain't dead

> > My Lenovo desktop (Core i5, dual core, quasi four with HTT) from 2011
> > has Nehalem Westmere (tail end of gen 1) with VT-X and nested page tables
> > (unrestricted guest mode, unreal/big real, whatever).
>
> Westmere was server, and mostly labeled as "Xeons", not "i5". If you have a
> 650 or 655, that is "enthusiast" variant Clarkdale.

You're right, I suppose (i5 650). I can barely keep track of their insane naming conventions. Even "i5" is useless. My old 2010 laptop is technically "Pentium" (mid-range?) dual-core but family 6 (obviously). One young person I talked to didn't understand "Core 2" vs. "cores" or "i7" vs. "seven cores". I swear they intentionally avoid mentioning these details (and VT-X and a billion other features, who can even keep track?).

> > Now that BIOS/CSM is effectively dead (no more native
> > booting), VT-X is very crucial (if you "need" legacy that badly).
>
> Yes. Note that VT-X is mainly for non-cooperating (full emulation) OSes.
> Stuff like Linux runs better, because some high bandwidth drivers are
> replaced by ones that hand it nicely to the hypervisor.

I think they just aren't optimized for tons of mode switches, especially not DOS/DJGPP. BTW, obviously VT-X is the new V86 mode (but took forever to get propagated to end users).

> Chromebooks are mainly intended to do some surfing (and then mostly "on the
> road"). I avoid them, and the N series in general (though I know some of
> the later ones are out of order, and not as bad as the early Atom ones).

It's no worse than an Android tablet, just bigger screen and keyboard. Slightly different but still similar.

My mother uses an old, used laptop that my brother gave her. 2 GB of RAM, single core, but barely-modern cpu circa 2009 or so (I forget exactly). It stays always plugged in, uses external mouse and keyboard, makes tons of fan noise, but otherwise works (thanks to me setting up a USB jump drive with Ubuntu for her). She's very cheap and stubborn, so if you think I'm a luddite, try convincing her to upgrade literally anything.

Sadly, I think most people are just expected to grab the first thing they see or whatever's on "sale". It's not like I need it for anything important, but still, I need to be careful.

> I do a lot of FPC compiling, and while that doesn't require a umpteen core
> threadripper, a basic quad core is nice. Higher core counts are less
> utilized. (e.g. my Ryzen 2600 hexa core is about 25-35% faster than the
> i7-3770 compiling FPC).

The only -j4 compiling I ever did was (minimal, for fun) cross-building p7zip and building a newer QEMU under Lucid Puppy Linux. "Four" cores definitely made a difference.

> Zen is nice though. The old core AMD advantages, price/performance, working
> well also if code isn't particularly optimized for it, and less playing
> games with the processor lineup than Intel does (this one gets vt-x, that
> one gets hyperthreading etc). A large part of the lineup has all features
> enabled.
>
> At work we have the budget AMDs (about Eur 50, tax inclusive) as workhorse,
> Athlon 200GE, based on original Zen. Even those are nice.

My brother and I both had AMD laptops back in 2007 or so (both something like TK-53 AMD64x2). His was a Toshiba and mine was HP Compaq. Both similarly failed/died/overheated.

(My brother also has a newer [2016??] AMD laptop, but he only got that because it was cheap, Black Friday sale or whatever. A6 APU? with VT-X and four cores, but he never did anything cool with it. I only barely got him to boot a USB jump drive successfully to DOS once, and that was a few months ago. He's more interested in multimedia and Windows. I loaned him a very old Pascal book and emailed him a bunch of links and examples re: FPC, but I don't know how much he's truly interested, despite some unprompted initiative from him. Certainly FreeDOS didn't sway his opinion.)

I still think very highly of AMD. I know they have very smart engineers. But my Dell laptop (Intel) was easily twice as good (esp. battery life). Then again, Dell was incredibly biased against AMD for years. So I don't (and shouldn't) hold a grudge.

Besides, AMD's Zen was redesigned from scratch, "no longer a generation behind", and is very popular and affordable. For fun (even though I refuse to play the stock market), I was watching their stock price for years. It's gone quite high in recent months, surprisingly. But the market is fickle and irrational, so I don't draw any conclusions there. (PS4 and XBox1 both were wildly successful and used AMD64, but that made no dent in their stock price, surprisingly.)

> > There's too many cpus. Zen was from early 2017. MS Surface has Zen+. Zen
> > 2 was just released. Intel's on, what, gen 10 or 11?? It's too much.
> > I did briefly online look at some Dell Ryzen laptops, but I really
> > wanted a reasonable Linux one, not Windows.
>
> Wait. This summer a Ryzen 4xxx series laptops should come out, and they
> will be good. My work laptop is up for a change, so I might snap one up
> myself.

Ever looked at FSF's "Respect Your Freedom" (refurbished?) laptops? I forget what that fork of Coreboot is used (Libreboot??). Quite ancient (2008-ish?) tech but no ME or PSP or whatever. Not dirt cheap either but nothing horrible.

> "official" linux branded hardware is maybe not wise. Usually they
> are targeted at education and research institutions and relatively
> overpriced.

Software engineers want good stuff, not old refurbished ten-year-old crap. SSD, 16 GB RAM, UHD, or whatever. Yes, it's overpriced a bit, but it's not for the lowly masses like myself. I just don't majorly want or need Windows, even though Win10 has WSL for running Linux 64-bit binaries.

> [Threadripper] is a beast, but also expensive (Eur 4000) a very unpractical
> power requirement (noisy) etc.

Compared to what? I think one person said the Intel equivalent was $10000!
Similarly, noise compared to what? A Pentium 4?? Even one streamer I watch played one XBox360 game on his XBox1 because it was quieter. (Yeah, 2005 PPC tri-core tech wasn't as efficient, big surprise.)

> The FPC project's build process uses Make in parallel mode on directories,
> getting about two to four times as fast when enabling multi core. But going
> from quad to hexacore or higher doesn't bring much, since due to
> dependencies they are underutilized.
>
> But that is compiling FPC, not compiling WITH FPC.

But ... but ... you compile FPC with FPC! (I did read once that Delphi won't build it due to their bugs. Who knows if that's changed.)

I've probably never even rebuilt FPC. I need to rebuild the Go32v2 version one of these days, for fun. It really should be buildable in DOS natively (famous last words).

> Yes. All main apps are 64-bit at work except for one.

Have you seen any Windows ARM64 machines? What are your opinions?

> That exception does a lot of x87 math. (like sin/cos etc),
> which seems to be faster in 32-bit, at least with Delphi.

AMD64 went minimal and only supported (like C89 or Oberon) REAL and LONGREAL (aka, single and double). Doesn't even FPC "extended" not work on AMD64? Meh. So yeah, third-party library needed ... or maybe AVX, dunno.

> C++20 has exciting new features like Modules and Coroutines. You know, the
> features that Modula2 had in 1980, and Modules were backported to Turbo
> Pascal as units in '86 or so

It will be great when modules finally stabilize. I hope they backport it to C. The less reliance on brittle (unportable) makefiles and POSIX shell, the better. (Doesn't even Win10 have Bash and Curl nowadays??)

Speaking of p7zip, it's not the best code (how would I know??), could be better abstracted or portablized or simplified or modularized, but it's quite nice for what it does. I have no idea why I waste time on such things that I know nothing about. (I do have a DOS-era C++ book from 1995, heh. I only halfway read it and gave up, decades ago. Probably shouldn't now learn C++ from before '11, if even that old. Then again, who cares, I can fire up a VM.)

> Maybe in 2040 they finally realize that = vs == is not smart either.

The switch statement could definitely be fixed. But they'll probably keep assignment in expressions. (Nested functions would be very nice to standardize, too. GCC and TCC support it, so do others like D.)

> I can barely keep track of their insane
> naming conventions.

Yes. I really look up everything on the website. I always wonder when people say "i5" or "i7" and expect you to be very impressed (but they didn't tell you the important bit, the generation)

> I swear they intentionally avoid mentioning these details (and VT-X
> and a billion other features, who can even keep track?).

Partially yes to have a really drawn out product-palette.

> > Yes. Note that VT-X is mainly for non-cooperating (full emulation) OSes.
> > Stuff like Linux runs better, because some high bandwidth drivers are
> > replaced by ones that hand it nicely to the hypervisor.
>
> I think they just aren't optimized for tons of mode switches, especially
> not DOS/DJGPP. BTW, obviously VT-X is the new V86 mode (but took forever to
> get propagated to end users).

Yes. Moreover most dos applications use HW directly, so replacing a driver is no good there.

> > Chromebooks are mainly intended to do some surfing (and then mostly "on
> the
> > road"). I avoid them, and the N series in general (though I know some of
> > the later ones are out of order, and not as bad as the early Atom ones).
>
> It's no worse than an Android tablet, just bigger screen and keyboard.

True. I had a Bay Trail one, but the glass cracked unfortunately.

> The only -j4 compiling I ever did was (minimal, for fun) cross-building
> p7zip and building a newer QEMU under Lucid Puppy Linux. "Four" cores
> definitely made a difference.

While some of the FPC parallelism is -j4, it got too complicated, and now there is a separate fpmake tool.

> My brother and I both had AMD laptops back in 2007 or so (both something
> like TK-53 AMD64x2). His was a Toshiba and mine was HP Compaq. Both
> similarly failed/died/overheated.

Yes. I haven't been impressed by the old "Turion" AMD laptops either, but I see Ryzen laptops appearing in shops again (as first AMD options in a decade or so), and hear good things about them.

> But my Dell laptop (Intel) was easily twice as good (esp. battery life).
> Then again, Dell was incredibly biased against AMD for years. So I don't
> (and shouldn't) hold a grudge.

Well, since my last (private) laptop was Sony, and Sony got out of the laptop biz, I'll need to find a new brand

My work laptop is Medion, which is a large German OEM afaik which uses Akoya (or something) branded mobos. Aldi and Mediamarkt/Saturn peddle their stuff.

I bought it mainly because back then they were the only brand that had SSD/HDD combo systems for under Eur 1000.

> > Wait. This summer a Ryzen 4xxx series laptops should come out, and they
> > will be good. My work laptop is up for a change, so I might snap one up
> > myself.
>
> Ever looked at FSF's "Respect Your Freedom" (refurbished?) laptops? I
> forget what that fork of Coreboot is used (Libreboot??). Quite ancient
> (2008-ish?) tech but no ME or PSP or whatever. Not dirt cheap either but
> nothing horrible.

No. I mostly run Windows nowadays.

> > "official" linux branded hardware is maybe not wise. Usually they
> > are targeted at education and research institutions and relatively
> > overpriced.
>
> Software engineers want good stuff, not old refurbished ten-year-old crap.
> SSD, 16 GB RAM, UHD, or whatever. Yes, it's overpriced a bit, but it's not
> for the lowly masses like myself. I just don't majorly want or need
> Windows, even though Win10 has WSL for running Linux 64-bit binaries.

For work I use Delphi and some other IDEs (like Visual Studio and some Netbeans stuff). Using really old stuff hurts. that said, my Ivy Bridge stuff is old, but was decent back then and still sort of works.


> > [Threadripper] is a beast, but also expensive (Eur 4000) a very
> unpractical
> > power requirement (noisy) etc.
>
> Compared to what? I think one person said the Intel equivalent was $10000!

Yeah, and that is overpriced too, the whole segment is. It is mostly for people with per scoket licensed software and a few special purposes.

> > But that is compiling FPC, not compiling WITH FPC.
>
> But ... but ... you compile FPC with FPC! (I did read once that Delphi
> won't build it due to their bugs. Who knows if that's changed.)

Parallelism is a complicated thing with FPC because it has a precompiled header system and finds its own files to compile. (no makefiles with long lists of files to compile). That makes parallel compiling more complicated, and make -j style would cause the various instances to conflict.

While there is some make -j level parallelism, most is on whole directory level. That however only scales so far because there are simply not enough directories independently compilable of eachother beyond 4-5 in parallel.

> I've probably never even rebuilt FPC. I need to rebuild the Go32v2 version
> one of these days, for fun. It really should be buildable in DOS natively
> (famous last words).

It could at some point, though most used Win9x. Later XP.

> Have you seen any Windows
> ARM64 machines? What are your opinions?

Currently irrelevant.

> > That exception does a lot of x87 math. (like sin/cos etc),
> > which seems to be faster in 32-bit, at least with Delphi.
>
> AMD64 went minimal and only supported (like C89 or Oberon) REAL and
> LONGREAL (aka, single and double). Doesn't even FPC "extended" not work on
> AMD64? Meh. So yeah, third-party library needed ... or maybe AVX, dunno.

Windows 64-bit deprecated x87 math. So all math is done using SSE2, which is faster for simple (+-/*) like math, but slower for more complex math (exp(),Sin/cos etc)

> > C++20 has exciting new features like Modules and Coroutines. You know,
> the
> > features that Modula2 had in 1980, and Modules were backported to Turbo
> > Pascal as units in '86 or so
>
> It will be great when modules finally stabilize. I hope they backport it to
> C.

I'm also interested how that works in practice, and how the practice compares to something like TP/FPC/Delphi. Basically most .h/.c files should be easily convertible, if you don't rely in the .h on preprocessor symbols from before the .h's inclusion. Basically that what it is, the bulk of .h(pp)/.c(pp) files that are tightly coupled can then be easier precompiled because the state before the inclusion no longer matters.

That is also one of the fundaments of Pascal/modula2 units/modules.

> The less reliance on brittle (unportable) makefiles and POSIX shell, the
> better. (Doesn't even Win10 have Bash and Curl nowadays??)

No, that is a separate add-on install.

> > Maybe in 2040 they finally realize that = vs == is not smart either.
>
> The switch statement could definitely be fixed.

Yup.

> But they'll probably keep
> assignment in expressions. (Nested functions would be very nice to
> standardize, too. GCC and TCC support it, so do others like D.)

Proper nested functions is a complex topic, specially how nested functions can reach their parents parameters and variables, even when recursing.

Afaik gcc doesn't really support that, only simple nesting.

> > I swear they intentionally avoid mentioning these details (and VT-X
> > and a billion other features, who can even keep track?).
>
> Partially yes to have a really drawn out product-palette.

"WinXP Mode" (not for home users!) didn't need it, but Hyper-V (only in Pro 64-bit) does. That may formerly have been more Intel stubbornness than MS.

> Well, since my last (private) laptop was Sony, and Sony got out of the
> laptop biz, I'll need to find a new brand

Brand means almost nothing. It's probably different people, different ideals across the years. But if you know nothing else (e.g. detailed specs), brand loyalty is better than nothing.

> My work laptop is Medion, which is a large German OEM afaik which uses
> Akoya (or something) branded mobos. Aldi and Mediamarkt/Saturn peddle their
> stuff.

Gesundheit (obvious joke). Never heard of it. All we have is the mundane HP, Dell, MS, Apple, Lenovo, Asus, etc.

> I bought it mainly because back then they were the only brand that had
> SSD/HDD combo systems for under Eur 1000.

You mean hybrid or dual (side-by-side)? Probably dual.

> > Ever looked at FSF's "Respect Your Freedom" (refurbished?) laptops?
> > Quite ancient (2008-ish?) tech but no ME or PSP or whatever.
>
> No. I mostly run Windows nowadays.

Intel's ME used your beloved Minix 3 behind the scenes. I don't think Andy (now retired) appreciated that, even if it did comply with BSD licensing.

I'm not that paranoid. I guess I'd almost rather have a reproducibly free/libre machine, even if old. (God forbid I use two separate devices!) Some people cannot be trusted.

But my hacks are wimpy anyways. Even if we could get a totally free system (with FreeDOS or Linux or Minix or Oberon), what would a wimp like me do with it? Rebuild FPC??

(This isn't quite what I meant, but one guy did convert the Oberon RISC emulator (EDIT: from C) to FPC + SDL2.)

> > I need to rebuild the Go32v2 version one of these days.
> It really should be buildable in DOS natively.
>
> It could at some point, though most used Win9x. Later XP.

Certainly FreeDOS (under VM) is more viable than those other "dead" OSes, IMHO.

> > Have you seen any Windows ARM64 machines? What are your opinions?
>
> Currently irrelevant.

IIRC ... always-on (phone?), emulates IA-32 software up through SSE2 (yet with native ARM64 drivers) and even emulates DirectX 9-12. Sounds interesting.

> > The less reliance on brittle (unportable) makefiles and POSIX shell, the
> > better. (Doesn't even Win10 have Bash and Curl nowadays??)
>
> No, that is a separate add-on install.

Okay, I wouldn't know, but it's very easy to download, presumably. (Just to split hairs, even "Win 10 S" only allows downloading from their Store [cheaper, more secure] unless you upgrade to Pro.)

> > (Nested functions would be very nice to standardize, too.
> > GCC and TCC support it, so do others like D.)
>
> Proper nested functions is a complex topic, specially how nested functions
> can reach their parents parameters and variables, even when recursing.
>
> Afaik gcc doesn't really support that, only simple nesting.

Trampolines? (I have no idea.) Yeah, I didn't say it was necessarily perfect or easy, just that some people heavily prefer them. It wouldn't be the first time something unpopular was standardized. (Make it optional?? But even that kind of thing some people are against.)

> Brand means almost nothing. It's probably different people, different
> ideals across the years. But if you know nothing else (e.g. detailed
> specs), brand loyalty is better than nothing.

Sure. The Sony example was bad, VAIO was much more expensive than I would usually buy, but this was during inventory clearing; I bought a refurbished 3000 series when 4000 series came out. (and the refurbished bit was mostly a bit of minor scratching), so it was less than half of the price.

The Medion story was what closer to what I meant. Only that brand had combinations of features that I deemed necessary. (more for work than for Private, since for work I often have quite large directories of test images). At least then, now SSD sizes have risen somewhat again.

That said, I think it really is a shame that various listings don't list free bays of a laptop. Then you could add storage only if it really was a problem.

> > My work laptop is Medion, which is a large German OEM afaik which uses
> > Akoya (or something) branded mobos. Aldi and Mediamarkt/Saturn peddle
> their
> > stuff.
>
> Gesundheit (obvious joke).

Don't you mean "gezondheid" ?

> Never heard of it. All we have is the mundane
> HP, Dell, MS, Apple, Lenovo, Asus, etc.

Yup, except for Apple of course since it doesn't sell Windows laptops afaik.

> > > I need to rebuild the Go32v2 version one of these days.
> > It really should be buildable in DOS natively.
> >
> > It could at some point, though most used Win9x. Later XP.
>
> Certainly FreeDOS (under VM) is more viable than those other "dead" OSes,
> IMHO.

Does it finally have decent LFN driver? That and commandline lengths are usually the breaking point.

> > > > Have you seen any
> Windows ARM64
> machines? What are your opinions?
> >
> > Currently irrelevant.
>
> IIRC ... always-on (phone?), emulates IA-32 software up through SSE2 (yet
> with native ARM64 drivers) and even emulates DirectX 9-12. Sounds
> interesting.

Maybe if it is ultra portable I could use it to run our Windows CRM client. But I have my doubts.

Yesterday I did some benchmarking of FPC building:

- RPI4 (32-bit(*)) with SSD (not flash) 4 minute 5 seconds
- Ryzen 2600 with SSD 1 minute 2 seconds.

That is still quite a gap, and then emulation overhead on top of that? Brr.

(*) Arm 64-bit still works with GNU AS as backend assembler and thus is twice as slow as the arm 32-bit (or x86 32/64-bit) targets that do have internal assembler and don't have to write it out as text and then parse it again.

> Okay, I wouldn't know, but it's very easy to download, presumably. (Just to
> split hairs, even "Win 10 S" only allows downloading from their Store
> [cheaper, more secure] unless you upgrade to Pro.)

Yeah. I regard Win 10 S as Chromebooks. Fine if you need something ultra portable for some surfing and minor document work, but if you don't really need that form-factor a lot, it is redundant

> > > (Nested functions would be very nice to standardize, too.
> > > GCC and TCC support it, so do others like D.)
> >
> > Proper nested functions is a complex topic, specially how nested
> functions
> > can reach their parents parameters and variables, even when recursing.
> >
> > Afaik gcc doesn't really support that, only simple nesting.
>
> Trampolines? (I have no idea.)

There are many ways. Displays is the most common one (which is just passing a pointer to a record with framepointers btw). Trampolines is afaik more a workaround if you don't want to change your stack and parameter handling too much.

> > > My work laptop is Medion, which is a large German OEM
> >
> > Gesundheit (obvious joke).
>
> Don't you mean "gezondheid" ?

You know, America is fairly uncultured, including myself. But it's still sometimes a joke when people pretend to be fancy: "Pardonez moi!"

You said German (not Dutch) OEM, so I said "Gesundheit!" Here in the States, we say that when someone sneezes (or "Bless you."), but it's also a joke when someone says something unintelligible (almost as if a sneeze). So since I've never heard of "Medion", I was joking. (I assume you half knew that already.)

> > Never heard of it. All we have is the mundane
> > HP, Dell, MS, Apple, Lenovo, Asus, etc.
>
> Yup, except for Apple of course since it doesn't sell Windows laptops
> afaik.

Bootcamp still exists, right? Dunno, never owned a Mac, and they indeed are a bit overpriced (as any Linux nerd will tell you ... wait, didn't Linus actually prefer a Macbook because of its battery life or convenience??).

> > > > I need to rebuild the Go32v2 version one of these days.
> > > It really should be buildable in DOS natively.
> > >
> > > It could at some point, though most used Win9x. Later XP.
> >
> > Certainly FreeDOS (under VM) is more viable than those other "dead"
> > OSes, IMHO.
>
> Does it finally have decent LFN driver? That and commandline lengths are
> usually the breaking point.

No native LFN support in the kernel (yet, if ever). Patents did finally expire in 2017 (ugh). We still only have old tools like (2012??) third-party TSR DOSLFN. It's somewhat slow, but it mostly works.

Cmdline stuff was automatically solved long ago for DJGPP stuff (via proxy). Those specific Watcom tools should've been cross-compiled for DJGPP to avoid such hangups.

> Yesterday I did some benchmarking of FPC building:
>
> - RPI4 (32-bit(*)) with SSD (not flash) 4 minute 5 seconds
> - Ryzen 2600 with SSD 1 minute 2 seconds.
>
> That is still quite a gap, and then emulation overhead on top of that?
> Brr.

Keep in mind that recompiling p7zip natively in DOS (with admittedly old G++ 3.4.6) also only took four minutes, IIRC. Yes, emulation can be very slow. Still, not to complain, slow emulation is better than literally nothing, as long as it's relatively accurate.

> > > > (Nested functions would be very nice to standardize, too.
> > > > GCC and TCC support it, so do others like D.)
> > >
> > > Proper nested functions is a complex topic, specially how nested
> > > functions can reach their parents parameters and variables,
> > > even when recursing.
> > >
> > > Afaik gcc doesn't really support that, only simple nesting.
> >
> > Trampolines? (I have no idea.)
>
> There are many ways. Displays is the most common one (which is just passing
> a pointer to a record with framepointers btw). Trampolines is afaik more a
> workaround if you don't want to change your stack and parameter handling
> too much.

Macs don't like trampolines, IIRC, and I'm not even sure if GPC works there anymore (from what little I read). Of course, they also discontinued 32-bit apps entirely, so that probably doesn't help. It's main platforms like that which hold up others (for good or bad, their dislike of Flash probably helped, indirectly, which is rare). I'm not complaining, if anything they probably have good reasons. BUT ... nested functions are (yet another) feature that many people can't live without. I wonder how Pascal-p5c deals with it (probably using the GCC extension, I haven't looked closely).

> > > > My work laptop is Medion, which is a large German OEM
> > >
> > > Gesundheit (obvious joke).
> >
> > Don't you mean "gezondheid" ?
>
> You know, America is fairly uncultured, including myself. But it's still
> sometimes a joke when people pretend to be fancy: "Pardonez moi!"

Well the default here is more "Je ne comprend pas!". At least that is the quintessential reaction of the French according to urban legend.

> You said German (not Dutch) OEM, so I said "Gesundheit!" Here in the
> States, we say that when someone sneezes (or "Bless you."),

Well, that is because that is what you are supposed to say in that case (also the Dutch version). There is no equivalent for "Bless you" in this context.

> but it's also a
> joke when someone says something unintelligible (almost as if a sneeze). So
> since I've never heard of "Medion", I was joking. (I assume you half knew
> that already.)

Somewhat :) But Medion sells here in those stores too, and their manuals are usually translated

> > > Never heard of it. All we have is the mundane
> > > HP, Dell, MS, Apple, Lenovo, Asus, etc.
> >
> > Yup, except for Apple of course since it doesn't sell Windows laptops
> > afaik.
>
> Bootcamp still exists, right?

Yeah, but why pay the idiot tax to run an emulator ?

> Dunno, never owned a Mac, and they indeed are
> a bit overpriced (as any Linux nerd will tell you ... wait, didn't Linus
> actually prefer a Macbook because of its battery life or convenience??).

It happens. I had a pendant for PPC Mac Mini's for a while. They had superior standby behaviour earlier than the rest, and still could double as funky *nix workstation.

Similarly some old friends preferred the rather more expensive Apple Gestalts (afaik Apple called it that in the US too in datasheets, mostly just the specific case incarnation with different inner workings), just because they took insane amount of RAMs, and could be upgraded in later life. With SDRAM however RAM prices bottomed out for the first time, and that was pretty much the end of that philosophy, from then on per unit, new RAM would be cheaper than old RAM.

> > Does it finally have decent LFN driver? That and commandline lengths are
> > usually the breaking point.
>
> No native LFN support in the kernel (yet, if ever). Patents did finally
> expire in 2017 (ugh). We still only have old tools like (2012??)
> third-party TSR DOSLFN. It's somewhat slow, but it mostly works.
>
> Cmdline stuff was automatically solved long ago for DJGPP stuff (via
> proxy). Those specific Watcom tools should've been cross-compiled for DJGPP
> to avoid such hangups.

The next FPC version eliminates Watcom tools. (maybe not yet for win3.1x native though). Generating 16-bits dos apps on 64-bits *nix without external tools is now viable.

> Keep in mind that recompiling p7zip natively in DOS (with admittedly old
> G++ 3.4.6) also only took four minutes, IIRC. Yes, emulation can be very
> slow. Still, not to complain, slow emulation is better than literally
> nothing, as long as it's relatively accurate.

I never compiled p7zip

> > > > Afaik gcc doesn't really support that, only simple nesting.
> > >
> > > Trampolines? (I have no idea.)
> >
> > There are many ways. Displays is the most common one (which is just
> passing
> > a pointer to a record with framepointers btw). Trampolines is afaik more
> a
> > workaround if you don't want to change your stack and parameter handling
> > too much.
>
> Macs don't like trampolines,

Since 2008, nobody likes trampolines since they require writable stack. Most 64-bit targets were fairly quick to require that also(since they had no legacy software)

> IIRC, and I'm not even sure if GPC works there
> anymore (from what little I read).

Well, the writing has been on the wall for a long time. Pity that they never did the reboot that Frank was talking about( generating C, more FB cgen style). Even though it wasn't my cup of tea, I was somewhat curious to see how it would turn out in practice.

> BUT ... nested functions are (yet another)
> feature that many people can't live without. I wonder how Pascal-p5c deals
> with it (probably using the GCC extension, I haven't looked closely).

From the website, it looks superficial, very basic. Wouldn't be surprised if FPC's ISO mode was more compatible.

> Well the default here is more "Je ne comprend pas!". At least that is the
> quintessential reaction of the French according to urban legend.

No one speaks French here, including me. (BTW, happy Mardi Gras.)

> > > > Never heard of it. All we have is the mundane
> > > > HP, Dell, MS, Apple, Lenovo, Asus, etc.
> > >
> > > Yup, except for Apple of course since it doesn't sell Windows laptops
> > > afaik.
> >
> > Bootcamp still exists, right?
>
> Yeah, but why pay the idiot tax to run an emulator ?

Some people need or use both, apparently. Hey, why pay the Windows tax if all you're going to use is Linux?? Why pay state taxes for almost all online purchases, including digital (like has been forced around here in recent years)?? Dunno!!

Want a good laugh? Apple’s MS-DOS Compatible 486 Macintosh from 1995! "The Power Macintosh 6100/66 DOS Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside!"

Nowadays, just run a hypervisor (presumably xhyve, based upon bhyve ... or maybe Parallels?). I haven't been as active in recent years, so I've done very little, but FreeDOS 1.3rc2 is out.

> The next FPC version eliminates Watcom tools. (maybe not yet for win3.1x
> native though). Generating 16-bits dos apps on 64-bits *nix without
> external tools is now viable.

I noticed via snapshots, just haven't tried to rebuild it myself.

> > Keep in mind that recompiling p7zip natively in DOS (with admittedly old
> > G++ 3.4.6) also only took four minutes, IIRC. Yes, emulation can be very
> > slow. Still, not to complain, slow emulation is better than literally
> > nothing, as long as it's relatively accurate.
>
> I never compiled p7zip

A quick try yesterday, with newer G++ 9.2.0, didn't show any huge slowdowns, so that's good. (GCC itself was converted to a subset of C++03 back in '13. I believe C++11 support finalized in the 4.8.x series. More or less, C++17 is fully supported in latest stable versions, barring platform anomalies.)

IIRC, *BSD has libarchive and its own unzipper these days. Ubuntu has included Info-Zip as default for a few years. Yeah, I remember FreeBSD has xz nowadays, too (.txz in RELEASE while OpenBSD still uses inferior .tgz, 32 kb dictionary vs. 16 MB, I think). i386/AMD64 are still "tier one" on FreeBSD, right?

Oh, I never bothered with Raspberry Pi, but FreeBSD apparently still (!) supports ARMv6 for that. I was amazed, years ago, since most people hated that old arch, that anybody at FreeBSD was sympathetic. (Of course, I'm sympathetic, from afar, just because it can't be that bad, but most people hate hate hate such "old" things! Yes, I know, newer versions have newer arches, so who cares.)

> > > > > Afaik gcc doesn't really support that, only simple nesting.
> > > >
> > > > Trampolines? (I have no idea.)
> >
> > Macs don't like trampolines,
>
> Since 2008, nobody likes trampolines since they require writable stack.

Executable stack, I presume you mean. (I'm no systems engineer, I don't fully know the details.) See Wikipedia.

> Most 64-bit targets were fairly quick to require that also(since they had
> no legacy software)

If you constantly and forcibly upgrade everything, it matters less. Not everything should be rolling release, though. (Doesn't ZFS on some modern OSes have fallbacks nowadays?)

> > IIRC, and I'm not even sure if GPC works there
> > anymore (from what little I read).
>
> Well, the writing has been on the wall for a long time. Pity that they
> never did the reboot that Frank was talking about( generating C, more FB
> cgen style). Even though it wasn't my cup of tea, I was somewhat curious to
> see how it would turn out in practice.

The ancient 3.4.6 codebase (2005?) was in C (K&R?), which made things difficult when they couldn't extend it, at least not as easily. Though I doubt C++ is a panacea for all ills.

GPC was mostly paid work, so I think the main developer (and other dude) were only interested in getting paid. (Not to sound cynical, but I think that's fair.) He didn't care for his own use, he actually preferred C++11, so he was only interested if someone else was financially interested. Apparently old users gave up and migrated to other things.

I did see one guy from .nl (SARC?) "privately" migrated from Extended Pascal (Prospero, not GPC) to D. I don't really blame him, I know it can get complicated, but his attempts to use FPC and Ada didn't pan out (surprisingly), yet he really loves D! Good for them, I guess.

What a strange world.

> > BUT ... nested functions are (yet another)
> > feature that many people can't live without. I wonder how Pascal-p5c
> > deals with it (probably using the GCC extension, I haven't looked closely).
>
> From the website, it looks superficial, very basic. Wouldn't be surprised
> if FPC's ISO mode was more compatible.

D is integrated as official frontend into GCC nowadays since 9.x, and it supports nested functions. Barring implementation limits or bugs or OS-specific problems, it makes no sense to say that GCC (or C or C++) can't handle it if it already handles it in the D frontend. That doesn't mean anybody cares or needs it that badly, nor that it will be standardized, just that it's "probably" not impossible.

Oh, BTW, GM2 (ISO 10514, ISO Modula-2 atop GCC) also works with nested procedures (and C++-compatible exceptions, your Delphi favorite feature), though I've barely tested it (years ago). Similarly, it probably will get merged one day. I always check this one blog from time to time.

> > Yeah, but why pay the idiot tax to run an emulator ?
>
> Some people need or use both, apparently. Hey, why pay the Windows tax if
> all you're going to use is Linux??

It shouldn't, but is simply too hard to avoid. But you can choose not buying an Apple and just a normal device.

> Want a good laugh? Apple’s MS-DOS
> Compatible 486 Macintosh from 1995! "The Power Macintosh 6100/66 DOS
> Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and
> Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside!"

Yeah, I've actually worked with such card once, though in slightly later Mac (4400 or its clone?), circa 2000 to run Turbo Pascal during a FPC get-together. I didn't have a laptop back then, and one of the local guys brought this one to work on for me.

> > The next FPC version eliminates Watcom tools. (maybe not yet for win3.1x
> > native though). Generating 16-bits dos apps on 64-bits *nix without
> > external tools is now viable.
>
> I noticed via snapshots, just haven't tried to rebuild it myself.

rc1 has been branched, probably takes a week or two before all is uploaded and announced.

> i386/AMD64 are still "tier one" on FreeBSD, right?

I don't do much FreeBSD. The servers that I have used for 2015 were taken offline in fall 2018, and at home I mostly switched to Linux derivatives due to HW support.

> Oh, I never bothered with Raspberry Pi, but FreeBSD apparently still (!)

I have all 4 iterations (1,2,3,4), so maybe I should give it a whirl.

> > Since 2008, nobody likes trampolines since they require writable stack.
>
> Executable stack, I presume you mean. (I'm no systems engineer, I don't
> fully know the details.) See
> Wikipedia.

Yup, sorry. That link seems to indicate that they are better than fat pointers or displays (which are stack records with information), without providing the reasons.

I only know what the GPC people told me long ago, that they chose it because it aligned with GPC. I also heard that the "C" nested implementation was limited, but also never verified that independently.

More complex cases of accessing parent parameters with multiple levels and recursion (basically writing a recursive descent parser as nested procs) was said to be big dividing line.

However such very procedural code is now much rarer.

> > Most 64-bit targets were fairly quick to require that also(since they
> had
> > no legacy software)
>
> If you constantly and forcibly upgrade everything, it matters less.

If the work sticking to the old stuff becomes larger than the disadvantages on the newer incarnation, I upgrade. Nostalgia is overrated.

> Not
> everything should be rolling release, though. (Doesn't ZFS on some modern
> OSes have fallbacks nowadays?)

I've no idea. I don't like rolling releases, I mostly use LTS versions.

(GPC)
> The ancient 3.4.6 codebase (2005?) was in C (K&R?), which made things
> difficult when they couldn't extend it, at least not as easily. Though I
> doubt C++ is a panacea for all ills.

At least typesafety and amount of casts would lessen somewhat.

> GPC was mostly paid work, so I think the main developer (and other dude)
> were only interested in getting paid. (Not to sound cynical, but I think
> that's fair.)

IMHO not fair. They worked on it voluntarily while they also used it at work. And they deserve credit for that volunteer work.

> He didn't care for his own use, he actually preferred C++11,
> so he was only interested if someone else was financially interested.

The company had changed a decade before that reckoning, so some synergies were gone. And then hobby becomes a chore.

> Apparently old users gave up and migrated to other things.

Most were already quite old.

> I did see one guy from .nl (SARC?) "privately"
> migrated
> from Extended Pascal (Prospero, not GPC) to D. I don't really blame him, I
> know it can get complicated, but his attempts to use FPC and Ada didn't pan
> out (surprisingly), yet he really loves D! Good for them, I guess.

Strange post, his demands are weird, and many have no or few details. Comparing GCed to non GC languages is IMHO apples and oranges anyway, and it heavily depends on intended application.

Usually such tradeoffs are driven in the direction the main guy wants anyway. It is usaully more about finding justification than to really measure the various languages. More importantly, I complete miss other aspects than language (libraries, target concerns, IDE, gui etc etc), which is another sign it is crafted for a specific audience when the decision already had effectively been made.

In my case D being GCed would earn a -50. Useless.

> D is integrated as official frontend into GCC nowadays since 9.x, and it
> supports nested functions. Barring implementation limits or bugs or
> OS-specific problems, it makes no sense to say that GCC (or C or C++) can't
> handle it if it already handles it in the D frontend.

C also has nested functions, but like D I don't know how far it goes. The need for trampolines would usually indicates a more advanced usage though.

> That doesn't mean
> anybody cares or needs it that badly, nor that it will be standardized,
> just that it's "probably" not impossible.

It can also mean that it only supports cases that can be transformed to internal form that doesn't do anything special. Probably you'd have to dig into the C and D regression suites to see what it supports.

> Oh, BTW, GM2 (ISO 10514, ISO Modula-2 atop GCC) also works with nested
> procedures (and C++-compatible exceptions, your Delphi favorite feature),

Don't understand. Do you mean SEH?

> though I've barely tested it (years ago). Similarly, it probably will get
> merged one day. I always check this one
> blog from time to time.

Browsed through it. Mostly same content as 2003. See that the M2 R10 stuff is also dead. (not that sad about it, IMHO it was a bit too baroque)

> Want a good laugh? Apple’s MS-DOS
> Compatible 486 Macintosh from 1995! "The Power Macintosh 6100/66 DOS
> Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and
> Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside!"

Nice and compact machine 2 in 1. Years ago I saw some x86 "emulator" long PCI card for MAC on ebay, quite overpriced. It contained almost whole PC with some Pentium, chipset, RAM, VGA, SB...
Hypervisors/VMs are nice but doesn't much bother with SB emulation - not interesting for business apps of course (...but I just read on Vogons that new VMWare improved theirs SB emulated HW so maybe not as bad...). It would be nice to have a modern PCIE card with some legacy PC that could run it's own system and send image data over PCIE to display them in host OS window and with some kind of file sharing...

---
DOS gives me freedom to unlimited HW access.

> > GPC was mostly paid work, so I think the main developer (and other dude)
> > were only interested in getting paid. (Not to sound cynical, but I think
> > that's fair.)
>
> IMHO not fair. They worked on it voluntarily while they also used it at
> work. And they deserve credit for that volunteer work.

Not a criticism, just an observation. One developer quoted an hourly wage to rewrite, and one user donated a noticeable amount of cash. That was in later years, when things were already stagnant. But it was still never integrated properly into GCC because they couldn't maintain their work in-tree (for whatever reason) and couldn't deal with the various backend bugs nor the tedious kludges needed to work in C (apparently).

I don't know, honestly. It was a cool compiler with good dialect support, but it just was too brittle, I suppose. (I had it installed [DJGPP version, of course] on XP in 2005 before I even knew what to do with it.)

N.B. "m o n e y" is a dirty word, according to this forum software, literally.

> > I did see one guy from .nl (SARC?) "privately" migrated from
> > Extended Pascal (Prospero, not GPC) to D. I don't really blame him,
> > I know it can get complicated, but his attempts to use FPC and Ada
> > didn't pan out
>
> Strange post, his demands are weird, and many have no or few details.
> Comparing GCed to non GC languages is IMHO apples and oranges anyway, and
> it heavily depends on intended application.

He seemed to have his reasons. I don't second-guess him too badly. Still, you would think that FPC or Ada would at least be halfway home, but maybe not. D seems farther away, but I guess it's not impossibly far.

D can minimize (or "mostly" eliminate) GC usage, AFAIK, and the runtime library has been rewritten to avoid it sometimes. So it's not that bad. Besides, there are different kinds of GC, so they aren't all the same (or slow, buggy). Don't forget that Oberon (usually, but not always) has GC, too. Even Ada was supposedly designed to optionally support it.

> Usually such tradeoffs are driven in the direction the main guy wants
> anyway. It is usaully more about finding justification than to really
> measure the various languages. More importantly, I complete miss other
> aspects than language (libraries, target concerns, IDE, gui etc etc), which
> is another sign it is crafted for a specific audience when the decision
> already had effectively been made.

I don't think he made the decision by himself. Rather, it seems he consulted with the company hierarchy itself first.

> In my case D being GCed would earn a -50. Useless.

Lua also has GC, but it's written in C. Mark and sweep?? I dunno, but it varies by implementation. However, you do have a point. I remember reading that Modula-3's [sic] biggest portability problem was its GC, by far. (You know, FreeBSD's cvsup was written in it, I think.)

GC is not perfect by any means, and I don't know enough to even pretend to advocate for it. But it's not (necessarily) the end of the world either.

> > Oh, BTW, GM2 (ISO 10514, ISO Modula-2 atop GCC) also works with nested
> > procedures (and C++-compatible exceptions, your Delphi favorite
> feature),
>
> Don't understand. Do you mean SEH?

I just meant that ISO added exceptions, unlike PIM. And exceptions are something that Delphi has that Turbo didn't. That's all. (You know, even C++ didn't have exceptions until much later, IIRC roughly AT&T 3.0 [1990??].)

> > though I've barely tested it (years ago). Similarly, it probably will
> > get merged one day. I always check this one
> > blog from time to time.
>
> Browsed through it. Mostly same content as 2003. See that the M2 R10 stuff
> is also dead. (not that sad about it, IMHO it was a bit too baroque)

R10 just simplified a bit, made it more Oberon-like (type extension, no variant records, IIRC). Let's be honest, ISO Modula-2 itself is a bit baroque, which is why many prefer PIM or Oberon (which is very non-standard, esp. for simple things like files or paramcount/paramstr that TP and C have by default). That makes little sense, why would people prefer non-standard? But they do. Still, I like Oberon a lot, but implementations vary quite a bit. (Standardization itself is overkill sometimes or too weak or unpopular, so I don't blame them for not wasting their time. C# is standard, but Java is not. Look at BASIC, its standards are heavily ignored, worse than Pascal, even!)

Long story short, I'm still sympathetic to ISO Modula-2 and Oberon-07 and whatever else (FPC/TP, of course). But it's like a weird halfway between two sides, even though neither will win.

> > IMHO not fair. They worked on it voluntarily while they also used it at
> > work. And they deserve credit for that volunteer work.
>
> Not a criticism, just an observation. One developer quoted an hourly wage
> to rewrite, and one user donated a noticeable amount of cash. That was in
> later years, when things were already stagnant. But it was still never
> integrated properly into GCC because they couldn't maintain their work
> in-tree (for whatever reason) and couldn't deal with the various backend
> bugs nor the tedious kludges needed to work in C (apparently).

Well, they were amateur (the GPC maintenance, not their usage in the company), while after 2000 GCC mostly had commercial. Still I never understood why GPC didn't centralize development more, had a VCS, a bug tracker etc.

> I don't know, honestly. It was a cool compiler with good dialect support,
> but it just was too brittle, I suppose. (I had it installed [DJGPP version,
> of course] on XP in 2005 before I even knew what to do with it.)

I actually tried GPC before FPC in 1997ish. Release were already old, couldn't get it to work reliably, non clear pointers on development versions, so I ended up with FPC.

> N.B. "m o n e y" is a dirty word, according to this forum software,
> literally.

Hehe. Well, we temporily banned the whole of China because of one bot, so I'd better not cast the first stone

> > > I did see one guy from .nl (SARC?) "privately" migrated from
> > > Extended Pascal (Prospero, not GPC) to D. I don't really blame him,
> > > I know it can get complicated, but his attempts to use FPC and Ada
> > > didn't pan out
> >
> > Strange post, his demands are weird, and many have no or few details.
> > Comparing GCed to non GC languages is IMHO apples and oranges anyway,
> and
> > it heavily depends on intended application.
>
> He seemed to have his reasons. I don't second-guess him too badly. Still,
> you would think that FPC or Ada would at least be halfway home, but maybe
> not. D seems farther away, but I guess it's not impossibly far.

I do second guess him. If the closest languages were not easy, you'd expect him to go with something mainstream, like Java/C# etc. GO,Rust,Python if need be.

But he ends up with D. He *chooses* from his dead-end minority Pascal compiler (and then I take Delphi as the majority one, not FPC) to rewrite in another boutique language.

I don't buy that, and to buy that he needs some very, very solid reasons. And what he produces is an amateur evaluation of languages that I could have regurgitated in 1998 in my sleep. No, no benefit of the doubt there.

His evaluation does push enormous "alarm" buttons in my mind because it is solely focused on language. Maybe this is because it is an engineering firm (and his apps are mostly calculating). But half of the his language arguments are about general application code, not purely calculating one. (like the safe pointers bit)

This is what me forces to reject this post. IMHO it is political.

> D can minimize (or "mostly" eliminate) GC usage, AFAIK, and the runtime
> library has been rewritten to avoid it sometimes. So it's not that bad.

I only saw fragments of this, never whole application examples. This might be fine if you are coding a isolated codec plugin in a DLL in D, but is it really relevant for application development in D as advertised?

> Besides, there are different kinds of GC, so they aren't all the same (or
> slow, buggy).

Afaik the D website itself says it is the worst "stop all threads with a global GC lock" kind. So that is not up for discussion.

> Don't forget that Oberon (usually, but not always) has GC,

Yes. Don't forget how far Oberon got. Exactly.

> too. Even Ada was supposedly designed to optionally support it.

Yes. Delphi was heavily modified also (a brief spell of Delphi.NET). But while it worked, it was more a special cases thing (and in Ada's case, to steer it past certain US military requirements), not something to desire for your every day.

> > Usually such tradeoffs are driven in the direction the main guy wants
> > anyway. It is usaully more about finding justification than to really
> > measure the various languages. More importantly, I complete miss other
> > aspects than language (libraries, target concerns, IDE, gui etc etc),
> which
> > is another sign it is crafted for a specific audience when the decision
> > already had effectively been made.
>
> I don't think he made the decision by himself. Rather, it seems he
> consulted with the company hierarchy itself first.

This looks like a one person document to me. I don't know if it is of his hand, or from the person who proclaimed D. I also miss all other majority languages in the comparison. I can't really believe something like this (and as far reaching as moving from a non-gc to gced language) is based on a 10 point language comparison.

One might as well toss a coin.

> > In my case D being GCed would earn a -50. Useless.
>
> Lua also has GC, but it's written in C.

Yeah, so no Lua for me. Point?

> Mark and sweep?? I dunno, but it
> varies by implementation. However, you do have a point. I remember reading
> that Modula-3's [sic] biggest portability problem was its GC, by far. (You
> know, FreeBSD's cvsup was written in it, I think.)

I know. I actually volunteered to look at it, in the hope of maintaining it.

And no, it was not the GC I think (since CVSUP is mostly a batch problem, a simple solution was simply be to never release memory, and try to handle some of the larger blocks manually.

The problem was simply the same that we have discussed here on this forum many times. The issue of no maintainership for extended periods of time (I think back then it was 2006 or 2007, and maintainerless since the mid to late nineties except for emergency fixes by ports@)

> GC is not perfect by any means, and I don't know enough to even pretend to
> advocate for it. But it's not (necessarily) the end of the world either.

No, it is "stop the world" :_)

Of course it is not the end of the world. But it is the end of the world for the category that is measured here. You might as well migrate to C# or Java then. So why aren't these in the list? He says himself that source-to-source conversion is not the problem. So why is the ugly duckling D suddenly the knight in shining armour?

For me, I'm in realtime image analysis, and many GCs feature a global lock that simply paralyses the application. So at the very least that would mean separating the codebase into two parts, e.g. a C++ part that does the main analysis and the more loosely coupled GUI part on top of it in "any" language.

> (You know, even
> C++ didn't have exceptions until much later, IIRC roughly AT&T 3.0
> [1990??].)

I've no idea. I didn't really consider C++ much before say late nineties. While I was aware of it, the subject was more the unique principles of Cfront rather than the language itself.

But the core difference is that exceptions only affect the current thread. It doesn't block another thread trying to allocate memory. (and usually the cost is also a magnitude less)

> > Browsed through it. Mostly same content as 2003. See that the M2 R10
> stuff
> > is also dead. (not that sad about it, IMHO it was a bit too baroque)
>
> R10 just simplified a bit, made it more Oberon-like (type extension, no
> variant records, IIRC).

Yes. Exactly that. It went from the System programming language that M2 was to be to the academic experiments that came after it. Useless. Oberon has been an interesting experiment (and doubly so because it was actually implemented), but nearly unusable for anything real.

Also most of the extensions seemed to be because of some strange desire to make M2 relevant for application development (as underpinning of the mythical objective M2). Which was, let's be honest, a whole delta worth of bridges too far.

IMHO it stood a better chance focussing on embedded, close to the machine. No world domination aspirations, just solid design and engineering.

> Still, I like Oberon a lot

I like Oberon like a small exe. Fun to see that a small grammar is possible, now let's take something else and get real work done.

> Long story short, I'm still sympathetic to ISO Modula-2 and Oberon-07 and
> whatever else (FPC/TP, of course). But it's like a weird halfway between
> two sides, even though neither will win.

Well, ISO M2 is mostly after my time (in my time it was more PIM3 vs PIM4), but it didn't seem as bad as you make it out to be. Oberon is IMHO in a totally different direction, and I don't see the synergy to be honest.

> I actually tried GPC before FPC in 1997ish. Release were already old,
> couldn't get it to work reliably, non clear pointers on development
> versions, so I ended up with FPC.

In 1997, I was using DJGPP for the first time (GCC 2.7.2.1) on a 486 (recompiling Allegro took 30 minutes). I was too young and dumb, and my pre-standard (1995, DOS, Turbo C++ Lite) book's code didn't run with it, so I gave up for a while and stuck to writing assembly. (I should've learned TP or Oberon. I greatly missed modules, sets, and not having to reinvent the wheel for obvious stuff. Sometimes writing raw assembly is pointless tedium.)

I had GPC installed in 2005 but never used it properly. It was only by 2010 where I tried using it to learn ISO Pascal (and derivatives). In 2013, I wrote a GNUmakefile for P5 and rebuilt it for Win32, Linux, and DOS (with GPC) and ran the test suite. I wrote a simple Befunge-93 interpreter, with some fixes for P5, that also compiled under TP compatibles. Trivial but interesting (to me). Of all the rewrites of that interpreter, I willingly spent the most time on Pascal and Oberon.

> > Don't forget that Oberon (usually, but not always) has GC,
>
> Yes. Don't forget how far Oberon got. Exactly.

Overall, I greatly admire Oberon, but it's not as portable nor robust as Free Pascal. But both are very good. Oberon accomplished a lot, actually, as did Modula-2. But Pascal was more popular.

Hey, even your beloved ACK had ISO Pascal and PIM Modula-2 support, among others (ANSI C, primitive BASIC, etc). Though Minix 3 long ago switched to Clang (and NetBSD userland).

> > > In my case D being GCed would earn a -50. Useless.
> >
> > Lua also has GC, but it's written in C.
>
> Yeah, so no Lua for me. Point?

C is considered a baseline of useful, and a GC-enabled language written in portable C is probably not considered broken. But I guess your needs are different.

> > Modula-3's [sic] biggest portability problem was its GC, by far.
> > (You know, FreeBSD's cvsup was written in it, I think.)
>
> And no, it was not the GC I think (since CVSUP is mostly a batch problem, a
> simple solution was simply be to never release memory, and try to handle
> some of the larger blocks manually.
>
> The problem was simply the same that we have discussed here on this forum
> many times. The issue of no maintainership for extended periods of time (I
> think back then it was 2006 or 2007, and maintainerless since the mid to
> late nineties except for emergency fixes by ports@)

DEC was bought by Compaq in 1997, which was bought by HP in 2002. The code was "POSIX or Windows", 32-bit or greater only, and not exactly simple. Although there were two or three ports to DOS, even, it was never properly maintained nor upstreamed to GCC (copyright reasons). CM3 had a release in 2010 based upon GCC 4.3.x but never got beyond that. IIRC, threading was built into the language itself, using a background thread for GC. But such a language (objects, generics, exceptions, threads, garbage collection) was less useful in later years, when most other competing languages had most of those features. It was simpler than Ada or C++, but that's not saying much.

> For me, I'm in realtime image analysis, and many GCs feature a global lock
> that simply paralyses the application. So at the very least that would mean
> separating the codebase into two parts, e.g. a C++ part that does the main
> analysis and the more loosely coupled GUI part on top of it in "any"
> language.

Keep in mind that there are some rare Oberon implementations that lack garbage collection, and you're encouraged to omit it and just use DISPOSE, if it meets your needs. But clearly you have other requirements even beyond that.

> Oberon has been an interesting experiment (and doubly so because
> it was actually implemented), but nearly unusable for anything real.

Self-hosted OS and compiler are real enough. Considered "too minimal" for you, and you seem to hate GC, but overall it's good for what it does. The typical excuse (as has been implemented many times) seems to be "Extend it, if it doesn't presently fit your needs." I'm talking beyond the original, -2, and -07, but also about Component Pascal [sic], Active Oberon, and Zonnon.

> > Long story short, I'm still sympathetic to ISO Modula-2 and Oberon-07 and
> > whatever else (FPC/TP, of course). But it's like a weird halfway between
> > two sides, even though neither will win.
>
> Well, ISO M2 is mostly after my time (in my time it was more PIM3 vs PIM4),

IIRC, PIM3 was '85 and (unpopular) PIM4 was '89, right around the time of Oberon ('88 or '90), not counting others (-2 was '93 and -07 was up through '13 or such). ISO M2 was '96, quite late and mostly unpopular (standard library was very kludgy). ISO M2 also had like 700 pages of VDM-SL or whatever!

> but it didn't seem as bad as you make it out to be. Oberon is IMHO in a
> totally different direction, and I don't see the synergy to be honest.

GM2 hit 1.0 back in 2010! It still hasn't been integrated into GCC (why?) although seemingly close. It's quite good. That will be a good day. There's still some Modula-2 fans in the wild, as you well know.

Oberon is too splintered, hobbyist, but it's still quite good and (relatively) popular. They just prefer to do things their own way. Being non-standard doesn't bother them much.

Check out XDS's sources (Apache 2.0). IIRC, it runs atop Win32 or Linux.

> More complex cases of accessing parent parameters with multiple levels and
> recursion (basically writing a recursive descent parser as nested procs)
> was said to be big dividing line.

Oberon-07 has simpler data support in nested procedures: (only) strictly local or strictly global. AFAIK, this is comparable to standard C (not GCC extensions). It's one of many simplifications made in that dialect. It presumably does simplify stack management quite a bit. I know you disregard Oberon overall, but ....

> > More complex cases of accessing parent parameters with multiple levels
> and
> > recursion (basically writing a recursive descent parser as nested procs)
> > was said to be big dividing line.
>
> Oberon-07 has simpler data support in nested procedures: (only) strictly
> local or strictly global. AFAIK, this is comparable to standard C (not GCC
> extensions). It's one of many simplifications made in that dialect. It
> presumably does simplify stack management quite a bit. I know you disregard
> Oberon overall, but ....

Yes, proves again its uselessness, even TP can do better.

But as I said in OO languages it might be used less, since your method variables (aka function pointers) already have some context, and less local functions are used, since methods in general share context via the object.

> > > Don't forget that Oberon (usually, but not always) has GC,
> >
> > Yes. Don't forget how far Oberon got. Exactly.
>
> Overall, I greatly admire Oberon, but it's not as portable nor robust as
> Free Pascal. But both are very good. Oberon accomplished a lot, actually,
> as did Modula-2. But Pascal was more popular.

As said I never really saw a practical use case for it. I considered it without any compromises to make it usable, and the basic dialect too limited and tied to its own little OS world.

Keep in mind though that I looked into M3 and Oberon in the M2 period, so 94-98 and on and off till 2000, and compared it mostly to _production_ Modula2 compilers, mostly Topspeed. There was some unfairness in that, and I realize that.

The whole D thing is much newer and judged on contemporary reasons.

> Hey, even your beloved ACK had ISO Pascal and PIM Modula-2 support, among
> others (ANSI C, primitive BASIC, etc). Though Minix 3 long ago switched to
> Clang (and NetBSD userland).

MY beloved ACK? I don't think I have seen it running this century

> > > > In my case D being GCed would earn a -50. Useless.
> > >
> > > Lua also has GC, but it's written in C.
> >
> > Yeah, so no Lua for me. Point?
>
> C is considered a baseline of useful,

Not by me. It's core feature is compiler availability, and that is not a language feature, but a popularity contest. C is maybe a good example of a language that became production to early, cutting out time to mature and at least ban the worst things.

> and a GC-enabled language written in
> portable C is probably not considered broken. But I guess your needs are
> different.

I don't really see that logic. At all. What does C implementation language to do with the usability of the result? Probably the C malloc also ties into the GC thus is halted by the global lock as well. Maybe the threads are even suspended to enable stack inspection.

(CVSUP/M3)
> But such
> a language (objects, generics, exceptions, threads, garbage collection) was
> less useful in later years, when most other competing languages had most of
> those features. It was simpler than Ada or C++, but that's not saying much.

Yes.Goes for Oberon too.

> main
> > analysis and the more loosely coupled GUI part on top of it in "any"
> > language.
>
> Keep in mind that there are some rare Oberon implementations that lack
> garbage collection, and you're encouraged to omit it and just use DISPOSE,
> if it meets your needs. But clearly you have other requirements even beyond
> that.

It is usually not that extreme. It is just that you don't select something that you have to battle more than you benefit from it. And using a rare usecase of an already rare development system is not really a preferable solution either.

> > Oberon has been an interesting experiment (and doubly so because
> > it was actually implemented), but nearly unusable for anything real.
>
> Self-hosted OS and compiler are real enough. Considered "too minimal" for
> you, and you seem to hate GC, but overall it's good for what it does.

What is that ? Being a minimal grammar demo ? My problem is that I never really saw fundamental benefits. Sure, you can program in it, as in most Turing complete languages, but there are thousands of those.

> > Well, ISO M2 is mostly after my time (in my time it was more PIM3 vs
> PIM4),
>
> IIRC, PIM3 was '85 and (unpopular) PIM4 was '89, right around the time of
> Oberon ('88 or '90), not counting others (-2 was '93 and -07 was up through
> '13 or such). ISO M2 was '96, quite late and mostly unpopular (standard
> library was very kludgy). ISO M2 also had like 700 pages of VDM-SL or
> whatever!

Standards were back then under wraps. So was the (British Standards?) validation suite. Anyway, I was less into building development tools back then. Both comprehension AND interests.

> GM2 hit 1.0 back in 2010! It still hasn't been integrated into GCC (why?)
> although seemingly close. It's quite good. That will be a good day. There's
> still some Modula-2 fans in the wild, as you well know.

I know it exists, but never dug deep into it, other than some reading on the website. And I have an allergy of GCC mods after GPC.

> > Oberon-07 has simpler data support in nested procedures: (only) strictly
> > local or strictly global. AFAIK, this is comparable to standard C.
>
> Yes, proves again its uselessness, even TP can do better.

You don't technically need it, and it simplifies implementations. Sure, it can be useful, but it's not mandatory. This is not a strict limitation but more of a design restriction (optimization?). You don't have to agree, but I think it's reasonable. You can't please everyone (although C++ certainly tries!). It's just yet another way of doing the same thing.

> As said I never really saw a practical use case for it. I considered it
> without any compromises to make it usable, and the basic dialect too
> limited and tied to its own little OS world.

If Oberon was exclusively tied to OberonOS, then that wouldn't be ideal. But there are many hosted compilers for other OSes, obviously, even DOS! There are many improved dialects, as I mentioned, so that's not totally restricting anyone either.

Don't forget that Extended Pascal was a strict superset of classic ISO Pascal, same as Objective C was originally a strict superset of C. (Modula-3 doesn't really fully inherit from Modula-2 but instead went a bit wayward. Actually, I think it was an improved Modula-2+ from third-parties. Still interesting.)

> > Hey, even your beloved ACK had ISO Pascal and PIM Modula-2 support
>
> MY beloved ACK? I don't think I have seen it running this century
>

I was half-joking, but it's still a fairly decent compiler. The last official prerelease was 2016 (with tons of minor changes in trunk since), maintained as a hobby by David Given, and it (mostly) works. I built it atop Linux and used it a bit in recent years. It's had quite some cleanups since the original releases, to say the least. It's no full replacement for GCC, of course, but it works.

Historically, it's tied to Minix, formerly being the system compiler. I had some minor fascination with Minix 2 (you know, DOSMinix ran atop DOS and FAT16) in years past. 2.0.2 was 1998 (last to run on XT?) and 2.04 (2003) was a quick cleanup to prepare for Minix 3 (2005+). So the v2 series is a bit dated (like DOS) but always impressed me with how much it could do. Minix 3 added and changed a whole heck of a lot, especially later releases, but I never fully delved into any of it because I was too green. Being BSD-licensed since 2000 was cool, and I considered it like a "lite" Linux (old POSIX compatible), aka "minimal *nix"! Too old and limited for most people, but I found it quite nice for what it did.

> > > > > In my case D being GCed would earn a -50. Useless.
> > > >
> > > > Lua also has GC, but it's written in C.
> > >
> > > Yeah, so no Lua for me. Point?
> >
> > C is considered a baseline of useful,
>
> Not by me. It's core feature is compiler availability, and that is not a
> language feature, but a popularity contest. C is maybe a good example of a
> language that became production to early, cutting out time to mature and at
> least ban the worst things.

C has some warts, but overall it's fairly good and works. Same with Pascal. You could maybe say it tries to do too much, even. It's just very hard to be functional, clean, and compatible. Some things are easier than others. It's not perfect, but it's still workable. "Where there's a will, there's a way." Pessimists who only see negatives will never even try to solve the obvious problems. Optimists make do with what they have. "A poor carpenter blames his tools!"

Anything that works is good. Anything that works cleanly and efficiently is better. But a portable solution is best because a localized solution that nobody else can use is almost worthless.

> > and a GC-enabled language written in portable C is probably
> > not considered broken. But I guess your needs are different.
>
> I don't really see that logic. At all. What does C implementation language
> to do with the usability of the result? Probably the C malloc also ties
> into the GC thus is halted by the global lock as well. Maybe the threads
> are even suspended to enable stack inspection.

Lua is portable, by design, so yeah, it's probably limited. Like I said, I heard that Modula-3's biggest portability problem, by far, was its garbage collector. That alone makes me wary of things like that. Extra features are great, but when tied too closely to an OS (or cpu or compiler or even dialect) that it restricts portability and future work (since modern computing is chaos and everything is frequently upheaved), it makes me a bit disillusioned. Slow or limited is better than broken or unportable/rare/proprietary.

> (GM2)
> I know it exists, but never dug deep into it, other than some reading on
> the website. And I have an allergy of GCC mods after GPC.

But is either useful for your production needs? Do either GM2 or GPC come close to doing what Delphi does for you? And if not, why not?

> If Oberon was exclusively tied to OberonOS, then that wouldn't be ideal.
> But there are many hosted compilers for other OSes, obviously, even DOS!
> There are many improved dialects, as I mentioned, so that's not totally
> restricting anyone either.

Most of that is from after my interest in Oberon. But the core point is that I don't have anything that would make me consider to Oberon in the first place.

> Don't forget that Extended Pascal was a strict superset of classic ISO
> Pascal, same as Objective C was originally a strict superset of C.

And I use neither.

> (Modula-3 doesn't really fully inherit from Modula-2 but instead went a bit
> wayward. Actually, I think it was an improved Modula-2+ from third-parties.
> Still interesting.)

I think M3 was an attempt to make an application building language to M2 the systems language, like C++ to C. Totally different objectives and approach.

And while I think that M2 with some (fairly common) improvements was a decent systems languages, I didn't really think M3 was all that special, tried to force OO too hard without it being fleshed out enough.

But as said it was a bit unfair since when I did most of that reconnaissance I used commercial M2 compilers (under educational license). Then the DEC M3 system looked really poor.

> Historically, it's tied to Minix,

I considered porting FPC to Minix somewhere in the 2003-2006 period. Probably during the Minux2->Minix3 transition. But my life changed from academia to daily work in that period, so in the end I never did.


> Too old and limited for most people,

Yeah, and that too. And, like OpenBSD in that time, they had some limitations to force you to spend a certain amount of monetary resources (in OpenBSD's case, no ready made disc images, in Minix case, buying the book)

So I had a large motivational problem.

> C has some warts, but overall it's fairly good and works.

Not everything that you can manage is good.

> Pessimists who only see negatives will never even try to solve the
> obvious problems. Optimists make do with what they have. "A poor carpenter
> blames his tools!"

The problem is that the Optimists label those people as pessimists. Those pessimists would probably self-identify as realists and label the Optimists as "Hopeless Dreamers that never get anything done" :_)

> Anything that works is good. Anything that works cleanly and efficiently is
> better. But a portable solution is best because a localized solution that
> nobody else can use is almost worthless.

IMHO portability is overrated. Few things are portable without reduced functionality , and even then require constant maintenance to remain that way.



> Like I said, I
> heard that Modula-3's biggest portability problem, by far, was its garbage
> collector.

Yeah, but nowadays GCed languages are more common. It might have been the problem of that *implementation*. But while I don't like GC, portability of the implementation should not be the main argument against

> > (GM2)
> > I know it exists, but never dug deep into it, other than some reading on
> > the website. And I have an allergy of GCC mods after GPC.
>
> But is either useful for your production needs? Do either GM2 or GPC come
> close to doing what Delphi does for you? And if not, why not?

GPC and GM2 probably don't even get close to my private requirements, let alone my professional.

I wouldn't even know where to start to list. No OO dialect, tons of libraries used etc. Moreover I connect to visual studio code (camera drivers), so whatever I use must be exception system compatible to VS C++ code. (read: SEH, not SJ)

But mostly importantly: no significant reason to try.

> > Historically, it's tied to Minix,
>
> I considered porting FPC to Minix somewhere in the 2003-2006 period.
> Probably during the Minux2->Minix3 transition. But my life changed from
> academia to daily work in that period, so in the end I never did.

Minix 3 started in 2005. Apparently the book is stuck to 3.1.0 (old version) while latest snapshot from 2017 is 3.4.0rc6.

A lot has changed over the years, but I've not really properly used it, so I could be wrong on details. (At one time, I couldn't get it working under VBox, but that was many years ago.) Proper X11 support, can save FPU/SIMD context across tasks, ELF (instead of a.out), shared libraries (no more segmentation hacks), but it's still 32-bit only (on x86, there are other unfinished?? ports) and no USB support. But it does use Clang and NetBSD userland.

They had major funding for a few years (2009-14?), but I guess that ran out. I had thought that main selling point was the self-healing drivers in the microkernel. I don't know if that attracted a lot of developers. Perhaps Linux is too entrenched (or popular or robust or easy or whatever).

> > Too old and limited for most people,
>
> in that time, they had some limitations to force you to spend
> a certain amount of monetary resources
>
> So I had a large motivational problem.

That's long not been a problem (since 2000), even older versions were relicensed. Minix 2 (DOSMinix) was small enough that I almost consider it a quick way to multitask with portable development tools and then go back to DOS to build a final release. (I think they even half recommended pcemu under Minix 2 back then, but I remember ACK's cpp had a problem with it. Minix 2 even chokes on too much RAM and required some boot monitor setting to avoid that. But you can probably at least run Bochs nowadays under Minix 3, who knows.) DOSMinix was not quite the same as old UMSDOS (Linux 2.4 series) like in Slackware 11.0 (ZipSlack from 2006), but I guess vaguely comparable. (Hey, both are more practical to run these days than early '90s proprietary Windows 3.x, obviously.)

I snipped all pointless and redundant replies about optimism, portability, etc. You already know the obvious answers, so I feel like I'm preaching to the choir here. What a messy world.

> > > Oberon-07 has simpler data support in nested procedures: (only)
> strictly
> > > local or strictly global. AFAIK, this is comparable to standard C.
> >
> > Yes, proves again its uselessness, even TP can do better.
>
> You don't technically need it, and it simplifies implementations. Sure, it
> can be useful, but it's not mandatory. This is not a strict limitation but
> more of a design restriction (optimization?). You don't have to agree, but
> I think it's reasonable. You can't please everyone (although C++ certainly
> tries!). It's just yet another way of doing the same thing.

I think it depends how you see nested functions. If you only consider information hiding angles, it is probably fine.

You can nest functions as long as you can make them functionally like a global function, but nest them so that their name don't appear global scope.

But for me nested functions always have been more a way to divide up large procedures as a step between one big procedure and making them totally independent functions. And that requires parent local var and param support.

> Many linux distros are already phasing out 32-bit versions....

Yeah, like Linux Mint (although they are apparently based upon Ubuntu, who's already mostly phased it out, so no huge surprise there).

Many distros (and other software) have done the same in recent years.

BTW ....

> Red Hat Enterprise Linux 9 will likely see support for older x86_64 CPUs
> eliminated to focus on more modern x86_64 Intel/AMD families.

https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update

> Fedora currently uses the original K8 micro-architecture (without 3DNow!
> and other AMD-specific parts) as the baseline for its x86_64 architecture.
> This baseline dates back to 2003 and has not been updated since.
> As a result, performance of Fedora is not as good as it could be on current CPUs.

Someone actually brought up the idea of requiring AVX2 as minimum, which didn't go over well. That doesn't mean requirements won't change, but it probably won't be that (yet). Especially since, apparently, Intel still doesn't include AVX on anything low-end (Celeron or Pentium), only Xeon and similar.

Apparently, GCC's FMV (function multi-versioning) was improved in GCC 6 (vs. 4.8). Haven't tried it, somewhat doubt it works fully with DJGPP, but who knows.

> Someone actually brought up the idea of requiring AVX2 as minimum, which
> didn't go over well. That doesn't mean requirements won't change, but it
> probably won't be that (yet). Especially since, apparently, Intel still
> doesn't include AVX on anything low-end (Celeron or Pentium), only Xeon and
> similar.

The Core2 generations are slowly getting extinct (and it will probably at least another year before a release with this change), but it would kill off quite usable Sandy Bridge and Ivy Bridge machines.

My own personal workstation and laptop are Ivy Bridge, though I have a newer replacement for the workstation (a Ryzen 2600)

> Apparently, GCC's FMV (function
> multi-versioning) was improved in GCC 6 (vs. 4.8). Haven't tried it,
> somewhat doubt it works fully with DJGPP, but who knows.

As a concept it is nice. But in these cases, troublefree introduction is everything. The whole gcc_s attempt was also a support nightmare.