C DLL

[Paul Edwards]

So on Windows - even Windows 95 - there was an
msvcrt.dll, but it wasn't documented.

But it's sufficiently understood for mingw and
PDPCLIB to use, and in the case of PDPCLIB at
least - produce a (partial) replacement.

MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).

So Microsoft never supported producing a 32-bit
OS/2 2.0 C DLL, but maybe IBM did with their
Visualage compiler. Or CSET/2.

EMX produced something, but I don't know if it was
considered "standard".

So I'm looking to build PDPCLIB (my own C runtime
library) into a mini-clone of something standard.

And then I'm looking to run those (small) executables
that use a separate C library under PDOS/386 and/or
PDOS-generic under Windows.

Is there a standard?

Thanks. Paul.

[Paul Edwards]

Post by Paul Edwards
MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).

I documented that in makefile.mos in pdpclib:

# Note that we should also produce a DLL that is compatible
# with the MSC 6.0 version when you do:
# c:cdllobjs .
# cl /AHu /MD /F 4000 world.c crtexe.obj cexample.lib
# set OS2LIBPATH=. (for Windows 2000, otherwise just LIBPATH)
# probably want to call the DLL PDPCRT.DLL


BFN. Paul.

[Paul Edwards]

Post by Paul Edwards

Post by Paul Edwards
MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).

# Note that we should also produce a DLL that is compatible
# c:cdllobjs .
# cl /AHu /MD /F 4000 world.c crtexe.obj cexample.lib
# set OS2LIBPATH=. (for Windows 2000, otherwise just LIBPATH)
# probably want to call the DLL PDPCRT.DLL

You have a choice of OS/2 v1 16 bit DLLs or OS/2 v2 32 bit DLLs.
See the OpenWatcom Linker guide

I think you misunderstood my question.

Do you know what mingw is on Windows? And msvcrt.dll.

I'm after the OS/2 2.0 equivalent of that.

I already (believe I) know the equivalent for OS/2 1.x.
Microsoft basically set the standard for OS/2 1.x C
compilers, and I know what they did to push the C
runtime library into a separate DLL instead of having
it statically linked into every executable.

With Microsoft gone by OS/2 2.0, it would have been
IBM with CSET/2 that set any standard for a separate
DLL for the C runtime.

BFN. Paul.

[Dave Yeo]

Post by Paul Edwards

Post by Paul Edwards

Post by Paul Edwards
MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).

# Note that we should also produce a DLL that is compatible
# c:cdllobjs .
# cl /AHu /MD /F 4000 world.c crtexe.obj cexample.lib
# set OS2LIBPATH=. (for Windows 2000, otherwise just LIBPATH)
# probably want to call the DLL PDPCRT.DLL

You have a choice of OS/2 v1 16 bit DLLs or OS/2 v2 32 bit DLLs.
See the OpenWatcom Linker guide

I think you misunderstood my question.

True.

Post by Paul Edwards
Do you know what mingw is on Windows? And msvcrt.dll.
I'm after the OS/2 2.0 equivalent of that.
I already (believe I) know the equivalent for OS/2 1.x.
Microsoft basically set the standard for OS/2 1.x C
compilers, and I know what they did to push the C
runtime library into a separate DLL instead of having
it statically linked into every executable.
With Microsoft gone by OS/2 2.0, it would have been
IBM with CSET/2 that set any standard for a separate
DLL for the C runtime.

Well, the equivalent of mingw is libcn, rebranded kLIBC which was a BSD
rewrite of EMX GPL libc. Mostly used with GCC.
The IBM compilers came with some libraries, single threaded and
multi-threaded that I forget the name of and are usually statically
linked in.
Perhaps os2386.lib is what you are looking for?
At least in GCC land, there is crt0.o and similar to be statically
linked in.
Dave

[Paul Edwards]

Post by Dave Yeo

