Discussion:
C galore
(too old to reply)
muta...@gmail.com
2021-04-30 07:43:18 UTC
Permalink
I think I finally have the concept I want.

Forget Pos, Win32 APIs. Just stick with C90.

To conceptualize, start with MSVCRT.DLL.

When a Win32 application does an fread() it
will go to MSVCRT. Every application uses the
same MSVCRT.DLL, but it gets a fresh copy of
it so that the data areas are unique to this
executable, and the code pointers all point to
this data area.

Reentrant code is a job for another day and
conceptually unimportant.

The OS exports its own copy of the C90 library.

So:

typedef struct {
FILE/void *(*fopen)(char *filename, char *mode);
size_t (*fread)(void *ptr, size_t size, size_t nmemb, FILE/void *stream);
} C90;

MSVCRT may be implemented to make every C
function simply directly call its OS counterpart,
ie:

fread()
{
os_c90->fread();
}

fgets()
{
os_c90->fgets();
}

or it may just be fread() that calls os_c90, and
other functions like fgets() call a local (to
MSVCRT) fread(), ie:

fread()
{
os_c90->fread();
}

fgets()
{
fread();
}

Since the OS supports (via the BIOS) a hard disk
called 0x81, then the OS will do:

fopen(filename, mode)
{
if (strncmp(filename, "0x", 2) == 0)
{
bios_c90->fopen(filename, "r+b");
}
}

Since the OS supports FAT partitions within the hard
disk, it will do:

/* note - raw disk */
if (strcmp("filename, "C:") == 0)
{
fatpart_c90->fopen("fileptr:12340000,offset:512000", "r+b");
}

where fileptr is a pointer to the FILE * (or void *)
returned by the bios fopen of 0x81, and offset is
the byte offset within that hard disk. It is all
byte-based, sector size is transparent.

When a request from MSVCRT is received, it would
be a simple fopen("fred.txt") and the OS's fopen
would change that into:

fat_c90->fopen("fileptr:23450000,fred.txt");

where fileptr is what was returned by fatpart_c90.

I think mainframe CKD disks can be supported too,
as simple byte offsets, as the VTOC blocks are a
fixed size, and the data files can have a fixed
18452 block size, so everything should be at
predictable offsets and sizes, no different to FAT.

And a bios_c90->fopen("", "r");
would return a slew of information from the BIOS,
such as names that can be fopened to retrieve
available memory, available hard disks and
available floppies.

BFN. Paul.
Melzzzzz
2021-04-30 09:13:38 UTC
Permalink
Post by ***@gmail.com
I think I finally have the concept I want.
Forget Pos, Win32 APIs. Just stick with C90.
To conceptualize, start with MSVCRT.DLL.
ahahahhahahaahhah
--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
muta...@gmail.com
2021-05-01 01:41:29 UTC
Permalink
Post by ***@gmail.com
MSVCRT may be implemented to make every C
function simply directly call its OS counterpart,
fread()
{
os_c90->fread();
}
fgets()
{
os_c90->fgets();
}
Just a clarification - the intention is that it would be:

fread(FILE *file)
{
os_c90->fread(file->os_hfile)
}

ie you need to reference the file handle returned by the OS.
Post by ***@gmail.com
fat_c90->fopen("fileptr:23450000,fred.txt");
And actually it is not necessary for the FAT api
to be reworked into C90-format. All that is
required is for the fatOpen(FATFILE *f, char *name);
etc api to be hidden inside the C90 library so that
anyone who wishes to access this functionality
does a normal fopen() call, but with an unusual
filename.

BFN. Paul.
Rod Pemberton
2021-05-01 06:56:53 UTC
Permalink
On Fri, 30 Apr 2021 00:43:18 -0700 (PDT)
Post by ***@gmail.com
I think I finally have the concept I want.
...
Post by ***@gmail.com
Forget Pos, Win32 APIs. Just stick with C90.
To conceptualize, start with MSVCRT.DLL.
Other than MSVCRT means M$ Visual C Run-Time,
and Windows 98/SE/ME had one, I'm not real sure
what is in there. I would expect C functions
available to M$ Visual C, but what are those?

<snip>
Post by ***@gmail.com
MSVCRT may be implemented to make every C
function simply directly call its OS counterpart,
It seems like that is stated backwards.

Can every C function can be wrapped around
an MSVCRT function? Maybe. Depends.

If there is a 1:1 function correspondence,
then, "Yes" is the answer, but I'm not
sure what is in MSVCRT. So, the answer
might also be "No", because the functions
don't actually correspond. Or, the answer
might be "Sometimes".

I wouldn't doubt it if some programming
is required to convert some C90 functions
to work with M$ VC functions. I'm making
this assumption based on DJGPP's back-end
code which converts some POSIX C functions
to MS-DOS non-C OS functions.

How similar is M$ Visual C to C90?
--
I'd love to answer that, but it would violate the TOS. Liberals can't
handle the truth, because the truth hurts.
muta...@gmail.com
2021-05-01 13:30:51 UTC
Permalink
Post by Rod Pemberton
Post by ***@gmail.com
To conceptualize, start with MSVCRT.DLL.
Other than MSVCRT means M$ Visual C Run-Time,
and Windows 98/SE/ME had one, I'm not real sure
what is in there. I would expect C functions
available to M$ Visual C, but what are those?
<snip>
Post by ***@gmail.com
MSVCRT may be implemented to make every C
function simply directly call its OS counterpart,
It seems like that is stated backwards.
Can every C function can be wrapped around
an MSVCRT function? Maybe. Depends.
If there is a 1:1 function correspondence,
then, "Yes" is the answer, but I'm not
sure what is in MSVCRT. So, the answer
might also be "No", because the functions
don't actually correspond. Or, the answer
might be "Sometimes".
I wouldn't doubt it if some programming
is required to convert some C90 functions
to work with M$ VC functions. I'm making
this assumption based on DJGPP's back-end
code which converts some POSIX C functions
to MS-DOS non-C OS functions.
How similar is M$ Visual C to C90?
I'm sorry, I can see how my original was confusing.

I was thinking of my own MSVCRT.DLL which has
nothing other than C90 functions in it, and all of
them.

So yes, there's a 1:1 correspondence.

Basically the concept I was trying to impart was a
pure C90 DLL, separate from both the application
and the OS.

BFN. Paul.

Loading...