C runtime library for Win32

[Paul Edwards]

I have written a public domain (not GPL etc) C runtime library
(PDPCLIB) for DOS, OS/2 and MVS. You can see it here:

http://sourceforge.net/projects/pdos/

I now wish to port it to Win32, so that I can create executables
to run under Windows 98 command prompt where every byte
of the executable is from public domain code.

I'm only interested in writing strictly conforming C89 programs,
ie TTY programs. PDPCLIB has no extensions.

I have gcc (egcs 2.91.57) installed, which came with Cygwin,
and I am happy to use gcc as my compiler, but I don't want to
use any GNU libraries. I basically want to implement
fopen/fread/etc by calling some Windows API, similar to OS/2.

I have done some reading on the web, and it would appear that
the equivalent of OS/2's DosOpen() is CreateFile(). What a
strange name for a function that opens existing files! So first
of all I would like to confirm that I've found the right API.
I found that here:

http://msdn.microsoft.com/library/de...ning_files.asp

Secondly, I'd like to know what process I need to use to start
writing applications that call these Win32 APIs without linking
in GNU libraries. If I just use gcc normally it will automatically
link in GNU libraries. I can use "gcc -nostdinc" to force gcc to
only pick headers up from my specified directories. How do I
force gcc to not link with the normal libraries? Do I need to
use "gcc -c" and "ld" myself? What is the syntax, so that I create
normal 32-bit Windows command line executables?

Also, how do I write to stdout via the Win32 API? Do I need
to do a CreateFile() or does a suitable handle already exist?
I'd like to get a "hello, world" program working first, to inspire
me to do the rest of the work.

I needed to write an assembler program in OS/2 as the executable
entry point. Do I need that for Win32 as well?

I've never done Windows programming before, so sorry for the
newbie questions. I'm really not sure how to get started.

Thanks. Paul.

[Kenny McCormack]

In article <45**********************@un-2park-reader-01.sydney.pipenetworks.com.au>,
Paul Edwards <ke******@nosppaam.w3.towrote:

>I have written a public domain (not GPL etc) C runtime library
(PDPCLIB) for DOS, OS/2 and MVS. You can see it here:

http://sourceforge.net/projects/pdos/

I now wish to port it to Win32, so that I can create executables
to run under Windows 98 command prompt where every byte
of the executable is from public domain code.

This is a very commendable project; I may look into it.

Unfortunately, any minute now, some dorkbrain is going to tell you that
you are off-topic. Be prepared for it.

[santosh]

Paul Edwards wrote:

I have written a public domain (not GPL etc) C runtime library
(PDPCLIB) for DOS, OS/2 and MVS. You can see it here:

http://sourceforge.net/projects/pdos/

I now wish to port it to Win32, so that I can create executables
to run under Windows 98 command prompt where every byte
of the executable is from public domain code.

Consider a fresh rewrite instead of a port.

<snip>

Secondly, I'd like to know what process I need to use to start
writing applications that call these Win32 APIs without linking
in GNU libraries. If I just use gcc normally it will automatically
link in GNU libraries. I can use "gcc -nostdinc" to force gcc to
only pick headers up from my specified directories. How do I
force gcc to not link with the normal libraries? Do I need to
use "gcc -c" and "ld" myself? What is the syntax, so that I create
normal 32-bit Windows command line executables?

You'll probably need more options than -nostdinc. Fully reading the gcc
and ld manuals in the best way int the long run.

Also, how do I write to stdout via the Win32 API?

Use WriteFile(). Again the best strategy is to download and install the
Platform SDK supplied by MS.

I needed to write an assembler program in OS/2 as the executable
entry point. Do I need that for Win32 as well?

Yes, the standard library's startup code will have to have some
assembly but it needs only be minimul and 32 bit x86 assembly is very
similar to 16 bit flat model.

I've never done Windows programming before, so sorry for the
newbie questions. I'm really not sure how to get started.

Why don't you try a few small practise apps before graduating to
porting/rewriting the C library?

Anyway, Windows related questions will be best answered on more
specific groups like comp.os.ms-windows.programmer etc. Also take a
peek at the sources for MinGW's runtime library or lcc-win32's standard
library to get a feel for what you must do. Fully 90% of the changes
would be the system calls. Unfortunately the Windows API is far from
simple and you'll have to spend *considerable* time on MSDN and with
Platform SDK before getting it right.

[Richard Heathfield]

santosh said:

<snip>