Post by Paul Edwards
With Microsoft gone by OS/2 2.0, it would have been
IBM with CSET/2 that set any standard for a separate
DLL for the C runtime.

Well, the equivalent of mingw is libcn, rebranded kLIBC which was a BSD
rewrite of EMX GPL libc. Mostly used with GCC.
The IBM compilers came with some libraries, single threaded and
multi-threaded that I forget the name of and are usually statically
linked in.
Perhaps os2386.lib is what you are looking for?

It depends whether os2386.lib has the function
printf etc that are very small and just create
a reference to something.dll to be resolved at
runtime, or whether they cause a large amount
of code to be linked in that gets resolved to
a DosWrite in doscalls.dll.

I am after the former, not the latter.

But that does sound interesting. That single-threaded
library that is *usually* statically linked in - does
that mean it can be dynamically linked in if desired?

If so, it resolves to what DLL, and does that DLL ship
with OS/2 even if you don't have the IBM compiler?

Post by Dave Yeo
At least in GCC land, there is crt0.o and similar to be statically
linked in.

I don't mind that. I just need the entire C90
library - printf, strtol, etc, to reside in an
external DLL. It's normal to have a little bit
of code statically linked in that will set things
up to call routines in that external DLL.

BFN. Paul.

[Dave Yeo]

Post by Paul Edwards

Post by Dave Yeo

Post by Paul Edwards
With Microsoft gone by OS/2 2.0, it would have been
IBM with CSET/2 that set any standard for a separate
DLL for the C runtime.

Well, the equivalent of mingw is libcn, rebranded kLIBC which was a BSD
rewrite of EMX GPL libc. Mostly used with GCC.
The IBM compilers came with some libraries, single threaded and
multi-threaded that I forget the name of and are usually statically
linked in.
Perhaps os2386.lib is what you are looking for?

It depends whether os2386.lib has the function
printf etc that are very small and just create
a reference to something.dll to be resolved at
runtime, or whether they cause a large amount
of code to be linked in that gets resolved to
a DosWrite in doscalls.dll.

Looking at a map file for an OW program using printf(), I see,
g:\WATCOM/lib386/os2\clib3s.lib
g:\WATCOM/lib386\math387s.lib
G:\OS2TK45\lib\os2386.lib

Note that I have the toolkit in the front of the set LIB statement as
the toolkit is the official SDK. I assume with an OW program that it is
clib3s.lib that has libc functions such as printf(). Really not sure
about the IBM compilers. Most of my limited experience has been with GCC

Post by Paul Edwards
I am after the former, not the latter.
But that does sound interesting. That single-threaded
library that is *usually* statically linked in - does
that mean it can be dynamically linked in if desired?

Single threaded libs are more for DOS programs.
I'm not sure which DLLs contain the libc functions if any. With GCC, it
is libcXX.dll.

Post by Paul Edwards
If so, it resolves to what DLL, and does that DLL ship
with OS/2 even if you don't have the IBM compiler?

Sometimes people forget statically link or include the DLL with programs
that are compiled with IBM compiler, they don't run. So no.

Post by Paul Edwards

Post by Dave Yeo
At least in GCC land, there is crt0.o and similar to be statically
linked in.

I don't mind that. I just need the entire C90
library - printf, strtol, etc, to reside in an
external DLL. It's normal to have a little bit
of code statically linked in that will set things
up to call routines in that external DLL.

I really don't know exactly how it works with the IBM compilers and
libc. Hopefully someone else can chime in.

You should install the toolkit,
yum install os2tk45 os2tk45-books os2tk45-headers os2tk45-libs os2tk45-utils
and perhaps os2tk45-ipf os2tk45-rc.
Find it installed in %UNIXROOT%\usr\include\os2tk45, %UNIXROOT%\usr\lib\
and various other places in %UNIXROOT%\usr
and favour the toolkit libs over the OW ones.
Dave

[Paul Edwards]

Post by Dave Yeo
I'm not sure which DLLs contain the libc functions if any. With GCC, it
is libcXX.dll.

