MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) (10/24/90)
Nothing against the sophisticated memory management of himem.sys, but we use older software which needs extended memory and has no chance to communicate their needs via himem. Smalltalk V/286 for example. Is there a utility available which after invocation of windows, I mean, after leaving it, gives extended memory back for undiscplined programs? - Thomas
akm@cs.uoregon.edu (Anant Kartik Mithal) (10/27/90)
In article <90297.155820MUHRTH@DB0TUI11.BITNET> MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes: >Nothing against the sophisticated memory management of himem.sys, but >we use older software which needs extended memory and has no chance to >communicate their needs via himem. Smalltalk V/286 for example. >Is there a utility available which after invocation of windows, I mean, >after leaving it, gives extended memory back for undiscplined programs? I actually don't understand why we need himem.sys at all. After all, both 286 and 386 systems can address extended memory without a problem (in protected mode), so why do we need to use himem? I understood the logic for emm, but not xms. kartik -- Anant Kartik Mithal akm@cs.uoregon.edu Network Manager, (503)346-4408 (msgs) Department of Computer Science, (503)346-4156 (direct) University of Oregon, Eugene, OR 97403-1202
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (10/27/90)
In article <1990Oct26.195130.17719@cs.uoregon.edu> akm@cs.uoregon.edu (Anant Kartik Mithal) writes: > >I actually don't understand why we need himem.sys at all. After all, >both 286 and 386 systems can address extended memory without a >problem (in protected mode), so why do we need to use himem? I >understood the logic for emm, but not xms. > Very simple: Microsoft did it that way to pimp out users of other companies software. Himem.sys makes it impossible to use any software using extended memory that was written earlier than it was. This means that Microsoft is saying "Hah Hah!! You thought it was safe to buy other companies products? Gotcha!!! We are Microsoft - you use our products, then WE will prevent you from running other companies products! If you buy ONLY ours...... (*)" Actually, there are ways to fake out himem.sys but they are rather complicated to describe. Basically, you lose unless your are a sneaky programmer. Doug McDonald (*) the older ones still will fail for the same reason. But, of course, send us money and we will send you a new version that does work.
aaron@jessica.stanford.edu (Aaron Wallace) (10/27/90)
In article <1990Oct26.214912.19652@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: [ Question as to why have Himem/XMS deleted ] >Very simple: Microsoft did it that way to pimp out users of other companies >software. Himem.sys makes it impossible to use any software using >extended memory that was written earlier than it was. This means that >Microsoft is saying "Hah Hah!! You thought it was safe to buy other >companies products? Gotcha!!! We are Microsoft - you use our >products, then WE will prevent you from running other companies >products! If you buy ONLY ours...... (*)" Excuse me, but anyone can write an XMS-compliant program. And should. The alternatives are very ugly and would be impossible to implement in DOS- compatible "environments" such as OS/2 and Windows DOS boxes. The alternatives? Back-patch INT 15h to reflect how much memory you're claiming-- this works well when programs are run/quit in a LIFO manner, but otherwise is silly. Look for VDISK signs? Same problem. XMS allows for flexible memory management and should have been done years ago. It's a long-overdue solution to how to use that &#$*#$ extended memory, not a sinister plot to do in older programs. >Actually, there are ways to fake out himem.sys but they are >rather complicated to describe. Basically, you lose unless your >are a sneaky programmer. Maybe Microsoft could have written a program that tells HIMEM to revert to the braindead non-memory-management system, but that would only encourage the writing of more braindead programs or create havoc for SmartDrive once XMS disappears... Aaron Wallace
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (10/27/90)
In article <1990Oct26.225054.28224@portia.Stanford.EDU> aaron@jessica.stanford.edu (Aaron Wallace) writes: >In article <1990Oct26.214912.19652@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > >[ Question as to why have Himem/XMS deleted ] > >>Very simple: Microsoft did it that way to pimp out users of other companies >>software. Himem.sys makes it impossible to use any software using >>extended memory that was written earlier than it was. This means that >>Microsoft is saying "Hah Hah!! You thought it was safe to buy other >>companies products? Gotcha!!! We are Microsoft - you use our >>products, then WE will prevent you from running other companies >>products! If you buy ONLY ours...... (*)" > >Excuse me, but anyone can write an XMS-compliant program. Certainly, they can now. Its trivial. ***BUT THEY COULD NOT DO SO BEFORE THE SPEC FOR IT EXISTED!!!!!!*** The point is that this new thing ***BREAKS EXISTING PERFECTLY CORRECT PROGRAMS***. It is an ex post facto attempt to usurp extended memory. >The alternatives? Back-patch INT 15h to reflect how much memory you're >claiming-- >this works well when programs are run/quit in a LIFO manner, Yep, thats how you do it. but otherwise > >>Actually, there are ways to fake out himem.sys but they are >>rather complicated to describe. Basically, you lose unless your >>are a sneaky programmer. > >Maybe Microsoft could have written a program that tells HIMEM to revert to the >braindead non-memory-management system, Exactly - they should have allowed for the older method to still work. I am VERY adamant about this. Doug McDonald
ckinsman@eecs.wsu.edu (Chris Kinsman - EE major) (10/28/90)
In article <1990Oct26.195130.17719@cs.uoregon.edu> akm@cs.uoregon.edu (Anant Kartik Mithal) writes: >In article <90297.155820MUHRTH@DB0TUI11.BITNET> MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes: >>Nothing against the sophisticated memory management of himem.sys, but >>we use older software which needs extended memory and has no chance to >>communicate their needs via himem. Smalltalk V/286 for example. >>Is there a utility available which after invocation of windows, I mean, >>after leaving it, gives extended memory back for undiscplined programs? > >I actually don't understand why we need himem.sys at all. After all, >both 286 and 386 systems can address extended memory without a >problem (in protected mode), so why do we need to use himem? I >understood the logic for emm, but not xms. > The reason as I understand it is to enable programs other than windows to access extended memory. On the 386 at least you can only have 1 protected mode memory manager. HIMEM.SYS becomes this manager and will then dole out the extended memory to your various programs. If Windows was the protected mode memory manager no other programs would be able to access the memory unless they communicated with windows. Chris
ckinsman@eecs.wsu.edu (Chris Kinsman - EE major) (10/28/90)
In article <1990Oct27.005409.19884@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <1990Oct26.225054.28224@portia.Stanford.EDU> aaron@jessica.stanford.edu (Aaron Wallace) writes: >>In article <1990Oct26.214912.19652@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >> >>[ Question as to why have Himem/XMS deleted ] >> >>>Very simple: Microsoft did it that way to pimp out users of other companies >>>software. Himem.sys makes it impossible to use any software using >>>extended memory that was written earlier than it was. This means that >>>Microsoft is saying "Hah Hah!! You thought it was safe to buy other >>>companies products? Gotcha!!! We are Microsoft - you use our >>>products, then WE will prevent you from running other companies >>>products! If you buy ONLY ours...... (*)" >> >>Excuse me, but anyone can write an XMS-compliant program. >Certainly, they can now. Its trivial. ***BUT THEY COULD NOT DO >SO BEFORE THE SPEC FOR IT EXISTED!!!!!!*** The point is that this >new thing ***BREAKS EXISTING PERFECTLY CORRECT PROGRAMS***. >It is an ex post facto attempt to usurp extended memory. > > > >>The alternatives? Back-patch INT 15h to reflect how much memory you're >>claiming-- >>this works well when programs are run/quit in a LIFO manner, >Yep, thats how you do it. > >but otherwise >> >>>Actually, there are ways to fake out himem.sys but they are >>>rather complicated to describe. Basically, you lose unless your >>>are a sneaky programmer. >> >>Maybe Microsoft could have written a program that tells HIMEM to revert to the >>braindead non-memory-management system, > > > >Exactly - they should have allowed for the older method to still work. >I am VERY adamant about this. > It always amazes me as to how many adamant fools there are in this world! Did you also stick with LIM 3.2 because LIM 4.0 broke many existing packages? Sheezz I agree with the earlier post. HIMEM.SYS is something that should have been done a while ago. Just because it breaks existing programs is no reason to condemn it. I think that progress always causes some problems and people have to adjust. You have the choice. Use the older programs, use HIMEM.SYS , or get the older programs updated and use them with HIMEM.SYS. Chris