DOS ain't dead - 32-bit MSDOS

kerravon

Sydney, Free World South,
26.06.2021, 15:52

32-bit MSDOS (Announce)

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.

tom Germany (West), 27.06.2021, 13:23 @ kerravon	32-bit MSDOS Post reply
	> My vision of what MSDOS should have become in the late 1980s is here: > > http://pdos.org what does it better than MSDOS? what sort of programs does it run? does it run Norton Commander? Does it support MS Lanmanager? can it read DVD/CD? as you mention MSVCRT.DLL: does it load PE executables?

kerravon

Sydney, Free World South,
27.06.2021, 13:46

@ tom

32-bit MSDOS

Post reply

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

It is 32-bit instead of 16-bit if you wish
to have that.

> what sort of programs does it run?
>
> does it run Norton Commander?
>
> Does it support MS Lanmanager?

It doesn't support anything unless you
recompile as 32-bit.

But (some) INT 21H functions are available
(in clean 32-bit mode, flat address space,
supervisor mode, no memory protection).

One executable format used is a.out (which
EMX 0.9d used, not sure about other DOS
extenders). But segment registers are
never used.

> can it read DVD/CD?

No. Only hard disks and floppy disks.

> as you mention MSVCRT.DLL: does it load PE executables?

Correct. That is the other executable format
supported. So if you write to the lowest
common denominator, you can have a Win32
executable that runs on PDOS/386 and also
Freedos+HX and also every version of Windows
since Win95 (not sure if it works on Win32s
systems prior to Win95) and also Linux/Wine
(or anything else with Wine).

Note that there is also a new GCC executable
for this environment just released an hour ago.

BFN. Paul.

tom

Germany (West),
27.06.2021, 14:14

@ kerravon

Post reply

> In the absence of mathematical proof either way
> for the above hypothesis, what tools should be
> used to answer it? The only tool I have at the
> moment is my "bios" proof of concept that calls
> "generic PDOS". I can look at it and say that
> it won't work if anyone does an INT instruction.

I think the test is - any application executable
that demands that a segment register be set a
certain way, or an interrupt vector be set a
certain way, precludes the ability of the caller
to be unprivileged.

Instead, only instructions (such as mov ecx, edx)
should exist inside an executable, as these are
unprivileged instructions that have no dependencies
on particular memory locations or particular
privileged registers.

So that includes anyone who calls INT 21H directly
at all, nevermind INT 31H.

Note that if PDOS/386 or HX do these interrupts
internally, that is fine, as they are part of
the OS implementation (from my perspective,
anyway). The HX applications themselves do not
depend on INT 31H. That instruction is not
inside the Win32 executables themselves.

BFN. Paul.

marcov 30.06.2021, 15:11 @ kerravon	32-bit MSDOS Post reply
	> I think the test is - any application executable > that demands that a segment register be set a > certain way, or an interrupt vector be set a > certain way, precludes the ability of the caller > to be unprivileged. Afaik Windows and Linux use %fs for TLS.

kerravon

Sydney, Free World South,
30.06.2021, 22:32

@ marcov

32-bit MSDOS

Post reply

> > I think the test is - any application executable
> > that demands that a segment register be set a
> > certain way, or an interrupt vector be set a
> > certain way, precludes the ability of the caller
> > to be unprivileged.
>
> Afaik Windows and Linux use %fs for TLS.

I know every byte that goes into the Win32
executables that I produce (that run under
normal Windows, HX and PDOS/386). There is no
requirement for %fs to be set. I don't even
know what TLS is.

BFN. Paul.

marcov

30.06.2021, 22:42

@ kerravon

32-bit MSDOS

Post reply

> > Afaik Windows and Linux use %fs for TLS.
>
> I know every byte that goes into the Win32
> executables that I produce (that run under
> normal Windows, HX and PDOS/386).

> There is no
> requirement for %fs to be set. I don't even
> know what TLS is.

I'm sure you know your subset, but since TLS also plays a role in SEH, in practice it is quite important for non trivial windows binaries, e.g. ones that interface COM, or use native Windows C++ and thus system libraries for exceptions (rather than SJLJ emulation)

Of course since TLS is related to threading it might be less relevant on a single threaded OS like dos. But the subset of Windows binaries (even commandline) that will run decreases because of it.

Which is sad, since from what I have read, Win32 seems to be the only way of running existing binaries on your OS.

Apropos, nearly all dos extenders use DPMI services for their memory operations (e.g. allocate blocks >1MB), access to segments and hooking interrupts. Emulating those should make it easier to retarget existing compilers.

kerravon

Sydney, Free World South,
30.06.2021, 22:57

@ marcov

32-bit MSDOS

Post reply

> > > Afaik Windows and Linux use %fs for TLS.
> >
> > I know every byte that goes into the Win32
> > executables that I produce (that run under
> > normal Windows, HX and PDOS/386).
>
> > There is no
> > requirement for %fs to be set. I don't even
> > know what TLS is.
>
> I'm sure you know your subset, but since TLS also plays a role in SEH, in
> practice it is quite important for non trivial windows binaries, e.g. ones
> that interface COM, or use native Windows C++ and thus system libraries for
> exceptions (rather than SJLJ emulation)

I don't know any of those terms, but GCCWIN is
a 3 MB executable and hardly "trivial". It's
400,000 lines of C code.

> Of course since TLS is related to threading it might be less relevant on a
> single threaded OS like dos. But the subset of Windows binaries (even
> commandline) that will run decreases because of it.

My focus is on getting C90-compliant programs
to work. The onus is on applications to be
written in such a way that in an environment
that doesn't support threading, the code base
produces a sensible executable.

> Which is sad, since from what I have read, Win32 seems to be the only way
> of running existing binaries on your OS.

It is the way that is officially supported.

It also runs (after defining!) 32-bit MSDOS
executables that look quite similar to
DOS32A, but don't make demands on segment
registers (but do make the same/similar
demand on INT 21H).

> Apropos, nearly all dos extenders use DPMI services for their memory
> operations (e.g. allocate blocks >1MB), access to segments and hooking
> interrupts. Emulating those should make it easier to retarget existing
> compilers.

It seems harmless enough to redirect an INT 31H
that requests >1MB memory to the appropriate
INT 21H function (which was necessarily an
extension in PDOS/386).

But access to what segments? I only have one
usable selector and the segment registers are
already set correctly. If any DPMI application
intends to inspect or modify those, it isn't
going to work. ie DOS32A won't work when it
starts looking at ES expecting a parameter
there.

There is an existing MSDOS call to hook interrupts
though. That is OK. I can redirect INT 31H to the
standard INT 21H call to hook interrupts.

So with 2 out of the 3 above things being doable,
does that enable anything existing to run?

Thanks. Paul.

marcov

01.07.2021, 09:45

@ kerravon

32-bit MSDOS

Post reply

> I don't know any of those terms, but GCCWIN is
> a 3 MB executable and hardly "trivial". It's
> 400,000 lines of C code.

But most don't touch OS.

> > Of course since TLS is related to threading it might be less relevant on
> a
> > single threaded OS like dos. But the subset of Windows binaries (even
> > commandline) that will run decreases because of it.
>
> My focus is on getting C90-compliant programs
> to work. The onus is on applications to be
> written in such a way that in an environment
> that doesn't support threading, the code base
> produces a sensible executable.

Count me out then, I'm not interested in C programming, except for when I absolutely can't avoid it in embedded situations.

The compiler I'm working on is not C nor one its derivatives (C++/D), but firmly in the Wirthian realm.

> But access to what segments? I only have one
> usable selector and the segment registers are
> already set correctly. If any DPMI application
> intends to inspect or modify those, it isn't
> going to work. ie DOS32A won't work when it
> starts looking at ES expecting a parameter
> there.

As said most assume an Unix model where ds=es.

Other selectors are sometimes used to map in the 16-bit dos 1MB and even rare for the VESA 2.0 linear framebuffer.

> So with 2 out of the 3 above things being doable,
> does that enable anything existing to run?

No, but it could be fairly trivial. E.g. for go32v2 (*) memory buffers have to be transfer from 32-bit space to 16-bit space before calling an integer, e.g. a filename or filebuffer.

But still, it requires modification, maintaining an extra target etc etc. The question is why would anybody. But I already asked that in a different post.

(*) The extender that DJGPP but also FPC or Free Basic uses. Afaik this one has been the choice of most for the last decade, but I might be mistaken. It would make sense to focus on that first.

kerravon

Sydney, Free World South,
01.07.2021, 13:39

@ marcov

32-bit MSDOS

Post reply

> > I don't know any of those terms, but GCCWIN is
> > a 3 MB executable and hardly "trivial". It's
> > 400,000 lines of C code.
>
> But most don't touch OS.

Sure. That's the class I support.

> > > Of course since TLS is related to threading it might be less relevant
> on
> > a
> > > single threaded OS like dos. But the subset of Windows binaries (even
> > > commandline) that will run decreases because of it.
> >
> > My focus is on getting C90-compliant programs
> > to work. The onus is on applications to be
> > written in such a way that in an environment
> > that doesn't support threading, the code base
> > produces a sensible executable.
>
> Count me out then, I'm not interested in C programming, except for when I
> absolutely can't avoid it in embedded situations.
>
> The compiler I'm working on is not C nor one its derivatives (C++/D), but
> firmly in the Wirthian realm.

To date I haven't considered other languages.
But maybe now is the time to start doing that.
I know I can make C90 applications work on
PDOS/386.

What is required to get Pascal to work? Starting
with println('hello, world')
or whatever it is in Pascal.

> > But access to what segments? I only have one
> > usable selector and the segment registers are
> > already set correctly. If any DPMI application
> > intends to inspect or modify those, it isn't
> > going to work. ie DOS32A won't work when it
> > starts looking at ES expecting a parameter
> > there.
>
> As said most assume an Unix model where ds=es.

Those ones won't have a problem then. BTW, I
can't remember if I mentioned it, but for
DOS32A, they muck around with "es" here:

http://dos32a.narechk.net/manual/index.html

Not sure what they're hoping to set es to.
There's only one selector available. If they
don't actually touch es, and assume ds = es,
then everything will be fine.

> Other selectors are sometimes used to map in the 16-bit dos 1MB and even
> rare for the VESA 2.0 linear framebuffer.
>
> > So with 2 out of the 3 above things being doable,
> > does that enable anything existing to run?
>
> No, but it could be fairly trivial. E.g. for go32v2 (*) memory buffers have
> to be transfer from 32-bit space to 16-bit space before calling an integer,
> e.g. a filename or filebuffer.

Ok, I provide an API to get memory below
1 MiB already, so if they unnecessarily
copy memory down there, that shouldn't
actually be a problem.

> But still, it requires modification, maintaining an extra target etc etc.
> The question is why would anybody. But I already asked that in a different
> post.

You don't have a Win32 target already for your
Pascal compiler/programs?

> (*) The extender that DJGPP but also FPC or Free Basic uses. Afaik this one
> has been the choice of most for the last decade, but I might be mistaken.
> It would make sense to focus on that first.

I may well be able to support it, but it would
seem strange to do so when you can produce a
Win32 executable that runs, or can run, on
almost every single computer and OS since
around 1990.

