efowler@milton.u.washington.edu (Eric Fowler) (10/09/90)
I have recently been trying to write a file IO routine that simply opens a file of ASCII text and reads it in one line at a time. In vanilla C, this is a trivial task with the fgets() function. However, using fgets() with the SDK earns me an instantaneous UAE in windows. I assume this is a compatibility problem involving the stack. On the other hand, using the Windows function _lread() does not allow me to bring the data in linewise-I only get a fixed number of characters. If you want to bring in file data line by line in windows, what is the easiest way to go about it? I find it hard to swallow that you have to give this up to program in windows, but I still can't find the function I need in the SDK. Any help mucho appreciated. Thanks, =Eric
risto@tuura.UUCP (Risto Lankinen) (10/10/90)
efowler@milton.u.washington.edu (Eric Fowler) writes: >I have recently been trying to write a file IO routine that simply opens >a file of ASCII text and reads it in one line at a time. In vanilla C, >this is a trivial task with the fgets() function. However, using >fgets() with the SDK earns me an instantaneous UAE in windows. Hi! My suggestion is that the following were checked: - The proper header (.H) file is #included - The header file declares the function as _cdecl or _pascal (in the case of standard C libraries, it probably should be _cdecl). The explicit calling convention declaration is the important thing, not that which it is. All Windows programs are compiled with _pascal calling convention. If the compiler lacks the declaration info, it will default to using _pascal even if the function expects using _cdecl (as the standard C libraries in most cases do). Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 2 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME! Now working on 2 +1 * replies: risto@yj.data.nokia.fi ***************************************
strobl@gmdzi.gmd.de (Wolfgang Strobl) (10/11/90)
risto@tuura.UUCP (Risto Lankinen) writes: >All Windows programs are compiled with _pascal calling convention. If >the compiler lacks the declaration info, it will default to using _pascal >even if the function expects using _cdecl (as the standard C libraries in >most cases do). Is this something which has been changed between version 2 and 3 of the Windows SDK and/or version 5 and 6 of the Microsoft C compiler? I ask because what you say isn't true for the SDK ver. 2. Here you declare all callback functions PASCAL, which is defined in windows.h to be the keyword pascal. All Windows functions are declared within windows.h to be FAR PASCAL (which is defined to be far and pascal). Everything else defaults to cdecl. At least this is the case for the two C compilers I use for Windows development: Zortech C++/C 2.1 and IBM C/2 1.1. Wolfgang Strobl #include <std.disclaimer.hpp>
risto@tuura.UUCP (Risto Lankinen) (10/12/90)
strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >risto@tuura.UUCP ( myself ) writes: >>All Windows programs are compiled with _pascal calling convention. If >>the compiler lacks the declaration info, it will default to using _pascal >>even if the function expects using _cdecl (as the standard C libraries in >>most cases do). >Is this something which has been changed between version 2 and 3 of the >Windows SDK and/or version 5 and 6 of the Microsoft C compiler? I ask >because what you say isn't true for the SDK ver. 2. Here you declare >all callback functions PASCAL, which is defined in windows.h to be >the keyword pascal. All Windows functions are declared within windows.h >to be FAR PASCAL (which is defined to be far and pascal). Everything >else defaults to cdecl. At least this is the case for the two Hi! Well, right. The sentence should have been ' ... are *more conveniently* compiled using _pascal ... '. Why? Using the -Gc switch for Microsoft-C sets the calling convention to _pascal unless overridden in the declar- ation. The programs' "internal" function calls being _pascal will not harm anything (except for the problem of my original reply), but will allow writing even the exported functions without having to remember the PASCAL keyword each time (though it is good to keep in mind where to add it if strange things occur). I think this is a matter of practice, and at least it hasn't changed between versions 2 and 3 of the SDK . The C compiler, however, has explicit _cdecl's and _pascal's in its include files wherever applicable, but I do not know whether it was so in previous (before 6.0) versions. By the way, the SDK 3.0 provides a documented way to discard using the standard C libraries altogether by addition of xNOCRT.LIB libraries. The resulting code will be smaller (but has to use Windows services only), and will have no functions declared _cdecl with the exception of Windows' 'wsprintf' I am using only those with the 'SET CL=-Gcw' with no troubles. Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 2 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME! Now working on 2 +1 * replies: risto@yj.data.nokia.fi ***************************************