Oh oh. I was mistaken. It was Dave Dunfield's MC323EXA.ZIP with the files ./DOSUTIL/REDIRECT.TXT ./DOSUTIL/RERROR.C ./DOSUTIL/ROUTPUT.C
RERROR handles stderr capture via DOS. ROUTPUT handles ALL text capture via BIOS. http://dunfield.classiccmp.org/dos/mc323exa.zip On Thu, Mar 23, 2023 at 5:04 PM Louis Santillan <lpsan...@gmail.com> wrote: > > I forget which one and which version, but it had the ability to > redirect the blacked out screen to a file. Been a long while since I > looked at them. > > On Thu, Mar 23, 2023 at 4:14 PM <jer...@shidel.net> wrote: > > > > Hi Louis, > > > > > On Mar 23, 2023, at 5:32 PM, Louis Santillan <lpsan...@gmail.com> wrote: > > > > > > Don’t blackout and bootsplash do something like this? > > > > > > > > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/blackout/ > > > > > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/bootsplash/ > > > > > > > Just to make sure I was not wasting my time, I looked at the readme files > > for those. Bootsplash looks like it is just a tweaked version of blackout. > > Blackout itself tries to provide a boot graphic like Windows and suppress > > device driver messages. I did not bother to try running them and don’t know > > if they bother animating the the graphic not. If I were making a boot > > splash splash screen, it would be animated. > > > > Regardless, this is absolutely not the functionality desired. Other than > > some startup messages, you won’t even know it is running. Development is > > going well. It is actually two programs. LOGGER.SYS is the device driver > > and LOG.COM (may change it to LOGGER.COM) to interact with the driver. > > > > Basically, you load the driver after your memory managers (HIMEM & EMM or > > equivalent). The driver will then log all messages to XMS memory. Later on, > > LOG.COM will tell the driver to stop logging. LOG.COM will also be able to > > save the logged information, clear the log and start (or stop) logging > > again. Maybe add log viewing in color as well at some point. > > > > At present, the driver loads and takes control of what it needs, tests for > > XMS and allocates memory. The interface program can find and talk to the > > driver. > > > > Next up, is capturing a decent log. Then, add printing/saving that log to > > the interface program. > > > > Finally, add command line option support to both. For the driver, that > > would permit adjusting the XMS memory allocated for the cyclic log buffer. > > For the interface program, to perform the basic interaction stuff. > > > > Although, there a a couple things in the driver I may just outsource to the > > interaction program to reduce the memory footprint a little. I haven’t > > decided. > > > > :-) > > > > Jerome > > > > > On Thu, Mar 23, 2023 at 5:52 AM <jer...@shidel.net> wrote: > > > Hi All, > > > > > > I decided I needed to take a break from my current project and do > > > something relatively easy and fun. > > > > > > So, I’ve begun working on a Boot Message Logger. Hopefully, it will be > > > ready for T2304. > > > > > > That just depends on if I can find the time to finish it up by that Build. > > > > > > If not, it will defiantly be in T2305. > > > > > > :-) > > > > > > Jerome > > > > > > > > >> On Mar 20, 2023, at 7:35 PM, Mercury Thirteen via Freedos-devel > > >> <freedos-devel@lists.sourceforge.net> wrote: > > >> > > >> Right, same basic idea. I guess the main difference is using the spare > > >> video memory as a starting buffer, but regular ol' RAM would be fine > > >> too. :) > > >> > > >> > > >> > > >> > > >> Sent with Proton Mail secure email. > > >> > > >> ------- Original Message ------- > > >> On Monday, March 20th, 2023 at 7:23 PM, jer...@shidel.net > > >> <jer...@shidel.net> wrote: > > >> > > >>> Hi, > > >>> > > >>>> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel > > >>>> <freedos-devel@lists.sourceforge.net> wrote: > > >>>> > > >>>> I realize this may be more trouble than it's worth, but it's > > >>>> technically possible to write up a small "shim" program which simply > > >>>> hooks the character printing interrupts and copies any characters > > >>>> passed to a small memory buffer* before forwarding them to the regular > > >>>> printing interrupt. This shim would need to be named COMMAND.COM so > > >>>> that it is loaded first after the kernel, and once this hook is > > >>>> established the shim would then pass control on to the real > > >>>> COMMAND.COM. > > >>>> > > >>>> * As I recall, the basic text mode offers multiple - what is it, > > >>>> eight? - pages of text, and this extra video memory could possibly be > > >>>> used as a memory buffer to avoid cutting into the available memory > > >>>> which applications could otherwise use. Once an XMS driver is loaded, > > >>>> the contents could be copied to an XMS block, freeing up the video > > >>>> memory for use by applications who actually use it for its intended > > >>>> purpose. > > >>>> > > >>>> Ok, all done. Now you're all free to shoot that idea full of holes! > > >>>> haha > > >>> > > >>> Same basic Idea as what I was saying. :-) > > >>> > > >>> Although, I’d do it as a device driver that you could load first, then > > >>> switch from temp storage to XMS when the memory drivers have been > > >>> loaded. Finally, after the boot process is complete, you could turn > > >>> off logging or switch to StdErr only logging. But, most programs don’t > > >>> use that device and just output errors to StdOut. > > >>> > > >>> Anyhow, the driver method would also capture messages by other device > > >>> drivers before the command shell is even loaded. > > >>> > > >>> It is not actually very difficult to do. But, like everything, it still > > >>> would take at least some time to make and test. > > >>> > > >>> Maybe I’ll whip one up if I get bored or just want to work on something > > >>> other than my current project for a little while. > > >>> > > >>> :-) > > >>> > > >>> Jerome > > >>> > > >>>> > > >>>> Sent with Proton Mail secure email. > > >>>> > > >>>> ------- Original Message ------- > > >>>> On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net > > >>>> <jer...@shidel.net> wrote: > > >>>> > > >>>>> Hi Paul, > > >>>>> > > >>>>>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel > > >>>>>> <freedos-devel@lists.sourceforge.net> wrote: > > >>>>>> > > >>>>>> So many messages on boot I cannot scroll back. > > >>>>>> If only the boot process would also copy everything in a boot.log > > >>>>>> file! > > >>>>>> > > >>>>> > > >>>>> At present, that is not really practical. Actually for a lot of the > > >>>>> boot processes on the LiveCD, not currently even possible. > > >>>>> > > >>>>> When the LiveCD boots, the system is an unknown state. During the > > >>>>> startup, it needs to figure out a lot of different things. There is > > >>>>> no known location it could write any such messages that could be > > >>>>> later viewed. During the early stages of the boot process, it is > > >>>>> simply not reliably possible at present. > > >>>>> > > >>>>> As things progress and it works out some stuff, it “could” write such > > >>>>> a log to the a hard drive if present. But being a LiveCD, that would > > >>>>> be a very bad idea and counter to user expectations. It should not > > >>>>> modify the contents of any drive unless explicitly told to do so. > > >>>>> > > >>>>> Therefore, it tries to bring up a RAM drive for the purpose of having > > >>>>> temporary storage for things like I/O redirection and extracting > > >>>>> software packages. By this point, a “boot.Log” would be of little > > >>>>> use, would complicate the process and possibly eat up precious RAM > > >>>>> disk space. > > >>>>> > > >>>>> All that being said, it would be possible to create fairly simple > > >>>>> device driver that could trap and log all displayed text to XMS > > >>>>> memory (when present). But, I’m very busy on other things for the > > >>>>> moment. > > >>>>> > > >>>>> Maybe after I finish the next stage of my current project, I’ll whip > > >>>>> one up. > > >>>>> > > >>>>> Jerome > > >>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 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 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 mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