Linux has Wine. Freedos/MSDOS has HX. PDOS/386
has it. Even Microsoft support it. Can't remember
the name of their shitty product. Something-11
I think I heard. :-)

BFN. Paul.

marcov

01.07.2021, 15:54

@ kerravon

32-bit MSDOS

Post reply

> What is required to get Pascal to work? Starting
> with println('hello, world')
> or whatever it is in Pascal.

Well, the easiest would be to use the 16-bit compiler and run it under your 16-bit OS. (Or use some antique compiler version that generates binaries that run under your win32 emulation, but more on windows later)

You need to port the runtime, but that is pretty trivial. You can also do away with the 1MB copying and adjust to your calls.

The problems are in
- the linker. There is an internal one for go32v2 target. djgpp ld is also possible. On go32v2, the compiler directly generates coff .o and .a's.
- exception support. I guess for go32v2 it is SJLJ, so no problem.
- stack checking
- startup code is OS specific and must be created/ported.
- uses two handful of djgpp/extender symbols for things like ctrl-c trapping.

All will require some time. If there are problems with the linkers, those are probably the most complicated.

>
> You don't have a Win32 target already for your
> Pascal compiler/programs?

Yes, it is called "Free Pascal" btw, and its IDE is called Lazarus(-IDE), following the Delphi mould. Includes gadgets like resource compilers and even a CHM helpfile compiler.

But win32 is not a retro target, and thus officially only supports still supported Windows versions (win8+), with vista and w7 in a kind of grace period. (compatibility issues are fixed when reported in release candidates). I got report that most basic functionality however still works on w2000 and XP, including the 3Mloc IDE.

Since 2015 it switched to mostly use -W functions and thus dropped win9x compatibility, since 2020 it uses SEH for exception handling.

In total there are 5 windows targets

- 16-bit Win3.x
- win32, see above
- win64(x86_64 and experimental ARM64, e.g. RPI4), shares 99.9% RTL with win32.
- NativeNT(going to ntdll, used for device drivers and other NT system applets)
- wince (i386 and ARM), in decline.

The compiler also had its "hello world" moment on Itanium, and then x86_64 happened :-) The core missing active one is WinRT, the Windows "apps" format.

There are several dos targets too in varying degrees of decomposition:
- the main 32-bit target go32v2, based on the go32 V2 extender that DJGPP also uses.
- the main 16-bit dos target "msdos" (with 6 memory models). Newly released in 2020 :-P !!
- OS/2 EMX, somewhat deprecated after the native OS/2 target emerged.
- watcom extender worked for a while too.

> I may well be able to support it, but it would
> seem strange to do so when you can produce a
> Win32 executable that runs, or can run, on
> almost every single computer and OS since
> around 1990.

The advantage of the old dos extenders is that they are fairly static, while most windows compilers slowly modernize as Windows moves on. E.g. using unicode functions.

> Linux has Wine. Freedos/MSDOS has HX.

And wdosx.

> PDOS/386
> has it. Even Microsoft support it. Can't remember
> the name of their shitty product. Something-11
> I think I heard. :-)

ReactOS :-)

Post reply

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

mceric

Germany,
05.07.2021, 12:40
(edited by mceric, 05.07.2021, 12:53)

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
05.07.2021, 14:00

@ mceric

32-bit MSDOS

Post reply

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

mceric

Germany,
05.07.2021, 16:27

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
05.07.2021, 23:55

@ mceric

32-bit MSDOS

Post reply

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

tom Germany (West), 06.07.2021, 09:51 @ kerravon	32-bit MSDOS Post reply
	> 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.

kerravon

Sydney, Free World South,
06.07.2021, 11:06

@ tom

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
07.07.2021, 09:31

@ kerravon

32-bit MSDOS

Post reply

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.

marcov

02.07.2021, 14:05

@ kerravon

32-bit MSDOS

Post reply

> I'm not very interested in PDOS/86. I would
> like a 32-bit OS running 32-bit applications.

Ok. I'll talk about 32-bit only from now on.

> Ok, so it used to support the older Win95, but
> a decision was made to abandon this older
> environment.

Yes. And that coincided with a decision that the system should be unicode proof, and some other long standing issues to be tackled.

Your instincts are correct, separating the "win32" port into a winNT and a win9x would have been a solution and this was also proposed, already quite early on in the discussion.

However the problem was that were near zero users and fully zero developers in regular communication about win9x. We had one or two guys that tested ones after every release (the final release often not even the candidates), and that was about it. A few months before it turned out that bugs in the "special dir" functionality made it dysfunctional on win9x, and nobody noticed for 15 full months.

Despite the low expectactions, an explicit call for people to do this was sent to maillists, and this didn't turn up more active users/developers.

> I think this is the fundamental point at which
> I diverge - I am interested in environments
> that are even less capable than Win95. I'm
> looking for the minimal environment required
> to write a "hello world" Pascal program.

That's very minimal, as we support many embedded boards, and even targets like ZX Spectrum/QL are more complex than that.

But those are with so called embedded versions of the runtime. Go32v2 and Win32 both use the more full RTL.

> A Pascal program takes in a bunch of text files,
> and outputs a single binary file. This basic
> functionality should exist on literally every
> Pascal platform that has ever existed, and I
> expect Free Pascal to have this as a target.

On Windows yes, since we have an internal assembler and linker there. Afaik go32v2 too btw.

> > that run under your win32 emulation, but more on windows later)
>
> Is there a reason you call it an "emulation"?

I was thinking about such extenders supporting a subset of the current API. I wasn't trying to make a point.

> Win32 is actually the only supported advertised
> API. I would have thought "mini-clone" or
> "subset" would be a better description.

Subset is better yes.

> Ok, I'm not interested in graphics at the moment.
> I just want to get text working at all.

There is a textmode IDE that is the spitting image of Turbo Pascal 7. Also a bit low on maintenance though, the GUI one took over.

> > Since 2015 it switched to mostly use -W functions and thus dropped win9x
> > compatibility, since 2020 it uses SEH for exception handling.
>
> Couldn't this have been abstracted? Windows
> already has this abstraction, doesn't it?

There are -A and -W versions for most calls, and a few macros to workaround that. But the macro/preprocessor solution is useful for Pascal, as Pascal uses precompiled units, and doesn't reinterpret every header on every compile. So that would make switching on a per application basis with a define difficult.

Runtime would require a lot of loadlibrary() and other tricks to avoid having links to the -W program refusing to load on win9x due to missing dependencies.

This was the main reason to use a separate target (that still could share quite some sources)

> I see this in my windows.h (in PDOS):
>
> #define CreateDirectory CreateDirectoryA
>
> If you just call CreateDirectory, then that will
> resolve (in other environments) to either A or W
> as required. Note that you could have an X instead
> of W and support 32-bit Unicode, if you were to
> rebuild PDOS/386. Currently I only support single
> byte - even wchar_t will give you a single byte.

We have one and two byte string types. The one byte stringtype has an encoding field. It can also be set to utf8, and then the RTL will automatically translate the utf16 to utf8 etc.

> Surely if this ancient environment is still supported,
> then PDOS/386 is just a slight variation of this plus
> Win32, and if you do that as a target, you will pick
> up Win95 et al too.

As with all targets, who will do the work is the core point. This is why some recent "old" targets like 16-bit dos and windows, Amiga and ZX Spectrum are alive, and the old majority targets Dos and Win9x are almost dead.

But yeah, doing a native port to your own api seems the most prudent direction. You could go for either dos or windows, but the dos port is more simple.

> Ok, with all these supported platforms, the
> code is probably already structured to support
> a "new" platform like basic Win32.

I think so. Several new targets are added annually. Architectures (processors) a bit more rarely, but still regularly.

> Win95 is static, isn't it?

Yes. But since you'd be effectively the only user, I'd directly make that a port to your system directly, rather than pretending "win9x".

> Or is the problem
> you don't have control of the compiler?

Currently the only external on non-unix is GDB. A start has been made with an own debugger (initially for windows), and it actually went 1.0 last week.

Compiler is less of a problem. Linker more likely.

> BTW, as of last night, gccwin is confirmed to
> be a native Windows compiler, not requiring
> Cygwin or an existing C compiler. It's a very
> simple setup. It's available at http://pdos.org
> I walked a non-programmer through the setup
> online.

FPC written in its own dialect. We of course look at gcc from time to time how they solve platform specific problems, but that is about it.

kerravon

Sydney, Free World South,
02.07.2021, 15:19

@ marcov

32-bit MSDOS

Post reply

> > I think this is the fundamental point at which
> > I diverge - I am interested in environments
> > that are even less capable than Win95. I'm
> > looking for the minimal environment required
> > to write a "hello world" Pascal program.
>
> That's very minimal, as we support many embedded boards, and even targets
> like ZX Spectrum/QL are more complex than that.

Ok, if you support the Amiga too, I don't see
why PDOS/386 can't be a target too.

> > Surely if this ancient environment is still supported,
> > then PDOS/386 is just a slight variation of this plus
> > Win32, and if you do that as a target, you will pick
> > up Win95 et al too.
>
> As with all targets, who will do the work is the core point. This is why
> some recent "old" targets like 16-bit dos and windows, Amiga and ZX
> Spectrum are alive, and the old majority targets Dos and Win9x are almost
> dead.

Ok, fair enough.

I am indeed interested in getting it to run
on PDOS/386 and then instantly getting Win95
etc too.

> But yeah, doing a native port to your own api seems the most prudent
> direction. You could go for either dos or windows, but the dos port
> is more simple.

When you say "my own API" - what do you mean?
I support a subset of standard Win95 kernel32.dll
and a subset of standard Win95 msvcrt.dll.

If by "my own API" you mean my vision of 32-bit
MSDOS, I don't see a reason to tie myself down
to that when I can pick up Win95 for free.

If you mean that the MSDOS API is much nicer,
I agree with that too, if you wrap the INT 21H
calls with something like PosOpenFile() that
does an INT 21H (16-bit or 32-bit), but you can
equally well make PosOpenFile() simply call
Windows CreateFile().

> Compiler is less of a problem. Linker more likely.

The compiler is designed to read some text files
and output a binary file.

The linker is designed to read some binary files
and output a binary file.

How are either of these things system-specific?

Anyway, I downloaded and installed it on my
Win 10 machine and had great success.

C:\devel\develop>type world.pas
program world;

begin
writeln('Hello, World')
end.

C:\devel\develop>fpc world.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling world.pas
Linking world.exe
5 lines compiled, 0.1 sec, 28224 bytes code, 1316 bytes data

C:\devel\develop>world
Hello, World

C:\devel\develop>objdump -p world.exe | grep -i dll
DllCharacteristics 00000000
vma: Hint Time Forward DLL First
DLL Name: kernel32.dll
DLL Name: oleaut32.dll
DLL Name: user32.dll

C:\devel\develop>

I don't support those last 2 DLLs on PDOS/386,
but it is good to see that there is no equivalent
of cygwin.dll in there.

And I suspect that those two DLLs that I don't
support could be filled with stubs and my
"hello world" won't exercise them.

