dsb@Rational.COM (David S. Bakin) (12/18/88)
I have a copy of Microsoft's XMS driver spec & disk. (This is the HIMEM driver which both allocates extended memory and lets a program run in 64K of memory "above the line".) The implementation notes say that it is incompatible with IBM's VDISK.SYS driver "and other drivers which use the VDISK scheme for allocating extended memory". So: What ramdisk software can I use that is compabible with HIMEM.SYS? Will Microsoft's own RAMDRIVE.SYS work? (I know Microsoft sent me the disk for free, but couldn't they have included a working ramdisk driver?) Thanks -- Dave ---------------------------------------------------------- Dave Bakin (408) 496-3600 c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197 Internet: dsb@rational.com Uucp: ...!uunet!igor!dsb
chasm@killer.DALLAS.TX.US (Charles Marslett) (12/19/88)
In article <499@igor.Rational.COM>, dsb@Rational.COM (David S. Bakin) writes: > I have a copy of Microsoft's XMS driver spec & disk. (This is the > HIMEM driver which both allocates extended memory and lets a program > run in 64K of memory "above the line".) The implementation notes > say that it is incompatible with IBM's VDISK.SYS driver "and other > drivers which use the VDISK scheme for allocating extended memory". > > So: What ramdisk software can I use that is compabible with HIMEM.SYS? > Will Microsoft's own RAMDRIVE.SYS work? Yep, and their cache program, they do all they can to keep you from running with any others. That's mostly self defense since a rabid cache program can do a fair amount of harm! > Thanks -- Dave Charles Marslett chasm@killer.dallas.tx.us
leefi@microsoft.UUCP (Lee Fisher) (12/19/88)
In article <499@igor.Rational.COM>, dsb@Rational.COM (David S. Bakin) writes: > > I have a copy of Microsoft's XMS driver spec & disk. (This is the > HIMEM driver which both allocates extended memory and lets a program > run in 64K of memory "above the line".) The implementation notes say > that it is incompatible with IBM's VDISK.SYS driver "and other > drivers which use the VDISK scheme for allocating extended memory". > So: What ramdisk software can I use that is compabible with > HIMEM.SYS? Will Microsoft's own RAMDRIVE.SYS work? (I know Microsoft > sent me the disk for free, but couldn't they have included a working > ramdisk driver?) Yes, Microsoft's RAMDRIVE.SYS will work when HIMEM.SYS is installed. So will versions of IBM's VDISK.SYS included with PC-DOS 4.00 or later. Earlier versions of VDISK.SYS, or programs that use the old-style VDISK extended memory allocation techniques will NOT work with HIMEM. There is a fundamental conflict in extended memory allocation. (The XMS specfication only says that it will not work with VDISK allocation schemes, but does not mention that IBM's VDISK allocation scheme changed in PC-DOS 4.00.) Here is a brief discussion on extended memory allocation techniques. It compares the method used by Microsoft products such as RAMDRIVE.SYS, SMARTDRV.SYS, and HIMEM.SYS, as well as IBM's VDISK.SYS, and discusses the allocation method change in VDISK.SYS in IBM PC-DOS Version 4.00. It is is targeted for understanding why the Microsoft XMS driver HIMEM.SYS will not work with the old-style VDISK extended memory allocation technique. Extended Memory Allocation: There are two popular techniques for allocating extended memory, referred to in this discussion as the "Top Down" and the "Bottom Up" methods. These names refer to the way in which the memory is allocated and used. The Top Down method allocates memory starting at the top of extended memory, working down to the bottom. In contrast, the Bottom Up method allocates memory in reverse order, starting from the bottom of extended memory. Bottom Up Allocation Method: The Bottom Up method allocates extended memory from the lower to higher addresses. This method is used by the IBM virtual disk driver VDISK.SYS included with IBM PC-DOS. (Note that IBM has changed its allocation strategy starting with IBM PC-DOS Version 4.00; see the Top Down discussion below for more details.) Most programs that use this method were inspired by VDISK.SYS and use an allocation strategy identical to that of VDISK. The source code for VDISK, VDISK.ASM, was included by IBM on the supplemental disk shipped with the IBM PC-DOS technical reference manual. IBM's VDISK method of controlling this memory is to create a control block that it uses for various purposes. One purpose of this block is to see how much extended memory is being used. This allocation method is difficult to use when multiple programs or drivers are trying to allocate extended memory, since only VDISK knows of its control block. This control block is located by looking at an offset of VDISK's ROM BIOS interrupt 19H interrupt handler. Thus, if another application also takes over interrupt 19H, it becomes difficult, if not impossible, to locate the VDISK control block. (For more information on how to emulate or coexist with the VDISK allocation method, refer to the VDISK.ASM program, included with IBM's PC-DOS technical reference.) Top Down Allocation Method: The Top Down allocation method allocates memory from higher to lower addresses. This method is used by the Microsoft virtual disk driver RAMDRIVE.SYS, included with MS-DOS. It is also used by other Microsoft drivers such as SMARTDRV.SYS and HIMEM.SYS. This method relies on the ROM BIOS interrupt 15H subfunction 88H, Get Extended Memory Size. This ROM BIOS service returns the number of kilobytes of extended memory available. The Top Down allocation method takes over this ROM BIOS subservice and, after allocating the memory that it needs for itself, returns a reduced value for any subsequent applications that query the amount of free extended memory. This method is very simple to implement compared to the control-block method used in the Bottom Up method. A drawback of this method is that it is hard to release extended memory. Only the last program that has allocated extended memory can free it (similar to a LIFO queue). This is not a major drawback, however, since most programs that use extended memory are device drivers that don't release the memory once they are installed. IBM, in the VDISK.SYS driver shipped with IBM PC-DOS Version 4.00, has changed its allocation strategy from the older Bottom Up method to the Top Down method. One implicit assumption of the Top Down allocation method is that the size reported by ROM BIOS interrupt 15H subservice 88H is of memory contiguous from 1 megabyte onward. XMS (eXtended Memory Specification): The XMS specification eliminates the OEM machine and CPU dependencies that plague software developers when trying to access extended memory. This specification defines a machine-independent method of allocating and accessing extended memory. Through an eXtended Memory Manager (XMM), extended memory is broken down into two logical components, the High Memory Area (HMA) and the Extended Memory Area (EMA). The High Memory Area is a 64K area of extended memory located at address FFFF:10h to FFFF:FFFFh (making it actually 64K - 16 bytes in size). An advantage of this area of memory is that, by manipulation of the A20 line of the 80286 or 80386 system, this area above 1 megabyte can be addressable in real (MS-DOS) mode, thus giving knowledgeable MS-DOS programs an extra 64K of memory that can be used to store code or data. The Extended Memory Area is the second logical subdivision of extended memory made by the XMM. This area is allocated in units called Extended Memory Blocks (EMBs) to programs. These blocks are easier to manipulate than manipulating extended memory directly without the help of the XMM. More Information: For more information on XMS memory, refer to the official specification, the "eXtended Memory Specification Version 2.0," jointly developed by Microsoft Corporation, Lotus Development Corporation, Intel Corporation, and AST Research, Inc., which is available free from Microsoft by calling (800) 426-9400. (Make sure that you ask for the supplemental XMS diskette, too.) The contents of the XMS diskette, which contains a machine readable copy of the XMS specification, normally named XMS.ARC or XMS20.ARC, is available on many information systems and bulletin board systems, such as the Microsoft OnLine Software Library. [Thanks to Gregory Hicks and Keith Peterson, this should be available on SIMTEL20 shortly...] For more information on the High Memory Area (HMA) subsection of XMS memory, refer to the periodical "Microsoft Systems Journal", volume 10, number 6, November, 1988, in the article entitled "The High Memory Area: 64KB More Memory in Real Mode", by Chip Anderson, pages 53-57. For more information on how to emulate or coexist with the VDISK allocation method, refer to the VDISK.ASM program, included with IBM's PC-DOS technical reference, with versions of IBM PC-DOS 3.X and above. For more information on the memory services provided by the ROM BIOS of IBM PS/2 and compatible OEM systems, refer to the "IBM PS/2 and PC BIOS Interface Technical Reference," part number 68X2260, available from IBM by calling (800) IBM-PCTB. (Another reference that contains similar material is the Microsoft Press book "Programmer's Quick Reference Series: IBM ROM BIOS," by Ray Duncan, ISBN 1-55615-135-7.) -- Lee Fisher - Microsoft Corp., Redmond WA - leefi@microsof.UUCP leefi%microsof@uw-beaver.MIL - leefi@microsof.beaver.washington.EDU {uw-beaver,decvax,decwrl,intelca,sco,sun,trsvax,uunet}!microsof!leefi Ka nama kaa lajerama. My opinions are obviously my own responsibility.
mlawless@ncrwic.Wichita.NCR.COM (Mike Lawless) (12/20/88)
In article <6478@killer.DALLAS.TX.US> chasm@killer.DALLAS.TX.US (Charles Marsl >In article <499@igor.Rational.COM>, dsb@Rational.COM (David S. Bakin) writes: > > So: What ramdisk software can I use that is compabible with HIMEM.SYS? > > Will Microsoft's own RAMDRIVE.SYS work? > >Yep, and their cache program, they do all they can to keep you from >running with any others. That's mostly self defense since a rabid >cache program can do a fair amount of harm! I know of at least one non-MS cache that will work with HIMEM.SYS, but you have to be careful how you set it up. The program is Super PC-Kwik; I wanted to continue using it rather that SMARTDRV.SYS, because I also use a spooler which piggybacks on top of the cache, and dynamically shares the same memory block that is allocated to the cache. Also, the cache has a background write- through to disk on writes, which speeds write performance as well as reads. The trick to setting it up is to make sure that it is installed before running Microsoft's SETUP.EXE (contrary to all the warnings you have heard). Windows 2.1 expects the allocation of extended memory to be the same as it was at setup time, and gives warning messages if not, and disables HIMEM. Also, avoid using MEMSET.EXE. It will try to force you to install SMARTDRV.SYS. If you want to use RAMDRIVE.SYS (and this is as good as any RAM disk I have seen), you can read the documentation (I think it is in a README file rather than the manual, but I am not sure) and add the necessary DEVICE= line to CONFIG.SYS manually. I have been using this setup for several months now with not a single problem (once I figured out how to get everything coexisting). -- Mike Lawless, NCR E&M Wichita, Box 20 (316) 636-8666 (NCR: 654-8666) 3718 N. Rock Road, Wichita, KS 67226 Mike.Lawless@Wichita.NCR.COM {ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!Mike.Lawless {sdcsvax,cbatt,dcdwest,nosc.ARPA}!ncr-sd!ncrwic!Mike.Lawless
ray@micomvax.UUCP (Ray Dunn) (01/04/89)
In article <6478@killer.DALLAS.TX.US> chasm@killer.DALLAS.TX.US (Charles Marsl >In article <499@igor.Rational.COM>, dsb@Rational.COM (David S. Bakin) writes: > > So: What ramdisk software can I use that is compabible with HIMEM.SYS? > > Will Microsoft's own RAMDRIVE.SYS work? > >Yep, and their cache program, they do all they can to keep you from >running with any others. That's mostly self defense since a rabid >cache program can do a fair amount of harm! Correct me please if I am wrong, but although RAMDRIVE.SYS *or* SMARTDRV.SYS will *co-exist* with HIMEM.SYS under MSDOS, neither *use* HIMEM.SYS in their allocation or management of the extended memory. They work with HIMEM.SYS only because at install time these drivers allocate their memory from the end of the available extended memory opposite to that used by HIMEM, i.e. they have been made to work despite the other's presence. When using *expanded* memory however, they *do* use LIM 4.0 to allocate and manage their memory requirements (the Correct Way). A sign that XMS has yet to mature in the same way as LIM? Frankly, I think that the support of *both* extended *and* expanded memory by Microsoft in DOS and its utilities is a retrograde step. Life is becoming more and more complicated for the application program writer on the PC. We now have x video standards and y memory management schemes all which must be supported to create a successful product. [Do I hear someone say "Gosh standards are A Good Thing, lets have another one!"] The only real thing the PC had going for it was a small set of universal standards. Unless something is done to streamline and minimize the current proliferation of these "standards" the PC will collapse under its own weight. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
rogerson@PEDEV.Columbia.NCR.COM (rogerson) (01/06/89)
Isn't Windows an attempt to isolate the application programer from the hardware? You do not have to worry about WHICH card a system has, but only the resolution. You also did not have to worry about many other hardware comptiblity problems. Windows programs run just fine on a Tandy 2000 which IS ONLY MSDOS compatible and it not PC compatible! -----Dale Rogerson-----
philba@microsoft.UUCP (Phil Barrett) (01/07/89)
I am only speaking for myself, not Microsoft but the point of XMS isn't to create an unnecessary standard but rather to provide a way for applications to co-operatively use extended memory AND provide a machine independent mechanism for accessing it. The simple fact is that there are a lot of machines out there with different mechanisms for switching A20 and switching modes (real <--> protected). An additional problem occurs with the top-down allocation scheme in that there is no way to free up space (if you aren't the last guy on the Int 15h chain). XMS addresses these. As to the complaint that this is a useless standard, lots of real mode apps, drivers, TSRs will use extended memory (particularly for the High Memory Area -- 1-st 64K-16 bytes of extended memory). I know of at least 6 that are (or will soon be) available. This would lead to chaos if not dealt with in standard fashion. That is why I believe that the XMS spec is a good thing. Phil Barrett Microsoft Corp.