chryses@xurilka.UUCP (Phong Co) (06/13/91)
Hi there, I notice that the SDK functions include analogs of functions in the standard Microsoft library, such as lstrcmp(), _lopen(), wsprintf(), and so forth. While these are not identical to their DOS counterparts, they perform pretty much the same tasks, and in a Windows-friendly way. The Guide to Programming also says that if you don't use (and link in) the DOS runtime libraries your application will be much smaller. While I cannot argue this, it seems to me that the SDK functions don't come close to fulfilling the needs of an average Windows app. For example, many string functions are missing. Although many (such as strchr()) are not hard to implement, this is the reason libraries were invented in the first place. And there are some that I can't seem to find Win functions for, such as: - testing for the existence of a directory (such as using access()). OpenFile() only seems to work on files. Any one have any suggestions? - floating point I/O. While my program does not use floating point for calculation, I do read and display them in an edit control. I currently use atof() to read the numbers, and sprintf() to print them. Windows seem not to support floating point numbers at all. Does Microsoft think that graphics programs have no need for fractions? Like most people, I jumped headfirst into Windows programming, and wrote messy code, which I would now like to clean up bit by bit. My question is, is it really feasible to write a Windows app without resorting to runtime library calls? Phong. -- ========================================================================= Phong T. Co | chryses@xurilka.UUCP | Nice girls don't explode. dada Indugu Inc. | -- Dave Sim (Cerebus #110) Montreal, CANADA |
risto@tuura.UUCP (Risto Lankinen) (06/14/91)
chryses@xurilka.UUCP (Phong Co) writes: >Hi there, >I notice that the SDK functions include analogs of functions in the >standard Microsoft library, such as lstrcmp(), _lopen(), wsprintf(), >and so forth. While these are not identical to their DOS >counterparts, they perform pretty much the same tasks, and in a >Windows-friendly way. The Guide to Programming also says that if you >don't use (and link in) the DOS runtime libraries your application >will be much smaller. While I cannot argue this, it seems to me that >the SDK functions don't come close to fulfilling the needs of an >average Windows app. For example, many string functions are missing. >Although many (such as strchr()) are not hard to implement, this is >the reason libraries were invented in the first place. And there are >some that I can't seem to find Win functions for, such as: Hi! I've been happily using the xNOCRT.LIB:s, and still been able to use the string functions. There are model independent calls which start with '_f' (as in _fstrcpy() ), which don't require the general start- up code. What this means, is that you can use the _fxxxxxx() calls in your code, link with the xNOCRT.LIB *and* the xLIBCyW.LIB , using this order on the linker's command line. In general, you might be able to use some other functions as well. To discover them, use the /MAP option with the linker, and see whether it lists any segments, whose names begin with 'X' (f.ex. 'XIB', 'XIE' ). Functions, using which produces such segments, should not be used. Why? The segments beginning with 'X' contain pointers to initializers and de-initializers, which the normal startup calls one by one, but the startup of the xNOCRT.LIB does not. If an object module has declared this segment, it would lack the initialization service which it would probably need. For example, the onexit() has one such table, functions pointed to by which will be called, when WinMain() returns. This, plus parsing the _argv and _environ, lack from the xNOCRT.LIB's startup code. Alternatively, you may want to make a DLL of C runtime functions, which suit that purpose. Create a do-nothing object module and a .DEF where a few C functions are exported. Link the dummy object with the /MAP and see, whether the resulting DLL has any contents on its data segment. The size of datasegment should be 0 ; if it is anything else, then one of the exported functions will need its private DS, and cannot be used as an export by itself. Use the LDLLCAW to get far calls and pointers, and make your own header to be used with the DLL (declaring any calls or pointers as 'FAR _cdecl' or 'LPSTR' respectively). Also, make sure that all exports were defined with 'NODATA', as they will perform a bit better without Windows having to tell them a data segment, which they won't make use of in the first place. Using 'DATA NONE' might be required, too. Third way is to use the intrinsic mode of those string functions, that have one. You'll be able to use (if I remember correctly) strcat(), strcpy() and strlen() among others, without referring to any lib at all. >My question is, is it really feasible to write a Windows app without >resorting to runtime library calls? Hope you can make a decision from the above. Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 3 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 +1 is PRIME! Now working on 2 -1 * replies: risto@yj.data.nokia.fi ***************************************