From owner-freebsd-emulation Sun Aug 31 08:14:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA07330 for emulation-outgoing; Sun, 31 Aug 1997 08:14:24 -0700 (PDT) Received: from ohm.ingsala.unal.edu.co ([168.176.15.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA07325 for ; Sun, 31 Aug 1997 08:14:21 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co (unalmodem06.usc.unal.edu.co [168.176.3.36]) by ohm.ingsala.unal.edu.co (8.8.5/8.8.5) with SMTP id KAA01054 for ; Sun, 31 Aug 1997 10:15:50 -0500 (COT) Message-ID: <3409A56F.7EA0@fps.biblos.unal.edu.co> Date: Sun, 31 Aug 1997 10:10:07 -0700 From: "Pedro Giffuni S," Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.01Gold [it] (Win16; I) MIME-Version: 1.0 To: emulation@FreeBSD.org Subject: DOSemu Alterer Novices Guide and technical guide Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Howdy, It seems like DOSEMU is so messy, they had to build a manual for hacking it. It is in a primitive state, but here it is: http://www.uel.ac.uk/pers/A.Macdonald/dosemu/dang/DANG.html The DOSemu technical guide seems more interesting: http://www.suse.com/~dosemu/doc-0.67/README-tech.html (specially the VM86PLUS part) It may also help knowing that they plan to include the FreeDOS kernel in a future release. cheers, Pedro. From owner-freebsd-emulation Sun Aug 31 08:52:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA08414 for emulation-outgoing; Sun, 31 Aug 1997 08:52:26 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA08409 for ; Sun, 31 Aug 1997 08:52:17 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA03007; Mon, 1 Sep 1997 01:20:36 +0930 (CST) Message-Id: <199708311550.BAA03007@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Pedro Giffuni S," cc: emulation@FreeBSD.org Subject: Re: DOSemu Alterer Novices Guide and technical guide In-reply-to: Your message of "Sun, 31 Aug 1997 10:10:07 MST." <3409A56F.7EA0@fps.biblos.unal.edu.co> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Sep 1997 01:20:33 +0930 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Howdy, > It seems like DOSEMU is so messy, they had to build a manual for hacking > it. It is in a primitive state, but here it is: > http://www.uel.ac.uk/pers/A.Macdonald/dosemu/dang/DANG.html It has been in this state for a long time. DANG used to largely depend on specially-formatted comments in the code. > The DOSemu technical guide seems more interesting: > http://www.suse.com/~dosemu/doc-0.67/README-tech.html > (specially the VM86PLUS part) > It may also help knowing that they plan to include the FreeDOS kernel in > a future release. They were planning to do this a year ago, at about the same time that I was evaluating FreeDOS for use with doscmd. The major problem with FreeDOS is that the DOS-C kernel had *no* networking support whatsoever, and its internal structures (eg. the LoL) were completely incompatible with those of MS-DOS. A slightly better bet would be the Caldera OpenDOS, if they ever get around to releasing the source under usable conditions. As it is, the binary release of ODOS works quite nicely. mike From owner-freebsd-emulation Sun Aug 31 12:14:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14144 for emulation-outgoing; Sun, 31 Aug 1997 12:14:50 -0700 (PDT) Received: from ohm.ingsala.unal.edu.co ([168.176.15.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA14139 for ; Sun, 31 Aug 1997 12:14:46 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co (unalmodem15.usc.unal.edu.co [168.176.3.45]) by ohm.ingsala.unal.edu.co (8.8.5/8.8.5) with SMTP id OAA01223; Sun, 31 Aug 1997 14:16:02 -0500 (COT) Message-ID: <3409DDBB.4C96@fps.biblos.unal.edu.co> Date: Sun, 31 Aug 1997 14:10:19 -0700 From: "Pedro Giffuni S," Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.01Gold [it] (Win16; I) MIME-Version: 1.0 To: Mike Smith CC: emulation@FreeBSD.org Subject: Re: DOSemu Alterer Novices Guide and technical guide References: <199708311550.BAA03007@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > They were planning to do this a year ago, at about the same time that I > was evaluating FreeDOS for use with doscmd. The major problem with > FreeDOS is that the DOS-C kernel had *no* networking support > whatsoever, and its internal structures (eg. the LoL) were completely > incompatible with those of MS-DOS. A slightly better bet would be the > Caldera OpenDOS, if they ever get around to releasing the source under > usable conditions. > I think what they are trying to do now, from what Pat Villani shared, is embed the C-kernel in order not to require redirector. Perhaps something like doscmd does so that you don't need to boot. > As it is, the binary release of ODOS works quite nicely. > Once again their license sucks, and you need like four compilers to build the kernel, but ODOS is an excellent testing ground. cheers, Pedro. From owner-freebsd-emulation Sun Aug 31 19:22:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00426 for emulation-outgoing; Sun, 31 Aug 1997 19:22:05 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00421 for ; Sun, 31 Aug 1997 19:22:00 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id LAA19644 for ; Mon, 1 Sep 1997 11:51:57 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00299; Mon, 1 Sep 1997 11:47:44 +0930 (CST) Message-Id: <199709010217.LAA00299@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Pedro Giffuni S," cc: Mike Smith , emulation@FreeBSD.org Subject: Re: DOSemu Alterer Novices Guide and technical guide In-reply-to: Your message of "Sun, 31 Aug 1997 14:10:19 MST." <3409DDBB.4C96@fps.biblos.unal.edu.co> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Sep 1997 11:47:42 +0930 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I think what they are trying to do now, from what Pat Villani shared, is > embed the C-kernel in order not to require redirector. Perhaps something > like doscmd does so that you don't need to boot. Huh? This isn't the problem so much as DOS-C doesn't support the concept of anything other than block-addressed media. You can't tell it about a drive that doesn't exist as a BIOS device, so you can't catch file operations on such a device (because it doesn't exist). The DOS emulation that doscmd does is at a *much* higher level. "embedding" a DOS kernel wouldn't help much there at all - you'd just about have to gut it completely to make it worthwhile. mike From owner-freebsd-emulation Sun Aug 31 19:47:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA01282 for emulation-outgoing; Sun, 31 Aug 1997 19:47:01 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA01274 for ; Sun, 31 Aug 1997 19:46:56 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id MAA19996 for ; Mon, 1 Sep 1997 12:16:43 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00384; Mon, 1 Sep 1997 12:09:22 +0930 (CST) Message-Id: <199709010239.MAA00384@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jonathan Lemon cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= , j_mini@efn.org, karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-reply-to: Your message of "Tue, 12 Aug 1997 19:50:34 EST." <19970812195034.31150@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 01 Sep 1997 12:09:21 +0930 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id TAA01277 Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (replying to an old message) > How would a vm86() interface be used? I don't think that just passing in > the i386 registers and an interrupt number to call would be enough; I think > that some of the INT calls want to pass data back and forth via low-memory > areas. In most cases, I see this interface being used by other kernel services to interact with BIOS functionality that's not available otherwise. Off the top of my head, the big consumers are likely to be : - Video control; access to the full set of VESA functionality - Resource management (especially the ECSD parameter space) > If that is the case, then the address space has to exist before and after > the call; probably the easiest way would be for the calling process to create > the address space and then pass it to the vm86 thread. Otherwise, the thread > could just attach to kernel area around 'atdevbase' I would, I guess, like to be able to say : - create vm86 context foo with memory size X, default layout, etc. - populate specific components of X - invoke in vm86 context foo - access X - destroy vm86 context foo At the bare minimum, the context should comprise the address space the vm86 thread has access to, the register state, I/O permissions, etc. It should be possible to copy code into the address space, or to request a set of "canned" operations. Perhaps pseudocode speaks this better : foo = vm86_create_context(64 * 1024, VM86_NOIOPERM, ...); VM86_INIT(foo); VM86_REG(foo, cx, 0x35); VM86_INTR(foo, 0x10, 0x55, 0x01); VM86_TERMINATE(foo); vm86_run_context(foo, ...); ie. create a context, initialise it for code insertion, insert code to set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor function 0x01, insert code to terminate the context, and then run the code in it. It might be desirable to supply some form of time limit in the run_context function to trap runaway invocations; that's probably fluff though. Being able to run it in parallel, and query it for status rather than blocking until it completes would be _very_ useful, as I'm sure you can imagine 8) > My current thinking (for the kernel) is: > > - create a 'vm86daemon', which maps in the lower physical 1M into > it's address space. Hmm. With the idea above, you would map the memory region belonging to the context at the bottom of the address space, and the ISA hole suitably, and leave most of the rest unmapped. I don't think too many callers will need an entire 1M mapped. > - submit requests to this thread, which puts the caller to sleep > until the request completes. I would be inclined to try to support more than one vm86 thread at once, with the possibility of asynch execution and notification (or even just blatant status polling). > Am I on the right track here, or am I totally off base? Sounds pretty groovy to me! mike From owner-freebsd-emulation Sun Aug 31 19:53:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA01536 for emulation-outgoing; Sun, 31 Aug 1997 19:53:54 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA01529 for ; Sun, 31 Aug 1997 19:53:50 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id MAA20124 for ; Mon, 1 Sep 1997 12:23:46 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00432; Mon, 1 Sep 1997 12:20:35 +0930 (CST) Message-Id: <199709010250.MAA00432@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stephen Milley cc: emulation@freebsd.org Subject: Re: Dos Emulation In-reply-to: Your message of "Wed, 30 Jul 1997 02:46:51 -0400." <1.5.4.32.19970730064651.0068f808@waterw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Sep 1997 12:20:34 +0930 From: Mike Smith Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I would like to contribute some work into allowing Dos executables to work > under FreeBSD. I have novice(but, not advanced) Dos knowledge, meaning that > I have made many programs in Dos, and know some of its limitations and I've > been under many compilers under that OS. However, I would like to strongly > support the FreeBBS software, whenever possible, and learn alot of things at > the same time. I am also good at reverse engineering, so I think I would be > a good programmer at doing Dos emulation, if that is what the FreeBSD > terminology calls it(I know it's called DOSEMU in Linux). Thanks, and e-mail > me if you think I am qualified for coding this. :-) Hi Stephen; sorry about the delay in getting back to you. We're naturally more than happy to have people interested in supporting DOS emulation on FreeBSD; regardless of your hacker studliness there's plenty of useful work that you can do. Discussion on this work mostly occurs on the FreeBSD emulation mailing list (emulation@freebsd.org), to which you should subscribe if you want to get involved. At the moment, the current state of the art is the 'doscmd' program, which is a part of FreeBSD-current. You will need to be running -current if you want to get heavily involved in this, and we'd be quite happy to help get you up to speed there. What sort of things would you like to work on? Just off the top of my head, the following need some attention : - doscmd's built-in DOS emulation isn't terribly wonderful; it falls far short of getting it "right" in many places, and needs an audit. - The video BIOS/interface code needs a serious rewrite; we need a modular design which allows either a tty-style interface using curses or an X window to be used, with appropriate VGA emulation, etc. - The network redirector is "OK" as far as it goes, but also falls far short of being perfect. - A packet-driver emulator would be very useful, so that DOS programs could interact with the network. I have code for the PCEMU emulator which provides a pseudo-interface on the BSD side of things which looks like a private network between the BSD system and the virtual DOS machine; this would be an excellent place to start. As well as this, documentation, installation procedures (getting started, etc.), or even just a functionality audit would be very useful. If you think you can, and want to, help with any of this, just get into it! Ask us questions, pester for details, whatever you need to get the job done. mike From owner-freebsd-emulation Sun Aug 31 21:13:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05134 for emulation-outgoing; Sun, 31 Aug 1997 21:13:04 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05129 for ; Sun, 31 Aug 1997 21:12:55 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id VAA04692; Sun, 31 Aug 1997 21:14:39 -0700 (PDT) Message-ID: <19970831211438.52861@micron.efn.org> Date: Sun, 31 Aug 1997 21:14:39 -0700 From: Jonathan Mini To: Mike Smith Cc: Jonathan Lemon , =?iso-8859-1?Q?S=F8ren_Schmidt?= , karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970812195034.31150@right.PCS> <199709010239.MAA00384@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199709010239.MAA00384@word.smith.net.au>; from Mike Smith on Mon, Sep 01, 1997 at 12:09:21PM +0930 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith stands accused of saying : > In most cases, I see this interface being used by other kernel services > to interact with BIOS functionality that's not available otherwise. > Off the top of my head, the big consumers are likely to be : > > - Video control; access to the full set of VESA functionality > - Resource management (especially the ECSD parameter space) VESA is big on my list. The main reason I want this support is that I am making a version of the FreeBSD kernel which will execute as a DPMI application. My final goal is that a user will be able to open a DOS box in his Win95 (or similar) desktop machine and run my application. My 'application' will act as an extender for a copy of my perverted FreeBSD kernel which will then run the proper process as init. In the meantime, I have a lot of work ahead of me. My first step is to make "devices" that use the BIOS and other similar blocks of code (such as Win95) in order to do common things such as access the hard drive(s), etc. My first milestone will be to have a kernel which will use the BIOS for all disk i/o. > I would, I guess, like to be able to say : > > - create vm86 context foo with memory size X, default layout, etc. > - populate specific components of X > - invoke in vm86 context foo > - access X > - destroy vm86 context foo > > At the bare minimum, the context should comprise the address space the > vm86 thread has access to, the register state, I/O permissions, etc. > It should be possible to copy code into the address space, or to > request a set of "canned" operations. Perhaps pseudocode speaks this > better : > > foo = vm86_create_context(64 * 1024, VM86_NOIOPERM, ...); > VM86_INIT(foo); > VM86_REG(foo, cx, 0x35); > VM86_INTR(foo, 0x10, 0x55, 0x01); > VM86_TERMINATE(foo); > vm86_run_context(foo, ...); > > ie. create a context, initialise it for code insertion, insert code to > set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor > function 0x01, insert code to terminate the context, and then run the > code in it. It might be desirable to supply some form of time limit in > the run_context function to trap runaway invocations; that's probably > fluff though. Being able to run it in parallel, and query it for > status rather than blocking until it completes would be _very_ useful, > as I'm sure you can imagine 8) Hmm. What I had in mind was something similar to a micro-kernel approach, where a vm86 context would be created, the proper memory addesses mapped into it, and then a piece of real mode code would be copies (or mapped) into the context, and the kernel would manage several pages of code to do various things. IMO, this seems to be more efficient than above, however, unless FreeBSD gets a version of gcc to output real mode code, my method dies in flames. (I have access to several real mode compilers, but they are all comemrcial) I know that a real mode version of gcc is possible -- Minix uses gcc, and it runs under Real mode. (Minix/386 doesn't, but the XT version does) > > My current thinking (for the kernel) is: > > > > - create a 'vm86daemon', which maps in the lower physical 1M into > > it's address space. > > Hmm. With the idea above, you would map the memory region belonging to > the context at the bottom of the address space, and the ISA hole > suitably, and leave most of the rest unmapped. I don't think too many > callers will need an entire 1M mapped. Better to create a mappign for each instance, because that way you can "map" sections of code into the region when you need it. Mapping an entire 640k block would be a Bad Idea, since it eats a good chunk of physical memory from VM space. > > - submit requests to this thread, which puts the caller to sleep > > until the request completes. > > I would be inclined to try to support more than one vm86 thread at > once, with the possibility of asynch execution and notification (or > even just blatant status polling). I would like to have that supprot also, but rember that the BIOS specification is not re-entrant, and I know of a lot of BIOSes (and BIOS emulators) that will crash if reentrance is attempted. > > Am I on the right track here, or am I totally off base? > > Sounds pretty groovy to me! > > mike > -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405 From owner-freebsd-emulation Sun Aug 31 21:54:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06497 for emulation-outgoing; Sun, 31 Aug 1997 21:54:25 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06421 for ; Sun, 31 Aug 1997 21:50:56 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id OAA21921 for ; Mon, 1 Sep 1997 14:20:49 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00750; Mon, 1 Sep 1997 14:11:57 +0930 (CST) Message-Id: <199709010441.OAA00750@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jonathan Mini cc: Mike Smith , Jonathan Lemon , =?iso-8859-1?Q?S=F8ren_Schmidt?= , karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-reply-to: Your message of "Sun, 31 Aug 1997 21:14:39 MST." <19970831211438.52861@micron.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Sep 1997 14:11:57 +0930 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ie. create a context, initialise it for code insertion, insert code to > > set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor > > function 0x01, insert code to terminate the context, and then run the > > code in it. It might be desirable to supply some form of time limit in > > the run_context function to trap runaway invocations; that's probably > > fluff though. Being able to run it in parallel, and query it for > > status rather than blocking until it completes would be _very_ useful, > > as I'm sure you can imagine 8) > > Hmm. What I had in mind was something similar to a micro-kernel approach, > where a vm86 context would be created, the proper memory addesses mapped into > it, and then a piece of real mode code would be copies (or mapped) into the > context, and the kernel would manage several pages of code to do various > things. IMO, this seems to be more efficient than above, The approach I proposed certainly doesn't preclude copying your own slab of code into the vm86 context; I was just proposing that in addition to that, there should be some macros which know how to append trivial code fragments in order to make writing and reading such callers easier. > however, unless > FreeBSD gets a version of gcc to output real mode code, my method dies in > flames. (I have access to several real mode compilers, but they are all > comemrcial) ports/devel/bcc > I know that a real mode version of gcc is possible -- Minix uses gcc, and it > runs under Real mode. (Minix/386 doesn't, but the XT version does) You are mistaken. The Minix cc for the x86 is *not* gcc. gcc is available for the 68k and i386 Minices however. > > I would be inclined to try to support more than one vm86 thread at > > once, with the possibility of asynch execution and notification (or > > even just blatant status polling). > > I would like to have that supprot also, but rember that the BIOS > specification is not re-entrant, and I know of a lot of BIOSes (and BIOS > emulators) that will crash if reentrance is attempted. It certainly makes no sense to attempt to reenter the video BIOS, but in at least the trivial sense there is nothing stopping me calling, say, an ESCD function in one virtual x86 context while the video BIOS is being called in another; remember that they are operating in distinct virtual contexts, where the only risk of conflict is in the I/O domain. mike From owner-freebsd-emulation Mon Sep 1 02:40:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA16967 for emulation-outgoing; Mon, 1 Sep 1997 02:40:08 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA16947 for ; Mon, 1 Sep 1997 02:40:01 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id CAA05623; Mon, 1 Sep 1997 02:42:18 -0700 (PDT) Message-ID: <19970901024217.20763@micron.efn.org> Date: Mon, 1 Sep 1997 02:42:17 -0700 From: Jonathan Mini To: Mike Smith Cc: Jonathan Lemon , =?iso-8859-1?Q?S=F8ren_Schmidt?= , karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970831211438.52861@micron.efn.org> <199709010441.OAA00750@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199709010441.OAA00750@word.smith.net.au>; from Mike Smith on Mon, Sep 01, 1997 at 02:11:57PM +0930 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith stands accused of saying : > > > ie. create a context, initialise it for code insertion, insert code to > > > set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor > > > function 0x01, insert code to terminate the context, and then run the > > > code in it. It might be desirable to supply some form of time limit in > > > the run_context function to trap runaway invocations; that's probably > > > fluff though. Being able to run it in parallel, and query it for > > > status rather than blocking until it completes would be _very_ useful, > > > as I'm sure you can imagine 8) > > > > Hmm. What I had in mind was something similar to a micro-kernel approach, > > where a vm86 context would be created, the proper memory addesses mapped into > > it, and then a piece of real mode code would be copies (or mapped) into the > > context, and the kernel would manage several pages of code to do various > > things. IMO, this seems to be more efficient than above, > > The approach I proposed certainly doesn't preclude copying your own > slab of code into the vm86 context; I was just proposing that in > addition to that, there should be some macros which know how to append > trivial code fragments in order to make writing and reading such > callers easier. True. Guess I wasn't thinking. > > however, unless > > FreeBSD gets a version of gcc to output real mode code, my method dies in > > flames. (I have access to several real mode compilers, but they are all > > comemrcial) > > ports/devel/bcc Cool. :) > > I know that a real mode version of gcc is possible -- Minix uses gcc, and it > > runs under Real mode. (Minix/386 doesn't, but the XT version does) > > You are mistaken. The Minix cc for the x86 is *not* gcc. gcc is > available for the 68k and i386 Minices however. Oh. I seem to rember discussion about it, perhaps this was discussion over Minix/i386. > > > I would be inclined to try to support more than one vm86 thread at > > > once, with the possibility of asynch execution and notification (or > > > even just blatant status polling). > > > > I would like to have that supprot also, but rember that the BIOS > > specification is not re-entrant, and I know of a lot of BIOSes (and BIOS > > emulators) that will crash if reentrance is attempted. > > It certainly makes no sense to attempt to reenter the video BIOS, but > in at least the trivial sense there is nothing stopping me calling, > say, an ESCD function in one virtual x86 context while the video BIOS > is being called in another; remember that they are operating in > distinct virtual contexts, where the only risk of conflict is in the > I/O domain. Umm. I hope you are rembering about memory-address registers? :) Another thing is that we are talking about two distinctly different cases. I keep thinking about BIOS simulators, which are (in general) evil. In the case of "why can't I call the BIOS on the video card when I am using the BIOS on my SCSI controller?" and the answer is "no reason at all." My problem is : "why can't I call the disk simulator's BIOS when I am using the video simulator's BIOS at the same time?" and there are too many reasons why not. (things like asking for a keypress and askingfor disk i/o simultaneously will crash Win95) My problem however, isn't your problem. :) -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405 From owner-freebsd-emulation Mon Sep 1 13:25:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18598 for emulation-outgoing; Mon, 1 Sep 1997 13:25:22 -0700 (PDT) Received: from atlantis.ping.at (a013.static.Vienna.AT.EU.net [193.154.186.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18591 for ; Mon, 1 Sep 1997 13:25:16 -0700 (PDT) Received: from atlantis (localhost.ping.at [127.0.0.1]) by atlantis.ping.at (8.8.7/8.6.12) with SMTP id WAA00601; Mon, 1 Sep 1997 22:25:01 +0200 (MEST) Message-ID: <340B249D.167EB0E7@ping.at> Date: Mon, 01 Sep 1997 22:25:01 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Mike Smith CC: emulation@FreeBSD.ORG Subject: Re: Dos Emulation References: <199709010250.MAA00432@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > > - doscmd's built-in DOS emulation isn't terribly wonderful; it falls > far short of getting it "right" in many places, and needs an audit. > - The video BIOS/interface code needs a serious rewrite; we need a > modular design which allows either a tty-style interface using > curses or an X window to be used, with appropriate VGA emulation, > etc. > - The network redirector is "OK" as far as it goes, but also falls far > short of being perfect. > - A packet-driver emulator would be very useful, so that DOS programs > could interact with the network. I have code for the PCEMU emulator > which provides a pseudo-interface on the BSD side of things which > looks like a private network between the BSD system and the virtual > DOS machine; this would be an excellent place to start. > > As well as this, documentation, installation procedures (getting > started, etc.), or even just a functionality audit would be very > useful. If you think you can, and want to, help with any of this, just > get into it! Ask us questions, pester for details, whatever you need > to get the job done. > > mike Hello, just to let you all know: I am working on an emulation for EMS (expanded memory as in LIM EMS 4.0) right now. The LIM EMS 3.0 subset is working and tested, but the more complex LIM EMS 4.0 functions need a bit of work yet. I will get it commited when it is ready (1-2 weeks). This emulation will need a (minor) rework of the callback function (INT 0xFF) because it is used for the redirector interface only now. I have a new version of instbsdi.exe. It is functionally equivalent to the current version, but it uses a function number in AX. This way the callback interrupt can be used for more things; for example in the EMS emulation, where it is needed. A question: Does somebody have a test program which will test the LIM EMS 4.0 functionality ? I have a test program (EMSTEST, From Borland C) but it tests only the LIM EMS 3.0 subset. I could write a test program myself, but I'd rather avoid that. Any hints, pointers ? New functionality added to doscmd recently: The emulation of XMS (extended memory) including usability of the HMA (High Memory Area) and UMBs (Upper Memory Blocks) exists now in doscmd (FreeBSD-current). MSDOS 6.22 boots now with "DOS=HIGH,UMB". Extended memory is usable. I could use a disc cache program (like smartdrv.exe). Future projects I am thinking about are: Mouse support: This should be fairly easy in X11 mode and not too hard in console mode. Graphics support: There are fragments in the existing code which could be used. The syscons driver supports switching to some simple VGA modes. A "well behaving" DOS program (i.e. one using the BIOS and video memory but not the card registers to do the graphics) should work this way. I too have looked at the LINUX dosemu package. The code was written by many authors, never got cleaned up and it shows. But I may try to port it to FreeBSD. It can do much more than our doscmd. It will need a rewrite in some parts, but I *think* this could be easier and less work than write all the functionality for ourselves. With the kernel support existing now in -current, most things of dosemu should work, except their DPMI emulation. This will probably need some more kernel support. Regards Helmut -- Helmut F. Wirth Email: hfwirth@ping.at From owner-freebsd-emulation Mon Sep 1 15:24:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22814 for emulation-outgoing; Mon, 1 Sep 1997 15:24:34 -0700 (PDT) Received: from water.waterw.com (water.waterw.com [199.171.193.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22806 for ; Mon, 1 Sep 1997 15:24:29 -0700 (PDT) Received: from steve (access34.accsyst.com [207.8.148.161]) by water.waterw.com (8.8.5/8.8.5) with SMTP id SAA19199 for ; Mon, 1 Sep 1997 18:24:25 -0400 (EDT) Message-Id: <1.5.4.32.19970901221943.00694068@waterw.com> X-Sender: smilley@waterw.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 01 Sep 1997 18:19:43 -0400 To: emulation@freebsd.org From: Stephen Milley Subject: subscribe Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I would like like to subscribe to this and be able to learn all possible about Dos Emulation and help with the project. I have quite a knowledge of Ansi C, and am now learning the FreeBSD specifics. Please don't hestitate on any suggestions and what I exactly need to know about this operating system and the compiler used for it. I am excited to help bring to you what FreeBSD was lacking, although a very powerful OS! I definitely need to learn about Makefiles, and have read the man page all about it, but I don't know what the CC flags are all about(yet). I am also into assembly, so I can learn that as well, if required. I have tooken courses in C, Pascal, dBASE IV, RPG II/II(used mostly in casinos. This language was a pain!), and QuickBasic(notice how that was last!), and I learned Assembly languge(very powerful for at least Dos applications) on my own. I appreciate you taking the time to read this, as I wanted you to know where I am coming from. Again thanks a bunch for allowing me to be a part of the team! FreeBBS kicks! :) From owner-freebsd-emulation Mon Sep 1 15:54:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24460 for emulation-outgoing; Mon, 1 Sep 1997 15:54:28 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24444 for ; Mon, 1 Sep 1997 15:54:13 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id PAA06328; Mon, 1 Sep 1997 15:56:26 -0700 (PDT) Message-ID: <19970901155625.60124@micron.efn.org> Date: Mon, 1 Sep 1997 15:56:25 -0700 From: Jonathan Mini To: Stephen Milley Cc: emulation@FreeBSD.ORG Subject: Re: subscribe Reply-To: Jonathan Mini References: <1.5.4.32.19970901221943.00694068@waterw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <1.5.4.32.19970901221943.00694068@waterw.com>; from Stephen Milley on Mon, Sep 01, 1997 at 06:19:43PM -0400 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk send a message to majordomo@freebsd.org containing the content : subscribe freebsd-emulation This will add you to the mailing list. Stephen Milley stands accused of saying : > I would like like to subscribe to this and be able to learn all possible > about Dos Emulation and help with the project. I have quite a knowledge of > Ansi C, and am now learning the FreeBSD specifics. Please don't hestitate on > any suggestions and what I exactly need to know about this operating system > and the compiler used for it. I am excited to help bring to you what FreeBSD > was lacking, although a very powerful OS! I definitely need to learn about > Makefiles, and have read the man page all about it, but I don't know what > the CC flags are all about(yet). I am also into assembly, so I can learn > that as well, if required. I have tooken courses in C, Pascal, dBASE IV, RPG > II/II(used mostly in casinos. This language was a pain!), and > QuickBasic(notice how that was last!), and I learned Assembly languge(very > powerful for at least Dos applications) on my own. I appreciate you taking > the time to read this, as I wanted you to know where I am coming from. Again > thanks a bunch for allowing me to be a part of the team! FreeBBS kicks! :) -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405 From owner-freebsd-emulation Mon Sep 1 19:01:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07136 for emulation-outgoing; Mon, 1 Sep 1997 19:01:43 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07124 for ; Mon, 1 Sep 1997 19:01:36 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id LAA26910 for ; Tue, 2 Sep 1997 11:31:32 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00629; Tue, 2 Sep 1997 11:26:19 +0930 (CST) Message-Id: <199709020156.LAA00629@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jonathan Mini cc: Mike Smith , emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-reply-to: Your message of "Mon, 01 Sep 1997 02:42:17 MST." <19970901024217.20763@micron.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 1997 11:26:18 +0930 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It certainly makes no sense to attempt to reenter the video BIOS, but > > in at least the trivial sense there is nothing stopping me calling, > > say, an ESCD function in one virtual x86 context while the video BIOS > > is being called in another; remember that they are operating in > > distinct virtual contexts, where the only risk of conflict is in the > > I/O domain. > > Umm. I hope you are rembering about memory-address registers? :) That is indeed what "I/O domain" means; the only resource shared between vm86 threads is hardware. > My problem is : "why can't I call the disk simulator's BIOS when I am using > the video simulator's BIOS at the same time?" and there are too many reasons > why not. (things like asking for a keypress and askingfor disk i/o > simultaneously will crash Win95) I don't think I understand you here. You are saying that someone else's BIOS implementation is nonreentrant, correct? That's more or less to be expected... mike From owner-freebsd-emulation Mon Sep 1 19:18:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07762 for emulation-outgoing; Mon, 1 Sep 1997 19:18:17 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07756 for ; Mon, 1 Sep 1997 19:18:10 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id TAA06612; Mon, 1 Sep 1997 19:20:46 -0700 (PDT) Message-ID: <19970901192045.39217@micron.efn.org> Date: Mon, 1 Sep 1997 19:20:45 -0700 From: Jonathan Mini To: Mike Smith Cc: emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD)' Reply-To: Jonathan Mini References: <19970901024217.20763@micron.efn.org> <199709020156.LAA00629@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199709020156.LAA00629@word.smith.net.au>; from Mike Smith on Tue, Sep 02, 1997 at 11:26:18AM +0930 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith stands accused of saying : > > > It certainly makes no sense to attempt to reenter the video BIOS, but > > > in at least the trivial sense there is nothing stopping me calling, > > > say, an ESCD function in one virtual x86 context while the video BIOS > > > is being called in another; remember that they are operating in > > > distinct virtual contexts, where the only risk of conflict is in the > > > I/O domain. > > > > Umm. I hope you are rembering about memory-address registers? :) > > That is indeed what "I/O domain" means; the only resource shared > between vm86 threads is hardware. > > > My problem is : "why can't I call the disk simulator's BIOS when I am using > > the video simulator's BIOS at the same time?" and there are too many reasons > > why not. (things like asking for a keypress and askingfor disk i/o > > simultaneously will crash Win95) > > I don't think I understand you here. You are saying that someone > else's BIOS implementation is nonreentrant, correct? That's more or > less to be expected... I'm sorry -- I was refering to simultaneous calls to _different_ BIOS's as opposed to simultaneous calls to the same BIOS, i.e. the BIOS on a SCSI card as opposed to the BIOS onboard the mb. also remember that many BIOS's store information within the BIOS/DOS "communication" aread, and the BIOS need to be able to access this. -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405 From owner-freebsd-emulation Mon Sep 1 19:28:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08101 for emulation-outgoing; Mon, 1 Sep 1997 19:28:42 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08095 for ; Mon, 1 Sep 1997 19:28:38 -0700 (PDT) Received: from word.smith.net.au (lot.atrad.adelaide.edu.au [203.20.121.21]) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) with ESMTP id LAA27048 for ; Tue, 2 Sep 1997 11:58:34 +0930 (CST) Received: from word.smith.net.au (localhost.atrad.adelaide.edu.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00764; Tue, 2 Sep 1997 11:53:34 +0930 (CST) Message-Id: <199709020223.LAA00764@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Helmut F. Wirth" cc: Mike Smith , emulation@FreeBSD.ORG Subject: Re: Dos Emulation In-reply-to: Your message of "Mon, 01 Sep 1997 22:25:01 +0200." <340B249D.167EB0E7@ping.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 1997 11:53:33 +0930 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk just to let you all know: I am working on an emulation for EMS (expanded > memory as in LIM EMS 4.0) right now. The LIM EMS 3.0 subset is working > and tested, but the more complex LIM EMS 4.0 functions need a bit of > work yet. I will get it commited when it is ready (1-2 weeks). I was going to ask (politely) if you were working on this after you did the XMS stuff. I'm really glad to hear this! > A question: Does somebody have a test program which will test the LIM > EMS 4.0 functionality ? I have a test program (EMSTEST, From Borland C) > but it tests only the LIM EMS 3.0 subset. I could write a test program > myself, but I'd rather avoid that. Any hints, pointers ? Short of just digging up applications and using them, no. 8( > Future projects I am thinking about are: > Mouse support: This should be fairly easy in X11 mode and not too hard > in console mode. > Graphics support: There are fragments in the existing code which could > be used. The syscons driver supports switching to some simple VGA modes. > A "well behaving" DOS program (i.e. one using the BIOS and video memory > but not the card registers to do the graphics) should work this way. I would *really* like to see the "screen" interface abstraction improved, if you think that you'd be able to come up with something there. The latest PCEmu (ftp://gsoft.com.au/pub/pcemu) has a tolerable curses-mode screen interface; I'm quite certain that something like this could be improved on dramatically. This would lead to a set of video support that would be quite comprehensive. > I too have looked at the LINUX dosemu package. The code was written by > many authors, never got cleaned up and it shows. But I may try to port > it to FreeBSD. It can do much more than our doscmd. It will need a > rewrite in some parts, but I *think* this could be easier and less work > than write all the functionality for ourselves. With the kernel support > existing now in -current, most things of dosemu should work, except > their DPMI emulation. This will probably need some more kernel support. To be honest, I would rather see you learn from dosemu and incorporate the fruits of said learning in doscmd; dosemu is forever crippled by the GPL as well. Just my UCU worth. mike From owner-freebsd-emulation Tue Sep 2 20:27:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13135 for emulation-outgoing; Tue, 2 Sep 1997 20:27:29 -0700 (PDT) Received: from emout02.mail.aol.com (emout02.mx.aol.com [198.81.11.93]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13120 for ; Tue, 2 Sep 1997 20:27:25 -0700 (PDT) From: StevenR362@aol.com Received: (from root@localhost) by emout02.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id XAA14863; Tue, 2 Sep 1997 23:26:46 -0400 (EDT) Date: Tue, 2 Sep 1997 23:26:46 -0400 (EDT) Message-ID: <970902232531_-266624518@emout02.mail.aol.com> To: hfwirth@ping.at cc: emulation@freebsd.org Subject: Re: Dos Emulation Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In a message dated 97-09-02 00:46:45 EDT, hfwirth@ping.at (Helmut F. Wirth) writes: > A question: Does somebody have a test program which will test the LIM > EMS 4.0 functionality ? I have a test program (EMSTEST, From Borland C) > but it tests only the LIM EMS 3.0 subset. I could write a test program > myself, but I'd rather avoid that. Any hints, pointers ? It is not a comprehensive LIM 4.0 test program, but manifest "mft.exe" that comes with Quarterdeck's Qemm package detects the EMS version and does EMS benchmarking as well as poking around with XMS and DPMI. I would be pleasantly surprised if it ran under doscmd. It should make for a good test program. Steve From owner-freebsd-emulation Tue Sep 2 22:32:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19094 for emulation-outgoing; Tue, 2 Sep 1997 22:32:25 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19087 for ; Tue, 2 Sep 1997 22:32:16 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id WAA09291; Tue, 2 Sep 1997 22:35:12 -0700 (PDT) Message-ID: <19970902223512.43984@micron.efn.org> Date: Tue, 2 Sep 1997 22:35:12 -0700 From: Jonathan Mini To: StevenR362@aol.com Cc: hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Dos Emulation Reply-To: Jonathan Mini References: <970902232531_-266624518@emout02.mail.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <970902232531_-266624518@emout02.mail.aol.com>; from StevenR362@aol.com on Tue, Sep 02, 1997 at 11:26:46PM -0400 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk StevenR362@aol.com stands accused of saying : > In a message dated 97-09-02 00:46:45 EDT, hfwirth@ping.at (Helmut F. Wirth) > writes: > > > A question: Does somebody have a test program which will test the LIM > > EMS 4.0 functionality ? I have a test program (EMSTEST, From Borland C) > > but it tests only the LIM EMS 3.0 subset. I could write a test program > > myself, but I'd rather avoid that. Any hints, pointers ? > > It is not a comprehensive LIM 4.0 test program, but manifest "mft.exe" that > comes with Quarterdeck's Qemm package detects the EMS version and > does EMS benchmarking as well as poking around with XMS and DPMI. > I would be pleasantly surprised if it ran under doscmd. It should make for > a good test program. It would be funny to see Norton's Sysinfo scale running under doscmd as well. I think it would be entertaining to watch it, and do something like compile a few kernels. :) > > Steve -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405