DOS ain't dead

My vision of what MSDOS should have become in the late 1980s is here:

http://pdos.org

Specifically in addition to IO.SYS, MSDOS.SYS and COMMAND.COM should have been added KERNEL32.DLL and MSVCRT.DLL.

That should have been the only visible change.

With the benefit of hindsight.

And a shitload of work.

Note that I am training (and paying) some people to take it from here, but it's a very slow process.

BFN. Paul.

> > I assume that CHS and LBA are mutually exclusive?
>
> Not at all. You simply use the LBA detection int 13 call and if that is
> positive, you are allowed to use LBA style disk access. You can always
> stick to CHS, but of course CHS has the added complexity that the same LBA
> sector can have different CHS locations depending on how your current
> geometry is arranged, for example based on your BIOS CMOS settings. But of
> course there also is an int 13 call to query the current CHS geometry

Thanks for your message full of information.

I think this knowledge needs to be encoded in
C90 code.

Note that PDOS/386 is now able to run the gccwin
C compiler, so it is now a mini Windows development
environment. Self-contained download is now available
from http://pdos.org

That is basically proof of concept done.

And that has now been extended to comms too. You
can see how I drive COM1 to access a news server
using pure C90 code, here:

https://groups.google.com/g/comp.lang.c/c/bYF6sl6z-MI

I think a sensible goal at this stage would be for
PDOS/386 to boot on every, or at least, most,
80386-based computers. Sort of with the goal that
the right geek will be sitting in front of an
obscure computer, boot PDOS as more-or-less the
only OS that actually works, and then proceed to
fix an important bug in PDOS.

What was theoretically possible with an 80386
processor? It could have been married to what
BIOS and hard disk? (ie I am looking for very
old configurations)

So starting from the MBR, and working within the
512-byte limitation (including FAT-32 restrictions),
what should have been done, with the benefit of
hindsight?

Thanks. Paul.

> I assume that CHS and LBA are mutually exclusive?

Not at all. You simply use the LBA detection int 13 call and if that is positive, you are allowed to use LBA style disk access. You can always stick to CHS, but of course CHS has the added complexity that the same LBA sector can have different CHS locations depending on how your current geometry is arranged, for example based on your BIOS CMOS settings. But of course there also is an int 13 call to query the current CHS geometry

> Or can you write code, including a boot sector, that
> gracefully detects whether you are on an LBA-capable
> system and switch to LBA?

Of course, yes. The detection is simple, just write your own public domain code to use it. From RBIL:

INT 13 - IBM/MS INT 13 Extensions - INSTALLATION CHECK
AH = 41h
BX = 55AAh
DL = drive (80h-FFh)
Return: CF set on error (extensions not supported)
AH = 01h (invalid function)
CF clear if successful
BX = AA55h if installed
AH = major version of extensions
01h = 1.x
20h = 2.0 / EDD-1.0
21h = 2.1 / EDD-1.1
30h = EDD-3.0
AL = internal use
CX = API subset support bitmap (see #00271)
DH = extension version

Bitfields for IBM/MS INT 13 Extensions API support bitmap:
Bit(s) Description (Table 00271)
0 extended disk access functions (AH=42h-44h,47h,48h) supported
1 removable drive controller functions (AH=45h,46h,48h,49h,INT 15/AH=52h)
supported
2 enhanced disk drive (EDD) functions (AH=48h,AH=4Eh) supported
extended drive parameter table is valid (see #00273,#00278)
3-15 reserved (0)

One of the reserved bits later got used to indicate support for linear pointers to RAM, I think even supporting 64-bit pointers for buffers beyond your first 4 GB of RAM, for int 13 LBA calls. Read the updated EDD specs for details if you want to use that feature.

See int 13 functions 08 and 48 for details about checking the current CHS geometry. To access sector contents, use functions 2 and 3 for CHS or 42 and 43 for LBA style.

---
FreeDOS / DOSEMU2 / ...

> Yes, in VM with a small disk with single partition probably everything
> works fine, I belive.. But out in the wild you can expect more oddities. I
> guess it may be similar problem like with FreeFdisk discused some months
> ago here - partitions starting at misaligned CHS values, as today on SSD
> many partition tools don't align to CHS but LBA, e.g. start 1st partition
> at 1MB... Just try your system on some real large partitioned HDD...

I want to stick with USB sticks until I can get
that working to my satisfaction. PDOS doesn't
yet have the necessary support tools to be a
standalone system. It still relies on fdisk and
format from Freedos, but I realized that I should
be able to write tools to manipulate a VHD image
instead.

I assume that CHS and LBA are mutually exclusive?
Or can you write code, including a boot sector, that
gracefully detects whether you are on an LBA-capable
system and switch to LBA?

I really need these exact switching rules to be
encapsulated in public domain source code that is
part of PDOS.

BFN. Paul.

[del]

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

> Not sure if anyone has implemented
> Posix on the 8086.
>

There were quite a few of 8086 based implementations of UNIX that conformed to POSIX. More or less. Xenix and Venix are one example.

There were also clones like Coherent and Minix. They have some POSIX conformance. Not sure on what level, though.

If you mean POSIX on top of DOS, there were several projects I'm aware. Quite a few of them being educational. If I remember right, Vsta had a version that ran on top of DOS.

P.S. Sorry for butting in late in the discussion. :)

Yes, in VM with a small disk with single partition probably everything works fine, I belive.. But out in the wild you can expect more oddities. I guess it may be similar problem like with FreeFdisk discused some months ago here - partitions starting at misaligned CHS values, as today on SSD many partition tools don't align to CHS but LBA, e.g. start 1st partition at 1MB... Just try your system on some real large partitioned HDD...

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

When a person experiments with a new operating system, they usually do a small-scale test first, for which a floppy image is ideal.

So starting to format a hard drive or USB drive didn't seem like the first option for me.

It is simply that.

Thank you very much for your explanations.

> > > My 2 GiB MS-DOS partition have low free space...
> > > (Windows 3.1, MS-Office, games, testing tools... )
> >
> > Use a USB stick?

> PC with AMD Phenom II x2 550 and SSD 240 GiB Toshiba SATA 3.

https://www.techpowerup.com/cpu-specs/phenom-ii-x2-550-be.c604

The AMD Phenom II X2 550 BE was a desktop processor with 2 cores, launched in June 2009.


USB ports commonly existed before 2000 I believe.

Therefore I believe you have a USB port and
probably the ability to boot a USB stick.

You need a USB stick with 1 GB capacity. You
probably have this too, and this is what the
image was designed for.

You probably don't have a real floppy disk, so
you would need to burn a floppy image to USB
stick and boot that anyway. Unless you have a
USB stick with less than 1 GB capacity it
shouldn't make any difference whether you burn
a hard disk image or a floppy disk image.

> First partition: MS-DOS 6.00 (2 GiB)
> Second partition; Windows 7 SP1

Neither of the above things has the ability
to boot a floppy disk image that I am aware
of - that is the function of the PC, not the
Microsoft OS. However, the latter probably
allows you to run Virtualbox etc which would
allow you to mount a hard disk or floppy
image and boot from that. The image could
exist as an ordinary file on any capacity
USB stick with at least 1 GB free space in
the case of the hard disk image.

What am I missing?

BFN. Paul.

> > My 2 GiB MS-DOS partition have low free space...
> > (Windows 3.1, MS-Office, games, testing tools... )
>
> Use a USB stick?
>
> BFN. Paul.


PC with AMD Phenom II x2 550 and SSD 240 GiB Toshiba SATA 3.

First partition: MS-DOS 6.00 (2 GiB)
Second partition; Windows 7 SP1

> When I want to execute the "old and good" Norton Commander in pure PDOS,
> says:
>
> "Pure MZ executables are not supported"

If you want to execute 16-bit executables
you need to use PDOS/86, built from the
same source base.

I don't have that on pdos.org though as I
am not really expecting it to be used. The
last official release is available in
sourceforge though.

> But I understand that that was to be expected.

Yes, if you don't have a use for Win32 executables,
PDOS/386 isn't very useful.

> I wish you good luck with your project

Thanks.

>> I would have thought that 1 GB would fit
>> comfortably on 2 GiB partitions and that
>> no-one in 2021 would have trouble finding
>> 2 GiB of disk space.

> My 2 GiB MS-DOS partition have low free space...
> (Windows 3.1, MS-Office, games, testing tools... )

Use a USB stick?

BFN. Paul.

>> I would have thought that 1 GB would fit comfortably on 2 GiB partitions and that no-one in 2021 would have trouble finding 2 GiB of disk space.

My 2 GiB MS-DOS partition have low free space... (Windows 3.1, MS-Office, games, testing tools... )

Thanks...

=> Floppy image:

http://www.pdos.org/pdosflop.img


When I want to execute the "old and good" Norton Commander in pure PDOS, says:

"Pure MZ executables are not supported"

But I understand that that was to be expected.

I wish you good luck with your project

> > My vision of what MSDOS should have become in the late 1980s is here:
> >
> > http://pdos.org
>
>
> I downloaded the compressed file PDOS.ZIP (1262888 b), and inside it there
> is a VERY LARGE image file PDOS.IMG (1048190976 b) with 15 files that only
> occupy 351968 b.

It is designed to have stuff added to it.
1 GB is actually close to the limit of what
is needed if the entire toolchain source is
extracted and compiled. We're not hitting
that limit right at the moment though because
of bugs preventing the process from working.

> That's too big to test into 2 GB partitions
> (normal on MS-DOS hard drives
> with GRUB4DOS for loading floppy images)

I'm not familiar with that scenario. I would
have thought that 1 GB would fit comfortably
on 2 GiB partitions and that no-one in 2021
would have trouble finding 2 GiB of disk
space.

> It seems to me that to do different tests, it would be better also to
> prepare an image file of 1474560 b (1.44 M) or 2949539 b (2.88 M)

There already is. See pdosflop.img. 1.44M.
Search for:
"Also there is a floppy disk image here if you prefer that."
at http://pdos.org

It has been there for over a month, but perhaps
not when you downloaded the HD image.

BFN. Paul.

> My vision of what MSDOS should have become in the late 1980s is here:
>
> http://pdos.org
>


I downloaded the compressed file PDOS.ZIP (1262888 b), and inside it there is a VERY LARGE image file PDOS.IMG (1048190976 b) with 15 files that only occupy 351968 b.

That's too big to test into 2 GB partitions (normal on MS-DOS hard drives with GRUB4DOS for loading floppy images)


It seems to me that to do different tests, it would be better also to prepare an image file of 1474560 b (1.44 M) or 2949539 b (2.88 M)

> I'll give PDOS a try. If it were Pharlap compatible, I'd be all over it.

BTW, why would PDOS be superior to Freedos if all
you want to do is run Pharlap executables?

And why do you want to run Pharlap executables in
the first place instead of Win32 executables?

Thanks. Paul.

> > By "PDOS32" do you mean the PDOS floppy image from http://pdos.org or an
> > older version from sourceforge?
>
> Yes, the image from pdos.org.

I just tried the PDOS floppy disk image and
hard disk image from pdos.org and tried booting
off floppy under Bochs, and indeed, I got a
"file not found" when I did "dir" on the C drive
(PDOS hard disk).

When I went to the D drive (freedos hard disk)
the "dir" worked correctly.

I'll pay US$50 to anyone who fixes that bug.

Or you can wait until some other people I have
been training manage to fix it. I don't know
how long that will take though, as I don't have
much experience in training people to do this
sort of work.

At the moment at least, I am unwilling to do the
work myself, as I don't want PDOS to be a one
man show. I want to make sure it can have a life
of its own.

BFN. Paul.

> > > I'll give PDOS a try. If it were Pharlap compatible, I'd be all over
> it.
> >
> > Can you tell me more about what a 32-bit Pharlap executable
> > looks like? ie what registers it is expecting at entry, and
> > how does it obtain services
> as any other 32 DOS program:
>
> it needs DPMI and the full range of 16-bit MSDOS services, nothing you
> intend to provide.

I don't mind providing those, converting a
32-bit request for a 16-bit service back into
a 32-bit service.

> > and does it manipulate segment registers?

> of course.

It's a non-starter then. I'm not going to allow
anyone to manipulate segment registers.

Win32 executables don't do that. If Pharlap
think they are smarter than Microsoft, that's
their choice, and we can go our separate ways.

BFN. Paul.

> > I'll give PDOS a try. If it were Pharlap compatible, I'd be all over it.
>
> Can you tell me more about what a 32-bit Pharlap executable
> looks like? ie what registers it is expecting at entry, and
> how does it obtain services
as any other 32 DOS program:

it needs DPMI and the full range of 16-bit MSDOS services, nothing you intend to provide.


> and does it manipulate segment registers?
of course.

> By "PDOS32" do you mean the PDOS floppy image from http://pdos.org or an
> older version from sourceforge?

Yes, the image from pdos.org.

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

> I'll give PDOS a try. If it were Pharlap compatible, I'd be all over it.

Can you tell me more about what a 32-bit Pharlap executable
looks like? ie what registers it is expecting at entry, and
how does it obtain services and does it manipulate segment
registers?

Thanks. Paul.

> I tried to boot PDOS32 floppy image on my PC via GRUB. When I changed drive
> from floppy to any of my FAT16 partitions and type "dir" I just got endless
> loop of files/dirs listing...

By "PDOS32" do you mean the PDOS floppy image from http://pdos.org or an older version from sourceforge?

I tried to boot PDOS32 floppy image on my PC via GRUB. When I changed drive from floppy to any of my FAT16 partitions and type "dir" I just got endless loop of files/dirs listing...

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

I've been writing 32-bit code for DOS since PharLap was introduced and Microway NDP compilers since they came out, ~1987 or so. Ported lots of code from the VAX 11/780 to a Compaq 386. The Watcom V2 compilers (2017 release) generate executables for PharLap 32 bit. I use Pharlap, NDP compilers, and the Watcom compilers for embedded systems these days- The ICOP VortexDX3 being the current processor of choice. The Watcom compilers are nice as they will generate code for Win10 all the way to extended DOS.

I'll give PDOS a try. If it were Pharlap compatible, I'd be all over it. MAy be a month or two- have to get a project out. NDP-Fortran is all over it.

For closure, I have committed the C-based Pascal
runtime library:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pascal/

Hopefully other languages will be supported the
same way.

It remains to be seen if some other aspects can
be fleshed out though. In particular passing
runtime arguments. "main" will need to be
C-style to work, unless main is renamed to
main2 and the C code receives initial control
and calls assembler to call Pascal's main2.

BFN. Paul.

> > The serial port predated the internet and is
> > available via INT 14H. It is my intention to
> > have ATDnews.eternal-september.org:119
> > work. I may modify SeaBIOS to do it, to get it
> > to convert serial port into bluetooth/wifi for
> > systems without a real serial port.
>
> please leave a note when you have done that.

I have already posted in the SeaBIOS mailing list
about the feasibility of that, but my follow-up
is waiting moderator approval for nearly a week.

In the meantime, I have a "terminal" program on
the PDOS/386 disk which does the INT 14H call,
and when run under Bochs I can redirect it to
an arbitrary TCP/IP address.

I also have a "virtual modem" designed to accept
the ATD request - this was first tasked to do
ASCII to EBCDIC translation so that I could
connect to an EBCDIC BBS. You can find that here:

https://sourceforge.net/p/mvs380/mvssrc/ci/master/tree/ozpd/c/modem.c

All components in that chain are pretty flakey at
the moment, but it did work sometimes, sort of.

I'm more likely to get that process working first,
so that you can connect an old PC to a modern
PC using a serial to USB cable, and access the
internet using PDOS/386.

At some point I will investigate what sort of
laptop I can buy that allows me to flash
SeaBIOS or some alternative.

Another thing that might delay SeaBIOS is that
I might have a BOOTX64.EFI that reinstalls a
BIOS on computers that have deleted it, and
as part of that, I can direct INT 14H to
something interesting. But I think there is
nothing interesting available via standard
UEFI, so I would have to resort to something
that is hardware-specific, so I am likely to
forget trying this, and instead go the
SeaBIOS route.

Probably in the medium term I will instead
run PDOS/386 natively from USB stick on a PC
that has BIOS support, and when I need to
gather UUCP news or whatever, I will reboot
to the hard disk or a different USB stick to
use something that has the required Wifi
drivers, ie either Windows or Linux, and then
run Bochs so that PDOS/386 has access to a
serial port thus the internet.

But yeah, I'm really keen to get PDOS/386
talking to my dumb phone which has bluetooth.
And my dumb phone has internet access, so
I don't know if it is possible for an app
to run on it that passes the bluetooth
data stream on to the internet. It's an
Alcatel One Touch. I have never owned a
smartphone. I only have this dumb phone
because my provider gave it to me for free
to stop using their 2G network. They sent
me so many SMSes telling me to get off the
network or I would lose my access, but I
waited till the bitter end, because I
was in a debate with someone whether my
Nokia N95 supported 3G or not. It didn't,
but the other guy still didn't give up, and
tried to get me to get a SIM from a different
provider. Since that required physical
movement, I decided to just let him continue
believing that he was right.

BFN. Paul.

> The serial port predated the internet and is
> available via INT 14H. It is my intention to
> have ATDnews.eternal-september.org:119
> work. I may modify SeaBIOS to do it, to get it
> to convert serial port into bluetooth/wifi for
> systems without a real serial port.

please leave a note when you have done that.

BFN. Tom.

> > > In particular when you have only a tiny subset of the features of
> > > Windows and refuse to add even standard things such as segments,
> > > threads or networking.
>
> > That "tiny subset" allows a complete toolchain
> > and editor to run, enabling you to reconstruct
> > the entire world at your leisure.
>
> Now you only need people who like to use their
> leisure time to build a world without using internet.

The serial port predated the internet and is
available via INT 14H. It is my intention to
have ATDnews.eternal-september.org:119
work. I may modify SeaBIOS to do it, to get it
to convert serial port into bluetooth/wifi for
systems without a real serial port.

> > > Not everything is as "insidious" as GPL. There also is LGPL and
> > > MIT, BSD, CC and other licenses are actually quite relaxed.
>
> > All of them designed to prevent the public from
> > owning that functionality.
>
> Has "the public" complained about that, apart from you?

Certainly not a majority. And?

> > And always open to the copyright holders deciding
> > that their interpretation of their license on their
> > copyrighted code requires more mentions, e.g. daily
> > popups. A judge will decide on that. Microsoft can
> > probably afford enough lawyers to win. Not everyone
> > can. Wouldn't touch any of them with a 10 foot pole.
>
> Maybe you should start to actually read the BSD, MIT
> or CC license. It would take less than 27 years, but
> maybe you are too busy preaching and being paranoid.

I would call the people slapping copyright notices
on their freeware as the ones who are "paranoid",
but it is more likely to be insidious than paranoid.

It's more likely to be stupidity than either of
those, but it's difficult to tell.

What makes you think I haven't read those licenses
anyway? I use CC0 myself as a fallback for people
who live in countries that don't recognize "released
to the public domain" as being released to the
public domain. The others have copyright notices
on them.

> > I don't really care what "most users care".
>
> That is obvious. You will have noticed some experts
> have lost interestin this thread because of this.

If "some experts" care about "most users" rather
than "some technical point", so be it. What do
you expect me to do about that? ie that still
achieves some goal I am aiming for, rather than
achieving someone else's goal.

> > I really don't care what random Russians do.
>
> Why should we care what random PD programmers do?

I'm not asking you to care, am I? I'm just letting
you know that you now have some PD software available
which you can use as a base and stick your favorite
virus license on or whatever you want. If that
doesn't help you achieve some goal you have, I
don't expect you to care at all.

> > What I care about is American (and other countries)
> > companies who refuse to touch anything with a
> > copyright notice, and develop their product from
> > scratch instead. And pass that development cost
> > on to the consumer. Everyone loses.
>
> So apparently Microsoft and Apple are not American
> companies. They include open source to reduce cost.

American companies willing to take their chances
with copyrighted open source code are not the
ones that I am targeting. I am targeting the ones
who won't touch copyrighted "freeware" with a 10
foot pole and would rather develop a solution from
scratch.

> > I have my own copyright-free product, and certain
> > people in the world know the value of that
>
> Given that less than 100 people care, who cares?

I'm not sure that figure is actually correct. If
100% of the world actually knew PDOS existed, I
think you would find a lot more than 100 people
cared. But regardless, I'm not trying to win
Miss America. I am trying to solve a problem I
see. I support capitalism, but monopolies are a
natural phenomenon in capitalism, and require
government intervention to end. For whatever
reason, the US government hasn't stepped in and
broken up IBM and Microsoft, and someone else,
like the CSIRO, hasn't spent their time developing
competing products. I literally have nothing
better to do than take up that technical
challenge myself.

BFN. Paul.

> > In particular when you have only a tiny subset of the features of
> > Windows and refuse to add even standard things such as segments,
> > threads or networking.

> That "tiny subset" allows a complete toolchain
> and editor to run, enabling you to reconstruct
> the entire world at your leisure.

Now you only need people who like to use their
leisure time to build a world without using internet.

> > Not everything is as "insidious" as GPL. There also is LGPL and
> > MIT, BSD, CC and other licenses are actually quite relaxed.

> All of them designed to prevent the public from
> owning that functionality.

Has "the public" complained about that, apart from you?

> And always open to the copyright holders deciding
> that their interpretation of their license on their
> copyrighted code requires more mentions, e.g. daily
> popups. A judge will decide on that. Microsoft can
> probably afford enough lawyers to win. Not everyone
> can. Wouldn't touch any of them with a 10 foot pole.

Maybe you should start to actually read the BSD, MIT
or CC license. It would take less than 27 years, but
maybe you are too busy preaching and being paranoid.

> I don't really care what "most users care".

That is obvious. You will have noticed some experts
have lost interestin this thread because of this.

> I really don't care what random Russians do.

Why should we care what random PD programmers do?

> What I care about is American (and other countries)
> companies who refuse to touch anything with a
> copyright notice, and develop their product from
> scratch instead. And pass that development cost
> on to the consumer. Everyone loses.

So apparently Microsoft and Apple are not American
companies. They include open source to reduce cost.

> I have my own copyright-free product, and certain
> people in the world know the value of that

Given that less than 100 people care, who cares?

---
FreeDOS / DOSEMU2 / ...

> > I'm just plugging away quietly creating a backstop
> > for people who think like me. I'm not alone, even
> > if I'm in a minority. Galileo was both alone and
> > jailed.
>
> Just. Stop.
>
> The whole "Galileo
> gambit" has been done countless times before. Invoking Galileo's
> name is something that is easy, old, trite, unoriginal, and wrong --- the
> exact opposite of the things Galileo actually did. </rant>

Argumentum ad populum has been done even more
times. But I didn't see you complain about
that to the OP.

If you had done the job for me, I wouldn't
have bothered doing it myself.

BFN. Paul.

> I'm just plugging away quietly creating a backstop
> for people who think like me. I'm not alone, even
> if I'm in a minority. Galileo was both alone and
> jailed.

Just. Stop.

The whole "Galileo gambit" has been done countless times before. Invoking Galileo's name is something that is easy, old, trite, unoriginal, and wrong --- the exact opposite of the things Galileo actually did. </rant>

---
https://codeberg.org/tkchia · https://disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> > Sure. I have a competing product.
> >
> > Far less features.
> >
> > Far less copyrighted code.
> >
> > People will probably need to make that
> > tradeoff for eternity. Not just with
> > freeware, but with commercial software
> > too. I'm not attempting to replace
> > commercial software. I'm trying to give
> > them unencumbered code to lower their
> > costs.
>
> Being very explicit about how "evil" open
> source is alone does not give you
> a market.

My own code is open source. And public domain too.

> In particular when you have only a tiny subset of the features of
> Windows and refuse to add even standard things such as segments,
> threads or networking.

That "tiny subset" allows a complete toolchain
and editor to run, enabling you to reconstruct
the entire world at your leisure.

In order of priority, replacing the toolchain
with public domain software (not just the
libraries) is of far more interest to me than
threads etc.

And after that, porting to other environments
is of more interest than threads etc.

> Not everything is as "insidious" as GPL. There also is LGPL and
> MIT, BSD, CC and other licenses are actually quite relaxed.

All of them designed to prevent the public from
owning that functionality.

> Even Windows
> includes many open source components. The cost for Microsoft is having to
> provide a website which mentions them all and mirrors their source code.
> Very affordable.

And always open to the copyright holders deciding
that their interpretation of their license on their
copyrighted code requires more mentions, e.g. daily
popups. A judge will decide on that. Microsoft can
probably afford enough lawyers to win. Not everyone
can. Wouldn't touch any of them with a 10 foot pole.

> Most users will not care either way. They use pre-installed Windows, do not
> read the license, are not aware of the "Microsoft tax" when buying a
> computer with Windows. It just is already there.

I don't really care what "most users care".

> Others use Linux, even
> states and companies do. Russia is even creating their own Linux distro, so
> they neither have to trust nor pay Microsoft. This can include closed
> source components, so they do not have to reveal every detail either. They
> only have to reveal their patches to existing open source parts:

And if the Russian government has nukes to protect
them from lawsuits, that's a choice they can make.

I really don't care what random Russians do.

What I care about is American (and other countries)
companies who refuse to touch anything with a
copyright notice, and develop their product from
scratch instead. And pass that development cost
on to the consumer. Everyone loses.

> If you look at Raspberry Pi style computers or simply at the better Arduino
> variants, you already get threads, multiple CPU cores and networking. On
> Raspberry Pi style single board computers (SBC), people simply use a full
> Linux.

Good luck to them.

> Sometimes the 3d and video acceleration drivers are closed source, like for
> other desktop and laptop PC. For some SBC, Android (derived from Linux) or
> lightweight Windows variants are available.

Good luck to them too.

I have my own copyright-free product, and certain
people in the world know the value of that, even
if the average Joe Bloggs doesn't, and even if
other developers know what it means, but insist
it has no value, hoping I will be swayed, and
keep ownership of OSes in the hands of the elite
instead of the public owning at least one that
does anything at all.

BFN. Paul.

> Change result:=32; to bla:=32;

Thanks. Works fine. I see that it does a
second compile of unit1.pas, but I couldn't
care less about that. No technical barrier
encountered so far.

BFN. Paul.



C:\devel\pascal2>type pascalc.c
/* public domain by Paul Edwards */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void fpc_initializeunits(void)
{
return;
}

int fpc_get_output(void)
{
static FILE *x = NULL;

if (x == NULL)
{
x = stdout;
}

return ((int)&x);
}

void fpc_write_text_shortstr(int handle, unsigned char *str, int unknown)
{
fwrite(str + 1, str[0], 1, *(FILE **)handle);
return;
}

void fpc_write_text_sint(int handle, int val, int unknown)
{
fprintf(*(FILE **)handle, "%d", val);
return;
}

void fpc_iocheck(void)
{
return;
}

void fpc_writeln_end(int handle)
{
fprintf(*(FILE **)handle, "\n");
return;
}

void fpc_do_exit(int x)
{
exit(x);
}

void fpc_assign_short_string(char *a, char *b)
{
a += sizeof(FILE *);
strcpy(a, b);
return;
}

void fpc_rewrite(void *a)
{
char *name = (char *)a + sizeof(FILE *) + 1;
FILE *fq;

fq = fopen(name, "w");
*(FILE **)a = fq;
return;
}

C:\devel\pascal2>




C:\devel\pascal2>type pascala.asm
# public domain by Paul Edwards

.section .text
.balign 16,0x90

.globl fpc_initializeunits
fpc_initializeunits:
call _fpc_initializeunits
ret

.globl fpc_get_output
fpc_get_output:
call _fpc_get_output
ret


# edx has file handle
# ecx has string to print, first character has length
# eax has a 0, don't know what that is

.globl fpc_write_text_shortstr
fpc_write_text_shortstr:
push %eax
push %ecx
push %edx
call _fpc_write_text_shortstr

add $12, %esp
ret

.globl fpc_write_text_sint
fpc_write_text_sint:
push %eax
push %ecx
push %edx
call _fpc_write_text_sint

add $12, %esp
ret

.globl fpc_iocheck
fpc_iocheck:
call _fpc_iocheck
ret

.globl fpc_writeln_end
fpc_writeln_end:
push %eax
call _fpc_writeln_end
add $4, %esp
ret

.globl fpc_do_exit
fpc_do_exit:
call _fpc_do_exit
ret

# %eax is destination, %edx is source
.globl SYSTEM_$$_ASSIGN$TEXT$SHORTSTRING
SYSTEM_$$_ASSIGN$TEXT$SHORTSTRING:
push %edx
push %eax
call _fpc_assign_short_string
add $8, %esp
ret

.globl SYSTEM_$$_REWRITE$TEXT
SYSTEM_$$_REWRITE$TEXT:
push %eax
call _fpc_rewrite
add $4, %esp
ret

.section .data

.globl INIT$_$SYSTEM
INIT$_$SYSTEM:

.globl INIT$_$FPINTRES
INIT$_$FPINTRES:

.globl THREADVARLIST_$SYSTEM$indirect
THREADVARLIST_$SYSTEM$indirect:

C:\devel\pascal2>




C:\devel\pascal2>type makefile.w32
# Produce Windows executable
# links with PDPCLIB created by makefile.msv

CC=gccwin
CFLAGS=-O2
# ldwin gives unresolved externals that require --noinhibit-exec
# to work around if "ld" can't be used. Given that we're currently
# dependent on fpc itself, adding ld to the dependency list is
# not onerous.
LD=ld
LDFLAGS=
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean prg.exe

prg.exe: prg.o unit1.o pascalc.o pascala.o
$(LD) $(LDFLAGS) -s -o prg.exe ../pdos/pdpclib/w32start.o prg.o unit1.o pascalc.o pascala.o ../pdos/pdpclib/msvcrt.a


# Without "-s", this produces an executable (but can be ignored)
# With "-s" this produces crap (which can be deleted)
# I choose to delete crap
.pas.o:
fpc -a -s $<
rm -f link*.res
rm -f ppas.bat
rm -f *.ppu
$(AS) -o $@ $*.s
rm -f $*.s

.c.o:
$(CC) $(COPTS) -o $*.s $<
$(AS) -o $@ $*.s
rm -f $*.s

.asm.o:
$(AS) -o $@ $<

clean:
rm -f *.o prg.exe

C:\devel\pascal2>

> > begin
> > result:=32;
> > end;
> > end.
>
> But I don't know how to resolve this:
>
> unit1.pas(11,1) Error: Identifier not found "result"

Change result:=32; to bla:=32;

that is a difference between Turbo pascal like and Delphi like modes.

Default is Turbo Pascal, but my day job is Delphi.

As for msvcrt and all other things. All things have been said. I'll limit my responses to technical only issues from now.

> Sure. I have a competing product.
>
> Far less features.
>
> Far less copyrighted code.
>
> People will probably need to make that
> tradeoff for eternity. Not just with
> freeware, but with commercial software
> too. I'm not attempting to replace
> commercial software. I'm trying to give
> them unencumbered code to lower their
> costs.

Being very explicit about how "evil" open source is alone does not give you a market. In particular when you have only a tiny subset of the features of Windows and refuse to add even standard things such as segments, threads or networking. Not everything is as "insidious" as GPL. There also is LGPL and MIT, BSD, CC and other licenses are actually quite relaxed. Even Windows includes many open source components. The cost for Microsoft is having to provide a website which mentions them all and mirrors their source code. Very affordable.

Most users will not care either way. They use pre-installed Windows, do not read the license, are not aware of the "Microsoft tax" when buying a computer with Windows. It just is already there. Others use Linux, even states and companies do. Russia is even creating their own Linux distro, so they neither have to trust nor pay Microsoft. This can include closed source components, so they do not have to reveal every detail either. They only have to reveal their patches to existing open source parts:

https://en.wikipedia.org/wiki/Astra_Linux

If you look at Raspberry Pi style computers or simply at the better Arduino variants, you already get threads, multiple CPU cores and networking. On Raspberry Pi style single board computers (SBC), people simply use a full Linux.

Sometimes the 3d and video acceleration drivers are closed source, like for other desktop and laptop PC. For some SBC, Android (derived from Linux) or lightweight Windows variants are available.

---
FreeDOS / DOSEMU2 / ...

> > > > I think I am missing something.
> > > >
> > > > What is wrong with having one C90-compliant
> > > > source file in FPC (or my own derivative)
> > > > and then building it with hundreds of
> > > > different C compilers?
> > >
> > > What will it actually solve? Solution in search of a problem actually.
> > You
> > > still have a C<->Pascal interface.
> >
> > The problem it will solve is that if someone has
> > already implemented a C compiler on a particular
> > system, FPC has a ready-made runtime library.
>
> It doesn't work that way. If that were the case the rtl/unix dir would be
> empty.

I don't know what you are talking about.

> It only seems that way of the extremely trivial dumbed down subset
> that you use,

What you are calling "dumbed down" subset is
far more than an embedded system will give you.

It gives you exactly what C90 gives you - files
and memory.

That's a bloody good start, and regardless, it's
all I have.

Pascal is hitting the same limit as C on PDOS/386.

That's all I actually want.

> but that is no problem with any scheme.

Not sure what you're talking about.

> Going at it that way just shifts the pascal<-> C interface to users code,
> losing abstraction.

No idea what you are talking about. I am producing
smaller binaries than standard FPC. Seems like a
good abstraction to me.

> > > Of course you can go that way, but you only need to rewrite a lot of
> RTL
> > > functions for kernel32 stuff and diverge unnecessary.
> >
> > I don't have to rewrite anything. It's all working
> > already. The effort (27 years) has already been done
> > to get the C side working.
>
> So is the FPC runtime library. And you casually throw that away too.

Sure. I have a competing product.

Far less features.

Far less copyrighted code.

People will probably need to make that
tradeoff for eternity. Not just with
freeware, but with commercial software
too. I'm not attempting to replace
commercial software. I'm trying to give
them unencumbered code to lower their
costs.

BFN. Paul.

> in a file called "unit1.pas"
>
> unit unit1;
>
> interface
>
> function bla:integer;
>
> implementation
>
> functon bla:integer;

I changed this to "function".

> begin
> result:=32;
> end;
> end.

But I don't know how to resolve this:

unit1.pas(11,1) Error: Identifier not found "result"


Thanks. Paul.

> > > I think I am missing something.
> > >
> > > What is wrong with having one C90-compliant
> > > source file in FPC (or my own derivative)
> > > and then building it with hundreds of
> > > different C compilers?
> >
> > What will it actually solve? Solution in search of a problem actually.
> You
> > still have a C<->Pascal interface.
>
> The problem it will solve is that if someone has
> already implemented a C compiler on a particular
> system, FPC has a ready-made runtime library.

It doesn't work that way. If that were the case the rtl/unix dir would be empty. It only seems that way of the extremely trivial dumbed down subset that you use, but that is no problem with any scheme.

Going at it that way just shifts the pascal<-> C interface to users code, losing abstraction.

> > Of course you can go that way, but you only need to rewrite a lot of RTL
> > functions for kernel32 stuff and diverge unnecessary.
>
> I don't have to rewrite anything. It's all working
> already. The effort (27 years) has already been done
> to get the C side working.

So is the FPC runtime library. And you casually throw that away too.

> > IOW if a source file passed to FPC references another module that needs
> > recompilation, the compiler will automatically recursively compile it.
>
> I don't mind things being recompiled repeatedly.
> But do I end up with a .s file?
>
> > This can't be disabled. Going in this direction will make multi module
> > Pascal programs difficult.
>
> Can you give a simple example? ie a one line
> function that prints something and then a
> caller of that?


in a file called "unit1.pas"

unit unit1;

interface

function bla:integer;

implementation

functon bla:integer;
begin
result:=32;
end;
end.

then in a "prg.pas" file

uses unit1;

begin
writeln(bla);
end.

and compile "prg.pas"

> It is people who are copyrighting their freeware
> that are the ones with hangups about PD. And that's
> being generous. If I was less generous I would say
> that they were insidious.

https://www.hermit.org/b7/Episodes/scripts/City-EOTW.html

VILA [whispering] Kerril. Kerril! All right, my friend. But you didn't fool me. [Vila advances and is teleported to where Kerril is]

> > > For the first (1) set of calls , keep in mind that the Windows
> console
> > is
> > > in a different (OEM) encoding than the api (ANSI). How do you handle
> > that
> > > difference (OEM vs Ansi) in your program?
> >
> > I'm not sure I understand the issue, I know that
> > OEM means "Other Equipment Manufacturer", but I
> > would be surprised if Pascal 83-0 was so complicated.
>
> Please read. Windows is so complicated, I told you how to neutralize it if
> it doesn't matter for your PDDos/386.

I have not encountered the complication you talk
of, and calling msvcrt.dll for C90 functions is
not complicated, and if you want to add complicated
things it can all be done within msvcrt.dll.

> IOW on Windows the runtime must hide the fact that the two apis (console
> I/O and other APIs use differing charsets). Just to keep extended ascii
> (and thus basic European accents) working.

I only support console mode at the moment, and it
is likely to stay there for a long time.

> Since you don't go for running basic Windows binaries, but only use the
> compilers to hack it for your OS, it doesn't matter much for you, and you
> can simply change those calls to user32.dll conversion routines to simply
> copy the string 1:1.

BTW, making code C90-compliant so that it works
on my OS is not really "hacking". The hack was
in the original source code for not having a
default C90 target.

> > I am thinking that ANSI interpretation belongs
> > in the BIOS layer rather than PDOS proper, but
> > I'm not sure.
>
> Windows 11 will require UEFI. I suspect the number of PCs with legacy
> biosses might start to dwindle soon.

The BIOS layer can call UEFI as an option.

> > Let me see if I can get this really basic
> > functionality working first.
>
> This message was all about explaining why the functions were used in the
> /runtime/ of FPC, and what you could do to get rid of those user32
> dependencies.

Ok, I've moved on. I found that the FPC runtime
could simply be replaced. So far, anyway.

BFN. Paul.

> > Ok, the main problem was solved by switching
> > from ldwin to the "ld" that is provided by
> > FPC. For some reason it is working even though
> > ld that comes with Cygwin, and my ldwin, come
> > up with errors and require --no-inhibit to
> > ignore them. I wonder what those errors mean,
> > as surely there must be a way of getting
> > normal "ld" to work?
>
> For windows, the internal linker is recommended, as I already told you.

Lots of things are preferred by others, but I
was hoping that my preferred option would work.

> For questions about why 3rd party builds of ld.exe don't work, ask the
> people that built them. It might be options, or known issues, problems with
> weak linking, problems with processing of link scripts or using _ prefixes
> for some legacy reason.

The root problem is that FPC is generating
assembler code that is far more complicated
than C produces. Is there a reason for that
and can it be disabled?

> > Producing a 100% public domain executable
>
> The PD thing is your own hang up. Nearly the entire world is fine with BSD
> and LGPL-static-linking-exception.

There was a time when the entire world, quite
literally, believed that the sun revolved around
the earth.

It's a logical fallacy - argumentum ad populum.

If people are too stupid to ask the question -
why are these people refusing to release their
code unconditionally - what are they holding
back, my executables are copyrighted by them,
they can decide to exercise their copyright
rights whenever they want, that's their problem.

I'm just plugging away quietly creating a backstop
for people who think like me. I'm not alone, even
if I'm in a minority. Galileo was both alone and
jailed.

It is people who are copyrighting their freeware
that are the ones with hangups about PD. And that's
being generous. If I was less generous I would say
that they were insidious.

> In the nineties some people were paranoid about open source licenses, but
> it is 2021 now, and this is all daily fare for most programmers. I haven't
> heard about this particular direction in decades.

Perhaps the question you should ask is why you
haven't heard about the decades-long effort.

Specifically why in 2021 the public doesn't
actually own an operating system (well, they
do now, but they don't know they do).

BFN. Paul.

> > # Without "-s", this produces an executable (but can be ignored)
> > # With "-s" this produces crap (which can be deleted)
> > # I choose to delete crap
> > .pas.o:
> > fpc -a -s $<
> > rm -fr link*.res
> > rm -fr ppas.bat
> > $(AS) -o $@ $*.s
> > rm -f $*.s
>
>
> Word of advise, FPC has no C compatible build mode so makefiles are hard.
>
> IOW if a source file passed to FPC references another module that needs
> recompilation, the compiler will automatically recursively compile it.

I don't mind things being recompiled repeatedly.
But do I end up with a .s file?

> This can't be disabled. Going in this direction will make multi module
> Pascal programs difficult.

Can you give a simple example? ie a one line
function that prints something and then a
caller of that?

Thanks. Paul.

> > By targeting msvcrt.dll, or in fact, just any C
> > library, my code should work on native Linux/BSD
> > too.
>
> The first Linux port dates for 1995, you are bit late here

And how many of those executables are pure
public domain?

> Do you really think you are the first one to propose this

Not at all. I am new to Pascal. The only thing I
have seen so far is "periods based on principles"
rather that technical limitations.

> (just from the top of my head)
>
> - iirc passing 64-bit integers (mmap/ftruncate/lseek etc)

None of the things in your list are standard C90.
I only support standard C90.

I have WORKING CODE. That includes running on
PDOS/386 and Win 95 and everywhere that supports
Win32 executables which is almost everything.

Whatever theory you are using that it "just won't
work" is untrue.

> You can of course dumb it all down again, and say it is only for some
> minimal work on your own OS,

Win 95 isn't my own OS. Nor is AmigaOS and many
others.

Or are you going to claim that the code I posted
already (other than the assembler glue) can't
possibly work on AmigaOS? It's pure C90.

> but if that were true, you wouldn't need to
> drag all this "other OS and hundred C compilers" into this.

C90 exists for a reason.

> Maybe for an extremely limited subset it doesn't matter much either way,
> but it is a dead end that will only hurt going beyond the most minimal
> subset.

You can say C90 itself is an "extremely limited
subset" (of what?) if you want. That is what I
support. And C90 is enough for an entire toolchain.

BFN. Paul.

> Don't put the Pascal standards on the same pedestal as C or C++ standards,

Yikes. I wasn't expecting that.

> Unless you are specifically planning to target known Standard Pascal
> codebases, I would avoid that, and go for actually living dialects TP
> (procedural) and Delphi (more object oriented, includes nearly the entire
> TP dialect)

I'm expecting someone else to provide the
compiler, so I don't care what the dialect
is. I just want to plug in the runtime
(for every dialect and every Pascal compiler).

BFN. Paul.

> > I think I am missing something.
> >
> > What is wrong with having one C90-compliant
> > source file in FPC (or my own derivative)
> > and then building it with hundreds of
> > different C compilers?
>
> What will it actually solve? Solution in search of a problem actually. You
> still have a C<->Pascal interface.

The problem it will solve is that if someone has
already implemented a C compiler on a particular
system, FPC has a ready-made runtime library.

I just did it with PDOS/386. But that same code
will work on PDOS/3X0 and MVS 3.8J and z/OS too
as soon as the FPC targets that new environment.

> > I am securing C first, so that's not a problem.
> > I personally will only be supporting Pascal on
> > a system that already has a working C90-compliant
> > C compiler. That's what I spent 27 years doing
> > on the x86 and S/3X0 (in tandem), to break
> > Microsoft's and IBM's respective monopolies.
>
> For one system, the whole "hundred compilers" and portability aspects are
> bogus.

Not true. It will work on AmigaOS too, another
place that PDPCLIB has been ported to.

> Of course you can go that way, but you only need to rewrite a lot of RTL
> functions for kernel32 stuff and diverge unnecessary.

I don't have to rewrite anything. It's all working
already. The effort (27 years) has already been done
to get the C side working. Adding Pascal (to the
same level as C90) is only a couple of days work,
as far as I can tell, and once the issues are known.

BFN. Paul.

> I am experimenting with compilers. I am very interested in a.out as it is
> very simple. Can you tell me more - who also supports this format?

Few new stuff. a.out is an old Unix fileformat. Unix changed to COFF and then later to ELF. Microsoft, as an Unix licensee, based its fileformat on COFF and called it PE/COFF.

I think Linux directly jumped from a.out to ELF, with Linux 2.0 somewhere in the late nineties.

I think OpenBSD changed much later (about 10 years later?) some 3.x version.

If you are interested in a.out get the book "Linkers and Loaders" by "John R Irvine". The authors site used to have it up for free.

> > For the first (1) set of calls , keep in mind that the Windows console
> is
> > in a different (OEM) encoding than the api (ANSI). How do you handle
> that
> > difference (OEM vs Ansi) in your program?
>
> I'm not sure I understand the issue, I know that
> OEM means "Other Equipment Manufacturer", but I
> would be surprised if Pascal 83-0 was so complicated.

Please read. Windows is so complicated, I told you how to neutralize it if it doesn't matter for your PDDos/386.

IOW on Windows the runtime must hide the fact that the two apis (console I/O and other APIs use differing charsets). Just to keep extended ascii (and thus basic European accents) working.

Since you don't go for running basic Windows binaries, but only use the compilers to hack it for your OS, it doesn't matter much for you, and you can simply change those calls to user32.dll conversion routines to simply copy the string 1:1.

> I am thinking that ANSI interpretation belongs
> in the BIOS layer rather than PDOS proper, but
> I'm not sure.

Windows 11 will require UEFI. I suspect the number of PCs with legacy biosses might start to dwindle soon.


> Let me see if I can get this really basic
> functionality working first.

This message was all about explaining why the functions were used in the /runtime/ of FPC, and what you could do to get rid of those user32 dependencies.

> Ok, the main problem was solved by switching
> from ldwin to the "ld" that is provided by
> FPC. For some reason it is working even though
> ld that comes with Cygwin, and my ldwin, come
> up with errors and require --no-inhibit to
> ignore them. I wonder what those errors mean,
> as surely there must be a way of getting
> normal "ld" to work?

For windows, the internal linker is recommended, as I already told you.

And yes, 3rd party builds of ld.exe might have issues, which is why we deliver our own. Same with gdb.exe

For questions about why 3rd party builds of ld.exe don't work, ask the people that built them. It might be options, or known issues, problems with weak linking, problems with processing of link scripts or using _ prefixes for some legacy reason.

> Producing a 100% public domain executable

The PD thing is your own hang up. Nearly the entire world is fine with BSD and LGPL-static-linking-exception.

In the nineties some people were paranoid about open source licenses, but it is 2021 now, and this is all daily fare for most programmers. I haven't heard about this particular direction in decades.

> # Without "-s", this produces an executable (but can be ignored)
> # With "-s" this produces crap (which can be deleted)
> # I choose to delete crap
> .pas.o:
> fpc -a -s $<
> rm -fr link*.res
> rm -fr ppas.bat
> $(AS) -o $@ $*.s
> rm -f $*.s


Word of advise, FPC has no C compatible build mode so makefiles are hard.

IOW if a source file passed to FPC references another module that needs recompilation, the compiler will automatically recursively compile it.

This can't be disabled. Going in this direction will make multi module Pascal programs difficult.

> By targeting msvcrt.dll, or in fact, just any C
> library, my code should work on native Linux/BSD
> too.

The first Linux port dates for 1995, you are bit late here

There already is fairly advanced code for that in the Unix ports (linux/*bsd/OSX/AIX/Solaris/BeOS and friends). And I wrote most of it.

As said linux/*bsd programs default don't link to libc, but they can with a ifdef.

Do you really think you are the first one to propose this (there are FAQs about it e.g. https://wiki.freepascal.org/libc_unit and http://www.stack.nl/~marcov/unixrtl.pdf), some problems with this approach (just from the top of my head)

- Mostly it is structs and macros that still need to be translated. So basically you only gain a few function calls that are pretty much trivial on most systems anyway. But in general you move to a system that is more likely to break (change in C compiler-> have to debug/fix pascal equivalent header, and deal with versioning, while C users might not even notice it)

- iirc passing 64-bit integers (mmap/ftruncate/lseek etc) on 32-bit systemswill be possible problems, as that is calling conventions dependent. I expect the problems more between Linux/FreeBSD and the rest though, and on x64. Linux vs freebsd on x86 might be ok.

- checking the existence, readonly status of a file requires handling stat, which must be translated manually, and also uses macros (is_dir etc)

- traversing files might require DIR* etc.

- Some constants differ, but mostly in termio parts, not in basic I/O, but some of these are used to check if stdin is redirected or not (e.g. to disable colouring of output when redirecting).

- truename() functionality (expanding a partial path to a whole) needs statfs

- Disabling ctrl-C, sockets and textmode mouse need sigset and fdset handling which vary considerably between Windows and *nix, and slightly within *nix.

You can of course dumb it all down again, and say it is only for some minimal work on your own OS, but if that were true, you wouldn't need to drag all this "other OS and hundred C compilers" into this.

Maybe for an extremely limited subset it doesn't matter much either way, but it is a dead end that will only hurt going beyond the most minimal subset.

> Rather than tying myself down to the Win32 API.
>
> In fact, if I can figure out how to replace the
> assembler "glue" file with a FPC Pascal file,
> this solution will work everywhere that both
> FPC and a C compiler exists.
>
> So the next question of course is - does FPC
> support S/370?

We support POWER processors, and there was somebody external working on it, but afaik it stalled. https://wiki.lazarus.freepascal.org/ZSeries

I wouldn't expect too much from it.