Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

32-bit MSDOS (Announce)

posted by marcov, 02.07.2021, 14:05

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

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 407 users online (1 registered, 406 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum