[Freedos-user] New FreeDOSers Monthly Reminder
OOPS! The remind file could not be downloaded! Here I am, brain the size of the universe, trying to send you a simple email, but wouldn't you know it, the file doesn't even exist! Where does that leave me?! I'm sure it would say something about FreeDOS, or Jim Hall, or some mailing list or other, but what do I care. *sigh* Humans. In case you think you can fix this, here is the log: --2018-03-01 01:00:01-- http://freedos.sourceforge.net/freedos/lists/remind.txt Resolving freedos.sourceforge.net (freedos.sourceforge.net)... 216.105.38.10 Connecting to freedos.sourceforge.net (freedos.sourceforge.net)|216.105.38.10|:80... connected. HTTP request sent, awaiting response... 503 Service Temporarily Unavailable 2018-03-01 01:00:01 ERROR 503: Service Temporarily Unavailable. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: Re: Windows 3.1 in 386 mode / 386enh
I tired the /D option but it did not help. On 02/20/2018 01:39 PM, Eric Auer wrote: Hi everybody ;-) I have Windows 3.11(not WFW) and can't find an option to turn off 32-bit disk acass in BIOS. Not in BIOS, just the Windows 386+ driver for it. On empowermentzone.com, I must have once found the win31faq.txt - you can probably find it on other websites as well: "Microsoft Windows Frequently Asked Questions Prepared 03/07/95" (from the Microsoft knowledge base) I can also recommend a thread from the DOSEMU mailing list in Nov 2004 about win386 compatibility, titled "Windows 386 in DOSEMU - explanation attempt" Finally, here are my (often very technical!) collected 2004 notes about Windows compatibility issues. Maybe some developers will enjoy them :-) Various issues probably did already get fixed in FreeDOS long ago. For you as USER, Jamie, please just scroll to the section with the "/D:.." options. Those are what you need if you want to disable 32 bit disk or file access, virtual IRQ or special handling of UMB and BIOS area. Good luck :-) Regards, Eric Notes about Windows 3.x+ and FreeDOS compatibility and related stuff: int 2f.1607.bx=0015.cx=function (DOSMGR interface DOS/Win386 taskstuff) 0, DX=0: return instanced (cx nonzero) / dx = DOS driver seg, 0->0x70 es:bx -> patch table: dw version h.l, saveds_off, savebx_off, user_id_off, critical_section_patch_table_off (below!), umb_head_off (all words in DOS ds, umb_head is word with seg of last non-UMB MCB) 1, bitmask DX: set patches, return ax=b97c dx=a2ab bx=bit mask ack (bits: 0 criticalsectionenable 1 nopoutuserid 2 makeint213fstdinpoll 3 trapwin386sysinitstackfault 4 trapdjmechansimorbios) 2, bitmask DX: remove 1 patch specified by DX, returns (ignored) CX 0 3, bitmask DX: get DOS structure size of 1 structure (bit 0: CurrDirS) returns CX=0 (unsupported request) or: CX=size/by AX=b97c DX=a2ab 4, get instance bitmask: return ax=b97c dx=a2ab bx=bitmask instanced items, bits: 0 CDS 1 SFT 2 devicelist 3 SDA (swappable data area) 5, get driver size of driver at ES: return ax=b97c dx=a2ab bx:cx=size (in bytes) or dx=ax=0 if no driver segment. Mini alternative to 2f.1607.0015: 2f.1603 -> returns AX=5248, DS:SI -> RM Nimbus MS DOS 3.3 ... used by Win3.x/3 DOSMGR if no 2f.1607.0015, which happens for all DOS < 5.0 ... Data structure format: dw io sys seg (0 means default 0x70), STACKS struc offset in IO or 0 (non-0 for DOS 3.2), count_instance_areas, then: instance area array with for each (max 32) entry: dw segment (2 = kernel), offset, size. *** If even 2f.1603 not supported, Win3.x uses hardcoded list!? *** (list is based on MS DOS version number, no list for non-MS?) Criticalsection: int 2a.800x enters critical section, handlers can hook this to avoid interrupting. Each c.s. may be active max. once. DOS 3.1+ has [SDA-11] list of offsets in DOS DS; they must be C3->50 (ret->pushax, DOS 3.x only) or 00->nonzero (DOS 4+) to activate. For DOS 4+, all words are 0d0c. Kernel calls 2a.80/2a.81, Win usu. grabs this and does not reflect unless [386Enh] ReflectDOSInt2A=1 or ModifyDOSInt2A=0 ... 2a.800x leaves critical section. Numbers x: 1 kernel / share / dosmgr (dos/share/net structure integrity prot.) 2 kernel / dosmgr (to block task switch while calling device driver) 5 network redirector / 6 IFSFUNC / 8 ASSIGN A MSCDEX, ... 2a.82 ends crit.sect. 0-7: called by proc.exit. / 21.c+ except 21.59 *** Also 2f.1681 / 2f.1682 disable / enable task switching *** (i.e. enter/leave crit. section, nestable; Win 2.x just uses InDOS) Instance data = areas which change over time and must be kept separate between different Windows DOS boxes. MS DeviceDevelKit Q90796 tells: VMM has 0x10F pages per box, of which are usually shared: all TSRs (which were loaded before Win), BIOS, DOS code. Usually local: All neither global (shared) nor instanced. Instanced: Shared except for instanced areas (to keep RAM usage low, not whole page is local). Unless SFT is instanced, you must not touch files which were open when Win/386 started from within Win... when Win exits, instanced areas are restored to state at Win start. Between call int 2f.1609 and 2f.1606, DOS is active but buffers not restored -> a TSR can save some data at 2f.1606 and restore at 2f.1609, to make Win stuff persistent. MS'es NeilSa "grepped through the sources" and lists: 40[13]w (memsize), "DOS memory arena", "selfmodifying code from DOS loader conspirative patch #14", 50[4]b (dj mechanism), 0[0]/400 (IDT), "internal DOS tables", "BIOS data from internal DOS tables" (2f.13??), SDA (Swappable Data Area), CDS (Current Directory String), System File Table (SFT), DOS stack(s), "last link in SFT table" (Win's own VM uses a bigger SFT, the VMs for DOS boxes do not), device header list (Win can locally add drivers), Win-devices which are local=* but not
Re: [Freedos-user] Windows 3.1 in 386 mode
Some people think if you enable 'InDOSPolling=TRUE' in your Sysystem.ini file and then run "Wndows\System\Dosx.exe" it will work but that gives me an error along the lines of "Can't load display.drv". It happens even if I use VGA. Anyone know anything about this? What I said recently: As a temporary work around I got SVGA(800x600 with 256 colors) by patching the bult-in SVGA driver to work on more hardware (unofficially patches are available online). I used the Sound Blaster Pro emulator built into my sound card to load Sound Blaster Pro drivers and use that for playback. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 in 386 mode
I am still running in Standard Mode On 02/28/2018 05:06 AM, Eric Auer wrote: Hi Jamie :-) As a temporary work around I got SVGA(800x600 with 256 colors) by patching the bult-in SVGA driver to work on more hardware (unoffically patches are available online). I used the Sound Blaster Pro emulator built into my sound card to load Sound Blaster Pro drivers and use that for playback. You mean for 386 mode? Or in general? Please be more specific about which sound and graphics hardware you use and which drivers with which configuration you use :-) Some links to those patches would be great, too. Thank you! Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- -Jamie Marchant -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 in 386 mode
I can't get "Beyond Planet Earth"* to work on DosBox, Dosemu or a Windows 98SE desktop. It runs fine on my FreeDos machine, they might be other software out there like that, this is why I sometimes prefer to use real hardware then emulators. Also Dosbox often seems to run slow for me and it may be my imagination but it is not as responsive . * https://www.amazon.com/Beyond-Planet-Earth-PC-CD-ROM/dp/1563313235 << I've had a copy lying around form when somone bought it when I was a kid. It's not as interesting as I remember, must have been the full motion videos.(there is a real human being on my computer, it's like a VHS on my PC!). This was before I played The Journeyman Project 3 and years before I would get my first DVD-ROM drive. On 02/27/2018 09:57 PM, Ariella wrote: I run Win 3.1 under DosBox. It's effortless. Just install and go. I use FreeDOS for as much free as I can muster (except WordPerfect. I'm a lifer with that software. :) ) Ella Original Message From: rugx...@gmail.com Sent: February 27, 2018 9:51 PM To: freedos-user@lists.sourceforge.net Reply to: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] Windows 3.1 in 386 mode Hi, On Mon, Feb 19, 2018 at 2:53 PM, jamie marchant wrote: I can't seem to get Windows 3.1 to run in 386 mode, is this a limitation for FreeDos? Please don't take this the wrong way. I don't blame you for tinkering! ;-) But I wonder why you want to use such ancient (unsupported! proprietary!) software. If Win 3.x was FOSS, it would be easy to support (famous last words!). But it's not. And even the vendor gave up on it. (Wikipedia says, "Unsupported as of December 31, 2001", back when XP was brand new!) Even Win64 doesn't care. Eric is right to suggest WINE as a possible solution. And yes, you can allegedly run under DOSBox, too (not that I've tried). Then again, MS has geared up to launch some ARM laptops with Win32 emulation: * https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch * https://www.anandtech.com/show/12327/the-asus-novago-two-minutes-with-snapdragon-835-and-windows I don't know all the details, not even sure if it's out or for sale yet! But it sounds intriguing. (I'm not really suggesting buying new hardware as a true, first solution to your needs. But unless you like scrounging around for half-baked solutions like the rest of us here, it might honestly be a safer bet. Then again, who knows, maybe their Win32 emulation doesn't cover 16-bit stuff!) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- -Jamie Marchant -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 in 386 mode
Even Wine has trouble running older software, as it is evolves I find it starts having the same problems as newer Windows OS have. This might be mean it's more closely copying the newer versions of Windows, which would be a good thing. Windows 3.1 is also an interesting thing to run for historical reasons. I don't run MS-DOS since I can't find my MS-DOS disks and because I thought I could benefit from some of the advances made in FreeDOS. A Windows 3.1 clone would be neat but I don't think anyone is interesting in writing one. In case anyone suggests ReactOS emulates Windows NT and is still very buggy for me in virtual machines. On 02/20/2018 03:10 PM, Rugxulo wrote: Hi, On Mon, Feb 19, 2018 at 2:53 PM, jamie marchant wrote: I can't seem to get Windows 3.1 to run in 386 mode, is this a limitation for FreeDos? Please don't take this the wrong way. I don't blame you for tinkering! ;-) But I wonder why you want to use such ancient (unsupported! proprietary!) software. If Win 3.x was FOSS, it would be easy to support (famous last words!). But it's not. And even the vendor gave up on it. (Wikipedia says, "Unsupported as of December 31, 2001", back when XP was brand new!) Even Win64 doesn't care. Eric is right to suggest WINE as a possible solution. And yes, you can allegedly run under DOSBox, too (not that I've tried). Then again, MS has geared up to launch some ARM laptops with Win32 emulation: * https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch * https://www.anandtech.com/show/12327/the-asus-novago-two-minutes-with-snapdragon-835-and-windows I don't know all the details, not even sure if it's out or for sale yet! But it sounds intriguing. (I'm not really suggesting buying new hardware as a true, first solution to your needs. But unless you like scrounging around for half-baked solutions like the rest of us here, it might honestly be a safer bet. Then again, who knows, maybe their Win32 emulation doesn't cover 16-bit stuff!) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- -Jamie Marchant -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 in 386 mode
Hi Jamie :-) > As a temporary work around I got SVGA(800x600 with 256 colors) by > patching the bult-in SVGA driver to work on more hardware (unoffically > patches are available online). I used the Sound Blaster Pro emulator > built into my sound card to load Sound Blaster Pro drivers and use that > for playback. You mean for 386 mode? Or in general? Please be more specific about which sound and graphics hardware you use and which drivers with which configuration you use :-) Some links to those patches would be great, too. Thank you! Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 in 386 mode
Hi Ella, > I run Win 3.1 under DosBox. It's effortless. Just install and go. > > I use FreeDOS for as much free as I can muster (except > WordPerfect. I'm a lifer with that software. :) ) > > Ella This is probably related to DosBox simulating a DOS and suitable hardware instead of running a full FreeDOS on real hardware :-) If you like WordPerfect, then you may want to try JOE "Joe's Own Editor" or SETEDIT, which officially supports use inside DOS: http://setedit.sourceforge.net/#scrnsht You can run FreeDOS in DosBox if you use a disk image, as far as I remember. I assume that Win 3.1 would run worse then, as you will start having the real problems of less simulation then. As mentioned before, if you already have Windows or Linux, it is easier to run Windows programs directly in Windows or WINE without installing the ancient Windows 3.1 and running that from FreeDOS. However, it would be cool to have some sort of how-to for making Windows 3.1 (or even Windows for Workgroups 3.11) work in 386enh mode on real (or simulated) hardware with a full installation of FreeDOS. As Windows is very picky about proper conditions to run in 386enh mode, such as drivers and amount of memory available, this needs some Windows and FreeDOS expert advice to be done. Has somebody succeeded in using 386enh mode of Windows WITHOUT the help of Dosemu or Dosbox? Then I would like to hear how it works :-) Thanks! Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: Re: Windows 3.1 in 386 mode / 386enh
Hi everybody ;-) > I have Windows 3.11(not WFW) and can't find an > option to turn off 32-bit disk acass in BIOS. Not in BIOS, just the Windows 386+ driver for it. On empowermentzone.com, I must have once found the win31faq.txt - you can probably find it on other websites as well: "Microsoft Windows Frequently Asked Questions Prepared 03/07/95" (from the Microsoft knowledge base) I can also recommend a thread from the DOSEMU mailing list in Nov 2004 about win386 compatibility, titled "Windows 386 in DOSEMU - explanation attempt" Finally, here are my (often very technical!) collected 2004 notes about Windows compatibility issues. Maybe some developers will enjoy them :-) Various issues probably did already get fixed in FreeDOS long ago. For you as USER, Jamie, please just scroll to the section with the "/D:.." options. Those are what you need if you want to disable 32 bit disk or file access, virtual IRQ or special handling of UMB and BIOS area. Good luck :-) Regards, Eric Notes about Windows 3.x+ and FreeDOS compatibility and related stuff: int 2f.1607.bx=0015.cx=function (DOSMGR interface DOS/Win386 taskstuff) 0, DX=0: return instanced (cx nonzero) / dx = DOS driver seg, 0->0x70 es:bx -> patch table: dw version h.l, saveds_off, savebx_off, user_id_off, critical_section_patch_table_off (below!), umb_head_off (all words in DOS ds, umb_head is word with seg of last non-UMB MCB) 1, bitmask DX: set patches, return ax=b97c dx=a2ab bx=bit mask ack (bits: 0 criticalsectionenable 1 nopoutuserid 2 makeint213fstdinpoll 3 trapwin386sysinitstackfault 4 trapdjmechansimorbios) 2, bitmask DX: remove 1 patch specified by DX, returns (ignored) CX 0 3, bitmask DX: get DOS structure size of 1 structure (bit 0: CurrDirS) returns CX=0 (unsupported request) or: CX=size/by AX=b97c DX=a2ab 4, get instance bitmask: return ax=b97c dx=a2ab bx=bitmask instanced items, bits: 0 CDS 1 SFT 2 devicelist 3 SDA (swappable data area) 5, get driver size of driver at ES: return ax=b97c dx=a2ab bx:cx=size (in bytes) or dx=ax=0 if no driver segment. Mini alternative to 2f.1607.0015: 2f.1603 -> returns AX=5248, DS:SI -> RM Nimbus MS DOS 3.3 ... used by Win3.x/3 DOSMGR if no 2f.1607.0015, which happens for all DOS < 5.0 ... Data structure format: dw io sys seg (0 means default 0x70), STACKS struc offset in IO or 0 (non-0 for DOS 3.2), count_instance_areas, then: instance area array with for each (max 32) entry: dw segment (2 = kernel), offset, size. *** If even 2f.1603 not supported, Win3.x uses hardcoded list!? *** (list is based on MS DOS version number, no list for non-MS?) Criticalsection: int 2a.800x enters critical section, handlers can hook this to avoid interrupting. Each c.s. may be active max. once. DOS 3.1+ has [SDA-11] list of offsets in DOS DS; they must be C3->50 (ret->pushax, DOS 3.x only) or 00->nonzero (DOS 4+) to activate. For DOS 4+, all words are 0d0c. Kernel calls 2a.80/2a.81, Win usu. grabs this and does not reflect unless [386Enh] ReflectDOSInt2A=1 or ModifyDOSInt2A=0 ... 2a.800x leaves critical section. Numbers x: >> 1 kernel / share / dosmgr (dos/share/net structure integrity prot.) >> 2 kernel / dosmgr (to block task switch while calling device driver) 5 network redirector / 6 IFSFUNC / 8 ASSIGN >> A MSCDEX, ... 2a.82 ends crit.sect. 0-7: called by proc.exit. / 21.c+ except 21.59 *** Also 2f.1681 / 2f.1682 disable / enable task switching *** (i.e. enter/leave crit. section, nestable; Win 2.x just uses InDOS) Instance data = areas which change over time and must be kept separate between different Windows DOS boxes. MS DeviceDevelKit Q90796 tells: VMM has 0x10F pages per box, of which are usually shared: all TSRs (which were loaded before Win), BIOS, DOS code. Usually local: All neither global (shared) nor instanced. Instanced: Shared except for instanced areas (to keep RAM usage low, not whole page is local). Unless SFT is instanced, you must not touch files which were open when Win/386 started from within Win... when Win exits, instanced areas are restored to state at Win start. Between call int 2f.1609 and 2f.1606, DOS is active but buffers not restored -> a TSR can save some data at 2f.1606 and restore at 2f.1609, to make Win stuff persistent. MS'es NeilSa "grepped through the sources" and lists: 40[13]w (memsize), "DOS memory arena", "selfmodifying code from DOS loader conspirative patch #14", 50[4]b (dj mechanism), 0[0]/400 (IDT), "internal DOS tables", "BIOS data from internal DOS tables" (2f.13??), SDA (Swappable Data Area), CDS (Current Directory String), System File Table (SFT), DOS stack(s), "last link in SFT table" (Win's own VM uses a bigger SFT, the VMs for DOS boxes do not), device header list (Win can locally add drivers), Win-devices which are local=* but not global. Extra instances, not using int 2f.1603 / 2f.1607.0015 to bootstrap: VKB keyboard: 40[15]/28, 40[80]/4