Re: [Freedos-devel] The other MORE issue
Thanks for letting me know. I've created a new bug to track this: https://sourceforge.net/p/freedos/bugs/319/ On Sat, Jul 24, 2021 at 10:25 AM Jerome Shidel wrote: > > Hi, > > The other day during the online get-together, Jim said he was going > to look into fixing an issue with more regarding where the source > for the text was coming. I mentioned there was another issue. But, I > could not seem to replicate it at the time. This is a followup to > that conversation. > > Jim, I figured out the how to replicate the issue… > > When more pauses at the end of a page, it displays "— More — > (??)—" You press a key, and the “MORE” line is replaced by the next > line of text from STDIN. The problem is MORE does not clear it’s > text from the screen, it just overwrites it. If you a piping it > something with short lines, it leaves garbage behind. > > For example, if MORE paused and the next line was “Beds" you would > see "Bedsore (??)—“ > > Anyhow... Since you plan on digging more into more, you may want to >fix this as well. > > :-) > > Jerome > ___ 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
[Freedos-devel] The other MORE issue
Hi, The other day during the online get-together, Jim said he was going to look into fixing an issue with more regarding where the source for the text was coming. I mentioned there was another issue. But, I could not seem to replicate it at the time. This is a followup to that conversation. Jim, I figured out the how to replicate the issue… When more pauses at the end of a page, it displays "— More — (??)—" You press a key, and the “MORE” line is replaced by the next line of text from STDIN. The problem is MORE does not clear it’s text from the screen, it just overwrites it. If you a piping it something with short lines, it leaves garbage behind. For example, if MORE paused and the next line was “Beds" you would see "Bedsore (??)—“ Anyhow... Since you plan on digging more into more, you may want to fix this as well. :-) Jerome ___ 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
