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, 16:16

> 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.
As far as I know, Microsoft never documented
msvcrt.dll as an interface.

But it has always existed, and I chose to
standardize on it.

> > > 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.
Ok. Maybe a C library doesn't buy me anything.
I'm not sure. Going via msvcrt gives more
opportunities for C library vendors to
replace it. But I'm not sure.

> > I'm not trying to solve all the world's problems
> > in one hit.
>
> You create more problems that you solve with this direction.
If I can get a "hello world" Pascal to run on
a public domain operating system, I will have
solved a infinity-year-old problem.

Well, make that 25-year-old problem, and Win32
executables. Pascal probably ran on MVS 3.8J.

> 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.
If you can detect that my "hello world" 6k
binary is wonky, I'll agree.

> > That's the great thing about software. You aren't
> > bound by other people's "periods".
>
> Well, at least of somewhat open software, yes.
Doesn't even need to be that. If you don't like
the fact that Microsoft took away "fdisk" and
does forced reboots, you switch to Freedos+HX,
and maybe soon there will be another system
with fdisk support.

> > > 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.
C:\devel\develop>type marcov.c
#include <stdio.h>

int main(void)
{
FILE *fq;

fq = fopen("c:\\scratch\\marcov.txt", "w");
if (fq != NULL)
{
printf("let's try\n");
fprintf(fq, "well, hallelujah\n");
fclose(fq);
}
return (0);
}

C:\devel\develop>gcc marcov.c

C:\devel\develop>a
let's try

C:\devel\develop>dir \scratch\marcov*
Volume in drive C is OS
Volume Serial Number is 500F-DBAC

Directory of C:\scratch

2021-07-04 00:00 17 marcov.txt
1 File(s) 17 bytes
0 Dir(s) 64,329,560,064 bytes free

C:\devel\develop>type \scratch\marcov.txt
well, hallelujah

C:\devel\develop>


> > The benefit is that the executables produced will
> > work on the current PDOS/386 technology unchanged.
>
> That is the only reason.
A pretty good reason from where I stand.

If most people are happy to work on copyrighted
operating systems, go for it.

I know I'm not alone in wanting to work on a
public domain operating system. The only reason
msvcrt.dll exists on PDOS/386 is because an
18-year old girl from Slovakia looked at the
various license agreements on the available
operating systems and said "I refuse all of
them".

A pity Microsoft's goons apparently assassinated
her so I can't marry her.

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

The only supported Win95 system will be mine.

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

> > 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.
I'm only going to do that if I think that
PDOS/386 is the one at fault. Standard
kernel32.dll is huge. I'm surprised anyone
needs to go outside that.

> How hard can it be to support a command like WriteFIle() ?
I support that already. That's in kernel32.dll.
I can't run msvcrt.dll without it.

BFN. Paul.

Post reply
 

Complete thread:

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