DOS ain't dead

Hello

Stock announcement and links below. The new features list url probably also has some msdos/go32v2/win16 relevancy. (msdos in FPC terms is 16-bit target support)

From a dos point of view it improves on the msdos target with more memorymodels (like huge). Like the 16-bit dos was initial in 3.0, but is more mature now. Win16 (win 3.x) is the "new" port in this release.

Afaik the textmode IDE has been built with a 7.x GDB

Be surecheck FTP. The website is still being synchronized, and not all files on FTP are indexed on the website.

Of particular note is ftp://ftp.freepascal.org/fpc/dist/3.2.0/i386-go32v2/separate/idedos_alternative_builds.zip a 60MB large archives with 7 or so alternative builds of the textmode IDE (with and without VESA etc).

====

Hello,

Finally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.0.

For an overview of what is new see

https://wiki.freepascal.org/FPC_New_Features_3.2

The website has been update for the major targets and work is still being done for the rest.

All downloads are available at the main FTP server and sourceforge.

https://sourceforge.net/projects/freepascal/files/

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/

Enjoy!

The Free Pascal Compiler Team

Welcome to Linux 5.4.48 x86_64 (tty1)

glennmcc-i5 login: root
Password:
Last login: Tue Jun 23 00:06:06 on tty1
Linux 5.4.48.

Pascal:
A programming language named after a man who would turn over in his
grave if he knew about it.



> Be surecheck FTP. The website is still being synchronized, and not
> all files on FTP are indexed on the website.
>
> ====
>
> All downloads are available at the main FTP server
>
> ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/

---
--
http://glennmcc.org/

> Welcome to Linux 5.4.48 x86_64 (tty1)
>
> glennmcc-i5 login: root
> Password:
> Last login: Tue Jun 23 00:06:06 on tty1
> Linux 5.4.48.
>
> Pascal:
> A programming language named after a man who would turn over in
> his
> grave if he knew about it.
>
>

Sometimes, when you have nothing to say, it is better to say nothing at all

I haven't really tested this much yet (except very very minimally once for Go32v2 only), but I did mirror it to iBiblio for FreeDOS, and Jim Hall announced it.

I did notice quite a size increase, especially for i8086-msdos. I'm sure you'll say it's justified, and I'm really NOT complaining, but it's a bit shocking!

> fpc-3.0.4.i386-win32.cross.i8086-msdos.exe 2017-11-27 25.0 MB
> fpc-3.2.0.i386-win32.cross.i8086-msdos.exe 2020-06-16 168.2 MB

That's a lot of improvement!

> > fpc-3.0.4.i386-win32.cross.i8086-msdos.exe 2017-11-27 25.0 MB
> > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe 2020-06-16 168.2 MB
>
> That's a lot of improvement!

It is because of support for more memory models (like in Borland C compilers) - tine, large, huge, etc.

I have no strong opinion about it. But I was always quite happy that in Turbo pascal I don't have to care about these things. (There are only compiler directives $F- and $F+)

---
DOS-u-akbar!

> I haven't really tested this much yet (except very very minimally once for
> Go32v2 only), but I did mirror it to
> iBiblio
> for FreeDOS, and Jim Hall
> announced
> it.
>
> I did notice quite a size increase, especially for i8086-msdos. I'm sure
> you'll say it's justified, and I'm really NOT complaining, but it's a bit
> shocking!

I also noticed it. For msdos this is very pronounced, but that is just an increase in memory model (and thus copies of the RTL).

But the SVN unfortunately got bloated with 10MB of TTF fonts for the pdf renderer. IMHO that is too much.

> I have no strong opinion about it. But I was always quite happy that in
> Turbo pascal I don't have to care about these things. (There are only
> compiler directives $F- and $F+)

If you choose a memory model larger than needed, in theory that is less performant, at least on old 486- hardware that is pretty much 1:1.

But for most stuff you just pick large, except for very small commandline programs you use compact. Huge is afaik more a speciality for backporting protected mode stuff.

> > > fpc-3.0.4.i386-win32.cross.i8086-msdos.exe 2017-11-27 25.0 MB
> > > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe 2020-06-16 168.2 MB
> >
> > That's a lot of improvement!
>
> It is because of support for more memory models (like in Borland C
> compilers) - tine, large, huge, etc.

