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 <https://proton.me/> 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 >>> <mailto: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 >>> <mailto: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