But ultimately I'd rather see just msvcrt.dll
showing up.

What is the quickest technical path to changing
those 3 DLLs into a single msvcrt.dll? With the
goal of just running that world.pas program
above. Or is there a technical barrier? I doubt
that there is a technical barrier to that when
there is no technical barrier to the Amiga.

BFN. Paul.

marcov

02.07.2021, 16:02

@ kerravon

32-bit MSDOS

Post reply

> > But yeah, doing a native port to your own api seems the most prudent
> > direction. You could go for either dos or windows, but the dos port
> > is more simple.
>
> When you say "my own API" - what do you mean?
> I support a subset of standard Win95 kernel32.dll
> and a subset of standard Win95 msvcrt.dll.

We don't use msvcrt.dll anywhere, as we are not a C compiler.

There is work being done to shift the FPC runtime to a DLL to share amongst programs too.

> If by "my own API" you mean my vision of 32-bit
> MSDOS, I don't see a reason to tie myself down
> to that when I can pick up Win95 for free.

Both need work. The win32-as-basis need deNTification, the dos as basic needs deGO32ification to seamlessly operate with your offerings.

But the size and complexity of the go32v2 port is much less. In the end it is your preference and what you are willing to work for.

> If you mean that the MSDOS API is much nicer,
> I agree with that too, if you wrap the INT 21H
> calls with something like PosOpenFile() that
> does an INT 21H (16-bit or 32-bit), but you can
> equally well make PosOpenFile() simply call
> Windows CreateFile().

Yes. It is now just TP dos like, doing interrupt calls by loading a record with register values and then calling the extender's INT routine.

See https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/sysfile.inc?view=markup

There are some runtime checks though, like switch betweeen ah=$7xxx style dos LFN calls and normal $3C00 dos open calls. This is toggable with a global "LFNSUPPORT" variable, also there is some more work to replace / with \.

> > Compiler is less of a problem. Linker more likely.
>
> The compiler is designed to read some text files
> and output a binary file.

That's not the problem, it generates mostly djgpp or mingw compatible files.

> The linker is designed to read some binary files
> and output a binary file.

"a" binary file. But not all binary files are exactly the same. There are NT only features in the PE format, and since the internal linker emerged when winXP was already dominant It is simply a subject that is a magnitude more complicated than the RTL work, so that's why I warned.

You can maybe use a mingw's LD linker, but you may lose smartlinking that way (and a lot of speed)

FPC install: run "fp" and see what happens :)

> C:\devel\develop>objdump -p world.exe | grep -i dll
> DllCharacteristics 00000000
> vma: Hint Time Forward DLL First
> DLL Name: kernel32.dll
> DLL Name: oleaut32.dll
> DLL Name: user32.dll
>

user32 is generally speaking core windows api. Our base Windows headers are winuser/wintypes.h etc translations, and afaik mix user32 kernel32, so I don't know exactly how much it is used.

In the system unit I only see a reference to messageboxa (for a exception popup in GUI applications), and charupperbufferw to uppercase a 16-bit character string.

Oleaut32 is used for the COM compatible string type, and less important, fairly easy to turn off or not.

> I don't support those last 2 DLLs on PDOS/386,
> but it is good to see that there is no equivalent
> of cygwin.dll in there.

We originate in Turbo Pascal, so there is no C or C library usage within the project.

> And I suspect that those two DLLs that I don't
> support could be filled with stubs and my
> "hello world" won't exercise them.

Yes. That is matter of compiling a few non trivial programs and looking with dependency walker what is exactly used.

> But ultimately I'd rather see just msvcrt.dll
> showing up.

I understand why you want that (since that means that the relevant C compiler has been turned from cygwin/mingw to use msvcrt runtime). But we don't use _any_ C runtime, also no own static abstraction internally.

Our origin and compatibility goal is Turbo Pascal/Delphi. Some experience with those would serve you well here.

> What is the quickest technical path to changing
> those 3 DLLs into a single msvcrt.dll? With the
> goal of just running that world.pas program
> above. Or is there a technical barrier?

I don't think there is a significant technical barrier for your own port. For our use it is an absolute nono, since afaik msvcrt has several limitations (e.g. not allowing full length pathnames etc), potential escaping issues, requiring zero terminating (not all our strings are zero terminated) etc.

Moreover, there is zero experience with it, we always used the core windows api. (

> I doubt
> that there is a technical barrier to that when
> there is no technical barrier to the Amiga.

It is all a matter of magnitude. RTL(library) work is relatively simple and can be done by a wider audience.

Note that the last version supporting win9x (afaik) is still online:
ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/i386-win32/fpc-2.6.4.i386-win32.exe

sources: ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/source/fpc-2.6.4.source.zip

mceric

Germany,
02.07.2021, 17:15

@ marcov

32-bit MSDOS

Post reply

> > C:\devel\develop>objdump -p world.exe | grep -i dll
> > DllCharacteristics 00000000
> > vma: Hint Time Forward DLL First
> > DLL Name: kernel32.dll
> > DLL Name: oleaut32.dll
> > DLL Name: user32.dll
> >
>
> user32 is generally speaking core windows api. Our base Windows headers are
> winuser/wintypes.h etc translations, and afaik mix user32 kernel32, so I
> don't know exactly how much it is used.
>
> In the system unit I only see a reference to messageboxa (for a exception
> popup in GUI applications), and charupperbufferw to uppercase a 16-bit
> character string.
>
> Oleaut32 is used for the COM compatible string type, and less important,
> fairly easy to turn off or not.

...
> > But ultimately I'd rather see just msvcrt.dll

Why would you want your compiled apps to depend on the runtime library for Microsoft Visual C? They should only depend on the operating system libraries, not on the C libraries of another brand of compiler.

I guess a hello world will not use much COM or OLE automation:

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

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

But I think it would make more sense to talk about a list of functions called by the hello world example from the three libraries than just saying "let us just use the C library of Microsoft C here". You can then proceed to implement those functions of the 3 used Windows libraries which are useful in PDOS/386 and make stubs for the others.

---
FreeDOS / DOSEMU2 / ...

kerravon

Sydney, Free World South,
02.07.2021, 17:43

@ mceric

32-bit MSDOS

Post reply

> > > But ultimately I'd rather see just msvcrt.dll
>
> Why would you want your compiled apps to depend on the runtime library for
> Microsoft Visual C? They should only depend on the operating system
> libraries, not on the C libraries of another brand of compiler.

msvcrt.dll is provided with every version of
Windows since Win95, and is effectively part
of the OS. That's how mingw32 works.

PDOS/386 provides its own msvcrt.dll, built
using PDPCLIB. Which incidentally works on
Freedos+HX.

BFN. Paul.

kerravon

Sydney, Free World South,
03.07.2021, 05:14

@ kerravon

32-bit MSDOS

Post reply

I decided to take a look at the assembler that
was being generated by Free Pascal. I couldn't
stop the assemble & link from happening, but
I was able to keep the assembler which meant
that I could simply redo the process.

When I saw the generated assembler, ie
fpc_write_text_shortstr etc, I had another
thought. I don't know what the license is of
the code that is currently being linked in to
my world.exe, but since I have a presumably
entirely different approach, that isn't
relevant - I can produce my own executable
consisting of nothing but public domain code,
just like my C90-based executables.

Unfortunately I don't know how to get my C
code to selectively generate "pascal" calling
convention, or whether Free Pascal's convention
is even that. I tried __pascal and __Pascal.
__stdcall does something different.

Is this approach likely to work, or am I
missing something?

Thanks. Paul.

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

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

void fpc_initializeunits(void)
{
return;
}

int fpc_get_output(void)
{
return ((int)stdout);
}

void fpc_write_text_shortstr(int handle, char *str)
{
fputs(str, (FILE*)handle);
return;
}

void fpc_iocheck(void)
{
return;
}

void fpc_writeln_end(void)
{
printf("\n");
}

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

C:\devel\pascal>type worldpas.pas
program world;

begin
writeln('Hello, World')
end.

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

CC=gccwin
CFLAGS=-O2
LD=ldwin
LDFLAGS=
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean worldpas.exe

worldpas.exe: worldpas.o pascal.o
$(LD) $(LDFLAGS) -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascal.o ../pdos/pdpclib/msvcrt.a

# This produces an executable and I don't know how to stop it
.pas.o:
fpc -a $<
$(AS) -o $@ $*.s

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

clean:
rm -f *.o worldpas.exe

C:\devel\pascal>pdmake -f makefile.w32
rm -f *.o worldpas.exe
fpc -a worldpas.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Note: Switching assembler to default source writing assembler
Target OS: Win32 for i386
Compiling worldpas.pas
Assembling world
Linking worldpas.exe
5 lines compiled, 0.1 sec, 28224 bytes code, 1268 bytes data
1 note(s) issued
aswin -o worldpas.o worldpas.s
gccwin -S -O2 -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__ -o pascal.s pascal.c
aswin -o pascal.o pascal.s
rm -f pascal.s
ldwin -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascal.o ../pdos/pdpclib/msvcrt.a
Cannot export FPC_RESOURCESTRINGTABLES: symbol not found
Cannot export FPC_RESSTRINITTABLES: symbol not found
Cannot export FPC_THREADVARTABLES: symbol not found
Cannot export FPC_WIDEINITTABLES: symbol not found
Cannot export INITFINAL: symbol not found
Cannot export PASCALMAIN: symbol not found
worldpas.o(.text.n__main+0x5):worldpas.pas: undefined reference to `fpc_initializeunits'
worldpas.o(.text.n__main+0xa):worldpas.pas: undefined reference to `fpc_get_output'
worldpas.o(.text.n__main+0x1d):worldpas.pas: undefined reference to `fpc_write_text_shortstr'
worldpas.o(.text.n__main+0x22):worldpas.pas: undefined reference to `fpc_iocheck'
worldpas.o(.text.n__main+0x29):worldpas.pas: undefined reference to `fpc_writeln_end'
worldpas.o(.text.n__main+0x2e):worldpas.pas: undefined reference to `fpc_iocheck'
worldpas.o(.text.n__main+0x33):worldpas.pas: undefined reference to `fpc_do_exit'
worldpas.o(.data.n_INITFINAL+0x8):worldpas.pas: undefined reference to `INIT$_$SYSTEM'
worldpas.o(.data.n_INITFINAL+0x10):worldpas.pas: undefined reference to `INIT$_$FPINTRES'
worldpas.o(.data.n_FPC_THREADVARTABLES+0x4):worldpas.pas: undefined reference to `THREADVARLIST_$SYSTEM$indirect'
[worldpas.exe] Error 1

mceric

Germany,
03.07.2021, 13:03

@ kerravon

32-bit MSDOS

Post reply

Your point seems to be that the FPC library does things, in particular at program start, and that you want it to do almost nothing instead. I think the better answer would be to let your OS implement stub versions of the called API functions. Then you could also run existing FPC Pascal compiled binaries instead of having to recompile the Pascal app source code with your own stripped down runtime library, or having to modify the app source code in question to touch less of the default FPC runtime library. People normally do such things only when they are trying to create VERY small executables, because it will have various side effects beyond doing less calling of the operating system API. So again, you should probably just let your OS provide more API stubs.

---
FreeDOS / DOSEMU2 / ...

kerravon

Sydney, Free World South,
03.07.2021, 13:16

@ mceric

32-bit MSDOS

Post reply

> Your point seems to be that the FPC library does things, in particular at
> program start, and that you want it to do almost nothing instead. I think
> the better answer would be to let your OS implement stub versions of the
> called API functions. Then you could also run existing FPC Pascal compiled
> binaries instead of having to recompile the Pascal app source code with
> your own stripped down runtime library,

I wish to recompile Pascal programs to create
a public domain executable that is dependent
on nothing other than msvcrt.dll, which, in
my opinion (not saying it is universal) will
make Pascal executables as good as C executables,
and able to run on almost every 80386 + OS
in existence so long as the free supporting
runtime is provided (HX/Wine). Pick up the
abandoned-by-FPC Win95 too.

> or having to modify the app source
> code in question to touch less of the default FPC runtime library.

I will add stubs and functionality to pascal.c
as the Pascal apps I wish to run get more
sophisticated.

> People
> normally do such things only when they are trying to create VERY small
> executables, because it will have various side effects beyond doing less
> calling of the operating system API. So again, you should probably
> just let your OS provide more API stubs.

My C90 utility executables are very small too.
Like 4k or 6k.

If simple Pascal utilities are a similar size,
by virtue of leveraging msvcrt.dll the same
way, that's something I'd like to see.

But to even have proof of concept I need to
know how to get gccwin to generate Pascal
calling convention and I don't know if an
appropriate keyword even exists. I guess I
could have an assembler stub that accepts
Pascal convention and calls the C counterpart.

There are still link errors I don't know about
though, because I don't know what the assembler
code is trying to do. It's not assembler that
I have seen generated from gccwin/gcc.

BFN. Paul.

marcov

03.07.2021, 15:35

@ kerravon

32-bit MSDOS

Post reply

> and able to run on almost every 80386 + OS
> in existence so long as the free supporting
> runtime is provided (HX/Wine).

Wine and ReactOS already run, HX and wdosx worked fine (without msvcrt) a few years back with the 2.4 and 2.6 versions that were still 9x compatible. Afaik HX supports quite some -W stuff too.

> > People
> > normally do such things only when they are trying to create VERY small
> > executables, because it will have various side effects beyond doing less
> > calling of the operating system API. So again, you should probably
> > just let your OS provide more API stubs.
>
> My C90 utility executables are very small too.
> Like 4k or 6k.

FPC has not really steered towards absolute minimizing of binary sizes. We chose more function over form. Current minimal sizes are 30kish.

More or less because the only actual use of extremely small binaries for normal major targets are bragging rights. It is all hot air, and rarely about solving practical problems.

That said, somebody is working (slowly) on supporting the FPC rtl in a dll, and then minimal sizes sink somewhat to 10k and even below that.

IOW the same solution as C. But minimal sizes are not the reason for this, the reasons for the rtl-in-dll direction is more to share the same RTL state between dlls and mainprogram.

> If simple Pascal utilities are a similar size,
> by virtue of leveraging msvcrt.dll the same
> way, that's something I'd like to see.

I agree with mceric here. You risk having to rewrite minimize programs to suit the minimal C functionality, reducing the compiler to some basic C equivalent syntax and libraries only.

IMHO that is pointless. Pascal programmers will see that as regression and not touch it, even more so if their existing programs require modification.

> But to even have proof of concept I need to
> know how to get gccwin to generate Pascal
> calling convention and I don't know if an
> appropriate keyword even exists. I guess I
> could have an assembler stub that accepts
> Pascal convention and calls the C counterpart.

Pascal can directly call C counterparts. Just do the
glue code in pascal and call the C function. Then you
don't need stubs or nothing.

kerravon

Sydney, Free World South,
03.07.2021, 15:45

@ marcov

Post reply

warning - failed to open AUTOEXEC.BAT

A:\]dir
IO.SYS 17882 2021-06-07 19:03:42
COMMAND.COM 71152 2021-06-28 21:45:06
KERNEL32.DLL 35328 2021-06-07 20:08:20 kernel32.dll
MSVCRT.DLL 38400 2021-06-07 20:10:30 msvcrt.dll
TERMINAL.EXE 15883 2021-06-14 15:00:04
HDTOFIL.EXE 4096 2021-06-13 15:13:58
ZFILL.EXE 3584 2021-06-25 22:31:56
HEXDUMP.EXE 3584 2021-06-13 15:11:38
PDPTEST.EXE 4608 2021-06-13 15:10:46
PORTINIT.EXE 15041 2021-06-13 15:01:54
PORTREAD.EXE 15741 2021-06-13 15:03:18
PORTWRIT.EXE 15567 2021-06-13 15:03:50
ZAP.EXE 3072 2021-06-13 15:13:18
README.TXT 2014 2021-06-13 15:50:38 readme.txt
MSDOS.SYS 106016 2021-06-28 21:57:12 msdos.sys
WORLDPAS.EXE 8928 2021-07-04 10:40:42 worldpas.exe

