Re: [Freedos-user] Dosemu on its own - does it exist?
Hi! > At the moment I know next to nothing about that "virtual x86 mode" - and > I was hoping that CPU can be made to switch to that mode and then to boot > even different OS into each "instance" That is exactly what Windows does, but the instances are called tasks. Because DOS is not task-aware, Windows has to catch everything which DOS believes to be single-user and redirect it into multi-user :-) You can run dosbox as a DOS app with HX RT, but just one instance. The trick with virtual x86 mode is that it hides the protected mode and task details from the "instance", so creating vm86 tasks means extra work for the creator. For example emm386 puts itself into protected mode and transplants DOS into a vm86 task, but makes use of the fact that only a single instance of DOS exists. The emm386 of DR-DOS already contains some preparations for swapping tasks, which makes it more complicated. Tools like desqview also use protected mode and vm86 tasks to keep track of user interaction attempts of DOS and let you swap between several DOS apps, which must all run in full screen mode. They are more powerful than MS DOSSHELL which I believe to use no protected mode: It probably only intercepts BIOS calls to keep track of the hardware state expected by each app when you swap between them. By the way, DOSEMU2 is aiming to also work on Windows, not just on Linux. It has a built-in CPU emulation for situations where no vm86 tasks can be acquired. Seems common in our 64-bit age. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Dosemu on its own - does it exist?
Some possibilities, haven't checked them out myself Concurrent DOS 386 https://en.wikipedia.org/wiki/Multiuser_DOS#CCP/M-86 https://winworldpc.com/product/digital-research-con/386-3x PC-MOS/386 https://en.wikipedia.org/wiki/PC-MOS/386 https://github.com/roelandjansen/pcmos386v501 Currently hiding in the Arkansas Delta ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
On Wed, Sep 2, 2020 at 10:10 AM ZB wrote: > On Wed, Sep 02, 2020 at 03:56:26PM +0200, Mateusz Viste wrote: > > > https://en.wikipedia.org/wiki/DESQview > > Indeed I recall that name - but somehow never used it before. Does it do > exactly what I've described? Like - for example - I could "split" 486 into > four x86 CPUs, then I can use one instance to boot FreeDOS there, the second > one to boot DOS 6.22 (for comparison), the third one for, say, DR-DOS etc. No, you can't. I ran it, back in the day. Think of it as a multitasking character mode GUI shell running on top of DOS. You were *not* running multiple copies of *DOS*. You were running multiple *applications* under DOS at the same time. DOS was single-tasking. DV serialized access to it by the various DOS applications, so it was the single task DOS was supporting. It used round robin time slicing, doing a bit of work on each process running under it and moving to the next. It really wanted a (by the standards of the day) fast and powerful machine to be used effectively. A chap I knew back when was a BBS Sysop, and had four nodes of Wildcat BBS software (a popular choice back then) running on a single 25mhz AT clone with a 286 CPU. Other sysops found themselves running multiple PCs on a LAN if they wanted more than one node of the BBS at a time. You needed to experiment with DV to get settings correct to best support what you did, with allocation of foreground and background time slices being key. Conceptually, Windows 3.1 was the next step beyond DesqView. It was a multi-tasking bit-mapped GUI shell on top of DOS. The transition Windows faced was from 16 bit to 32 bit applications. Win95 made a start on that, but DOS was still under the hood. Win98 was the next step. DOS was still there because Win98 needed a real-mode *loader*, but once it was initialized and running, it took over all OS functions and DOS was out of the loop. Win2K was a fully virtualized 32 bit system, and had no need for DOS. (It *did* provide DOS emulation for folks who still wanted to run DOS programs wia the NTVDM DLL.) Win7 and later were aimed at 64bit systems. On a 64bit system, support for 16bit programs went away. If you really needed them, you ran some form of VM under Windows and ran the DOS programs in it. (The vDOS Plus package discussed here is essentially a VM for running 16bit DOS apps.) > Zbigniew __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Wed, Sep 2, 2020 at 5:47 AM tom ehlert wrote: > > UNIX System V certainly was connected to serial terminals (Televideo, > VT100, ...) > > and it had the VI visual editor with definitively cursor movement > across the screen, even when the terminal had no cursor keys. I was a system administrator for setups like that. (At one shop, I had 90 dumb terminals connecting to a SysV, and later a Solaris, machine.) The vi editor relied on the TERM variable being properly set in the login profile. (And vi is a "moded" editor. In Insert mode, things you type are inserted into the file you are editing. In command mode, keys on the keyboard become commands. H, J, K, and L move the cursor left, down, up, and right respectively. So you can use vi on machines that don't have arrow keys.) Unix used a database called termcap (short for terminal capabilities) to tell how to communicate with the terminal. The $TERM variable got set to an entry in the local termcap file. An ANSI termcap entry looked like this. It was provided with a DOS port of the Unix Larn D style game (and required the ANSI.SYS driver to be loaded.) \E is the escape character (ASCII 27). A command sequences begin with escape left bracket # # Monochrome IBMPC. #This is a termcap for the NANSI.SYS device driver. #It is the same as the ANSI termcap, except NANSI supports #line insert (al) and delete (dl) while ANSI does not. # ibmpc-mono:\ Name of termcap entry :co#80:\ Number of screen columns :li#24:\ Number of screen rows :ho=\E[H:\Home the cursor :cl=\E[;H\E[2J:\Clear line :bs:\Terminal has backspace key :cm=\E[%i%2;%2H:\Cursor motion :up=\E[A:\ Up arrow :xd=\E[B:\ Down arrow :nd=\E[C:\ Right arrow (non-destructive space) :bc=\E[D:\ Left arrow :ce=\E[K:\ Clear entry :cd=\E[J:\Clear display :ti=\E[m:\Terminal mode init :te=\E[m:\ Terminal mode end init :so=\E[1m:\ Standout mode (usually boldface) :se=\E[m:\ End standout :us=\E[4m:\ Underline mode :ue=\E[m:\ End underline :al=\E[L:\ Add line :dl=\E[M: Delete line This is a simple example. More complex ones existed. But there were limits in how complex - terminal definitions had to fit into a 1K buffer in memory. Terminals fell into two broad categories - ASCII and ANSI. Earlier terminals were ASCII terminals, and the typical example was the DEC VT52 or the Wyse 50. The VT100 was the typical ANSI terminal. The principal difference was ANSI terminals using ANSI escape sequences for terminal commands, which were a subset of the ANSI 3.64 specification. The latter made life easier for admins. The Wyse 50 ASCII terminal, for example, had a backspace key and a left arrow key. *Both* sent ^H when sent, with no way to determine which of those keys was pressed when the system got a ^H from the terminal. > cursor movement is not tied to memory-mapped devices, and even old DOS > Software (MS Word and friends) were derivative of CP/M software where > they also have to live with serial terminals. they (for the most part) > used only BIOS functions for screen control. And CP/M had a configurable BIOS you could customize to best support your hardware, because there was wide variation in what vendors offered. Likewise, early PC clones took a bit to get IBM PC BIOS emulation correct. Earlier versions of the VDE editor mentioned here could be configured to use the BIOS for cursor movement if the particular brand of machine wasn't fully PC compatible and didn't support the expected control sequences. Using BIOS calls was slower and more expensive than direct addressing, so all breathed sighs of relief when it stopped being needed. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
On Wed, Sep 02, 2020 at 04:23:47PM +0200, Mateusz Viste wrote: > I wonder how far one could get with just an emulated 8086 core, 640K of > mapped memory and a simulated BIOS. At the moment I know next to nothing about that "virtual x86 mode" - and I was hoping that CPU can be made to switch to that mode and then to boot even different OS into each "instance" -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
No, it was application-level, and AFAIR it required the applications not to be too greedy about what they do. I think that what you describe now isn't possible without introducing some form of (expensive) emulation to avoid the different systems to fight for shared resources. At the very least it would require an emulation of a different BIOS for each instance. I wonder how far one could get with just an emulated 8086 core, 640K of mapped memory and a simulated BIOS. Perhaps it could run some early MDA-compatible software that was made before the "use hardware directly" era. Mateusz On 02/09/2020 16:08, ZB wrote: On Wed, Sep 02, 2020 at 03:56:26PM +0200, Mateusz Viste wrote: https://en.wikipedia.org/wiki/DESQview Indeed I recall that name - but somehow never used it before. Does it do exactly what I've described? Like - for example - I could "split" 486 into four x86 CPUs, then I can use one instance to boot FreeDOS there, the second one to boot DOS 6.22 (for comparison), the third one for, say, DR-DOS etc. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
On Wed, Sep 02, 2020 at 03:56:26PM +0200, Mateusz Viste wrote: > https://en.wikipedia.org/wiki/DESQview Indeed I recall that name - but somehow never used it before. Does it do exactly what I've described? Like - for example - I could "split" 486 into four x86 CPUs, then I can use one instance to boot FreeDOS there, the second one to boot DOS 6.22 (for comparison), the third one for, say, DR-DOS etc. -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 9/2/2020 2:29 AM, tom ehlert wrote: UNIX System V certainly was connected to serial terminals (Televideo, VT100, ...) and it had the VI visual editor with definitively cursor movement across the screen, even when the terminal had no cursor keys. cursor movement is not tied to memory-mapped devices, and even old DOS Software (MS Word and friends) were derivative of CP/M software where they also have to live with serial terminals. they (for the most part) used only BIOS funtions for screen control. only much later direct memory control became en vogue. Well, yes, serial terminals had (depending on the model) quite sophisticated means of cursor control, however this is something that on the DOS level needs to be supported. And there are/were many different and largely incompatible sets of terminal control codes out there... Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
DOSemu relies on a number of Linuxisms, hence cannot be used as such kind of bootstrap. What you think about is called DESQview. https://en.wikipedia.org/wiki/DESQview Mateusz On 02/09/2020 15:48, ZB wrote: If I'm correct, Dosemu uses "virtual x86 mode" of 386 and later processors. But Dosemu of course needs "host OS". I wonder does there exist any utility that offers "virtual x86 mode" and acts as "host" by itself? Suppose we have (quite modest for today) computer with 386/486 and 4 MB RAM. Theoretically it should be possible to run quite comfortably four DOS "instances" each one having 1 MB just for itself - and, say, switching among them with - like among consoles in Linux. So concentrating on using DOS - because 486 is much too "weak" for Linux of today - I mean utility whose duty is just to switch CPU into "virtual x86 mode", split RAM among established "instances" and then just share hardware resources (keyboard, CD-ROM, video, sound... everything) among them. No idea - maybe it had been aleady created, just I didn't stumble upon it yet? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Dosemu on its own - does it exist?
If I'm correct, Dosemu uses "virtual x86 mode" of 386 and later processors. But Dosemu of course needs "host OS". I wonder does there exist any utility that offers "virtual x86 mode" and acts as "host" by itself? Suppose we have (quite modest for today) computer with 386/486 and 4 MB RAM. Theoretically it should be possible to run quite comfortably four DOS "instances" each one having 1 MB just for itself - and, say, switching among them with - like among consoles in Linux. So concentrating on using DOS - because 486 is much too "weak" for Linux of today - I mean utility whose duty is just to switch CPU into "virtual x86 mode", split RAM among established "instances" and then just share hardware resources (keyboard, CD-ROM, video, sound... everything) among them. No idea - maybe it had been aleady created, just I didn't stumble upon it yet? -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> And as there aren't many tools where ZB's idea would make > sense in his opinion, it seems a bit like brewing up a tempest in a > teacup... ;-) +1 > And another reason why this might not be in general a good idea is if we > take compatibility with old(er) DOS software/environments serious, one > might want to consider that DOS (in its basic form) was able to run on > non-memory mapped devices, like serial terminals, which might limit your > ability to move the cursor quite a bit. UNIX System V certainly was connected to serial terminals (Televideo, VT100, ...) and it had the VI visual editor with definitively cursor movement across the screen, even when the terminal had no cursor keys. cursor movement is not tied to memory-mapped devices, and even old DOS Software (MS Word and friends) were derivative of CP/M software where they also have to live with serial terminals. they (for the most part) used only BIOS funtions for screen control. only much later direct memory control became en vogue. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