Unfortunately the Windows API is far from
simple

True enough. Nevertheless, it's reasonably easy.

and you'll have to spend *considerable* time on MSDN and with
Platform SDK before getting it right.

Not really. C is C. The Win32 API is Just Another API. No sweat. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[santosh]

Richard Heathfield wrote:

santosh said:

<snip>

Unfortunately the Windows API is far from
simple

True enough. Nevertheless, it's reasonably easy.

and you'll have to spend *considerable* time on MSDN and with
Platform SDK before getting it right.

Not really. C is C. The Win32 API is Just Another API. No sweat. :-)

True. However what would probably take up time is the sheer size of the
API. But I suppose the standard C library functions will only ever use
a small subset of it.

[Paul Edwards]

"Kenny McCormack" <ga*****@xmission.xmission.comwrote in message news:ej**********@news.xmission.com...

In article <45**********************@un-2park-reader-01.sydney.pipenetworks.com.au>,
Paul Edwards <ke******@nosppaam.w3.towrote:

I have written a public domain (not GPL etc) C runtime library
(PDPCLIB) for DOS, OS/2 and MVS. You can see it here:

http://sourceforge.net/projects/pdos/

I now wish to port it to Win32, so that I can create executables
to run under Windows 98 command prompt where every byte
of the executable is from public domain code.

This is a very commendable project; I may look into it.

That would be great! I think it is very important to have
a completely public domain C90 runtime library on every
platform. The MVS version actually has users, because
there is no other alternative for people who want to use
GCC. The DOS version is very fast at what it was
designed for, which is fast processing of fgets() on text
files, and fast processing of fread() on binary files. See
the performance benchmarks. I expect the WIN32 version
will similarly be faster than the available alternatives.

Unfortunately, any minute now, some dorkbrain is going to tell you that
you are off-topic. Be prepared for it.

C runtime libraries are off-topic in comp.lang.c? Where
would you suggest I post instead?

BFN. Paul.

[santosh]

Paul Edwards wrote:
<snip>

C runtime libraries are off-topic in comp.lang.c? Where
would you suggest I post instead?

Their semantics would be topical here and in comp.std.c, but any detail
of implementation is ostensibly not. For that a platform specific group
like one of comp.os.ms-windows.* or MSDN lists etc. would be preferred.

[jacob navia]

Paul Edwards wrote:

I have written a public domain (not GPL etc) C runtime library
(PDPCLIB) for DOS, OS/2 and MVS. You can see it here:

http://sourceforge.net/projects/pdos/

I now wish to port it to Win32, so that I can create executables
to run under Windows 98 command prompt where every byte
of the executable is from public domain code.

Well, I have done this for lcc-win64. Be prepared for quite a lot of work.

I'm only interested in writing strictly conforming C89 programs,
ie TTY programs. PDPCLIB has no extensions.

I did it for strictly C99 conforming programs. lcc-win64 has some
extensions... as you may know.

I have gcc (egcs 2.91.57) installed, which came with Cygwin,
and I am happy to use gcc as my compiler, but I don't want to
use any GNU libraries. I basically want to implement
fopen/fread/etc by calling some Windows API, similar to OS/2.

I have done some reading on the web, and it would appear that
the equivalent of OS/2's DosOpen() is CreateFile(). What a
strange name for a function that opens existing files! So first
of all I would like to confirm that I've found the right API.
I found that here:

http://msdn.microsoft.com/library/de...ning_files.asp

Yes, that is the primitive to use. CreateFile, ReadFile, WriteFile and
CloseHandle...

Secondly, I'd like to know what process I need to use to start
writing applications that call these Win32 APIs without linking
in GNU libraries. If I just use gcc normally it will automatically
link in GNU libraries. I can use "gcc -nostdinc" to force gcc to
only pick headers up from my specified directories. How do I
force gcc to not link with the normal libraries? Do I need to
use "gcc -c" and "ld" myself? What is the syntax, so that I create
normal 32-bit Windows command line executables?

I would just replace the gcc runtime library

Also, how do I write to stdout via the Win32 API? Do I need
to do a CreateFile() or does a suitable handle already exist?

There are already predefined "handles" for the STDIN, STDOUT and STDERR.
If you use that, it will work.

I'd like to get a "hello, world" program working first, to inspire
me to do the rest of the work.

I needed to write an assembler program in OS/2 as the executable
entry point. Do I need that for Win32 as well?