A:\]worldpas
warning - failed to open worldpas.com
Hello, World

A:\]

Can't ask for more than that.

Now to consolidate. A clean link would be good,
but I don't know if I'm hitting limitations of
ldwin.

BFN. Paul.

C:\devel\pascal>objdump -p worldpas.exe | grep -i dll
DllCharacteristics 00000000
vma: Hint Time Forward DLL First
DLL Name: msvcrt.dll

C:\devel\pascal>type pascals.s
# 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

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

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

# This "add" doesn't seem to work for some reason
# add %esp, 12
pop %eax
pop %ecx
pop %edx
ret

.globl fpc_iocheck
fpc_iocheck:
call _fpc_iocheck
ret

.globl fpc_writeln_end
fpc_writeln_end:
call _fpc_writeln_end
ret

.globl fpc_do_exit
fpc_do_exit:
call _fpc_do_exit
ret

.section .data

.globl FPC_RESOURCESTRINGTABLES
FPC_RESOURCESTRINGTABLES:

.globl FPC_RESSTRINITTABLES
FPC_RESSTRINITTABLES:

.globl FPC_THREADVARTABLES
FPC_THREADVARTABLES:

.globl FPC_WIDEINITTABLES
FPC_WIDEINITTABLES:

.globl INITFINAL
INITFINAL:

.globl PASCALMAIN
PASCALMAIN:

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

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

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

C:\devel\pascal>

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

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

void fpc_initializeunits(void)
{
return;
}

int fpc_get_output(void)
{
return ((int)stdout);
}

void fpc_write_text_shortstr(int handle, char *str, int unknown)
{
/* fputs(str, (FILE*)handle); */
/* fputs("fix the registers", stdout); */
fwrite(str + 1, str[0], 1, stdout);
return;
}

void fpc_iocheck(void)
{
return;
}

void fpc_writeln_end(void)
{
printf("\n");
}

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

C:\devel\pascal>

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

CC=gccwin
CFLAGS=-O2
LD=ldwin
LDFLAGS=--noinhibit-exec
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean worldpas.exe

worldpas.exe: worldpas.o pascalc.o pascals.o
$(LD) $(LDFLAGS) -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.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 -fr link*.res
rm -fr ppas.bat
$(AS) -o $@ $*.s
rm -f $*.s

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

.s.o:
$(AS) -o $@ $*.s

clean:
rm -f *.o worldpas.exe

C:\devel\pascal>

C:\devel\pascal>type worldpas.pas
program world;

begin
writeln('Hello, World')
end.

C:\devel\pascal>

marcov

04.07.2021, 22:59

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
05.07.2021, 00:51

@ marcov

32-bit MSDOS

Post reply

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

marcov

05.07.2021, 10:00

@ kerravon

32-bit MSDOS

Post reply

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

kerravon Sydney, Free World South, 05.07.2021, 10:23 @ marcov	32-bit MSDOS Post reply
	> 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.

marcov

05.07.2021, 13:19

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
05.07.2021, 13:48

@ marcov

32-bit MSDOS

Post reply

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

kerravon Sydney, Free World South, 04.07.2021, 03:10 @ kerravon	32-bit MSDOS Post reply
	By targeting msvcrt.dll, or in fact, just any C library, my code should work on native Linux/BSD too. 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? BFN. Paul.

kerravon Sydney, Free World South, 04.07.2021, 03:15 @ kerravon	32-bit MSDOS Post reply
	> So the next question of course is - does FPC > support S/370? Not that I can see unfortunately: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/ No sign of MVS (aka z/OS), CMS (aka z/VM), VSE (aka DOS/VS, z/VSE). So I guess people need to stick to using C90 on those platforms. BFN. Paul.

kerravon

Sydney, Free World South,
04.07.2021, 05:24

@ kerravon

32-bit MSDOS

Post reply

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? I'm working at the
assembler level here.

Anyway, the revised code is below.

Producing a 100% public domain executable
derived from Pascal source, that works on
a 100% public domain OS, and also works
(or can work) on almost every 80386+
computer and OS in existence.

If that isn't a target environment that is of
interest to FPC, so be it. It's the most
interesting target to me, and I doubt that I
am the only person in the world who is also
interested in such a target.

BFN. Paul.

C:\devel\pascal>type worldpas.pas
(* public domain by Paul Edwards *)

program worldpas;

begin
writeln('Hello, World from Pascal!')
end.

C:\devel\pascal>type pascals.s
# 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

# This "add" doesn't seem to work for some reason
# add %esp, 12
pop %edx
pop %ecx
pop %eax
ret

.globl fpc_iocheck
fpc_iocheck:
call _fpc_iocheck
ret

.globl fpc_writeln_end
fpc_writeln_end:
call _fpc_writeln_end
ret

.globl fpc_do_exit
fpc_do_exit:
call _fpc_do_exit
ret

.section .data

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

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

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

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

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

void fpc_initializeunits(void)
{
return;
}

int fpc_get_output(void)
{
return ((int)stdout);
}

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

void fpc_iocheck(void)
{
return;
}

void fpc_writeln_end(void)
{
printf("\n");
}

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

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

CC=gccwin
CFLAGS=-O2
LD=ld
LDFLAGS=
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean worldpas.exe

worldpas.exe: worldpas.o pascalc.o pascals.o
$(LD) $(LDFLAGS) -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.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 -fr link*.res
rm -fr ppas.bat
$(AS) -o $@ $*.s
rm -f $*.s

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

.s.o:
$(AS) -o $@ $*.s

clean:
rm -f *.o worldpas.exe

C:\devel\pascal>dir worldpas.exe
Volume in drive C is OS
Volume Serial Number is 500F-DBAC

Directory of C:\devel\pascal

2021-07-04 12:37 6,656 worldpas.exe

C:\devel\pascal>worldpas
Hello, World from Pascal!

kerravon

Sydney, Free World South,
04.07.2021, 05:32

@ kerravon

32-bit MSDOS

Post reply

> 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? I'm working at the
> assembler level here.

Sorry, misinformation above. I tried again,
and "ld" from Cygwin does indeed work, it is
my custom ldwin (of an older version) that
does not.

