C runtime library for Win32

P

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/d...n-us/fileio/fs/creating_and_opening_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.
 
K

Kenny McCormack

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.
 
S

santosh

Paul said:
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.

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.
 
R

Richard Heathfield

santosh said:

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.
 
S

santosh

Richard said:
santosh said:



True enough. Nevertheless, it's reasonably easy.


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.
 
P

Paul Edwards

Kenny McCormack said:
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.
 
S

santosh

Paul Edwards wrote:
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.
 
J

jacob navia

Paul said:
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/d...n-us/fileio/fs/creating_and_opening_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
 
R

Richard Heathfield

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.

--
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.
 
K

Keith Thompson

Paul Edwards said:
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>
 
K

Keith Thompson

Richard Heathfield said:
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.)
 
T

Tor Rustad

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

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/d...n-us/fileio/fs/creating_and_opening_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.
 
R

robertwessel2

Tor said:
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.
 
R

robertwessel2

Paul said:
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.
 
P

Paul Edwards

santosh said:
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.
 
T

Tor Rustad

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>
 
R

robertwessel2

Tor said:
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.
 
T

Tor Rustad

(e-mail address removed) wrote:

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.
 
P

Paul Edwards

Tor Rustad said:
(e-mail address removed) 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.
 
A

Al Balmer

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top