mguyott@mirror.TMC.COM (Marc Guyott) (10/10/88)
In article <8087@umn-cs.CS.UMN.EDU> kehyoe@umn-cs.CS.UMN.EDU (Ong Keh Yoe) writes: > > If I compile a program in one of the memory models e.g. > the small model, then must all my library calls with > pointer arguments use near pointers ? Or far pointers ? If you use the small memory model you should link with the small model libraries. i.e. slibw.lib, swinlibc.lib, etc. and all of the pointers passed would be near pointers (at least for the library code that are hard linked - see the discussion below about Windows DLL calls). > Is there a difference between a standard library call, > and a Windows library call (e.g. MessageBox) ? Pointer args to windows library calls should always be FAR pointers. If you are using windows.h then all of the prototypes for the windows routines should cast your pointers correctly so that you do not have to be concerned. Be careful about keeping FAR pointers to data or code around. When you call certain windows functions (there are 5, GetMessage, PeekMessage, SendMessage, PostMessage, and one other that I can not think of at the moment) windows may move your code and/or data segments. If this occurs the FAR pointers you have in you program's variables will end up pointing into the great unknown. > My reasoning is as follows : > If compilation is performed in a certain memory model, > then all library routines will expect the default > (near or far). This is still true for routines in libraries like slibc.lib which are hard linked into your application. However, windows libraries are dynamically linked and always expect FAR pointers no matter what memory model you compile with. > compiled with the small model, the library functions > should (e.g. strcpy) expect near pointers. I believe this is true for statically linked functions. > However, > for the library routines to access these pointers in > the default data segment, don't these routines have > to be in the default code segment ? Since routines like strcpy are hard linked to your application there should be no problem (these routines use your default data segment). > If they are > not in the current code segment, does that mean > all pointers passed must be far pointers ? Are you passing code pointers? Then yes. Are you passing data pointers to a routine which uses the same data segment (medium model)? If yes, then the pointers can be NEAR otherwise the pointers must be FAR. > Does > a Windows library call differ from a normal call > because the memory required is much larger, and > overflows to other segments. Is any of this > correct ? A windows library call differs from a normal call because it is in a shareable code segment and any process can call this routine (not just yours). A windows library call also differs from a normal call because the code and data segments for the dynamic linked library are different than the code and data segments of your application (the stack is the same - both use your application's stack) hence the need for FAR pointers. Because library routines like strcpy are hard linked with your application they use the same data segment as your application. > Another thing that has perplexed me is if there > are several code segments, does each code segment > have it's own stack and heap, or are these > centralized ? > As long as each code segment specifies the default data segment as their data segment then all of the code segments in your application will use the same data segment. If the same data segment is being used than the same local heap is being used because the local heap is part of the data segment. As for the stack, under MS Windows each application has it's own stack and all DLL's that get called use that same stack. This stack is usually located in the Applications default data segment. I hope that this helps. Any questions or comments? Marc ---- ... I never saw the morning until I stayed up all night ... Tom Waits Marc Guyott mguyott@mirror.TMC.COM {mit-eddie, pyramid, harvard!wjh12, xait, datacube}!mirror!mguyott Mirror Systems Cambridge, MA 02140 617/661-0777