porting OW to PD-Windows

[[e-mail]]

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]

Post by ***@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
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.

Post by ***@gmail.com
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.

[[e-mail]]

Post by Paul S Person

Post by ***@gmail.com
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.

[[e-mail]]

Post by ***@gmail.com
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.