I still haven't installed it (yet).

No, it already supported Tiny and Large, etc. The only new one is Huge. So it's some other reason (generics? Win16? uncompressed?). Actually, I assume the installer is using compression, but maybe not?

EDIT: Off-topic: (joking) FPC took so long to have a new release that Vandenberg came out of retirement! (First new album in 35 years came out last month. Okay, so mostly new lineup: new singer, etc. Luckily, Slacker Radio [LiveXLive] has it.)

> If you choose a memory model larger than needed, in theory that is less
> performant, at least on old 486- hardware that is pretty much 1:1.

Some apps aren't worth optimizing as much. Only frequently-used or long-running apps really matter here, but yes, it can be quite noticeable.

Then again, for simplicity, it may be less work to not support literally everything. "Good enough!"

> But for most stuff you just pick large, except for very small commandline
> programs you use compact. Huge is afaik more a speciality for backporting
> protected mode stuff.

"Small" model is for the basics, the common simple stuff. "Large" would be for anything relatively complicated and powerful. Everything else is only for obscure niches (still useful but less so).

There's (too) much fragmentation in the world, usually for good reason (but not always). Simplicity is a virtue, so is portability, but it takes hard work.

> Then again, for simplicity, it may be less work to not support literally
> everything. "Good enough!"

Yeah, the bulk of code is usually reusuable. The problem is usually more in the libraries where you store routines for reuse, and might use some assembler here and there, and e.g. parts that use really large data structures.

(In my case this was more Modula2)

> > But for most stuff you just pick large, except for very small
> commandline
> > programs you use compact. Huge is afaik more a speciality for
> backporting
> > protected mode stuff.
>
> "Small" model is for the basics, the common simple stuff. "Large" would be
> for anything relatively complicated and powerful. Everything else is only
> for obscure niches (still useful but less so).

I was wrong, (the terminology is slightly different). Huge does allow data >64kb, which you can occasionally need when you are growing out of large memory model.

The huge in FPC seems to be the same as XLarge in M2. I mixed up "huge memory model", and "huge pointers" (pointer normalizing after each operations to access datastructures >64k). That is a separate item, and luckily not for all pointers. (what I thought, that would really slow down).

Fun part seems to be though that you can turn on huge on a per unit basis. So you can just put it on for some large static data units to get an own segment, but use the common data segment for the rest.

Reading it is really cool. Make me really want to do some segmented programming again. And with modern tricks like generics etc. Would be fun!

OTOH, I'm already doing 16-bit programming a lot lately(like half of my work time)/.

New boards with new microchip pic24/dspic33 variants are being developed. Which btw have an even worse data model, where 16-bit datasegment is separated in two 15-bit spaces, with the upper 15-bit being a kind of pageframe to access either flash (workaround for harvard architecture) or additional memory, the bigger ones have a crazy 48kb!

So maybe wait till this gulf of embedded jobs at work is done. But I really need to set up some freedos VM to test or so.

> There's (too) much fragmentation in the world, usually for good reason (but
> not always). Simplicity is a virtue, so is portability, but it takes hard
> work.

Yup. It is always a tradeoff.

> > fpc-3.0.4.i386-win32.cross.i8086-msdos.exe 2017-11-27 25.0 MB
> > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe 2020-06-16 168.2 MB

I don't check what inside, but looks like good collection of pron. For compiler it is too big.

---
Make DOS great again!
Make Russia small again!

> > > fpc-3.0.4.i386-win32.cross.i8086-msdos.exe 2017-11-27 25.0 MB
> > > fpc-3.2.0.i386-win32.cross.i8086-msdos.exe 2020-06-16 168.2 MB
>
> I don't check what inside, but looks like good collection of pron. For
> compiler it is too big.

It is a complete system including libraries, utils etc. So not just a compiler.

> It is a complete system including libraries, utils etc. So not just a compiler.

A quick check shows subdirs for separately-built libraries for 8086, 186, 286, and nowadays 386 (for i8086-msdos target). Don't forget that "Huge" is new here, too.

The PPCROSS8086.EXE compiler itself (via "-ic") now says it can target 8086, 80[1234]86, PENTIUM, and PENTIUM[234M]. (That's probably minimal tuning on most of those.)

Various GENERICS.*.A libraries take up about 33 MB of space.