I did that, yes. But you can use the C compiler to write the assembly
for you.

I've never done Windows programming before, so sorry for the
newbie questions. I'm really not sure how to get started.

Well, you will learn a lot.

Good luck.

Jacob

[Richard Heathfield]

Paul Edwards said:

"Kenny McCormack" <ga*****@xmission.xmission.comwrote in message
news:ej**********@news.xmission.com...

>Unfortunately, any minute now, some dorkbrain is going to tell you that
you are off-topic. Be prepared for it.

C runtime libraries are off-topic in comp.lang.c? Where
would you suggest I post instead?

You have just been trolled. I can't think of anywhere better to discuss
standard C library implementation than in comp.lang.c.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Keith Thompson]

"Paul Edwards" <ke******@nosppaam.w3.towrites:
[...]

I have gcc (egcs 2.91.57) installed, which came with Cygwin,
and I am happy to use gcc as my compiler, but I don't want to
use any GNU libraries. I basically want to implement
fopen/fread/etc by calling some Windows API, similar to OS/2.

<OT>
Cygwin currently provides gcc 3.4.4; you might want to consider
updating. (Just run the Cygwin "setup.exe" program.) Or stick
with egcs 2.91.57 if it suits your purposes.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Paul Edwards said:

[...]

>C runtime libraries are off-topic in comp.lang.c? Where
would you suggest I post instead?

You have just been trolled. I can't think of anywhere better to discuss
standard C library implementation than in comp.lang.c.

Yes, but some of his questions are specific to Windows, gcc, and
possibly Cygwin. The best sources of information for those are
probably comp.os.ms-windows.programmer.win32, gnu.gcc.help, and the
Cygwin mailing lists available at <http://cygwin.com/lists.html>. You
should browse all of those and see whether they're likely to be more
helpful to you than we are.

For any C language issues that aren't specific to some particular
environment or compiler, this is the right place.

(Kenny McCormack is a self-proclaimed troll. He's not here to help
you. I suggest ignoring him.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tor Rustad]

Paul Edwards wrote:

I have written a public domain (not GPL etc) C runtime library

<snip>

I have gcc (egcs 2.91.57) installed, which came with Cygwin,
and I am happy to use gcc as my compiler, but I don't want to
use any GNU libraries. I basically want to implement
fopen/fread/etc by calling some Windows API, similar to OS/2.

If you look at Microsoft standard C library implementation, msvcrt.dll,
you will notice that it just makes call to one module, namely
kernel32.dll, which is where the Win32 functions are located.

I have done some reading on the web, and it would appear that
the equivalent of OS/2's DosOpen() is CreateFile(). What a
strange name for a function that opens existing files! So first
of all I would like to confirm that I've found the right API.
I found that here:

http://msdn.microsoft.com/library/de...ning_files.asp

Yes, CreateFile() is the Win32 API for this, by dumping the
kernel32.dll, you can see this function maps to

<...>
57 38 0001C10F CreateFileA
58 39 00016DD6 CreateFileMappingA
59 3A 00016E47 CreateFileMappingW
60 3B 0001C141 CreateFileW
<...>

CreateFileA and CreateFileW. Near the end of the list, an interesting
section can be located:

<...>
804 323 0001EE73 _hread
805 324 0001EE9A _hwrite
806 325 0001EED5 _lclose
807 326 0001EE49 _lcreat
808 327 0001EEEB _llseek
809 328 0001EDFE _lopen
810 329 0001EE73 _lread
811 32A 0001EE9A _lwrite
<...>

so it appears, that the low-level I/O API's (_open, _close, _read etc.)
provided in msvcrt.dll, has direct hooks into the kernel. This set of
functions is an alternative to the Win32 API, and might be faster to
use.

--
Tor <torust AT online DOT no>

[robertwessel2]

Tor Rustad wrote:

Paul Edwards wrote:

<...>

804 323 0001EE73 _hread
805 324 0001EE9A _hwrite
806 325 0001EED5 _lclose
807 326 0001EE49 _lcreat
808 327 0001EEEB _llseek
809 328 0001EDFE _lopen
810 329 0001EE73 _lread
811 32A 0001EE9A _lwrite
<...>

so it appears, that the low-level I/O API's (_open, _close, _read etc.)
provided in msvcrt.dll, has direct hooks into the kernel. This set of
functions is an alternative to the Win32 API, and might be faster to
use.