Since I'm relying on someone else's Pascal
compiler anyway, there's no extra harm in
relying on their linker too, although I
would still have preferred "ldwin" to work.

C:\devel\pascal>ld --version
GNU ld (GNU Binutils) 2.23.52.20130309
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

C:\devel\pascal>ld -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.o ../pdos/pdpclib/msvcrt.a

C:\devel\pascal>ldwin -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.o ../pdos/pdpclib/msvcrt.a
Cannot export FPC_RESOURCESTRINGTABLES: symbol not found
Cannot export FPC_RESSTRINITTABLES: symbol not found
Cannot export FPC_THREADVARTABLES: symbol not found
Cannot export FPC_WIDEINITTABLES: symbol not found
Cannot export INIT$_$FPINTRES: symbol not found
Cannot export INIT$_$SYSTEM: symbol not found
Cannot export INITFINAL: symbol not found
Cannot export PASCALMAIN: symbol not found
Cannot export THREADVARLIST_$SYSTEM$indirect: symbol not found

C:\devel\pascal>ldwin --version
GNU ld version 2.14 20030612
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

BFN. Paul.

marcov

04.07.2021, 23:08

@ kerravon

32-bit MSDOS

Post reply

kerravon

Sydney, Free World South,
05.07.2021, 01:00

@ marcov

32-bit MSDOS

Post reply

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

kerravon Sydney, Free World South, 05.07.2021, 04:10 @ kerravon	32-bit MSDOS Post reply
	> 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]

tkchia

05.07.2021, 15:09
(edited by tkchia, 05.07.2021, 15:28)

@ kerravon

32-bit MSDOS

Post reply

> 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://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

kerravon

Sydney, Free World South,
05.07.2021, 15:48

@ tkchia

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
04.07.2021, 05:43

@ kerravon

32-bit MSDOS

Post reply

Another thing to note is that this technique
effectively introduces new reserved words into
the Pascal language - fwrite, printf etc.

So it's presumably not 100% Pascal83-0 compliant
and requires a subset of even that. Well, right
at the moment it is down to a subset that is
just writeln(), but I would hope that other
Pascal83-0 stuff could be supported when I find
out what it actually is. The language itself is
already covered (other than the new reserved
words), but it's not clear to me yet what the
limits of the C90-based runtime are.

Maybe I can only support I/O checks done
immediately after a file access attempt, or
something like that.

BFN. Paul.

kerravon

Sydney, Free World South,
04.07.2021, 07:06

@ kerravon

32-bit MSDOS

Post reply

> words), but it's not clear to me yet what the
> limits of the C90-based runtime are.

I had to make some adjustments, but I can open
and write to files. Which means reading is
probably doable too, so no obvious limits. And
reading and writing files is almost everything
I actually want to do, and probably all that
ISO Pascal defines.

BFN. Paul.

C:\devel\pascal>type worldpas.pas
(* public domain by Paul Edwards *)

program worldpas;

var
fq : TextFile;

begin
writeln('Hello, World from Pascal!');
assign(fq, 'out.txt');
rewrite(fq);
writeln(fq, 'Write to file');
end.

C:\devel\pascal>type pascals.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_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\pascal>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 int init = 0;
static FILE *x;

