nathan@eddie.mit.edu (Nathan Glasser) (10/05/90)
Hello,
I've got a question about versions of MSC 6.0 or later for those of you
who are familiar with technical aspects of it.
In versions 5.1 and earlier, all of the (MSDOS) libraries were compiled
with the assumption that SS=DS. While the compiler itself can be told not
to make this assumption, if you're going to use the libraries they supply,
you have to be sure that SS=DS holds (for the most part).
I'm wondering whether the later version(s) of MSC also make this assumption in
their MSDOS libraries. What I want to run is an MSDOS application for which SS
!= DS, and use the MSC library. Note that OS/2 libraries that may be supplied
with the compiler are probably of little use for this purpose, since they
almost certainly use OS/2 specific system calls; however, feel free to correct
me if you have reason to believe this is not the case.
I know it's probably possible to purchase the library source code and
recompile it to use my custom memory model, but obviously if such a memory
model is already supported, I'd like not to have to do this.
Thanks in advance for your responses.
--
Nathan Glasser
fnord nathan@{mit-eddie.uucp, brokaw.lcs.mit.edu}
YP-17 Nate on IRC, Forum, and Bitnet Relay
Beware the DDG! Pulsar on Abermudrommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (10/06/90)
In article <1990Oct5.024155.19090@eddie.mit.edu> nathan@eddie.UUCP (Nathan Glasser) writes: >In versions 5.1 and earlier, all of the (MSDOS) libraries were compiled >with the assumption that SS=DS. While the compiler itself can be told not >to make this assumption, if you're going to use the libraries they supply, >you have to be sure that SS=DS holds (for the most part). > >I'm wondering whether the later version(s) of MSC also make this assumption in >their MSDOS libraries. What I want to run is an MSDOS application for which SS >!= DS, and use the MSC library. Note that OS/2 libraries that may be supplied It is probably clear to you, that in small-data models you HAVE to have DS==SS because you would otherwise need far pointer to address both global (static) and automatic variables (consider scanf("%d", &num) !). In large-data models it would generally be possible to use different data and stack segments like Turbo C does. But under MS-DOS you have no structure in the memory management and can do what you want. Under systems like Windows or OS/2, the system architecture predicts a "default data segment" which contains the stack and data items of small size. You can then have other data segments with large data items. The fact that under Windows and OS/2 often DS!=SS is used, should not imply that data and stack segments are different! Instead, DS!=SS is needed there for DLL's which use the caller's stack but have their own local data and for callback functions which are uses as Window procedures. But for program modules (not DLL's) the default data segments always holds stack and data items of small size. Probably MS imposed this DS==SS law because of compatibility to these future (now real) systems even in the first MS C versions (as far as I know development of WIndows already started about 1983 or even earlier). Another reason is speed. When you have different stack and data segments, the segment registers have to be reloaded more often when you access the two most often used data classes (static/extern and auto). This is a *VERY* expensive operation under protected mode (2 cycles vs. 17 cycles on a 386!) and having small data items and the stack in one segment speeds things up. If thes DS==SS law restricts your amount of static/extern data and stack because they share one 64k segment, you can use the -Gt[size] option with about 256 or less as argument or explicitly declare data items like structures or arrays or strings, that you declare as extern/static, with the "far" (or now "_far" in 6.00) keyword. This forces them to be placed in extra data segments and frees some space in the default data segment. Hope this is all correct and helps, Kai Uwe Rommel -- /* Kai Uwe Rommel * Munich * rommel@lan.informatik.tu-muenchen.dbp.de */