No, don't use those - those are all obsolete and exist for ease of
porting Win16 programs and backwards compatibility only. Stick with
the CreateFile/ReadFile/etc. stuff.

[robertwessel2]

Paul Edwards wrote:

Also, how do I write to stdout via the Win32 API? Do I need
to do a CreateFile() or does a suitable handle already exist?

See the GetStdHandle() API.

[Paul Edwards]

"santosh" <sa*********@gmail.comwrote in message news:11**********************@i42g2000cwa.googlegr oups.com...

Also take a
peek at the sources for MinGW's runtime library

I did this, and lo and behold, MinGW is public domain, not
GPL, which means part of the job, the startup code, is already
done.

However, the MinGW documentation says that all programs
compiled with gcc link libgcc.a, which is not public domain
(it is LGPL instead). What exactly does MinGW need libgcc.a
for? What is in libgcc.a? I thought MinGW accessed MSC's
CRT thus shouldn't require any GPL library?

It appears that libkernel32.a is the only thing I will need to
link with in order to use my own CRT. Is that correct? What
is the legal status of libkernel32.a?

BFN. Paul.

[Tor Rustad]

ro***********@yahoo.com wrote:

Tor Rustad wrote:

Paul Edwards wrote:

<...>

804 323 0001EE73 _hread
805 324 0001EE9A _hwrite
806 325 0001EED5 _lclose
807 326 0001EE49 _lcreat
808 327 0001EEEB _llseek
809 328 0001EDFE _lopen
810 329 0001EE73 _lread
811 32A 0001EE9A _lwrite
<...>

so it appears, that the low-level I/O API's (_open, _close, _read etc.)
provided in msvcrt.dll, has direct hooks into the kernel. This set of
functions is an alternative to the Win32 API, and might be faster to
use.

No, don't use those - those are all obsolete and exist for ease of
porting Win16 programs and backwards compatibility only. Stick with
the CreateFile/ReadFile/etc. stuff.

Wrong, these low-level functions should be of great interest for
someone porting a std C library, from OS/2, Unix or Linux.
Furthermore, you could try to trace what Microsoft do in their
std C library... not really a big surprise really:

fopen() calls _open()!
Doc from MSDN "Low-level I/O":

These functions invoke the operating system directly for
lower-level operation than that provided by stream I/O.
Low-level input and output calls do not buffer or format data.

Low-level routines can access the standard streams
opened at program startup using the following predefined handles:

Stream Handle
stdin 0
stdout 1
stderr 2

<snip>

--
Tor <torust AT online DOT no>

[robertwessel2]

Tor Rustad wrote:

ro***********@yahoo.com wrote:

Tor Rustad wrote:

Paul Edwards wrote:
<...>
804 323 0001EE73 _hread
805 324 0001EE9A _hwrite
806 325 0001EED5 _lclose
807 326 0001EE49 _lcreat
808 327 0001EEEB _llseek
809 328 0001EDFE _lopen
810 329 0001EE73 _lread
811 32A 0001EE9A _lwrite
<...>
>
so it appears, that the low-level I/O API's (_open, _close, _read etc.)
provided in msvcrt.dll, has direct hooks into the kernel. This set of
functions is an alternative to the Win32 API, and might be faster to
use.

No, don't use those - those are all obsolete and exist for ease of
porting Win16 programs and backwards compatibility only. Stick with
the CreateFile/ReadFile/etc. stuff.

Wrong, these low-level functions should be of great interest for
someone porting a std C library, from OS/2, Unix or Linux.
Furthermore, you could try to trace what Microsoft do in their
std C library... not really a big surprise really:

fopen() calls _open()!
Doc from MSDN "Low-level I/O":

These functions invoke the operating system directly for
lower-level operation than that provided by stream I/O.
Low-level input and output calls do not buffer or format data.

Low-level routines can access the standard streams
opened at program startup using the following predefined handles:

Stream Handle
stdin 0
stdout 1
stderr 2

First, my original comment applied to the Win32 APIs, which include
_lopen(). _open() is an internal CRT function (which is documented and
available to a C programmer as a front end to the OS APIs), and is
*not* an OS API. _open() does get called by fopen() (as well as by
most, if not all, of the variations of "file open" in the MSVC CRT).

