Re: [Freedos-user] command / shell conflict
Don, in my opinion this is a SHELL bug. after executing a program (being it command.com or dataperfect), shell does some 'cleanup' code. it simply thinks that all (MZ) memory blocks above SHELL.EXE are leftovers from external execution, and calls DOSfree(). if they are leftover PSPs, the potential environment at psp:[2c] is also freed. now freedos command.com loads it's own environment as high as possible; usually at around 9F9F:0. when SHELL executes an external program, this environment gets freed, and soon after trashed. SHELL bug. case closed. Tom am 6. Juni 2016 um 12:42 schrieben Sie: >>So "all my path variables are intact" means there is probably a memory >>corruption issue somewhere?? > Since this happens on every PC (7 total) that is unlikely; and > this does not happen with the regular DOSes. > I am now using a menu (PowerMenu by Brown Bag Software) with the > %WPSHELL%/C command and our current FreeCOM which is working well. >>You mean "SET" within FDCONFIG.SYS?? > > I have a MENU selection in FDCONFIG.SYS pointing to an IF > "%config%" option in AUTOEXEC.BAT which loads my PowerMenu which > takes over from there, this is the "cleanest" way of resolving the issue that > I have found. >>But yes, FreeCOM has various bugs and needs to be cleaned up and >fixed >>(eventually), but so far nobody has stepped up to do it. > Yeah, we need to prioritize that for 2.0. > > On Mon, Jun 6, 2016 at 4:31 AM, Rugxulo wrote: > Hi, > > On Sat, Jun 4, 2016 at 4:34 AM, Don Flowers wrote: >> UPDATE: >> So after three or four loads of shell.exe per session, the strings error >> showed up again (Freecom 0.84) > > Even when using "/MSG /P"? So what is the implication, that there's a > memory leak in FreeCOM somewhere? I wouldn't be too surprised. > >> and Freecom 0.80 has some issues (2GB max shown on HD, OGN not recognized) > > Testing an old release for comparison? Why not test 0.82pl3 from SF.net? > > > https://sourceforge.net/projects/freedos/files/FreeCOM/082pl3%20%28use%20xmsswap%20for%20386%2B%20PC%29/ > > But yes, FreeCOM has various bugs and needs to be cleaned up and fixed > (eventually), but so far nobody has stepped up to do it. > >> I discovered one other alternative that seems to be working - I set a >> %config% variable (SET WPSHELL=C:\DP23\SHELL.EXE), > > You mean "SET" within FDCONFIG.SYS?? > >> then %WPSHELL% /C; >> following that I execute a batch file with the same command and the shell >> loads as it should and on exit all my path variables are intact with no >> strings error messages. > > So "all my path variables are intact" means there is probably a memory > corruption issue somewhere?? > > >> On Mon, May 23, 2016 at 5:21 PM, Rugxulo wrote: >>> >>> On Mon, May 23, 2016 at 4:18 PM, Don Flowers wrote: >>> > >>> > So /MSG seems to work, more testing needed to be sure, What does this >>> > switch >>> > do, (besides help me of course)? >>> >>> http://help.fdos.org/en/hhstndrd/base/command.htm >>> >>> "/MSG Stores all error messages in memory (requires /P as well)." > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. > https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
Tom, I'll defer to your expertise and consider it so on my end as well; thanks for taking the time to debug it. On Wed, Jun 8, 2016 at 11:12 AM, Tom Ehlert wrote: > Don, > > in my opinion this is a SHELL bug. > > after executing a program (being it command.com or dataperfect), shell > does some 'cleanup' code. > > it simply thinks that all (MZ) memory blocks above SHELL.EXE are leftovers > from external execution, and calls DOSfree(). if they are leftover > PSPs, the potential environment at psp:[2c] is also freed. > > > > now freedos command.com loads it's own environment as high as > possible; usually at around 9F9F:0. > > when SHELL executes an external program, this environment gets freed, > and soon after trashed. > > > SHELL bug. case closed. > > Tom > > > > > > > > > > am 6. Juni 2016 um 12:42 schrieben Sie: > > >>So "all my path variables are intact" means there is probably a memory > >>corruption issue somewhere?? > > > Since this happens on every PC (7 total) that is unlikely; and > > this does not happen with the regular DOSes. > > > I am now using a menu (PowerMenu by Brown Bag Software) with the > > %WPSHELL%/C command and our current FreeCOM which is working well. > > >>You mean "SET" within FDCONFIG.SYS?? > > > > I have a MENU selection in FDCONFIG.SYS pointing to an IF > > "%config%" option in AUTOEXEC.BAT which loads my PowerMenu which > > takes over from there, this is the "cleanest" way of resolving the issue > that I have found. > > >>But yes, FreeCOM has various bugs and needs to be cleaned up and >fixed > >>(eventually), but so far nobody has stepped up to do it. > > > > Yeah, we need to prioritize that for 2.0. > > > > > > > > > > On Mon, Jun 6, 2016 at 4:31 AM, Rugxulo wrote: > > > Hi, > > > > On Sat, Jun 4, 2016 at 4:34 AM, Don Flowers wrote: > >> UPDATE: > >> So after three or four loads of shell.exe per session, the strings > error showed up again (Freecom 0.84) > > > > Even when using "/MSG /P"? So what is the implication, that there's a > > memory leak in FreeCOM somewhere? I wouldn't be too surprised. > > > >> and Freecom 0.80 has some issues (2GB max shown on HD, OGN not > recognized) > > > > Testing an old release for comparison? Why not test 0.82pl3 from SF.net? > > > > > > > https://sourceforge.net/projects/freedos/files/FreeCOM/082pl3%20%28use%20xmsswap%20for%20386%2B%20PC%29/ > > > > But yes, FreeCOM has various bugs and needs to be cleaned up and fixed > > (eventually), but so far nobody has stepped up to do it. > > > >> I discovered one other alternative that seems to be working - I set a > >> %config% variable (SET WPSHELL=C:\DP23\SHELL.EXE), > > > > You mean "SET" within FDCONFIG.SYS?? > > > >> then %WPSHELL% /C; > >> following that I execute a batch file with the same command and the > shell > >> loads as it should and on exit all my path variables are intact with no > >> strings error messages. > > > > So "all my path variables are intact" means there is probably a memory > > corruption issue somewhere?? > > > > > >> On Mon, May 23, 2016 at 5:21 PM, Rugxulo wrote: > >>> > >>> On Mon, May 23, 2016 at 4:18 PM, Don Flowers > wrote: > >>> > > >>> > So /MSG seems to work, more testing needed to be sure, What does > this > >>> > switch > >>> > do, (besides help me of course)? > >>> > >>> http://help.fdos.org/en/hhstndrd/base/command.htm > >>> > >>> "/MSGStores all error messages in memory (requires /P as > well)." > > > > > > > -- > > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > > patterns at an interface-level. Reveals which users, apps, and > protocols are > > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > > J-Flow, sFlow and other flows. Make informed decisions using capacity > > planning reports. > > https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > > > > ___ > > Freedos-user mailing list > > Freedos-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-user > > > > > > > Mit freundlichen Grüßen/Kind regards > Tom Ehlert > +49-241-79886 > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- What NetFlow Analyzer can do for you? Moni
Re: [Freedos-user] command / shell conflict
This actually sounds similar to a problem I was having with FreeDOS, which I needed to work around in my programs. In my case, the problem is actually with how FreeDOS allocates memory. I don't know for sure if this is the same thing or not, but it could be related. In my particular case, the problem occurs when I try to install a TSR in CONFIG.SYS using the INSTALL= option. FreeDOS installs its code, including the code it needs to return to when it's done "installing" my TSR, at the top of conventional memory. In and of itself this is not a problem. But, the memory that the FreeDOS kernel uses is simply used without actually being allocated (there is no MCB to prevent other programs from trying to use the same memory). My programs intentionally use the upper end of conventional memory themselves (part of the process they use to minimize memory use). The result is that my programs clobber the memory that the kernel was using, and everything crashes when my program exits. The root cause is a bug in the FreeDOS kernel (not always allocating memory with an MCB like it should), not with my programs. My programs are able to detect the problem and "work around" it. AFAIK, this only occurs in FreeDOS and not any others (at least not MS-DOS or PC-DOS). Again, I don't know if this is actually related or not, but it sounds like it could be. Nextiva vFAX Why Do You Still Have An Old Fax Machine? http://thirdpartyoffers.juno.com/TGL3141/57585e231e5955e22334bst01vuc -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
On Jun 8, 2016 2:05 PM, "Bret Johnson" wrote: > > This actually sounds similar to a problem I was having with FreeDOS, which I needed to work around in my programs. In my case, the problem is actually with how FreeDOS allocates memory. I don't know for sure if this is the same thing or not, but it could be related. > > In my particular case, the problem occurs when I try to install a TSR in CONFIG.SYS using the INSTALL= option. FreeDOS installs its code, including the code it needs to return to when it's done "installing" my TSR, at the top of conventional memory. In and of itself this is not a problem. But, the memory that the FreeDOS kernel uses is simply used without actually being allocated (there is no MCB to prevent other programs from trying to use the same memory). > ... This should be fixed (or at least better) in an upcoming kernel later this year. If you could direct me to one of your programs that works with MS-DOS but not FD kernel that I can test with, I would appreciate it. Given Tom's email, I gather this is a different but similar issue though. Jeremy -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
Hi Bret, the problem of using but not reserving memory for the kernel in FreeDOS sounds vaguely similar to the problem of HMA usage in DOS in general: DOS installs trampoline handlers outside HMA which make sure that the HMA is actually enabled before DOS calls code there. Maybe a similar approach could be used for the unallocated FreeDOS memory? It could check if the not-reserved temp data is still valid and if not, avoid attempts to use it. Of course it would be better if FreeDOS could behave and use MCB for that temp data in the first place, but I do not know the ins and outs of why it does not or maybe can not do that now. Also, this could be relevant for the way in which FreeCOM misbehaves by using without allocating memory, if I understand the other mails well. It should probably check if the data left in RAM is still valid and if not, reload the (message string) data from disk or from XMS swap RAM? Regards, Eric -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
I'm going to try a couple of things in DOS 5.0 and DOS 6.20, I'll be back. On Wed, Jun 8, 2016 at 2:52 PM, Eric Auer wrote: > > Hi Bret, > > the problem of using but not reserving memory for the kernel in FreeDOS > sounds vaguely similar to the problem of HMA usage in DOS in general: > > DOS installs trampoline handlers outside HMA which make sure that the > HMA is actually enabled before DOS calls code there. Maybe a similar > approach could be used for the unallocated FreeDOS memory? > > It could check if the not-reserved temp data is still valid and if not, > avoid attempts to use it. Of course it would be better if FreeDOS could > behave and use MCB for that temp data in the first place, but I do not > know the ins and outs of why it does not or maybe can not do that now. > > Also, this could be relevant for the way in which FreeCOM misbehaves by > using without allocating memory, if I understand the other mails well. > > It should probably check if the data left in RAM is still valid and if > not, reload the (message string) data from disk or from XMS swap RAM? > > Regards, Eric > > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
I just tried this on Compaq DOS 5.0 with Compaq Himem only with no errors and no missing paths. So unless it's a FAT32 problem it must go back to FreeDOS somehow??? On Wed, Jun 8, 2016 at 3:30 PM, Don Flowers wrote: > I'm going to try a couple of things in DOS 5.0 and DOS 6.20, I'll be back. > > On Wed, Jun 8, 2016 at 2:52 PM, Eric Auer wrote: > >> >> Hi Bret, >> >> the problem of using but not reserving memory for the kernel in FreeDOS >> sounds vaguely similar to the problem of HMA usage in DOS in general: >> >> DOS installs trampoline handlers outside HMA which make sure that the >> HMA is actually enabled before DOS calls code there. Maybe a similar >> approach could be used for the unallocated FreeDOS memory? >> >> It could check if the not-reserved temp data is still valid and if not, >> avoid attempts to use it. Of course it would be better if FreeDOS could >> behave and use MCB for that temp data in the first place, but I do not >> know the ins and outs of why it does not or maybe can not do that now. >> >> Also, this could be relevant for the way in which FreeCOM misbehaves by >> using without allocating memory, if I understand the other mails well. >> >> It should probably check if the data left in RAM is still valid and if >> not, reload the (message string) data from disk or from XMS swap RAM? >> >> Regards, Eric >> >> >> >> >> -- >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. >> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e >> ___ >> Freedos-user mailing list >> Freedos-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-user >> > > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
Hi Don, you probably misunderstood me. I said that DOS in general has security code in the kernel to make sure that the HMA is activated before parts of the kernel which are stored in HMA get used. The security code itself is kept outside the HMA... What exactly were you testing with FAT32 and Compaq and FreeDOS and which test results and differences did you see or expect in that testing now? Regards, Eric > I just tried this on Compaq DOS 5.0 with Compaq Himem only with no errors > and no missing paths. So unless it's a FAT32 problem it must go back to > FreeDOS somehow??? > On Wed, Jun 8, 2016 at 3:30 PM, Don Flowers wrote: >> I'm going to try a couple of things in DOS 5.0 and DOS 6.20, I'll be back. >> On Wed, Jun 8, 2016 at 2:52 PM, Eric Auer wrote: ... >>> the problem of using but not reserving memory for the kernel in FreeDOS >>> sounds vaguely similar to the problem of HMA usage in DOS in general: >>> >>> DOS installs trampoline handlers outside HMA which make sure that the >>> HMA is actually enabled before DOS calls code there. Maybe a similar >>> approach could be used for the unallocated FreeDOS memory? ... -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command / shell conflict
Hi Eric, I did misunderstand, I get it now. As far as the Compaq DOS experiement is was on a FAT16 whereas all my FreeDOSs are in FAT32 (some as large as 100GB). On Wed, Jun 8, 2016 at 6:50 PM, Eric Auer wrote: > > Hi Don, > > you probably misunderstood me. I said that DOS in general has security > code in the kernel to make sure that the HMA is activated before parts > of the kernel which are stored in HMA get used. The security code itself > is kept outside the HMA... What exactly were you testing with FAT32 and > Compaq and FreeDOS and which test results and differences did you see or > expect in that testing now? > > Regards, Eric > > > > I just tried this on Compaq DOS 5.0 with Compaq Himem only with no errors > > and no missing paths. So unless it's a FAT32 problem it must go back to > > FreeDOS somehow??? > > > > On Wed, Jun 8, 2016 at 3:30 PM, Don Flowers wrote: > >> I'm going to try a couple of things in DOS 5.0 and DOS 6.20, I'll be > back. > > > >> On Wed, Jun 8, 2016 at 2:52 PM, Eric Auer wrote: > ... > >>> the problem of using but not reserving memory for the kernel in FreeDOS > >>> sounds vaguely similar to the problem of HMA usage in DOS in general: > >>> > >>> DOS installs trampoline handlers outside HMA which make sure that the > >>> HMA is actually enabled before DOS calls code there. Maybe a similar > >>> approach could be used for the unallocated FreeDOS memory? > > ... > > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user