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