Anyway, _open(), rather unsurprisingly, calls CreateFile(). Look at
the source yourself (it's in open.c in the ...\vc\crt\src directory).
Given that the OP wants to write his own CRT, it's unlikely that he'll
want to use _open() from the MS CRT in any event.

As I said originally, the old Win32 file I/O APIs, like _lopen(), are,
in fact, obsolete, and should not be used.

[Tor Rustad]

ro***********@yahoo.com wrote:

<snip>

As I said originally, the old Win32 file I/O APIs, like _lopen(),
are, in fact, obsolete, and should not be used.

I took a look in a debugger, and yes _open() calls _topen(),
which calls _tsopen() where a call to CreateFile() can be
located. This only means that _lopen() is not a hook into the
kernel32 for _open().

OP can still use the _open() interface provided in msvcrt.dll,
just like Microsoft has done themselves. As a first implementation,
this make a lot of sense, there will be easier to port the
standard C library to Win32, the library can rapidly provide
support for the POSIX functions: open(), close(), ...

Note, there is nothing stopping OP from eleminating msvcrt.dll
at a later stage, by rewriting the _open() function to hook
directly into the kernel32.dll via the CreateFile() API.

--
Tor <torust AT online DOT no>

[Paul Edwards]

"Tor Rustad" <to********@hotmail.comwrote in message news:11**********************@i42g2000cwa.googlegr oups.com...

ro***********@yahoo.com wrote:
Note, there is nothing stopping OP from eleminating msvcrt.dll
at a later stage, by rewriting the _open() function to hook
directly into the kernel32.dll via the CreateFile() API.

It is minimal effort to modify PDPCLIB to use WriteFile()
etc, and the latest CVS for PDPCLIB now has a "hello, world"
plus parameter printing program working for Win32 within
the normal structure of my CRT.

However, there is one fly in the ointment.

If I have a large amount (5000 bytes) of data on the stack, gcc
generates a call to alloca(). How do I stop gcc from doing
that and just use a fixed stack instead?

Where is the stack size specified in Win32 console mode
applications anyway?

BFN. Paul.

[Al Balmer]

On 15 Nov 2006 16:05:47 -0800, "ro***********@yahoo.com"
<ro***********@yahoo.comwrote:

>
Tor Rustad wrote:

>Paul Edwards wrote:

<...>

804 323 0001EE73 _hread
805 324 0001EE9A _hwrite
806 325 0001EED5 _lclose
807 326 0001EE49 _lcreat
808 327 0001EEEB _llseek
809 328 0001EDFE _lopen
810 329 0001EE73 _lread
811 32A 0001EE9A _lwrite
<...>

so it appears, that the low-level I/O API's (_open, _close, _read etc.)
provided in msvcrt.dll, has direct hooks into the kernel. This set of
functions is an alternative to the Win32 API, and might be faster to
use.

No, don't use those - those are all obsolete and exist for ease of
porting Win16 programs and backwards compatibility only. Stick with
the CreateFile/ReadFile/etc. stuff.

I know this is marked OT, but it's getting to be *very* off-topic, and
I think you would be much better served in a group of people who
really know this stuff.

It's been said time and again, but aside from keeping this group
reasonably on track, one of the main reasons for posting in the proper
group is that you get more answers from a wider range of experience,
and they are peer reviewed.

--
Al Balmer
Sun City, AZ

[Iwo Mergler]

Paul Edwards wrote:

However, the MinGW documentation says that all programs
compiled with gcc link libgcc.a, which is not public domain
(it is LGPL instead). What exactly does MinGW need libgcc.a
for? What is in libgcc.a?

All the stuff GCC doesn't want to inline at compile time.
Typically floating point emulation, larger-than-int arithmetics,
frame handling, etc.

objdump -T libgcc_s.so gives you the symbol table.

Kind regards,

Iwo

[Paul Edwards]

"Iwo Mergler" <Iw*********@soton.sc.philips.comwrote in message news:k0************@c2968.soton.sc.philips.com...

Paul Edwards wrote:

However, the MinGW documentation says that all programs
compiled with gcc link libgcc.a, which is not public domain
(it is LGPL instead). What exactly does MinGW need libgcc.a
for? What is in libgcc.a?

All the stuff GCC doesn't want to inline at compile time.
Typically floating point emulation, larger-than-int arithmetics,
frame handling, etc.

Ok, looks like I can't do away with that then. I've successfully
tested my CRT by compiling gccmvs 3.2.3 with it, and it produces
identical output to the Cygwin-compiled version, so that gave
it a good exercise. I found one longstanding bug by doing that.
The code has all been checked in to CVS if anyone is interested
in it.

BFN. Paul.