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 kerravon E-mail, Ligao, Free World North, 03.07.2021, 14:41

> I've maintained Free Pascal's *nix ports (Linux, *BSD, bit of OS X) for
> years. I've it all, and heard the arguments all hundred times.

I haven't. I'm new to this (non-C90) so don't know
what the issue is.

> Keep in mind that standards like C90 and Posix usually don't really fixate
I'm not interested in Posix, only C90.

> much (like how FILE* is internally), but rather specify like things that
> should be there, and a minimal size for them. I consider these standards
> to be vastly overrated.
I've been using C90 for more than 3 decades on
multiple platforms and have never had an issue.

Unless you count a very recent issue in that in
order to use ANSI escape sequences I need to
send the ESC character and C90 doesn't have a
#define for that.

Without that #define I need to create my own
define for ASCII and EBCDIC targets, and
theoretically other targets. gcc has '\e' as
an extension.

I'm interested in creating a C90+ that has
the required #define for me to have micro-emacs
working portably (both PC and mainframe), but
for now I just put that into micro-emacs.

> > > Moreover, there is zero experience with it, we always
> > > used the core windows api.
> >
> > A "generic C90" target would target a lot more
> > than just msvcrt.dll.
>
> There is no such thing like a generic "C90" if you can't interpret the
> headers in an automated fashion. Then it is just another procedural API,
> and it doesn't matter if the header is C90 compliant and not. And each
> requires hand porting.
Are you talking about needing to know the
size of "FILE"? Don't you just call fopen
and let it define the size of FILE itself?
Why does Pascal need to be exposed to
anything more than a pointer?

> And win32 api is better than the VS api for several reasons. Chiefly
> because incompatible fucnctions are given another name (typicall -Ex or
> -2), also when only the data type changes. Also it gets the changes first.
What changes? msvcrt.dll is static since Win95.

> Moreover there is generally less problems and more options (think
> accidentally escaping, size limits in filenames etc).
I haven't noticed any problems with msvcrt.dll
in anything I have used it for. And I have
control over my own version of it if I do.

If Microsoft's version turns out to be inferior
I will just suggest people to switch to
Freedos + HX + my MSVCRT.

> There are no real benefits to calling msvcrt. In the past (with Turbo
> Pascal string type) it even mismatched with stringtypes( zero-terminated
> pointer vs length+pointer)
I see a benefit - small executables that work
everywhere.

> And fat chance that if you start compile larger FPC codebases, that they'll
> start to use functions of the windows unit (and thus potentially also
> win32) too.

I'm not trying to solve all the world's problems
in one hit. First I would like to get "hello world"
to work. One day I will find out the limits of
the msvcrt.dll solution and advise people to use
the normal FPC distribution, even if that means
having to upgrade from Win 95 (or PDOS/386) to
Win 2127 or whatever FPC happens to support at
the time.

> > > then what difference does it make
> > whether you call CreateFile() in kernel32 or
> > fopen() in msvcrt?
>
> For your own dedicated port it wouldn't matter. Our windows ports won't
> change, period.
That's the great thing about software. You aren't
bound by other people's "periods".

> > BTW, this Pascal stuff made me realize that I
> > should be able to create my own cygwin1.dll
> > that simply calls functions in msvcrt.dll and
> > stubs the rest out.
>
> In theory yes, the problem however is that msys
I'm not familiar with msys. My (mild) interest
is in cygwin1.

> and cygwin1 can't deal with
> proper windows paths with volumes names/driveletters.
Are you saying I can't do an fopen("c:\\scratch\temp.txt")
in a standard gcc-compiled program that produces an
executable that depends on cygwin1? That doesn't
sound right to me.

> Also some might
> require exclusively forward slashes. There are more such issues, I also
> expect funkiness with signal handling etc.
I don't care if signal handling doesn't work.
Again, if I can get a "hello world" to work
(built on Windows 10, run on PDOS/386) I'll
be pretty happy.

> My guestimate is that for the effort you can port a lot of programs to
> msvcrt manually.
My normal practice is to make programs
C90-compliant. Once they are so, I simply
recompile with gccwin and PDPCLIB and there
is nothing further to do.

And for the mainframe I use gccmvs and PDPCLIB.

> > Specifically I want to find out if I can make that
> > code call fwrite() instead of WriteFile() which I
> > presume it is currently calling.
>
> Yes, it uses WriteFile()
Cool.

> > > 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.
> >
> > The Amiga etc probably doesn't have all these
> > things either.
>
> No. And the Zx Spectrum has even less. But because we support ZX Spectrum,
> we don't dumb all targets down to its level.
I'm not suggesting dumbing all targets down to
Zx or msvcrt level. I'm suggesting having one
new target.

> Moreover, there is simply no benefit.
The benefit is that the executables produced will
work on the current PDOS/386 technology unchanged.

And support Win95 at the same time.

Maybe supporting those targets doesn't interest you,
or most/all other people, but it interests me.

Pascal programs could run on current PDOS/386
where currently no know Pascal-originated
executables can run, despite the fact that
PDOS/386 supports sufficient Win32 API to
support both msvcrt.dll and a whopping
3 MB GCC Win32 executable.

BFN. Paul.

Post reply
 

Complete thread:

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