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 amemory 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
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> 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
