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 <https://proton.me/> 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 >>> <mailto: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 <http://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 >>> <http://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 >>> <mailto:jer...@shidel.net> <jer...@shidel.net <mailto: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 >>>>> <https://lists.sourceforge.net/lists/listinfo/freedos-devel> >>>> >>> >>> _______________________________________________ >>> 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
