porting OW to PD-Windows

[muta...@gmail.com]

I have a public domain project called "PD-Windows"
which provides a subset of Windows command line,
pretty much limited to what is needed to support
C90-compliant programs. You can find it here:
http://pdos.sourceforge.net

wcl and wcl386 should either be C90-compliant
already, or able to be made so, as all they do is
read in a bunch of text files and output a binary file.

Does anyone know how far away they are from
being C90-compliant?

Thanks. Paul.

[Paul S Person]

On Sun, 20 Sep 2020 08:23:49 -0700 (PDT), "muta...@gmail.com"
<muta...@gmail.com> wrote:

>I have a public domain project called "PD-Windows"
>which provides a subset of Windows command line,
>pretty much limited to what is needed to support
>C90-compliant programs. You can find it here:
>http://pdos.sourceforge.net
>
>wcl and wcl386 should either be C90-compliant
>already, or able to be made so, as all they do is
>read in a bunch of text files and output a binary file.

Actually, standard compliance has more to do with recognizing keywords
and other items than with the mechanics of reading and writing files.

>Does anyone know how far away they are from
>being C90-compliant?

The servers are down per the current storms in Florida; I am currently
using EternalSeptember.

I believe it is C90-compliant, and has at least some features of C99
and other related standards.
--
"I begin to envy Petronius."
"I have envied him long since."

[muta...@gmail.com]

On Tuesday, September 22, 2020 at 1:09:35 AM UTC+10, Paul S Person wrote:

> >wcl and wcl386 should either be C90-compliant
> >already, or able to be made so, as all they do is
> >read in a bunch of text files and output a binary file.

> Actually, standard compliance has more to do with recognizing keywords
> and other items than with the mechanics of reading and writing files.

My concern is whether wcl(386) call non-C90 functions.
PD-Windows doesn't provide much more than just the
C90 functions.

When I do this command:

C:\WATCOM\binnt>objdump -p wcl386.exe | grep -v reloc

I get a whole stack of non-C90 functions like:

e386 20 GetConsoleMode
e398 21 GetCurrentDirectoryA
e3b0 22 GetCurrentThreadId

none of which exist in PD-Windows:

C:\devel\pdos\src>grep Get windows.h
HANDLE WINAPI GetStdHandle(DWORD nStdHandle);
#define GetFileAttributes GetFileAttributesA
DWORD WINAPI GetFileAttributesA(
#define GetCommandLine GetCommandLineA
LPTSTR WINAPI GetCommandLineA(void);
LPTCH WINAPI GetEnvironmentStrings(void);
BOOL WINAPI GetExitCodeProcess(HANDLE hProcess, LPDWORD lpExitCode);
DWORD WINAPI GetLastError(void);
void WINAPI GetSystemTime(LPSYSTEMTIME lpSystemTime);
BOOL WINAPI GetConsoleScreenBufferInfo(


So how much effort would be required to restrict
wcl(386) to only use C90 functions? It should be
possible to read in text files and output a binary
file (which is all that wcl does) using purely C90
functions.

Thanks. Paul.

[muta...@gmail.com]

On Tuesday, September 22, 2020 at 2:35:01 PM UTC+10, muta...@gmail.com wrote:

> So how much effort would be required to restrict
> wcl(386) to only use C90 functions? It should be
> possible to read in text files and output a binary
> file (which is all that wcl does) using purely C90
> functions.

Note that I have already been through the effort of
beating GCC 3.2.3 into C90-compliance.

BFN. Paul.