Ok, thanks.

Post by Dave Yeo
Sometimes people forget statically link or include the DLL with programs
that are compiled with IBM compiler, they don't run. So no.

Ok, thanks.

Post by Dave Yeo
You should install the toolkit,
yum install os2tk45 os2tk45-books os2tk45-headers os2tk45-libs
os2tk45-utils
and perhaps os2tk45-ipf os2tk45-rc.
Find it installed in %UNIXROOT%\usr\include\os2tk45, %UNIXROOT%\usr\lib\
and various other places in %UNIXROOT%\usr
and favour the toolkit libs over the OW ones.

I don't use the OW libs. I have my own (part of
PDPCLIB/PDOS). I only use their compiler. Not
their header files, and not their libraries.
And I am building on Windows 2000 (but can build
on PDOS/386 instead if I want - a mini-clone of
Windows).

And then I transport a single executable to
ArcaOS.

But hopefully soon I'll be able to build on
PDOS/386 as well as execute on PDOS/386.

As well as be able to build PDOS/386 and all
those tools that make it self-hosting, on
ArcaOS. Or even OS/2 2.0.

BFN. Paul.

[Paul Edwards]

.
.

Post by Paul Edwards
I don't use the OW libs. I have my own (part of
PDPCLIB/PDOS). I only use their compiler. Not
their header files, and not their libraries.
And I am building on Windows 2000 (but can build
on PDOS/386 instead if I want - a mini-clone of
Windows).

It seems that you assume that an operating system (or at least most of it) must always be built with one particular compiler for one particular programming language (namely C) using one particular ("standard") C runtime library which then must be used by all the operating system components and at least indirectly by all programs created for that operating system. While this is more or less the case e.g. for Linux and probably also for MS Windows (for different reasons, but with more or less the same result), this is simply not the case with OS/2 and has never been (for various reasons). Thus there's nothing like a standard C library for OS/2. There are multiple C library implementations shipped with OS/2 (and at least one other shipped with ArcaOS) even if talking just about those available for dynamic linking and parts of other C library implementations linked in statically. At least some device drivers were probably created in assembler, thus not using any C library whatsoever, and others may have been created in some other language. However, the common base for all the programs is not some C library nor any other library bound to some other programming language but rather the kernel and the associated API functions provided in the form of DLLs (as documented in the OS/2 programming toolkit). And, believe it or not, there are also other programming languages, not only C. ;-)
Tomas

I don't know where you are reading this.

As far as the OS interface goes - Windows has a
kernel32.dll which is similar to doscalls.dll - ie
the same (DLL) interface is used.

Nor does it matter what the language is. I'm just
trying to get C programs to work - but others are
free to write in any language they like, using the
published interface.

Nor do I make any assumptions as to what the OS
is written in. I don't care if Windows was written
in Turtle Graphics.

I am merely looking for how a C90 application can
interact with the various OSes.

And Windows - since Windows 95 - has shipped with
a very convenient msvcrt.dll, It isn't documented
by Microsoft, but we know what it is anyway, and
we can make use of it. mingw does that too.

So - I was asking if there was something similar
on OS/2 2.0+, and the answer is "no", basically.

So be it.

