Re: [Freedos-devel] video FreeDOS running Windows 3.1
Hi Jeremy, others, > Kernel patches - http://server2.fdos.org/tests/kernel-win3-patch.diff > rest of sources (kernel, FreeCOM, format, fdisk, sys, share, edit) - > https://github.com/fdos I have been browsing those patches a bit. So I can share some insights about them, also implying many questions. Maybe Jeremy can explain the areas which looked complicated or confusing to me. Maybe the confusing areas even include some which actually could use code improvements :-) Sorry about the length of the "review" below. > hdr/portab.h | 7 + > kernel/entry.asm | 186 - > kernel/init-mod.h | 4 +- > kernel/int2f.asm | 51 ++- > kernel/inthndlr.c | 340 +- > kernel/kernel.asm | 37 - > kernel/main.c | 19 ++- > 7 files changed, 623 insertions(+), 21 deletions(-) portab.h just introduces loword and hiword access macros entry.asm: there is a new int 13 handler, but the style worries me. It does CLI STC, then calls the original handler while forcing DS to be the kernel one, then increments SP twice, then returns with STI via RETF 2. Why all those things? Changing the interrupt flag, carry flag and DS all seem to be a bad idea and SP should probably not be incremented like that either, it gets unaligned for a moment. The actual action "if carry set and AH is 6 on return" even is commented out right now and the 8086-compatible method of pushing the value 13h for that looks convoluted. There also is some intWrapCall helper which uses a lot of stack. The next new thing in entry.asm is a new step for the int 19 handler which uses intWrapCall to call int 19 instead of just doing "int 19", but I do not see what the advantage of that is supposed to be. Interestingly, int21_user only calls dos_crit_sect if NOT compiled with Windows 3.1 386enh support? If compiled WITH that, there will instead be an int 2a.8001 call (preserving AX) before byte InDOS is incremented. Also, dos_crit_sect is only called at int21_3 if NOT compiled with Windows support, while it is called after decrementing InDOS at int21_exit instead if compiled WITH Windows support? Note that there is NO call to int 21.8101 (leave critical section) at that point (it is commented out via "if 0") and that dos_crit_sect is what is called (copies AX to a local variable, calls int 2a.82 with preserved AX) which leaves all critical sections 0-7, instead of just a specific one as int 2a.810x would do after int 2a.800x has been called to enter it? What is the "skip to int21_3 if ah is 6" thing about, which has a comment "testing, this function call crashes" next to it? init-mod.h: Adds the int13_handler and makes the lol FAR *const LoL, adding const to the properties of the list of lists pointer. int2f.asm: Adds IntDosCal style functions 13h and 46h and clears BX for function 4a33h for some "undocumented" reason? If Win 3.1 support is compiled in, some non-reentrant switch to a local mux2F_stk_top-30 will be triggered, copying 13 words to it, while preparing for IntDosCal style int 2f functions, of course copying everything back to the user stack later. Why the effort? inthndlr.c: Includes a whole new win.h (as well as debug.h) but win.h itself does not seem to be part of the Win 3.1 compatibility patch? I seem to be missing something here? It also accesses BIOS and user int 13 and int 19 vectors. The updated int2F_12_handler() now has ah=13h "disk interrupt hook" functionality as described in RBIL, which is used by Windows to mess with disk I/O in WDCTRL.386 which insists on this to at least return a changed DS when invoked. It also implements int 2f.1600 / 2f.160a (both NOP), int 2f.1603 (get instance data, dummy because 1607.bx=15 is preferred), int 2f.1605 (Win startup broadcast, returns some data structure, of course does not return optional vm86 on/off callback), 2f.1606 (Win exit broadcast, just logged at the moment) int 2f.1607 is the large VxD API, BX selects which VxD to work with: Only bx 15h supported, DOSMGR: CX 0 returns a flag, the DOS driver data segment (segment of nul_dev) and a patch table, CX 1 activates and CX 2 optionally deactivates patches, CX 3 returns DOS sizes of DOS data structures, CX 4 tells about instance data structures etc.: FreeDOS just reports it would have patched everything as requested for critical section support, to keep Win3 from trying to patch it. This involves features such as int 2a.8x0x calls, machine ID tracking, limiting atomic I/O size (split up to multitask better) and notifying Windows if "halt on stack error" or for "floppy drive DJ messages". For function 3, only the CDS size is counted: FreeDOS pretends that SFT, device list and SDA would all be zero size. Sounds dangerous! Why is the implementation like that? Would Windows only care about the CDS size? What if multiple DOS boxes are opened in Windows 3? Our function 4 suggests that FreeDOS tries to avoid function 3? In function 4, DOS could tell which
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Hello Jeremy, > Eric who's original research helped with the initial > implementation of the necessary patches a decade ago > (https://web.archive.org/web/20061001224249/http://www.coli.uni-saarland.de/~eric/stuff/soft/specials/win3.x-dosext-freedos-notes.txt) Wow that was from 2004 :-o The current URL would be https://auersoft.eu/soft/specials/win3.x-dosext-freedos-notes.txt I think some of the ideas are from Konstantin Koll? Others came from several experts on freedos-devel. Regarding the potential future quality of the kernel (and SHARE) we should not forget the DOSEMU2 people, in other words Stas and the others :-) The problem is how to cherry-pick all goodies from FDPP which are not specific to the DOSEMU2 use case of their FDPP kernel. Regards, Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Hello everyone, So it took me a bit longer than I planned, but below is the information needed to reproduce and links to sources. (Be kind, I know that the code needs more work.) To see it in action, from installing FreeDOS & Windows to running I posted an updated the video (about 4 minutes, sped up some stuff and cut some scenes down but its originally a single recording from first boot until the end) https://youtu.be/4o7TR3Oo6y0 Steps: download boot disk - http://server2.fdos.org/tests/fdos2043w.img contains: kernel *** requires patches, see below for source command.com (FreeCOM) fdisk format sys share edit have available Windows 3.1 install media (*** not provided ***) create a virtual machine (or have a compatible real computer) example has a 200MB hard drive with 32MB of memory and otherwise virtual box's Win 3.1 default settings. boot FreeDOS floppy fdisk create a primary partition, don't use FAT32, use all available space, ensure active reboot so kernel see new partition format format the C: drive and set label as desired fdisk /MBR install master boot record so hard drive is bootable sys C: install system boot record and files to C: partition copies kernel.sys and command.com to C: copy share.com c: copy EDIT.* C: so have available after install Windows Optional: take out (disconnect virtual) floppy from drive and reboot, ensure hard drive boots Optional: create a CONFIG.SYS and AUTOEXEC.BAT so not prompted with date and time Install Windows put in first Windows floppy and run SETUP follow prompts until complete, allow it to modify CONFIG.SYS and AUTOEXEC.BAT Optional: edit AUTOEXEC.BAT to load SHARE.COM (if you do not do this step, you must remember to do so before starting Windows) Edit C:\WINDOWS\SYSTEM.INI (adjust based on actual installation and editor of choice) find [386Enh] section, at bottom add line: InDOSPolling=TRUE save file win start Windows, will be in Enhanced mode if supported Source: Kernel patches - http://server2.fdos.org/tests/kernel-win3-patch.diff rest of sources (kernel, FreeCOM, format, fdisk, sys, share, edit) - https://github.com/fdos Credits: Bart, Tom, and others who have improved the FreeDOS kernel to where it is today All the other FreeDOS developers, especially for FreeCOM, FDISK, FORMAT, and EDIT And Eric who's original research helped with the initial implementation of the necessary patches a decade ago (https://web.archive.org/web/20061001224249/http://www.coli.uni-saarland.de/~eric/stuff/soft/specials/win3.x-dosext-freedos-notes.txt) I will be working on improving the code, specifically the critical section handling and hopefully remove the need for the InDOSPolling flag being set as well. Enjoy, Jeremy ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
That is very good news IMHO, Jeremy!! Sure a thing to wait for, for FreeDOS 1.3 release. I think it is a meaningful milestone (even if there is not many people running Win3.X that wouldn't do it over MS-DOS), but very relevant all the same. All the best, Aitor On Sat, 24 Jul 2021 at 08:02, wrote: > Hello all, > > I thought some of you might enjoy this (others may really dislike it). > Link is to a (posted to YouTube) about 2 minute video of (version > 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and > Standard mode. I haven't pushed the changes to the public GitHub > repository yet as there are still some rough edges to fix (all the > changes are technically there, just in the old unstable branch). I > will make a test version (with source) available later this week along > with steps to run Windows. [I need to go to sleep now.] > > https://youtu.be/35OQjLYdvJ0 > (I apologize for anyone that can't view the video - it is just FreeDOS > kernel booting in VirtualBox, me running a bunch of ver /r commands > and WIN along with a dos prompt, and showing both enhanced and > standard mode.) > > For the technical aspect - the changes are minimal to the kernel, > added support for a few int 2F function calls that were never merged > in was about all it took. All significant changes behind a > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > Enjoy, > Jeremy > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
On Sat, 24 Jul 2021 at 15:29, Steve Nickolas wrote: > > For what it's worth, Windows 3.x comes with its own versions of HIMEM and > SMARTDRV. I *think* it also comes with EMM386, but I'm not so sure about > that one. It did, yes, and IIRC there were problems and/or warnings if you used older DOS versions of these tools that predated $WindowsVersion. But _later_ DOS versions were fine -- e.g. from MS-DOS 5. > I think Windows' 386 mode is pretty heavily tied into undocumented > features of EMM386 when it is active, so it wouldn't surprise me if a free > version of EMM386 made it go down in flames. I don't know that for a fact, but it's possible. However it *did* work fine on DR-DOS' EMM386, and on Quarterdeck's QEMM386 and some other memory managers, so on the whole I do not think so, no. I routinely used 3rd party memory managers with Win 3.0, 3.1, WfWg 3.1 and 3.11 because they enabled more free RAM for DOS apps. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
> > I think Windows' 386 mode is pretty heavily tied into undocumented > features of EMM386 when it is active, so it wouldn't surprise me if a free > version of EMM386 made it go down in flames. > See my earlier reply about the lack of support for the GEMMIS spec in JEMM386. Windows 3.x in 386 Enhanced mode should work with any EMM386 alternative that supports GEMMIS, such as QEMM386, and I believe also 386MAX. Unfortunately, there are currently no Free and Open source EMM386 alternatives with GEMMIS support, at least as far as I know. Is there anybody here with the knowledge and interest to work on such support? There is documentation available for this. See the GitHub issue link I shared in my earlier reply. On Sat, Jul 24, 2021 at 3:29 PM Steve Nickolas wrote: > On Sat, 24 Jul 2021, Eric Auer wrote: > > > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft > > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually > > necessary? I would expect things to also work with HIMEMX or XMGR, > > as long as no free EMM386 is loaded at all? Why do you use 4DOS in > > the DOS window inside Windows? Any special system.ini [386enh] items? > > See my notes below :-) Is setting VERSION=6.0 required, too? > > For what it's worth, Windows 3.x comes with its own versions of HIMEM and > SMARTDRV. I *think* it also comes with EMM386, but I'm not so sure about > that one. Have to check my setup disks. > > I think Windows' 386 mode is pretty heavily tied into undocumented > features of EMM386 when it is active, so it wouldn't surprise me if a free > version of EMM386 made it go down in flames. > > -uso. > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Followup to my last comment, since I actually went and checked. On Sat, 24 Jul 2021, Steve Nickolas wrote: For what it's worth, Windows 3.x comes with its own versions of HIMEM and SMARTDRV. I *think* it also comes with EMM386, but I'm not so sure about that one. Have to check my setup disks. Answer: It comes with its own HIMEM, EMM386, SMARTDRV and RAMDRIVE. -uso. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
On Sat, 24 Jul 2021, Eric Auer wrote: I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually necessary? I would expect things to also work with HIMEMX or XMGR, as long as no free EMM386 is loaded at all? Why do you use 4DOS in the DOS window inside Windows? Any special system.ini [386enh] items? See my notes below :-) Is setting VERSION=6.0 required, too? For what it's worth, Windows 3.x comes with its own versions of HIMEM and SMARTDRV. I *think* it also comes with EMM386, but I'm not so sure about that one. Have to check my setup disks. I think Windows' 386 mode is pretty heavily tied into undocumented features of EMM386 when it is active, so it wouldn't surprise me if a free version of EMM386 made it go down in flames. -uso. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
On Sat, Jul 24, 2021, 6:43 AM Eric Auer wrote: > > Hi Jeremy, > > does that mean the unstable kernel already supported Win 3.1 386enh? > Yes, but it didn't work as well for running a dos prompt, 1st character typed was lost and possibly other issues > Cool to know :-) How about Windows for Workgroups in 386 mode, which > is "non safe mode" there, so features are lost without it in WfW 3.11? > I have not yet tested it yet > Thanks for cherry-picking all the relevant patches! I guess the FDPP > kernel of DOSEMU2 will have some more of those for you ;-) > > Checking your video, it says kernel 2043 build Jul 24 2021, > but the copyright messages says 1995-2012, probably a typo. > I guess that date hasn't been updated in a while :-) > Do you have a link to the relevant patchsets for proof-reading > in case there is a risk of regressions? > I will post them later today, but yes more work is needed to ensure no regressions > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually > necessary? I would expect things to also work with HIMEMX or XMGR, > as long as no free EMM386 is loaded For my initial work I wanted to limit possible issues, so I started with versions I know work with Windows 3 since they came with it. These specific versions are not a requirement. at all? Why do you use 4DOS in > the DOS window inside Windows? Any I believe it is because I have 4dos as my c:/command.com so that is being spawned, but I may have set it explicitly at some point in the past. I originally tested with 4dos just like other programs, because it is known to work. special system.ini [386enh] items? > I don't recall, this is a virtual machine I set up years ago. I am going to create a new one from scratch and document the steps so anyone (with win3) can reproduce, just haven't had time yet See my notes below :-) Is setting VERSION=6.0 required, too? > No, just minimizing possible issues for initial testing > Cool that WIN, WIN /3 and WIN /S apparently all work :-) > Some custom (un-)settings from an old system.ini [386enh] of mine: > > ; device=lanman10.386 > ; mouse=lvmd.386 > ; network=*dosnet,*vnetbios > ; old version: device=*vtd new version: device=vtda.386 (in "WW0981" fix) > device=vtda.386 > FileSysChange=0 > PagingFile=C:\WINDOWS\WIN386.SWP MaxPagingFileSize=1024 > ; also: PermSwapDOSDrive=... PermSwapSizeK=... > ; disable swapfile stuff: > Paging=0 > ; prepare for more than 200 breakpoints, 150 is minimum useful: > MaxBPs=768 > ; better if lots of RAM: > PageOverCommit=1 > ; equivalent of /D:FSVX > 32BitDiskAccess=No > SystemROMBreakPoint=No VirtualHDIrq=No > ; *** EMMEXclude=A000- > NoEmmDriver=1 > IgnoreInstalledEMM=1 > WinExclusive=1 > ; > TimerCriticalSection=1 > DMABufferSize=64 > XlatBufferSize=128 > KeyBoostTime=.005 > MinUserDiskSpace=5120 > PageBuffer=32 > Com1Buffer=512 > ComBoostTime=20 > Com1AutoAssign=-1 > ScreenLines=50 > ; > InDOSPolling=1 > ; P.V.F.: 10, or 0 if share installed > PerVMFILES=0 > ReflectDosInt2a=1 > INT28Critical=1 > ; I.V.W.U.T.: 1/2/4/*8*... seconds: how often to pump int 8/1c into idle > VMs > IdleVMWakeUpTime=1 > ; D.P.E.I.: enable to get explanation how to leave DOS box when starting > one > DOSPromptExitInstruc=0 > ; force DMA buffers to be in 1st 1MB range: > DMABufferIn1MB=1 > > For standard mode, I also had those settings: > > [standard] > ; Stacks=12 (8..64) StackSize=384 - Settings for DOSX DOS Extender > ; Int28Filter=0,1..*10*..: only let through every Nth int 28 ... > Stacks=16 > StackSize=512 > Int28Filter=1 > DOSPromptExitInstruc=0 > > Note that Windows 3.x all have issues when you have too much > RAM. There are binary patch files for that, but the obvious > other workaround is telling your EMM386 or HIMEM or similar > to not let Windows know how much RAM you really have ;-) > I went the simple way and limited the memory to my VM and it's disk size. > Cheers, Eric > > > https://youtu.be/35OQjLYdvJ0 > > > For the technical aspect - the changes are minimal to the kernel, > > added support for a few int 2F function calls that were never merged > > in was about all it took. All significant changes behind a > > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > I will post an update with better details as soon as I can, hopefully this evening. Jeremy ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Great work Jeremy! Watching your YouTube video, I noticed the FreeDOS VM booting with Microsoft EMM386. And that makes sense, since JEMM386 currently doesn't support GEMMIS, a standard required for by Win3.x and Win9x for memory management handover from the EMM manager to the Windows kernel as it starts up from DOS. (That's necessary when you want to start Windows 3.x in 386 Enhanced mode while having an EMM manager loaded.) There is an outstanding feature request for GEMMIS in JEMM, but the JEMM maintainer has expressed a disinterest in adding such support: https://github.com/Baron-von-Riedesel/Jemm/issues/5 That's unfortunate, since GEMMIS support in JEMM, in addition to Jeremy's FreeDOS kernel patch, would result in full support for Windows 3.x (and even Win9x) by the FreeDOS distribution. Would any other developer here with the necessary expertise be willing to work on GEMMIS support in JEMM? Or perhaps on adding GEMMIS to another open source EMM386 alternative? For instance, wasn't there an older EMM386 alternative that used to ship with FreeDOS before it was replaced with JEMM? Apparently, there is a GEMMIS implementation integrated in DOSBox, so this code could perhaps be copied or used as an example, when implementing GEMMIS in JEMM or in another open source EMM386 alternative. And in addition to that, another question for Jeremy: I also noticed how that DOS window within Windows 3.11 still seemed to "boot" an instance of MS-DOS as opposed to FreeDOS. Would it be possible to have the DOS windows inside Windows launch FreeDOS instead as well? Or would that require patching Windows itself? Thanks again! On Sat, Jul 24, 2021 at 12:43 PM Eric Auer wrote: > > Hi Jeremy, > > does that mean the unstable kernel already supported Win 3.1 386enh? > > Cool to know :-) How about Windows for Workgroups in 386 mode, which > is "non safe mode" there, so features are lost without it in WfW 3.11? > > Thanks for cherry-picking all the relevant patches! I guess the FDPP > kernel of DOSEMU2 will have some more of those for you ;-) > > Checking your video, it says kernel 2043 build Jul 24 2021, > but the copyright messages says 1995-2012, probably a typo. > > Do you have a link to the relevant patchsets for proof-reading > in case there is a risk of regressions? > > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually > necessary? I would expect things to also work with HIMEMX or XMGR, > as long as no free EMM386 is loaded at all? Why do you use 4DOS in > the DOS window inside Windows? Any special system.ini [386enh] items? > See my notes below :-) Is setting VERSION=6.0 required, too? > > Cool that WIN, WIN /3 and WIN /S apparently all work :-) > > Some custom (un-)settings from an old system.ini [386enh] of mine: > > ; device=lanman10.386 > ; mouse=lvmd.386 > ; network=*dosnet,*vnetbios > ; old version: device=*vtd new version: device=vtda.386 (in "WW0981" fix) > device=vtda.386 > FileSysChange=0 > PagingFile=C:\WINDOWS\WIN386.SWP > MaxPagingFileSize=1024 > ; also: PermSwapDOSDrive=... PermSwapSizeK=... > ; disable swapfile stuff: > Paging=0 > ; prepare for more than 200 breakpoints, 150 is minimum useful: > MaxBPs=768 > ; better if lots of RAM: > PageOverCommit=1 > ; equivalent of /D:FSVX > 32BitDiskAccess=No > SystemROMBreakPoint=No > VirtualHDIrq=No > ; *** EMMEXclude=A000- > NoEmmDriver=1 > IgnoreInstalledEMM=1 > WinExclusive=1 > ; > TimerCriticalSection=1 > DMABufferSize=64 > XlatBufferSize=128 > KeyBoostTime=.005 > MinUserDiskSpace=5120 > PageBuffer=32 > Com1Buffer=512 > ComBoostTime=20 > Com1AutoAssign=-1 > ScreenLines=50 > ; > InDOSPolling=1 > ; P.V.F.: 10, or 0 if share installed > PerVMFILES=0 > ReflectDosInt2a=1 > INT28Critical=1 > ; I.V.W.U.T.: 1/2/4/*8*... seconds: how often to pump int 8/1c into idle > VMs > IdleVMWakeUpTime=1 > ; D.P.E.I.: enable to get explanation how to leave DOS box when starting > one > DOSPromptExitInstruc=0 > ; force DMA buffers to be in 1st 1MB range: > DMABufferIn1MB=1 > > For standard mode, I also had those settings: > > [standard] > ; Stacks=12 (8..64) StackSize=384 - Settings for DOSX DOS Extender > ; Int28Filter=0,1..*10*..: only let through every Nth int 28 ... > Stacks=16 > StackSize=512 > Int28Filter=1 > DOSPromptExitInstruc=0 > > Note that Windows 3.x all have issues when you have too much > RAM. There are binary patch files for that, but the obvious > other workaround is telling your EMM386 or HIMEM or similar > to not let Windows know how much RAM you really have ;-) > > Cheers, Eric > > > https://youtu.be/35OQjLYdvJ0 > > > For the technical aspect - the changes are minimal to the kernel, > > added support for a few int 2F function calls that were never merged > > in was about all it took. All significant changes behind a > > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > > > ___ > Freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Hi Jeremy, does that mean the unstable kernel already supported Win 3.1 386enh? Cool to know :-) How about Windows for Workgroups in 386 mode, which is "non safe mode" there, so features are lost without it in WfW 3.11? Thanks for cherry-picking all the relevant patches! I guess the FDPP kernel of DOSEMU2 will have some more of those for you ;-) Checking your video, it says kernel 2043 build Jul 24 2021, but the copyright messages says 1995-2012, probably a typo. Do you have a link to the relevant patchsets for proof-reading in case there is a risk of regressions? I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually necessary? I would expect things to also work with HIMEMX or XMGR, as long as no free EMM386 is loaded at all? Why do you use 4DOS in the DOS window inside Windows? Any special system.ini [386enh] items? See my notes below :-) Is setting VERSION=6.0 required, too? Cool that WIN, WIN /3 and WIN /S apparently all work :-) Some custom (un-)settings from an old system.ini [386enh] of mine: ; device=lanman10.386 ; mouse=lvmd.386 ; network=*dosnet,*vnetbios ; old version: device=*vtd new version: device=vtda.386 (in "WW0981" fix) device=vtda.386 FileSysChange=0 PagingFile=C:\WINDOWS\WIN386.SWP MaxPagingFileSize=1024 ; also: PermSwapDOSDrive=... PermSwapSizeK=... ; disable swapfile stuff: Paging=0 ; prepare for more than 200 breakpoints, 150 is minimum useful: MaxBPs=768 ; better if lots of RAM: PageOverCommit=1 ; equivalent of /D:FSVX 32BitDiskAccess=No SystemROMBreakPoint=No VirtualHDIrq=No ; *** EMMEXclude=A000- NoEmmDriver=1 IgnoreInstalledEMM=1 WinExclusive=1 ; TimerCriticalSection=1 DMABufferSize=64 XlatBufferSize=128 KeyBoostTime=.005 MinUserDiskSpace=5120 PageBuffer=32 Com1Buffer=512 ComBoostTime=20 Com1AutoAssign=-1 ScreenLines=50 ; InDOSPolling=1 ; P.V.F.: 10, or 0 if share installed PerVMFILES=0 ReflectDosInt2a=1 INT28Critical=1 ; I.V.W.U.T.: 1/2/4/*8*... seconds: how often to pump int 8/1c into idle VMs IdleVMWakeUpTime=1 ; D.P.E.I.: enable to get explanation how to leave DOS box when starting one DOSPromptExitInstruc=0 ; force DMA buffers to be in 1st 1MB range: DMABufferIn1MB=1 For standard mode, I also had those settings: [standard] ; Stacks=12 (8..64) StackSize=384 - Settings for DOSX DOS Extender ; Int28Filter=0,1..*10*..: only let through every Nth int 28 ... Stacks=16 StackSize=512 Int28Filter=1 DOSPromptExitInstruc=0 Note that Windows 3.x all have issues when you have too much RAM. There are binary patch files for that, but the obvious other workaround is telling your EMM386 or HIMEM or similar to not let Windows know how much RAM you really have ;-) Cheers, Eric > https://youtu.be/35OQjLYdvJ0 > For the technical aspect - the changes are minimal to the kernel, > added support for a few int 2F function calls that were never merged > in was about all it took. All significant changes behind a > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
This is awesome! :D Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, July 24th, 2021 at 2:01 AM, wrote: > Hello all, > > I thought some of you might enjoy this (others may really dislike it). > > Link is to a (posted to YouTube) about 2 minute video of (version > > 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and > > Standard mode. I haven't pushed the changes to the public GitHub > > repository yet as there are still some rough edges to fix (all the > > changes are technically there, just in the old unstable branch). I > > will make a test version (with source) available later this week along > > with steps to run Windows. [I need to go to sleep now.] > > https://youtu.be/35OQjLYdvJ0 > > (I apologize for anyone that can't view the video - it is just FreeDOS > > kernel booting in VirtualBox, me running a bunch of ver /r commands > > and WIN along with a dos prompt, and showing both enhanced and > > standard mode.) > > For the technical aspect - the changes are minimal to the kernel, > > added support for a few int 2F function calls that were never merged > > in was about all it took. All significant changes behind a > > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > Enjoy, > > Jeremy > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Awesome! This is perhaps the last big feature DR-DOS and PC-DOS had over FreeDOS. July 24, 2021 6:03 AM, perditi...@gmail.com wrote: > Hello all, > > I thought some of you might enjoy this (others may really dislike it). > Link is to a (posted to YouTube) about 2 minute video of (version > 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and > Standard mode. I haven't pushed the changes to the public GitHub > repository yet as there are still some rough edges to fix (all the > changes are technically there, just in the old unstable branch). I > will make a test version (with source) available later this week along > with steps to run Windows. [I need to go to sleep now.] > > https://youtu.be/35OQjLYdvJ0 > (I apologize for anyone that can't view the video - it is just FreeDOS > kernel booting in VirtualBox, me running a bunch of ver /r commands > and WIN along with a dos prompt, and showing both enhanced and > standard mode.) > > For the technical aspect - the changes are minimal to the kernel, > added support for a few int 2F function calls that were never merged > in was about all it took. All significant changes behind a > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > Enjoy, > Jeremy > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] video FreeDOS running Windows 3.1
Hello all, I thought some of you might enjoy this (others may really dislike it). Link is to a (posted to YouTube) about 2 minute video of (version 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and Standard mode. I haven't pushed the changes to the public GitHub repository yet as there are still some rough edges to fix (all the changes are technically there, just in the old unstable branch). I will make a test version (with source) available later this week along with steps to run Windows. [I need to go to sleep now.] https://youtu.be/35OQjLYdvJ0 (I apologize for anyone that can't view the video - it is just FreeDOS kernel booting in VirtualBox, me running a bunch of ver /r commands and WIN along with a dos prompt, and showing both enhanced and standard mode.) For the technical aspect - the changes are minimal to the kernel, added support for a few int 2F function calls that were never merged in was about all it took. All significant changes behind a WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. Enjoy, Jeremy ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
