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.

On 17/02/24 04:35, Paul Edwards wrote:

> 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 wrote:
> 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

Paul Edwards wrote:
> On 17/02/24 04:35, Paul Edwards wrote:
>
>> 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

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

On 17/02/24 07:32, Dave Yeo wrote:

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

Am 16.02.24 um 21:35 schrieb 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.

> 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

On 17/02/24 17:11, Marcel Mueller wrote:

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

On 17/02/24 18:00, Paul Edwards wrote:

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

Paul Edwards wrote:
> On 17/02/24 07:32, Dave Yeo wrote:
>
>>>> 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
>>
>> 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.

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

On 18/02/24 02:42, Dave Yeo wrote:

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

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

Paul Edwards wrote:
> On 18/02/24 02:42, Dave Yeo wrote:
>
>>> 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

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

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

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

On 18/02/24 08:27, Dave Yeo wrote:

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

Ok, thanks.

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

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

On February 18, 2024 at 02:56:38 +0100 Paul Edwards wrote:

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

On 18/02/24 23:33, xhajt03 wrote:
> On February 18, 2024 at 02:56:38 +0100 Paul Edwards wrote:
>
> .
> .
>> 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 know anyway) "standard".
BFN. Paul.

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

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

On 19/02/24 19:47, xhajt03 wrote:

> If it was written in Turtle Graphics, MS would
> probably have distributed something like msvtgrt.dll
> with it.

Ok, I think I get your point.

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

I forked and maintain gcc 3.2.3.

It is now C90 compliant.

The supported FSF version isn't even written
in C anymore.

So, as a C compiler maintainer, and also (before
that) the author of a C library, I basically get
to decide what the DLL will look like. Just as
the EMX guy decided for his fork.

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

And I'm one of those porters.

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

There isn't a single C runtime library associated
with GCC, is there?

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

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.

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.

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

In the meantime, I've had two breakthroughs with
the Linux version of PDPCLIB in the last week
(including just a few hours ago), which should see
Linux apps working fine and normally under PDOS/386.

BFN. Paul.

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

On 20/02/24 06:31, Dave Yeo wrote:

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

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

Paul Edwards wrote:
> On 20/02/24 06:31, Dave Yeo wrote:
>
>>> 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.
>
>>> 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

On 20/02/24 14:03, Dave Yeo wrote:

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