And so I now have a plan - port my own msvcrt.dll.
It will be an OS/2 DLL, but use the Microsoft
(undocumented but we

[xhajt03]

On February 19, 2024 at 03:41:56 +0100 Paul Edwards wrote:

.
.

Post by Paul Edwards
I don't know where you are reading this.
As far as the OS interface goes - Windows has a
kernel32.dll which is similar to doscalls.dll - ie
the same (DLL) interface is used.
Nor does it matter what the language is. I'm just
trying to get C programs to work - but others are
free to write in any language they like, using the
published interface.
Nor do I make any assumptions as to what the OS
is written in. I don't care if Windows was written
in Turtle Graphics.

.
.

If it was written in Turtle Graphics, MS would probably have distributed something like msvtgrt.dll with it. That's actually the point - the only reason why msvcrt.dll (_M_S_ _V_isual _C_ _R_un_T_ime DLL) is distributed with MS Windows is because that is the runtime library of their own C compiler (Visual C) and they used it for compiling the operating system (and, obviously, they also wanted to promote their compiler). It isn't because they wanted to simplify things for C programmers interfacing the operating system or anything like that, nor it becomes a standard C runtime library because of that. Various C compilers have their own C run-time library for the platforms they target (and compilers for other languages have their own runtime libraries). Using these libraries (in combination with the respective compiler) brings benefits because people don't have to reinvent the wheel by redoing something already solved by the C compiler authors (or their porters to the respective target operating system). OTOH, duplicating msvcrt.dll on OS/2 or whatever else (by building it from scratch using a different C compiler instead of using the runtime library of that particular C compiler) brings no benefits visible to me at least.

Tomas

[Dave Yeo]

Is OS/2 even supported by FSF? I didn't see any
sign of that in the gcc 3.2.3 source code.

No, it was forked a long time back. Likely RMS didn't want anything to
do with a propriety OS.

And since I don't need to thunk, because I don't
need to run 16-bit code, then the gcc 3.2.3 compiler
that I distribute should produce code that works
for OS/2.

How are you planning on supporting OMF? It is the native object format,
usually with USE32 and FLAT for pure 32 bit code.

But it is pending on other components being
available, specifically the pdld linker.
And the author of pdld has only agreed to work on
that if I first get OS/2 applications to load under
PDOS/386 so that he can test the result.

Are you planning on supporting LX binaries?

And that in turn is pending on the result of my
bug report in ArcaOS as I don't want to disturb
my environment.

Dave

[Paul Edwards]

Post by Dave Yeo

And since I don't need to thunk, because I don't
need to run 16-bit code, then the gcc 3.2.3 compiler
that I distribute should produce code that works
for OS/2.

How are you planning on supporting OMF? It is the native object format,
usually with USE32 and FLAT for pure 32 bit code.

I'm not. I'm planning on using COFF object
code, as per Windows, but pdld would produce
an LX binary.

Same equation for ELF output with coff input.

Post by Dave Yeo

And the author of pdld has only agreed to work on
that if I first get OS/2 applications to load under
PDOS/386 so that he can test the result.

Are you planning on supporting LX binaries?

Correct.

The exeload.c that I pointed to before already detects
LX binaries but just says they are unsupported. It
supports PE currently.

BFN. Paul.

[Dave Yeo]

Post by Paul Edwards

Post by Dave Yeo

And since I don't need to thunk, because I don't
need to run 16-bit code, then the gcc 3.2.3 compiler
that I distribute should produce code that works
for OS/2.

How are you planning on supporting OMF? It is the native object format,
usually with USE32 and FLAT for pure 32 bit code.

I'm not. I'm planning on using COFF object
code, as per Windows, but pdld would produce
an LX binary.
Same equation for ELF output with coff input.

Post by Dave Yeo

And the author of pdld has only agreed to work on
that if I first get OS/2 applications to load under
PDOS/386 so that he can test the result.

Are you planning on supporting LX binaries?

Correct.
The exeload.c that I pointed to before already detects
LX binaries but just says they are unsupported. It
supports PE currently.

And DLL's? OS/2 DLL's are more strict then Windows DLL's. 8.3 naming
with the internal name needing to match the module name.
Dave

[Paul Edwards]

Post by Dave Yeo

Post by Paul Edwards
The exeload.c that I pointed to before already detects
LX binaries but just says they are unsupported. It
supports PE currently.

And DLL's? OS/2 DLL's are more strict then Windows DLL's. 8.3 naming
with the internal name needing to match the module name.

I will only be supporting two DLLs:

1. doscalls.dll

2. msvcrt.dll (or maybe pdpcrt.dll)

And those won't exist as real DLLs on PDOS/386.
They will be resolved to internal code in
pdos.exe (currently I have a kernel32.c that
resolves kernel32.dll too - a thin layer on
top of the underlying native Pos* (inspired
by OS/2 Dos* naming convention, but MSDOS
API) API).

msvcrt.dll hopefully doesn't need a thin layer -
it will already exist. (but this needs a proof
of concept).

msvcrt.dll will exist as a real DLL on OS/2 2.0+
though, and yes, I'll obey whatever the rules are.

BFN. Paul.

[Dave Yeo]

Post by Paul Edwards
So on Windows - even Windows 95 - there was an
msvcrt.dll, but it wasn't documented.
But it's sufficiently understood for mingw and
PDPCLIB to use, and in the case of PDPCLIB at
least - produce a (partial) replacement.
MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).
So Microsoft never supported producing a 32-bit
OS/2 2.0 C DLL, but maybe IBM did with their
Visualage compiler. Or CSET/2.
EMX produced something, but I don't know if it was
considered "standard".
So I'm looking to build PDPCLIB (my own C runtime
library) into a mini-clone of something standard.
And then I'm looking to run those (small) executables
that use a separate C library under PDOS/386 and/or
PDOS-generic under Windows.
Is there a standard?

