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, 03.07.2021, 15:54

C90: let's agree to differ. I've posted my opinion. Early Msvcrt might be shipped by Microsoft, but were not part of the winapi. That changed only later.

> > 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.
That is due your simultaneous dumbing down of the runtime libraries and throwing away standard Pascal features like its STD I/O implementation, not the kernel32-user32 vs msvcrt change.

This happens for real embedded Pascal too, but is pointless for everbody except that one person in the world that still needs the binary to be 8k instead of 32kb, because he still has some kiosk with a 16MB SD flashcard.

> I'm not trying to solve all the world's problems
> in one hit.

You create more problems that you solve with this direction.

I'm saying you are going against the grain with this. Yes, you can force your way with brute force, but the result will be wonky because of it.

> 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.
The few people that care probably already/still use perfectly fine 2013 2.6.4 versions. Of course the templates/generics of that version will be a simplistic, but being minimalists, they probably won't even use that anyway. For most basic and even intermediate use (like making some HMI for a PLC for some long forgotten embedded PC with embedded touchscreen) such version is fine.

> That's the great thing about software. You aren't
> bound by other people's "periods".
Well, at least of somewhat open software, yes.

> > 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.
I don't use much of cygwin daily anymore, but yes, it used to be like that, iirc msys required /drv/<driveletter>/rest/of/path or /<driveletter>/rest/of/path and cygwin /cygdrive/c/rest/of/path.

And the rest of path needed to be posix compliant, so / not \.

The shell had some workarounds, afaik the libraries not.

> The benefit is that the executables produced will
> work on the current PDOS/386 technology unchanged.
That is the only reason.

> And support Win95 at the same time.
win95 doesn't need those changes, just removing some newer features

- changing -W back to -A,
- removing some initialization of some features (COM/TLS/threading)
- removing/changing getspecialdir() back to win9x specific code. (CS_IDL* stuff) to get special dirs like "My Documents" and "\Program Files\" "Common Files" etc, things that changed several times (w2k,XP,Vista).

> Maybe supporting those targets doesn't interest you,
I'm here and talking to you ain't I? Not a fair remark.

> 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.
IMHO simply add some stubs for at least the most basic user32 functionality, like OS/2, Wine, ReactOS, WDosX, HX,and all other winapi compatibles do.

How hard can it be to support a command like WriteFIle() ?

Post reply
 

Complete thread:

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