satam@ecs.umass.edu (Kirtikumar Satam, ECE, UMASS Amherst) (08/29/90)
Last week I posted a query on the newsgroups comp.sys.IBM.pc, comp.sys.ibm.pc.programmer and comp.windows.ms regarding "how to put a large program on a 386 under DOS". Before giving out the responses, I would like to briefly represent the problem. I have one application (originally developed on VAX/VMS) which needs to be ported on 386 box under DOS. Now, the code section of the program is less than 100K, stack of around 32K and a huge data space of anywhere between 700K to 1.5M. Now, this data area is not a large array or some orderly data structures, but rather contains general data. Now, a natural question is then why the data area is so big?. Well, I will try to explain the need of such data space. The application is basically a simulation package which simulates networks with OSI layer software. It simulates the behavior of each node separately using the same code. In order to distinguish between different processes running on different nodes, it keeps separate stack of each process and uses context switching like techniques to schedule the processes. Note here that the variables are also created on the process' "stack". Since, there can be 100/200 processes "running", assuming a stack size of 4k per each process, the requirement of the "stack areas" is above 800k. Clearly, such a huge data can not be accommodated in a normal program stack. Thus, the application keeps the copies of all these "stack" in its data area and hence this huge size. Note here that for the OS, the simulation is just one task and the execution of multiple threads inside the simulation is entirely hidden from the OS. Now, my problem is to put this program on 386 system under DOS without much (ideally nil) changes in the code. Clearly, I need something that will allow me access 4Mb of RAM on the 386 box without any elaborate mechanism being done by myself. That it, I need a platform above normal DOS allows me to use the flat addressing of 386 including and above 640K as if there is no distinction at all. Although, I can use OS/2 or XENIX/UNIX, I'm constrained to use only DOS. Now the possible solutions suggested were 1. Using DOS extender. This needs me to make specific INT calls to use the facility which means a lot of changes to code which is not acceptable. 2. Using EMS. Not possible using directly due to same reason. 3. Using WINDOWS 3.0 which gives the platform I am looking for. I was not aware of how to do it in Windows 3.0, and hence was my previous post. Below, I give a summary of replies that I received. This subject is still open for discussion and at the end I will quote some lines from the August issue of Byte on which expert comments are welcome. -------------------------------------------------------------------------- REPLY 1: FROM: A.C.Beresford@cc.flinders.oz.au >You need a 80386 Cpu, > Phar Lap Dos-extender >Pascal compiler that knows its working >with Dos extender , see Microway ads >in BYTE or Dr. Dobbs and other places. >cheers from Down under. >I did a job last month that had a similar problem >with just a karge data array. It needed to be written in >Fortran and manipulated 512by 512 8 bit valku images. > >Tony Beresford Thanks, but could you furnish more details? is "Phar-Lap DOS-extender" from Mircoway? Which PASCAL compiler knows that it is working with DOS-ex? Are all DOS-ex are similar? -satam >You can purchase Phar-Lap Dos extender from Microway, >although it may be cheaper from some of the other mail >order places. In regards to 32-bit Pascal compilers, >they are usually advertised as such, so it is quite >clear . They are a different programme than the MS-DOs >compiler and usually advertised distinctly. Microway >sell one made by NDP. Dos extenders are similar but >different in detail, apart from PharLap there is VM386 >and a couple of others. Look up Dr. Dobbs last year >for comparison between them --------------------------------------------------------------------------- REPLY 2: FROM: turnbull@alpha.ces.cwru.edu >If you are using Turbo Pascal 5.5 then Object Professional from >Turbo Power software allows arrays up the size of EMS memory or >32 M if you use disk swapping. Similar packages probably exist for other >Pascals, although I don't know of them. >John. Could you furnish some more details? what exactly is "object professional" from "Turbo Power s/w", some package from Borland? Turbo PASCAL is fine with me, but I don't get the point of "using disk swapping"? who decides that? Is it a compiler directive or do I have to incorporate something into my code? -satam >"Object Professional" is a package from a company called Turbo Power. > >The Address of Turbo Power is > P.O. Box 66747 > Scotts Valley, CA 95066 > >Object Professional was looked at in the September '90 issue of Dr. Dobb's. > >You can choose between RAM , EMS or virtual arrays. Under DOS the largest >virtual array will be 32Meg, the other types will depend on the memory >available. It can also choose which type is most suitable if wanted. > >Hope this clarifies things a bit > >John ---------------------------------------------------------------------------- REPLY 3: FROM: carlw@xlnvax.novell.com > Microsoft C allows the use of huge arrays, data in larger than >64K chunks. Windows 3 provides a large 'global heap' to allocate chunks >from. In Win 3 code segments can be made movable and discardable using >1 statement in a .def file. However writing a user interface in Win 3 >is harder than using character output. Remember: 'No code is portable >until it's been ported'! > >--- >Carl Wohlforth, 2180 Fortune Dr., San Jose Ca., 95131 Could you please explain in more details about "global heap" as provided by WIN 3.0? Can any Microsoft C work on it? As I indicated, my problem is more of a huge data segment and a comparatively small code. And my program has no user interaction. There reason for looking towards WIN 3.0 is to break the barrier of 1M memory limit "transparently" without modifying the code. That is, a s/w driver which allows programs to access the extended memory as if it is a linear memory rather than doing page management itself. -satam >Hi, > >> Could you please explain in more details about "global heap" as provided >> by WIN 3.0? Can any Microsoft C work on it? > > I use MSC 5.1, don't know about earlier versions since compilers >need to be windows aware. Huge pointers point to data larger than 64K. >I haven't used them for more than about 100K. The global heap is a >linear address space that windows uses. This includes available RAM >and swap space on the disk. I know what you want to do, just haven't >tried it myself. > >> As I indicated, my problem is more of a huge data segment and a >> comparatively small code. And my program has no user interaction. >> There reason for looking towards WIN 3.0 is to break the barrier of 1M >> memory limit "transparently" without modifying the code. That is, a > > This may (or may not, but I don't know of an easier way) be the >easiest way to access large amounts of linear memory on a DOS computer, >but you will definitely have to do some code changes even if you don't >do much of a user interface. Also lots of expensive software would >be needed, such as a recent MSC compiler and the SDK. > >> s/w driver which allows programs to access the extended memory as if >> it is a linear memory rather than doing page management itself. >> >> -satam >> >> > Good luck! >> >> thanks, >> Just a small query. >> what is "SDK"? you mentioned it alongwith MSC compiler. > > The software developers toolkit. It costs alot (I'm not sure >how much), Windows costs $99 around here, the compililer costs alot >also. Fortunately my employer buys this stuff for me :-) ---------------------------------------------------------------------------- REPLY 4: FROM: brianf@umd5.umd.edu > The first problem you will run into is Windows doesn't support multi-thread >programs. You could work around this using timers and Windows messaging but >this would require a fair amount of work on your part and a good understanding >of windows. > > Windows does allow you to allocate several megs of memory if its available >but it is meant for you data not your stack. Most well designed Windows apps. >have a single data segment of less than 64k which contains your stack, global >and local variables. Large memory objects are allocated with "GlobalAloc" >which returns a "handle" to the memory which is used by the routines >"GlobalLock" and "GlobalUnlock" to actually get the pointers to the object. >This is a hangover from Windows 2.x and 1.x to allows better use of memory >when multi-megs of memory weren't available. > > >Hope this helps. > >Brian Farmer >brianf@umd5.umd.edu > Since I'm hiding the use of multi-thread execution from the OS, I don't think that will be a problem. As long as the OS allows the user to fiddle around with its own stack pointer, any OS should be able to support this. Also, as I mentioned in my net posting that "I'm keeping the *stacks* of the processes' in the *data* area of my program". I bring them to the actual stack only when I "go into" the context of that process. My actual stack is small and can easily be fitted in 64K. Also, I need absolutely transparent memory access to the underlying memory. I'm not very clear about what you have mentioned as "globalAloc" etc. Could you please enlighten me on that? -satam ---------------------------------------------------------------------------- REPLY 5: FROM: goodearl@world.std.com I believe that OS/2 would be much better suited to what you intend. It supports threads, which windows does not, and it supports large (and I believe huge) model programs, which windows does not do gracefully. If, however, that is not a possibility, then you could do it with windows by making each "process" a separate instance of the application and calling GlobalAlloc when each "process" starts. There is also the ability to write flat memory model Dynamic Link Libraries (no segmentation, 32 bit address registers) if you're running on a 386. I'm not really familiar with the constraints, though. Also, for more information, the SDK manuals should be available in any good technical bookstore. ---------------------------------------------------------------------------- Now, the quote from BYTE mag. ISSUE AUGUST 1990. Page: 133 thru' 140, by Micheal Geary. Title: A Long and Winding Road. page 133, middle column. >The 386 (and i486) has additional addressing modes, notably the 32-bit >flat mode. Windows 3.0 applications can, with some extra work, use some >of the 386 addressing modes,but for the ....... How to use that 32-bit flat mode?? What is this extra work? About Windows 3.0 enhanced 386 mode: Page 140, middle column. >It's interesting to note that even though Windows applications, and most >of Windows itself, run in the 16-bit segmented memory model, the >WIN386.EXE control program and the virtual device driver that it uses >run in a single flat-mode 32-bit segment. And, the last column in the same page, >It is possible for a Windows application to go to some extra work and >have parts of its code run in true 32-bit segments, but the simplicity >of the flat model is still beyond Windows' reach. With due apologies to Micheal Geary for quoting him rather out of context and without his or Byte's permission, I would like to know how this 32-bit flat addressing can be achieved? Just by setting some compiler option for Windows based compiler? Thanks a lot. - Satam. ------------------------------------------------------------------------ Kirtikumar "Mumbaichaa" Satam INTERNET : satam@jambo.ecs.umass.edu BITNET : satam@umaecs.bitnet 19 Puffton Village, Amherst, MA 01002 Tel# 413-549-0848 ------------------------------------------------------------------------