if (!init)
{
init = 1;
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_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\pascal>type makefile.w32
# Produce Windows executables
# 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.
LD=ld
LDFLAGS=
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean worldpas.exe

worldpas.exe: worldpas.o pascalc.o pascals.o
$(LD) $(LDFLAGS) -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.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 -fr link*.res
rm -fr ppas.bat
$(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 worldpas.exe

C:\devel\pascal>dir out.txt
Volume in drive C is OS
Volume Serial Number is 500F-DBAC

Directory of C:\devel\pascal

2021-07-04 14:54 15 out.txt
1 File(s) 15 bytes
0 Dir(s) 62,185,209,856 bytes free

C:\devel\pascal>hexdump out.txt
000000 57726974 6520746F 2066696C 650D0A Write to file..

kerravon

Sydney, Free World South,
04.07.2021, 07:35

@ kerravon

32-bit MSDOS

Post reply

> > So the next question of course is - does FPC
> > support S/370?
>
> Not that I can see unfortunately:

I found my name mentioned on the Free Pascal wiki though:

https://wiki.freepascal.org/ZSeries/Part_4

Ironic.

That's from 2012.

If the S/370 or S/390 instructions ever
eventuated, PDPCLIB is ready to slot in
already with just changes to the
already-posted pascals.asm to be S/370
instead of 80386.

BFN. Paul.

tkchia

04.07.2021, 09:16

@ kerravon

32-bit MSDOS

Post reply

Hello kerravon,

> By targeting msvcrt.dll, or in fact, just any C
> library, my code should work on native Linux/BSD
> too.
> Rather than tying myself down to the Win32 API.

I am not sure why you believe it is so important that to make your PDOS kernel run "on top of" other OSes, with zero emulation or virtualization whatsoever. This has never been a requirement for any other OS that I know of.

If I want to run some OS "inside" some other OS, I can just fire up QEMU or Bochs or VirtualBox and call it a day.

Thank you!

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

kerravon

Sydney, Free World South,
04.07.2021, 10:13

@ tkchia

32-bit MSDOS

Post reply

> > By targeting msvcrt.dll, or in fact, just any C
> > library, my code should work on native Linux/BSD
> > too.
> > Rather than tying myself down to the Win32 API.
>
> I am not sure why you believe it is so important that to make your PDOS
> kernel run "on top of" other OSes, with zero emulation or virtualization
> whatsoever. This has never been a requirement for any other OS that I know
> of.

I'm not sure why you made the above comment in
relation to the above quote. The above quote
was for Pascal-derived executables, not PDOS.

But regardless, yes, I do have a requirement
for PDOS/386 to be decoupled from the BIOS,
and turn into PDOS-generic.

> If I want to run some OS "inside" some other OS,
> I can just fire up QEMU or
> Bochs or VirtualBox and call it a day.

Bochs/Qemu doesn't run at native speed.

VirtualBox requires privilege I think.

I wish to run PDOS in environments such as
AmigaOS where I have no access to address 4
(it was going through the motions of an
Amiga port where PDOS-generic was conceived,
thanks to the assistance of an Amiga forum,
about 6-12 months ago).

I wish to run PDOS-generic (with FAT disks)
under both PDOS/3X0 (which only supports CKD
disks), as well as under z/OS (where I won't
be authorized, so can't do SVCs (equivalent
of INT)).

BFN. Paul.

tkchia

04.07.2021, 11:03

@ kerravon

32-bit MSDOS

Post reply

Post reply

> I decided to take a look at the assembler that
> was being generated by Free Pascal. I couldn't
> stop the assemble & link from happening, but
> I was able to keep the assembler which meant
> that I could simply redo the process.

Compile with -a -s. It will keep the assembler, and generate a script to assemble and link it (ppas.sh or ppas.bat)

> When I saw the generated assembler, ie
> fpc_write_text_shortstr etc, I had another
> thought. I don't know what the license is of
> the code that is currently being linked in to
> my world.exe,

LGPL+ static linking exception, roughly the same as gcc's libgcc. Nearly all linkable code has that license, only the compiler and the IDEs are GPL (again, much like gcc)

> I can produce my own executable
> consisting of nothing but public domain code,
> just like my C90-based executables.

C90 is a source standard. Calling binaries "C90" has no meaning.

> Unfortunately I don't know how to get my C
> code to selectively generate "pascal" calling
> convention, or whether Free Pascal's convention
> is even that. I tried __pascal and __Pascal.
> __stdcall does something different.

The calling convention is called "register", used by Delphi and Free Pascal, and is somewhat related to stdcall in philosophy. Probably the only C(actually C++) compilers that do it are Borland's BCB.

> Is this approach likely to work, or am I
> missing something?

Yes. Register calling convention support in the gcc compiler. Let the Pascal code call C.

> void fpc_initializeunits(void)
> {
> return;
> }

This is an identifier that calls what is equivalent to CTORs (table with initialization code of varying units). Without it, initialization code in units (including the system unit) wont work.

> int fpc_get_output(void)
> {
> return ((int)stdout);
> }

Ok. Is afaik a function for thread variable (TLS) reasons.

> void fpc_write_text_shortstr(int handle, char *str)
> {
> fputs(str, (FILE*)handle);
> return;
> }

This signature doesn't match. shortstrings are complicated beasts. Only replace the final call to the OS (in rtl/win/sysfile).

> void fpc_iocheck(void)
> {
> return;
> }

Would disables all I/O checking, and among others checking for the existence of a file relies on that, so wouldn't work.

If you want any measure of compatibility, replace _only_ the user32 DLL calls to msvcrt DLL calls, and let the msvcrt initializing be done using normal ways (dll_initialize), and don't go rearranging.

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

That's probably ok.

> Cannot export FPC_RESOURCESTRINGTABLES: symbol not found
> Cannot export FPC_RESSTRINITTABLES: symbol not found
> Cannot export FPC_THREADVARTABLES: symbol not found
> Cannot export FPC_WIDEINITTABLES: symbol not found
> Cannot export INITFINAL: symbol not found
> Cannot export PASCALMAIN: symbol not found
> worldpas.o(.text.n__main+0x5):worldpas.pas: undefined reference to
> `fpc_initializeunits'
> worldpas.o(.text.n__main+0xa):worldpas.pas: undefined reference to
> `fpc_get_output'
> worldpas.o(.text.n__main+0x1d):worldpas.pas: undefined reference to
> `fpc_write_text_shortstr'
> worldpas.o(.text.n__main+0x22):worldpas.pas: undefined reference to
> `fpc_iocheck'
> worldpas.o(.text.n__main+0x29):worldpas.pas: undefined reference to
> `fpc_writeln_end'
> worldpas.o(.text.n__main+0x2e):worldpas.pas: undefined reference to
> `fpc_iocheck'
> worldpas.o(.text.n__main+0x33):worldpas.pas: undefined reference to
> `fpc_do_exit'
> worldpas.o(.data.n_INITFINAL+0x8):worldpas.pas: undefined reference to
> `INIT$_$SYSTEM'
> worldpas.o(.data.n_INITFINAL+0x10):worldpas.pas: undefined reference to
> `INIT$_$FPINTRES'
> worldpas.o(.data.n_FPC_THREADVARTABLES+0x4):worldpas.pas: undefined
> reference to `THREADVARLIST_$SYSTEM$indirect'
> [worldpas.exe] Error 1

You didn't link FPC libraries or startup code. I wouldn't go this route, at least not for first steps, let Free Pascal generate the linking. You can tell it to link .o and .a's by doing {$L myobject.o} in the main program.

Use the earlier parameters to look at how it calls the linker, and then manipulate the source again till it works.

marcov

03.07.2021, 14:47

@ marcov

32-bit MSDOS

Post reply

> > void fpc_write_text_shortstr(int handle, char *str)
> > {
> > fputs(str, (FILE*)handle);
> > return;
> > }
>
> This signature doesn't match. shortstrings are complicated beasts.

This was wrong, they are not really complicated, being simply one byte length and up to 255 characters of character data. (const often means by reference in these context). And not null terminated, iow it needs conversion to change into null terminated pointer.

> Only replace the final call to the OS (in rtl/win/sysfile).

In this case as WriteFile is untyped I/O. Use raw/untyped I/O. e.g. posix Write() rather than fputs.

Then you can write

if length(s)>0 then
posix_write(@s[1],length(s)); // create pointer to first real character (s[0]=length)

kerravon

Sydney, Free World South,
03.07.2021, 15:39

@ marcov

32-bit MSDOS

Post reply

> > I decided to take a look at the assembler that
> > was being generated by Free Pascal. I couldn't
> > stop the assemble & link from happening, but
> > I was able to keep the assembler which meant
> > that I could simply redo the process.
>
> Compile with -a -s. It will keep the assembler, and generate a script to
> assemble and link it (ppas.sh or ppas.bat)

Thanks. That worked, just had to clean up stuff.

> > When I saw the generated assembler, ie
> > fpc_write_text_shortstr etc, I had another
> > thought. I don't know what the license is of
> > the code that is currently being linked in to
> > my world.exe,
>
> LGPL+ static linking exception, roughly the same as gcc's libgcc. Nearly
> all linkable code has that license, only the compiler and the IDEs are GPL
> (again, much like gcc)

Ok, so I'd like to produce a public domain
replacement, even if it isn't, for now, as
capable as the copyrighted version.

I've already done that for libgcc (subset).
Only took 27 years.

> > I can produce my own executable
> > consisting of nothing but public domain code,
> > just like my C90-based executables.
>
> C90 is a source standard. Calling binaries "C90" has no meaning.

C90-derived I meant. ie binaries produced
from C90 source code.

> > Unfortunately I don't know how to get my C
> > code to selectively generate "pascal" calling
> > convention, or whether Free Pascal's convention
> > is even that. I tried __pascal and __Pascal.
> > __stdcall does something different.
>
> The calling convention is called "register", used by Delphi and Free
> Pascal, and is somewhat related to stdcall in philosophy. Probably the only
> C(actually C++) compilers that do it are Borland's BCB.
>
> > Is this approach likely to work, or am I
> > missing something?
>
> Yes. Register calling convention support in the gcc compiler.

Ok, thanks.

> Let the Pascal code call C.

I don't know how to do that, and I don't have
control of that anyway, so I just created
some assembler code that will push the registers
onto the stack when I figure out how to get it
to even link.

> > void fpc_initializeunits(void)
> > {
> > return;
> > }
>
> This is an identifier that calls what is equivalent to CTORs (table with
> initialization code of varying units). Without it, initialization code in
> units (including the system unit) wont work.

I don't understand any of that, but I can tell
from the generated code that my "hello world"
won't care.

> > int fpc_get_output(void)
> > {
> > return ((int)stdout);
> > }
>
> Ok. Is afaik a function for thread variable (TLS) reasons.

I don't wish to support threads.

> > void fpc_write_text_shortstr(int handle, char *str)
> > {
> > fputs(str, (FILE*)handle);
> > return;
> > }
>
> This signature doesn't match. shortstrings are complicated beasts. Only
> replace the final call to the OS (in rtl/win/sysfile).

Ok, I sort of fixed that for now.

> > void fpc_iocheck(void)
> > {
> > return;
> > }
>
> Would disables all I/O checking, and among others checking for the
> existence of a file relies on that, so wouldn't work.

Ok. Will need to fix that eventually then.

> If you want any measure of compatibility, replace _only_ the user32 DLL
> calls to msvcrt DLL calls,

Compatibility with what? I want it to be
compatible with PDOS/386 as it is now.

> and let the msvcrt initializing be done using
> normal ways (dll_initialize), and don't go rearranging.

I checked PDPCLIB and there is no such function.

> You didn't link FPC libraries or startup code.

I don't wish to use other people's copyrighted
code in my executable if there is any way around
it. Even if it takes me 27 years.

> I wouldn't go this route, at
> least not for first steps, let Free Pascal generate the linking. You can
> tell it to link .o and .a's by doing {$L myobject.o} in the main program.

I don't wish to change the main program. It is
standard Pascal. It's everything else that has
to change.

> Use the earlier parameters to look at how it calls the linker, and then
> manipulate the source again till it works.

Here's what I have now. I don't know how to
resolve the link errors. It both complains
that the symbols are duplicate and complains
that they are missing.

BFN. Paul.

C:\devel\pascal>type pascals.s
# 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

.globl fpc_write_text_shortstr
fpc_write_text_shortstr:
call _fpc_write_text_shortstr
ret

.globl fpc_iocheck
fpc_iocheck:
call _fpc_iocheck
ret

.globl fpc_writeln_end
fpc_writeln_end:
call _fpc_writeln_end
ret

.globl fpc_do_exit
fpc_do_exit:
call _fpc_do_exit
ret

.section .data

.globl FPC_RESOURCESTRINGTABLES
FPC_RESOURCESTRINGTABLES:

.globl FPC_RESSTRINITTABLES
FPC_RESSTRINITTABLES:

.globl FPC_THREADVARTABLES
FPC_THREADVARTABLES:

.globl FPC_WIDEINITTABLES
FPC_WIDEINITTABLES:

.globl INITFINAL
INITFINAL:

.globl PASCALMAIN
PASCALMAIN:

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

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

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

C:\devel\pascal>

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

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

void fpc_initializeunits(void)
{
return;
}

int fpc_get_output(void)
{
return ((int)stdout);
}

void fpc_write_text_shortstr(int handle, char *str)
{
/* fputs(str, (FILE*)handle); */
fputs("fix the registers", stdout);
return;
}

void fpc_iocheck(void)
{
return;
}

void fpc_writeln_end(void)
{
printf("\n");
}

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

C:\devel\pascal>

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

CC=gccwin
CFLAGS=-O2
LD=ldwin
LDFLAGS=
AS=aswin
AR=arwin
COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__

all: clean worldpas.exe

worldpas.exe: worldpas.o pascalc.o pascals.o
$(LD) $(LDFLAGS) -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.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 -fr link*.res
rm -fr ppas.bat
$(AS) -o $@ $*.s
rm -f $*.s

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

.s.o:
$(AS) -o $@ $*.s

clean:
rm -f *.o worldpas.exe

C:\devel\pascal>

C:\devel\pascal>pdmake -f makefile.w32
rm -f *.o worldpas.exe
fpc -a -s worldpas.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Note: Switching assembler to default source writing assembler
Target OS: Win32 for i386
Compiling worldpas.pas
Closing script ppas.bat
5 lines compiled, 0.2 sec
1 note(s) issued
rm -fr link*.res
rm -fr ppas.bat
aswin -o worldpas.o worldpas.s
rm -f worldpas.s
gccwin -S -O2 -fno-common -ansi -I. -I../pdos/pdpclib -D__WIN32__ -o pascalc.s pascalc.c
aswin -o pascalc.o pascalc.s
rm -f pascalc.s
aswin -o pascals.o pascals.s
ldwin -s -o worldpas.exe ../pdos/pdpclib/w32start.o worldpas.o pascalc.o pascals.o ../pdos/pdpclib/msvcrt.a
pascals.o(.data+0x0):fake: multiple definition of `FPC_RESOURCESTRINGTABLES'
worldpas.o(.rodata.n_FPC_RESOURCESTRINGTABLES+0x0):worldpas.pas: first defined here
pascals.o(.data+0x0):fake: multiple definition of `FPC_RESSTRINITTABLES'
worldpas.o(.data.n_FPC_RESSTRINITTABLES+0x0):worldpas.pas: first defined here
pascals.o(.data+0x0):fake: multiple definition of `FPC_THREADVARTABLES'
worldpas.o(.data.n_FPC_THREADVARTABLES+0x0):worldpas.pas: first defined here
pascals.o(.data+0x0):fake: multiple definition of `FPC_WIDEINITTABLES'
worldpas.o(.data.n_FPC_WIDEINITTABLES+0x0):worldpas.pas: first defined here
pascals.o(.data+0x0):fake: multiple definition of `INITFINAL'
worldpas.o(.data.n_INITFINAL+0x0):worldpas.pas: first defined here
pascals.o(.data+0x0):fake: multiple definition of `PASCALMAIN'
worldpas.o(.text.n__main+0x0):worldpas.pas: first defined here
Cannot export FPC_RESOURCESTRINGTABLES: symbol not found
Cannot export FPC_RESSTRINITTABLES: symbol not found
Cannot export FPC_THREADVARTABLES: symbol not found
Cannot export FPC_WIDEINITTABLES: symbol not found
Cannot export INIT$_$FPINTRES: symbol not found
Cannot export INIT$_$SYSTEM: symbol not found
Cannot export INITFINAL: symbol not found
Cannot export PASCALMAIN: symbol not found
Cannot export THREADVARLIST_$SYSTEM$indirect: symbol not found
[worldpas.exe] Error 1

C:\devel\pascal>

marcov

03.07.2021, 16:12

@ kerravon

32-bit MSDOS

Post reply

Post reply

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

tkchia

30.06.2021, 19:04

@ kerravon

32-bit MSDOS

Post reply

Hello kerravon,

> I think the test is - any application executable
> that demands that a segment register be set a
> certain way, or an interrupt vector be set a
> certain way, precludes the ability of the caller
> to be unprivileged.

I appreciate that PDOS is your personal project --- but what you said is simply not true.

I do not know where you get the idea that DPMI applications demand "that a segment register be set a certain way", or that they cannot run unprivileged.

Thank you!

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

kerravon

Sydney, Free World South,
30.06.2021, 22:42

@ tkchia

Post reply

Hello RayeR,

> I think that DPMI API INT31 is something different that cannot be simply
> redirected to INT21. But maybe HDPMI/CWSDPMI source could be ported some

That is correct (http://www.delorie.com/djgpp/doc/dpmi/). int 0x31 is only for DPMI-specific services --- the various BIOS and DOS services must still be invoked via int 0x10, int 0x21, int 0x33, etc. (sometimes by way of int 0x31).

> run in PDOS. But maybe PDOS could load e.g. DJGPP 32b apps? I don't know if
> there's some hard obstacle why not as they are also 32b apps but requires
> DPMI API...

I have look at the DJGPP C library source code --- and yes, the DJGPP libc runs directly on top of a DPMI host, without any DOS extender. This is unlike Watcom's 32-bit libc, which (if I am not wrong) will need a DOS extender to work properly.

Thank you!

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

kerravon

Sydney, Free World South,
29.06.2021, 05:16

@ RayeR

32-bit MSDOS

Post reply

Japheth

Germany (South),
29.06.2021, 05:40

@ kerravon

32-bit MSDOS

Post reply

> But at what level does INT 31H make sense in
> a PDOS/386 environment? There is no 16-bit
> DOS waiting to be called, and if you attempt
> to do that, you will fail.

I think this all is a misunderstanding.

You labeled this thread "32-bit MSDOS" and this made a few people ( including me ) think that you had to offer a somewhat "DOS compatible" OS. It's clear now that this is not the case - and hence there's absolutely no need to implement DPMI for your OS.

---
MS-DOS forever!

kerravon

Sydney, Free World South,
29.06.2021, 07:14

@ Japheth

32-bit MSDOS

Post reply

> > But at what level does INT 31H make sense in
> > a PDOS/386 environment? There is no 16-bit
> > DOS waiting to be called, and if you attempt
> > to do that, you will fail.
>
> I think this all is a misunderstanding.
>
> You labeled this thread "32-bit MSDOS" and this made a few people (
> including me ) think that you had to offer a somewhat "DOS compatible" OS.
> It's clear now that this is not the case

Well, it depends what you mean by "DOS
compatible". INT 21H exists. The INT 21H
looks very much like MSDOS and very much
like DOS32A, but not identical.

It's obviously designed to be called in PM32,
hence the "32-bit" in the title.

I'm not sure if it is a misunderstanding or
a semantic debate.

> - and hence there's absolutely no
> need to implement DPMI for your OS.

Ok. I have my own kernel32.dll and msvcrt.dll,
but I would like to support all the other
HX DLLs.

What are those other HX DLLs dependent on?

I can flesh out my own kernel32.dll as required.

Thanks. Paul.

tom Germany (West), 30.06.2021, 22:19 @ Japheth	32-bit Public Domain DOS Post reply
	> I think this all is a misunderstanding. > > You labeled this thread "32-bit MSDOS" and this made a few people ( > including me ) think that you had to offer a somewhat "DOS compatible" OS. > It's clear now that this is not the case - and hence there's absolutely no > need to implement DPMI for your OS. Amen.

kerravon

Sydney, Free World South,
27.06.2021, 18:00

@ Japheth

32-bit MSDOS

Post reply

Hi Japheth.

Sorry, I didn't notice I was responding
to someone different.

> JWasm, for example?

I forgot to answer this specific question.
jwasm uses some non-C90 functions:

C:\devel\jwasm>pdmake -f makefile.w32
rm -f *.o jwasm.exe
gccwin -S -O2 -fno-common -I. -I../pdos/pdpclib -Ih -D__WIN32__ -o main.s main.c
main.c:34:19: fcntl.h: No such file or directory
main.c:39:18: io.h: No such file or directory

I don't know what those result in if compiled
with a different C compiler that supports
them, but they probably result in something
that I haven't implemented.

However, it is my hope that HX can be ported
to this new (PDOS/386) environment, as well
as run on PDOS/86. I'm not familiar with the
internals of HX, but I would have thought that
most of the code is already 32-bit, and either
takes control of the hardware itself (which is
fine - I don't manipulate the hardware, I make
BIOS calls), or does INT 21H calls, and the
only difference here is that HX doesn't need
to (and can't) drop down to RM16 to do those
calls, it needs to stay in 32-bit mode and do
the INT 21H.

HX probably makes some INT 21H calls that I
haven't implemented, but maybe those can be
added when I find out what the scope of the
problem is. Especially for the task of
executing jwasm.

Note that I have made binutils 2.14a C90-compliant
so I provide an "aswin" which is a 32-bit
assembler that runs under both HX and PDOS/386.
I also provide "as386" which is a 32-bit
assembler that only runs under PDOS/386, but
is probably very similar to DOS/4GW.

BFN. Paul.

kerravon

Sydney, Free World South,
27.06.2021, 18:31

@ kerravon

32-bit MSDOS

Post reply

One other piece of information that isn't
documented anywhere. I have a "wrapper" on
all the INT 21H functions I use, e.g. I
call PosOpenFile() instead of INT 21H AH=3DH.

This compiles appropriately for 16-bit real
mode so that it works on Freedos, MSDOS
and PDOS/86.

It compiles appropriately for 32-bit MSDOS
that works on PDOS/386 only.

What I plan to add is for it to do a 32-bit
compile to call kernel32 calls so that the
resultant executable works on all Windows
environments (PDOS/386, HX, Windows 95-10).

That way applications can ditch the awful
SECURITY_ATTRIBUTES, LONG etc introduced
by Microsoft and return to a much saner
MSDOS-inspired API.

So there will be 3 competing APIs.

POSIX
Windows
MSDOS-inspired-Pos*

The last one on that list will do 16-bit MSDOS.
Windows won't. Not sure if anyone has implemented
Posix on the 8086.

BFN. Paul.

kerravon

Sydney, Free World South,
27.06.2021, 18:47

@ kerravon

32-bit MSDOS

Post reply

I realized that I could test jwasm.

Here is what happened:

A:\]dir
IO.SYS 17882 2021-06-07 19:03:42
COMMAND.COM 71120 2021-06-07 19:05:50
KERNEL32.DLL 35328 2021-06-07 20:08:20 kernel32.dll
MSVCRT.DLL 38400 2021-06-07 20:10:30 msvcrt.dll
TERMINAL.EXE 15883 2021-06-14 15:00:04
HDTOFIL.EXE 4096 2021-06-13 15:13:58
ZFILL.EXE 3584 2021-06-25 22:31:56
HEXDUMP.EXE 3584 2021-06-13 15:11:38
PDPTEST.EXE 4608 2021-06-13 15:10:46
PORTINIT.EXE 15041 2021-06-13 15:01:54
PORTREAD.EXE 15741 2021-06-13 15:03:18
PORTWRIT.EXE 15567 2021-06-13 15:03:50
ZAP.EXE 3072 2021-06-13 15:13:18
README.TXT 133 2021-06-10 02:45:30 readme.txt
MSDOS.SYS 101024 2021-06-07 19:05:20 msdos.sys
JWASM.EXE 302592 2021-05-31 20:33:22 jwasm.exe

A:\]jwasm
warning - failed to open jwasm.com
warning - this executable uses a non-standard DLL KERNEL32.DLL
Function CreateEventA not found in DLL
Failed to load DLL KERNEL32.DLL

A:\]

