c++.windows.32-bits - Compiling C programs from previous Zortech/Symantec compilers
- Kenneth Spencer (88/88) May 11 2007 Re.: Compiling C programs from previous Zortech/Symantec compilers
- Walter Bright (13/115) Jul 11 2007 There is only one memory model for Win32 programming, and that's 'flat'....
Re.: Compiling C programs from previous Zortech/Symantec compilers We have several programs written in previous versions of Zortech/Symantec C (no C++), which we wish to convert to compile with Digital Mars. (Zortech C/C++ and Symantec C/C++ are predecessors of Digital Mars). Most of the programs consist of several C modules compiled and linked with a Large Memory module: we have used this approach because the resultant executables have been found to run on all versions of Windows from 3.1 through 9/98/2k/2k3/XP and now Vista. We are trying to use the IIDE for these projects, which have previously been compiled and linked at the command line. However, when we try to compile the programs in DM, we encounter rather too many errors and issues, and wondered whether anyone may be able to help. ISSUE 1 we do not seem to be able to change the Memory Model for compilation: it is restricted to "Flat". ISSUE 2 Issue two occurs early in the compilation of the first module and results in the compiler ceasing to process code after the include statement: #include <drivinit.h> However the compiler continues to count lines (even thought the count grossly exceeds the line count of our projects!) until it fails and issues the report: ============ complier output report =========================== sc Persw.c -p -mn -o+time -WA -3 -a8 -c -H -HO- - IC:\SW_Tools\DigiMars\include -oPersw.obj nbytes = 65520, ph_maxsize = 65520 Fatal Error: C:\SW_Tools\DigiMars\include\win32\drivinit.h(2): internal error ph 1817 Lines Processed: 645805 Errors: 1 Warnings: 0 Build failed ================================================================ ISSUE 3 If we remove the Include line which generates ISSUE 1, the compiler stops and reports many problems relating to a need to introduce explicit casts into our code. This is code that compiles and runs correctly under the previous versions. Some examples of the code, and the errors generated are: ============= CODE SAMPLE A ===================================== BOOL InitApplication (hInstance) HANDLE hInstance; { int count; WNDCLASS wc; wc.style = NULL; wc.lpfnWndProc = MainWndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = LoadIcon (hInst, "PERSWIcon"); wc.hCursor = LoadCursor (NULL, IDC_ARROW); wc.hbrBackground = GetStockObject (LTGRAY_BRUSH); wc.lpszMenuName = "PERSWMenu"; wc.lpszClassName = "PERSWClass"; return (RegisterClass (&wc)); } ==================== COMPILER OUTPUT ========================= sc Persw.c -p -mn -o+time -WA -3 -a8 -c -H -HO- - IC:\SW_Tools\DigiMars\include -oPersw.obj Error: K:\PERS-SYS\DigiMarsTest\Persw.c(850): need explicit cast to convert K:\PERS-SYS\DigiMarsTest\Persw.c(850): from: void * K:\PERS-SYS\DigiMarsTest\Persw.c(850): to : unsigned ============================================================== This error references the line: wc.style = NULL; in the above code. There are many errors of this type, for example: ================ CODE SAMPLE B =============================== Referencing the line below from CODE SAMPLE A above: wc.lpfnWndProc = MainWndProc; we have defined the function MainWindowProc as: long FAR PASCAL MainWndProc (HWND, unsigned, WORD, LONG); in our include file for the Project. This generates the error: Error: K:\PERS-SYS\DigiMarsTest\Persw.c(851): need explicit cast to convert K:\PERS-SYS\DigiMarsTest\Persw.c(851): from: long (*std func)(void *,unsigned ,unsigned short ,long ) K:\PERS-SYS\DigiMarsTest\Persw.c(851): to : long (*std func)(void *,unsigned ,unsigned ,long ) So can anyone advise us on any of these issues, or do we have to go back to our old compiler and forget about tryoing to use the later versions of Digital Mars ? Regards and thanks in advance, Kenneth Spencer
May 11 2007
Kenneth Spencer wrote:Re.: Compiling C programs from previous Zortech/Symantec compilers We have several programs written in previous versions of Zortech/Symantec C (no C++), which we wish to convert to compile with Digital Mars. (Zortech C/C++ and Symantec C/C++ are predecessors of Digital Mars). Most of the programs consist of several C modules compiled and linked with a Large Memory module: we have used this approach because the resultant executables have been found to run on all versions of Windows from 3.1 through 9/98/2k/2k3/XP and now Vista. We are trying to use the IIDE for these projects, which have previously been compiled and linked at the command line. However, when we try to compile the programs in DM, we encounter rather too many errors and issues, and wondered whether anyone may be able to help. ISSUE 1 we do not seem to be able to change the Memory Model for compilation: it is restricted to "Flat".There is only one memory model for Win32 programming, and that's 'flat'. For 16 bit Windows, use the other IDDE scw.exe, not scw32.exe.ISSUE 2 Issue two occurs early in the compilation of the first module and results in the compiler ceasing to process code after the include statement: #include <drivinit.h> However the compiler continues to count lines (even thought the count grossly exceeds the line count of our projects!) until it fails and issues the report: ============ complier output report =========================== sc Persw.c -p -mn -o+time -WA -3 -a8 -c -H -HO- - IC:\SW_Tools\DigiMars\include -oPersw.obj nbytes = 65520, ph_maxsize = 65520 Fatal Error: C:\SW_Tools\DigiMars\include\win32\drivinit.h(2): internal error ph 1817 Lines Processed: 645805 Errors: 1 Warnings: 0 Build failed ================================================================I can't figure this out without a reproducible sample.ISSUE 3 If we remove the Include line which generates ISSUE 1, the compiler stops and reports many problems relating to a need to introduce explicit casts into our code. This is code that compiles and runs correctly under the previous versions. Some examples of the code, and the errors generated are: ============= CODE SAMPLE A ===================================== BOOL InitApplication (hInstance) HANDLE hInstance; { int count; WNDCLASS wc; wc.style = NULL; wc.lpfnWndProc = MainWndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = LoadIcon (hInst, "PERSWIcon"); wc.hCursor = LoadCursor (NULL, IDC_ARROW); wc.hbrBackground = GetStockObject (LTGRAY_BRUSH); wc.lpszMenuName = "PERSWMenu"; wc.lpszClassName = "PERSWClass"; return (RegisterClass (&wc)); } ==================== COMPILER OUTPUT ========================= sc Persw.c -p -mn -o+time -WA -3 -a8 -c -H -HO- - IC:\SW_Tools\DigiMars\include -oPersw.obj Error: K:\PERS-SYS\DigiMarsTest\Persw.c(850): need explicit cast to convert K:\PERS-SYS\DigiMarsTest\Persw.c(850): from: void * K:\PERS-SYS\DigiMarsTest\Persw.c(850): to : unsignedImplicit casting of void* to unsigned is not valid C code, so an explicit cast is needed.============================================================== This error references the line: wc.style = NULL; in the above code. There are many errors of this type, for example: ================ CODE SAMPLE B =============================== Referencing the line below from CODE SAMPLE A above: wc.lpfnWndProc = MainWndProc; we have defined the function MainWindowProc as: long FAR PASCAL MainWndProc (HWND, unsigned, WORD, LONG); in our include file for the Project. This generates the error: Error: K:\PERS-SYS\DigiMarsTest\Persw.c(851): need explicit cast to convert K:\PERS-SYS\DigiMarsTest\Persw.c(851): from: long (*std func)(void *,unsigned ,unsigned short ,long ) K:\PERS-SYS\DigiMarsTest\Persw.c(851): to : long (*std func)(void *,unsigned ,unsigned ,long )The functions have different parameter types, so issuing an error is correct. I suggest determining which function declaration is the correct one, and change the other to match.So can anyone advise us on any of these issues, or do we have to go back to our old compiler and forget about tryoing to use the later versions of Digital Mars ?If the older compilers are working fine for you, and you do not wish to change any of the legacy source code, there is no reason to upgrade. But if you're writing any new code, I'd use the newer compiler as it is more standard compliant.Regards and thanks in advance, Kenneth Spencer
Jul 11 2007