There's a few linkers available.
W:\OS2>LINK.EXE

Microsoft (R) Segmented-Executable Linker Version 5.10.005
Copyright (C) Microsoft Corp 1984-1989. All rights reserved

W:\OS2>LINK386.EXE

Operating System/2 Linear Executable Linker
Version 4.00.001 Sep 24 2001
Copyright (C) IBM Corporation 1988-1993.
Copyright (C) Microsoft Corp. 1988-1993.

Various versions of ilink, which shipped with IBM compilers.
Now, mostly using wlink, which can produce all kinds of DLL's, see the
OpenWatcom documentation. Latest is best and needed if you want HLL
debug data. wlink is the only linker that will work for very large DLLs,
with some fixes for using the whole address space added after OW 1.6 I
believe.
Dave

[Marcel Mueller]

Post by Paul Edwards
MSC 6.0 had the ability to produce an OS/2 1.x
C DLL, but it wasn't a standard name (cdllobjs.cmd
produces cexample.dll by default, but that wasn't
something shipped with OS/2 1.x that I am aware of).
So Microsoft never supported producing a 32-bit
OS/2 2.0 C DLL, but maybe IBM did with their
Visualage compiler. Or CSET/2.
EMX produced something, but I don't know if it was
considered "standard".

AFAIK there never was something like a standard.
The C Runtime ist always part of the compiler. And it _might_ be shipped
as dynamically linked library.

There are as many implementations as compilers. IBM, gcc, Watcom ...
And there are different versions for the same compiler too. You always
need the one that exactly matches the build environment. To some degree
Compilers had updated versions that are downward compatible.

Post by Paul Edwards
So I'm looking to build PDPCLIB (my own C runtime
library) into a mini-clone of something standard.

There is no standard. if you want to replace the runtime of different
compilers you need to do this one by one.


Marcel

[Paul Edwards]

Post by Marcel Mueller

Post by Paul Edwards
So Microsoft never supported producing a 32-bit
OS/2 2.0 C DLL, but maybe IBM did with their
Visualage compiler. Or CSET/2.
EMX produced something, but I don't know if it was
considered "standard".

AFAIK there never was something like a standard.

Ok, thanks.

In that case, I'll produce my own that follows
the msvcrt standard that mingw uses - except
for OS/2.

BFN. Paul.

[Paul Edwards]

Post by Paul Edwards

Post by Marcel Mueller
AFAIK there never was something like a standard.

Ok, thanks.
In that case, I'll produce my own that follows
the msvcrt standard that mingw uses - except
for OS/2.

And I may as well do the same thing for
Linux ELF and OS/2 1.x too.

BFN. Paul.