Don't worry about the warnings, that's just
something I like to know.

But yes, CreateEventA is something I need to
add to my kernel32.c in order to get jwasm
to work.

This is Windows crap that I really have no
interest in. MSDOS doesn't do that.

I have no idea why an assembler would have
a requirement to create events, whatever
that even means. It's supposed to be reading
in a text file and outputting a single binary
file. Nothing more. You don't need more than
C90 to do that.

If I can create a dummy CreateEventA that
just returns "success" and does nothing,
that's fine.

It depends what Watcom's C library is trying
to achieve.

PDPCLIB doesn't do things like that. I use
PDPCLIB.

BFN. Paul.

Japheth

Germany (South),
27.06.2021, 20:40

@ kerravon

32-bit MSDOS

Post reply

> But yes, CreateEventA is something I need to
> add to my kernel32.c in order to get jwasm
> to work.
>
> This is Windows crap that I really have no
> interest in. MSDOS doesn't do that.
>
> I have no idea why an assembler would have
> a requirement to create events, whatever
> that even means. It's supposed to be reading
> in a text file and outputting a single binary
> file. Nothing more. You don't need more than
> C90 to do that.

Actually, jwasm is written in C89/C90.

This createevent thing comes from the Open Watcom static C library (maybe something to support Ctrl-C/Ctrl-Break?).

There's also a jwasmd.exe (d for DOS), where the Win32 API used by OW is translated to 32-bit DOS protected-mode int 21h calls (by linking in the HX kernel32 code statically) - I'm afraid, however, that PDOS doesn't support all the int 21h ( and BIOS interrupts ) that this executable will call.

---
MS-DOS forever!

kerravon

Sydney, Free World South,
27.06.2021, 20:57

@ Japheth

32-bit MSDOS

Post reply

> > But yes, CreateEventA is something I need to
> > add to my kernel32.c in order to get jwasm
> > to work.
> >
> > This is Windows crap that I really have no
> > interest in. MSDOS doesn't do that.
> >
> > I have no idea why an assembler would have
> > a requirement to create events, whatever
> > that even means. It's supposed to be reading
> > in a text file and outputting a single binary
> > file. Nothing more. You don't need more than
> > C90 to do that.
>
> Actually, jwasm is written in C89/C90.

It is using non-C90 includes, so I can't
compile against PDPCLIB.

If it is written in C90, why does it need
those includes?

If you can eliminate those includes, I will
be able to produce my own jwasm executable
that works.

I'm using an old jwasm though. I think I tried
to upgrade, but jwasmr didn't work or something
like that, so I went back to the working version.

BFN. Paul.

kerravon

Sydney, Free World South,
27.06.2021, 22:12

@ kerravon

32-bit MSDOS

Post reply

Another thing of interest, especially since there
are so many Germans here.

I don't wish to support UTF-8. I want to return
to having non-ASCII characters in the top 128
bytes.

People can code using wchar_t, but I have defined
that as one byte.

The Vietnamese need 6 control characters to be
released, so I have found 6 that don't interfere
with micro-emacs keystrokes that I use or
anything else. VISCII takes things I use.

The Chinese are the only people who have
exceeded 2 bytes, so they can have a wchar_t
of 4, which will incidentally cover anyone
who likes Unicode.

All they need to do is recompile. They do not
need to depend on Microsoft.

BFN. Paul.

bocke

14.09.2021, 11:33

@ kerravon

32-bit MSDOS

Post reply

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

tom

Germany (West),
27.06.2021, 20:03

@ kerravon

YAOIS - Yet Another Irrelevant Operating System

Post reply

> > > My vision of what MSDOS should have become in the late 1980s is here:
> > >
> > > http://pdos.org
> >
> > what does it better than MSDOS?
>
> It is 32-bit instead of 16-bit if you wish
> to have that.

nobody cares about the bitness of the OS. people care if the performance of the OS is faster/slower, but not if it has more bits.

anyDOS can execute 32-bit DOOM.EXE.
PDOS can't - at any speed.

where is PDOS advantage?

in fact, if you can't execute DOS executables why do you call your project 32-bit DOS?

last, not least: don't get me wrong. at least you have something to show which is 100% more the NightDOS ;-)

kerravon

Sydney, Free World South,
27.06.2021, 20:18

@ tom

32-bit MSDOS

Post reply

> > > > My vision of what MSDOS should have become in the late 1980s is
> here:
> > > >
> > > > http://pdos.org
> > >
> > > what does it better than MSDOS?
> >
> > It is 32-bit instead of 16-bit if you wish
> > to have that.
>
> nobody cares about the bitness of the OS.

I care. I want to be able to write 32-bit
applications and be able to debug them by
putting debug into the OS, not just the
application.

And if my computer hangs, I want to be able
to debug the OS.

And if I spend time debugging the OS, and
getting familiar with it, I want to be able
to create a commercial derivative of it
without restriction. And for that I need it
to be public domain.

And if I enable paging but keep V = R, to
enable memory protection, I want an MVS-style
dump produced. I already have proof of concept
for that with divide by zero.

If you don't have the same requirements,
that's fine. But don't say "nobody". I'm
not trying to win Miss America, I'm trying
to create a pristine programming environment.

> people care if the performance of
> the OS is faster/slower, but not if it has more bits.

Applications are normally bottlenecked in
the application, not in the OS.

> anyDOS can execute 32-bit DOOM.EXE.
> PDOS can't - at any speed.
>
> where is PDOS advantage?

I don't want to run DOOM.EXE. I want to
run GCCWIN.EXE and GCC386.EXE.

I'm a programmer, not a gamer.

Regardless, I don't know what the internals
of DOOM are, but if it just wants to take
control of the hardware, it can do that
under PDOS. It needs to be compiled to one
of the two supported formats though. If it
doesn't come with C source code you won't
be able to do that currently.

BFN. Paul.

kerravon

Sydney, Free World South,
27.06.2021, 20:23

@ tom

YAOIS - Yet Another Irrelevant Operating System

Post reply

(sorry for the extra reply, I either missed
this bit or you edited your message)

> in fact, if you can't execute DOS executables why do you call your project
> 32-bit DOS?

Because it executes 32-bit DOS executables,
rather than 16-bit DOS executables.

Regardless, I also produce a PDOS/86 that
executes some 16-bit DOS executables. My
hope is for it to also progress to the point
where it can run HX unchanged, to provide
yet another Win32 environment.

> last, not least: don't get me wrong. at least you have something to show
> which is 100% more the NightDOS ;-)

My project is public domain. I don't know why
they don't simply pick up my code and do
whatever they want with it. They can slap any
alternative license on it they want. It's
unrestricted public domain.

BFN. Paul.

mceric

Germany,
27.06.2021, 20:28

@ tom

YAOIS - Yet Another Irrelevant Operating System

Post reply

> where is PDOS advantage?

One claim is that public domain is in some way superior to other open or closed source. I would hope that because PDOS/386 assumes int 21 to do everything in a flat 32-bit mode, it could be made to support DOS32A style API to become useful for protected mode DOS extended apps. It also supports a minimal subset of the Win32 API already, basically just enough to run a compiler: Handle files and console output. There also is a normal PDOS version which runs normal DOS apps in a limited way.

If you limit yourself to BIOS-ignorant apps, PDOS/386 could run DOS32A style apps on UEFI-only systems eventually, by having different versions of the kernel: BIOS-based, UEFI-based or hardware-based device I/O.

My general impression is that both PDOS variants put simplicity and elegance over compatibility and I agree with you that people will not recompile their apps just to run them on yet another newcomer OS. As you compare it to NightDOS, it seems that FD32 is showing some signs of life again. Note that you could technically call everything which talks to apps and BIOS for the purpose of facilitating file access could technically be called a DOS ;-)

---
FreeDOS / DOSEMU2 / ...

kerravon

Sydney, Free World South,
27.06.2021, 20:47

@ mceric

YAOIS - Yet Another Irrelevant Operating System

Post reply

(replying in 2+ parts because I don't know why it
is rejecting my message)

> One claim is that public domain is in some way superior to other open or
> closed source.

Oh yeah - that's another thing I forgot to mention.
People slap copyrights on things precisely because
they know that some people will do things with the
software that they don't want them to do.

I cater for those people who want to do those things.

Almost no-one else does. If you try to find
some public domain OSes, you won't find much.

> I would hope that because PDOS/386 assumes int 21 to do
> everything in a flat 32-bit mode, it could be made to support DOS32A style
> API to become useful for protected mode DOS extended apps.

I looked at DOS32A a couple of weeks ago, saw
that it used segments, and lost interest.

kerravon Sydney, Free World South, 27.06.2021, 20:51 @ kerravon	YAOIS - Yet Another Irrelevant Operating System Post reply
	> style apps on UEFI-only systems eventually, by having different versions of > the kernel: BIOS-based, UEFI-based or hardware-based device I/O. I have a tentative plan to create a BOOTX64.EFI that reinstates the BIOS so that there is literally no change to the PDOS/386 disk except one extra file is added.

kerravon

Sydney, Free World South,
27.06.2021, 20:53

@ kerravon

YAOIS - Yet Another Irrelevant Operating System

Post reply

However, before p*lluting my pristine PDOS/386
disk with UEFI aaaa that I never asked for, I
am more interested in bbbbing the firmware
with SeaBIOS to do it there. In addition, I want
SeaBIOS to restore an INT 14H so that I get my
serial port back, even on a system that doesn't
have a serial port. Instead INT 14H can be
directed to bluetooth or wifi. In addition I
would like a BIOS option to make INT 14H read
block.

kerravon

Sydney, Free World South,
27.06.2021, 20:54

@ kerravon

YAOIS - Yet Another Irrelevant Operating System

Post reply

Wow. It was p*olluting it didn't like. It was
happy with crap and flashing.

> My general impression is that both PDOS variants put simplicity and
> elegance

Right. My plan is to switch from large memory
model to huge memory model so that I can remove
the kludge I put in for PDOS/86 memory management.

A couple of days ago I discovered that although
Watcom generates appropriate code in huge memory
mode, Turbo C doesn't.

Then I would make size_t 32-bit (long) in this
huge memory model.

Another plan (see the "bios" directory for proof
of concept) is to have a C90 BIOS abstraction.
So disks would be seen as just files. This
restricts disks to 2 GiB though. To lift that
restriction I want to make long (only) 64-bit.
Still with 80386 code.

> over compatibility and I agree with you that people will not
> recompile their apps just to run them on yet another newcomer OS. As you

Win32 applications don't need to be recompiled
if they have been written to the lowest
common denominator which is PDOS/386.

Berlin, Germany,
27.06.2021, 21:21

@ kerravon

YAOIS - Yet Another Irrelevant Operating System

Post reply

> Wow. It was p*olluting it didn't like. It was
> happy with crap and flashing.

In fact the word it doesn't like is 'p*oll'.
We just filled the bad words list with words used by forum spammers.

---
Forum admin

kerravon

Sydney, Free World South,
27.06.2021, 21:30

@ tom

YAOIS - Yet Another Irrelevant Operating System

Post reply

> nobody cares about the bitness of the OS.

> where is PDOS advantage?

Here's what someone wrote in an email to me
in 2014. Note that I started in 1994, long
before this person emailed me, but I had
always hypothesized that people like him
existed.

Dear Paul Edwards,

I just found PDOS and read your manifesto. Right on!

My problems are that a) I don't trust any OS for cybersecurity reasons,
and need to read the code, and also b) I want to do some new things with
it and not have to give them away.

But as you astutely point out, if more such components were free of
restrictions, commercial code will be better and cheaper, precisely what
I hope to do.

It's too early to commit (10 minutes in) to contributing enhancements. I
might work up to it. But I could kick in a few bucks. If I can find an
address I'll just mail in a check for my donation.

Man, I really appreciate you're having this idea and getting this far
with it! It's saving my butt.

kerravon

Sydney, Free World South,
27.06.2021, 21:59

@ kerravon

YAOIS - Yet Another Irrelevant Operating System

Post reply

BTW, you know how Win32 programs normally
say "this program cannot be run in DOS mode"?

Here's what executables I produce say:

C:\winpath>hexdump md5.exe 0 200
000000 4D5A9000 03000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000050 496E7374 616C6C20 4858206F 72207570 Install HX or up
000060 67726164 6520746F 2050444F 532F3338 grade to PDOS/38
000070 36206F72 2057696E 65206574 630D0A24 6 or Wine etc..$
000080 50450000 4C010400 8748D860 00000000 PE..L....H.`....
000090 00000000 E0000E02 0B010238 000E0000 ...........8....
0000A0 00060000 00000000 00100000 00100000 ................
0000B0 00000000 00004000 00100000 00020000 ......@.........
0000C0 04000000 01000000 ........

DosWorld

04.07.2021, 11:22

@ kerravon

a.out support in dos

Post reply

> a.out (which
> EMX 0.9d used, not sure about other DOS
> extenders).

(general question for all)

Hello!

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?

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

kerravon

Sydney, Free World South,
04.07.2021, 12:01

@ DosWorld

a.out support in dos

Post reply

> > a.out (which
> > EMX 0.9d used, not sure about other DOS
> > extenders).
>
> (general question for all)
>
> Hello!
>
> 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?

32-bit a.out executables are supported directly
by PDOS/386. It is the original format and the
loader and OS and command processor have not yet
been weaned off this. micro-emacs too.

You can build a.out modules using the gcc386/as386/etc
toolchain which I provide Win32 executables for on my
website (via link).

You can run those Win32 executables on virtually any
platform.

You can compile the gcc386 etc source code on any
C90-compliant compiler, doesn't have to be gcc,
although I've never actually tested other compilers,
and when I tried using Visual Studio, I got a
problem when running it against some C source
code. YMMV.

Is there something specific you want to know
or do?

I would advise switching to PE/COFF instead of
a.out if you can. There is public domain code
available to load PE/COFF, if you think it is
difficult (which it is, compared to a.out,
anyway).

Note that binutils actually deleted the i386-aout
target from the code base, so you'll need to go
back to an older version (as I did), if you wish
to use their code.

BFN. Paul.

Post reply

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.

kerravon Sydney, Free World South, 06.08.2021, 13:56 @ Brian_extended	32-bit MSDOS Post reply
	> 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.

tom

Germany (West),
06.08.2021, 15:21

@ kerravon

32-bit Public Domain OS

Post reply

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

kerravon

Sydney, Free World South,
06.08.2021, 15:57

@ tom

32-bit Public Domain OS

Post reply

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

kerravon Sydney, Free World South, 07.08.2021, 05:41 @ Brian_extended	32-bit MSDOS Post reply
	> 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.

RayeR

CZ,
03.08.2021, 06:59

@ kerravon

32-bit MSDOS

Post reply

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.

kerravon Sydney, Free World South, 06.08.2021, 13:50 @ RayeR	32-bit MSDOS Post reply
	> 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?

RayeR

CZ,
06.08.2021, 15:09

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
06.08.2021, 16:07

@ RayeR

32-bit MSDOS

Post reply

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

RayeR

CZ,
20.08.2021, 18:59

@ kerravon

32-bit MSDOS

Post reply

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.

kerravon

Sydney, Free World South,
27.09.2021, 04:28

@ RayeR

32-bit MSDOS

Post reply

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

mceric

Germany,
28.09.2021, 01:04

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
14.10.2021, 04:37

@ mceric

32-bit MSDOS

Post reply

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

dggionco

Buenos Aires - Argentina,
09.08.2021, 14:43
(edited by dggionco, 09.08.2021, 14:56)

@ kerravon

32-bit MSDOS

Post reply

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

kerravon

Sydney, Free World South,
09.08.2021, 15:39

@ dggionco

32-bit MSDOS

Post reply

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

dggionco Buenos Aires - Argentina, 09.08.2021, 20:00 @ kerravon	32-bit MSDOS Post reply
	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

kerravon

Sydney, Free World South,
09.08.2021, 21:25

@ dggionco

32-bit MSDOS

Post reply

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

dggionco Buenos Aires - Argentina, 10.08.2021, 14:58 @ kerravon	32-bit MSDOS Post reply
	> > 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

kerravon

Sydney, Free World South,
10.08.2021, 17:06

@ dggionco

32-bit MSDOS

Post reply

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

dggionco Buenos Aires - Argentina, 10.08.2021, 18:06 @ kerravon	32-bit MSDOS Post reply
	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.

dggionco Buenos Aires - Argentina, 09.08.2021, 20:09 @ kerravon	32-bit MSDOS Post reply
	>> 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... )