Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi All,

Fixed a minor issue in Logger, that would cause the interface program to not 
find the device driver when it was loaded low. 

At present, the interface program just does a brute force memory scan to find 
the driver. There are safeguards in place to prevent false positives and some 
optimizations to help expedite the process. But yes, it is a slow crappy way to 
locate the driver. It is only doing it this way until I decide on what is the 
best and most compatible thing to hook with zero chance of a collision or 
failure to find. Needs more pondering. Under general use, you probably won’t 
even notice the delay. But, there would definitely be a large performance hit 
under heavy use of the interface program.

Anyhow, I whipped up a modified version of the Boot Image for the FreeDOS 1.3 
LiveCD and works with the interim build of the LiveCD. It was just a test. But, 
I figured I would share it to save you some work. You can fetch it from my 
server at https://fd.lod.bz/redist/system/  
Then simply fire VirtualBox with the diskette and a LiveCD 1.3 (or later 
interim build) attached to check it out. Just make sure the VM is booting the 
floppy first. 

:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi All,

Logger is done for now and is available for testing. I’ve only done testing 
under FreeDOS and a little under MS-DOS. If it works under others, thats fine. 
If not, oh well. 

While it is not difficult to use, be sure to check out the DOC and DEMOS. There 
are some sort-of neat little things that may not be obvious. Also, the TO-DO 
has some ideas I’m mulling over. 

Let  us (you, me and the rest of mailing list) know if you think we should 
include it on a future Interim build. Also, if you think any of the various 
install media should boot loading it or not. Since logging can be turned off 
and on. It is possible to have the LiveCD boot with it. Then when reaching the 
command prompt, turn it off. Then, if the OS installer (FDI) is run, turn 
logging back on until finished. 

There are also a couple other nice benefits when logger is running that I don’t 
feel like going over at present. Maybe later.

On a side note, PRINT and ANSI are for redirecting to a text file. Not really 
for viewing. If the logged text was written all the way to the 80th column 
printing it in a 80 column wide will cause a blank line to appear when output 
to the screen. This is not a bug, that output is meant to be sent to a text 
file (like “logger print >boot.log”). It is easy enough to test if the output 
is redirected or not. So, I may have it not do that in future versions. Maybe I 
will leave it as it is. We will see.

Also, the PRINT, ANSI and CLEAR options turn off logging. For PRINT and ANSI, 
that is mainly to prevent the user from doing something silly like “logger 
print | more” while logging is enabled. Which of course, would send the 
contents of the log back to the log. 

Regardless, the logger interface program has a built in viewer. It supports 4 
directional movement through the log, leaves logging on or off and some other 
niceties. 

https://fd.lod.bz/repos/current/pkg-html/logger.html 


:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi Tom,

> On Mar 26, 2023, at 5:57 AM, tom ehlert  wrote:
> 
>> For
>> instance, vecho (which displays many user messages, like “Welcome to
>> FreeDOS”) don’t output text the same way as other programs and do not get 
>> captured at present.
> 
> I don't know how and why vecho displays text different. However it
> could "display" the text twice: once in the complicated way, and once
> in a "do nothing" way intercepted by your logger.

Thats easy enough for me to explain. :-)

Most stuff uses DOS interrupt calls to output text. In turn DOS itself displays 
that text through the BIOS Teletype Output [1] function (int 0x10, function 
0x0e).

VECHO (part of V8Power Tools) does not use that interrupt function to display 
text. Those programs uses multiple BIOS interrupts to move the cursor 
around[2][3], display text[4] and scroll the screen[5]. They use those 
functions (instead of the simple Teletype output) to support windowed like 
behavior needed by the FreeDOS installer. It allows them to write text inside 
“window” boxes and such things. 

A more general method will be to just grab stuff as it scrolls off the screen, 
or when the screen is cleared. Then as long as a program is not directly 
managing video memory for the scroll, any text (even if written directly to 
video memory) that is displayed will be captured. 

But, I definitely plan on adding a “add to log” function in the driver. This 
will permit the interface program to directly write messages and allow 
redirecting individual program output to the log. All of which will be very 
useful in the FreeDOS installer and permit capturing output from programs like 
FDISK for trouble shooting installation problems.

> 
>> There is a lot of other stuff that I’d like to get done with Logger
>> for the T2304 Interim Build. But, those are not critical functionality.
> 
> cool would be a single logger.exe, useful both as
> 
>  device=logger.exe
> 
> and
>  c:>logger.exe
> later

For now, I’m going with two files, the driver a SYS and interface a COM. 

 device[high]=logger.sys
and
 c:\logger.com

But, there are a couple of advantages to just having a single EXE. 
So eventually, it will most likely move to that file format. 

> Tom

:-)

Jerome

[1] - https://fd.lod.bz/rbil/interrup/video/100e.html#140
[2] - https://fd.lod.bz/rbil/interrup/video/1002.html#121
[3] - https://fd.lod.bz/rbil/interrup/video/1003.html#122
[4] - https://fd.lod.bz/rbil/interrup/video/1009.html#133
[5] - https://fd.lod.bz/rbil/interrup/video/1006.html#130



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

Re: [Freedos-devel] I wish I had a boot.log file

[tom ehlert]

> For
> instance, vecho (which displays many user messages, like “Welcome to
> FreeDOS”) don’t output text the same way as other programs and do not get 
> captured at present.

I don't know how and why vecho displays text different. However it
could "display" the text twice: once in the complicated way, and once
in a "do nothing" way intercepted by your logger.


> There is a lot of other stuff that I’d like to get done with Logger
> for the T2304 Interim Build. But, those are not critical functionality.

cool would be a single logger.exe, useful both as

  device=logger.exe

and
  c:>logger.exe
later

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi All,

Logger is coming along very well and is already semi-functional. 

At present, the driver loads, allocates XMS storage and takes control of what 
it needs. Also, the rudimentary logging works and it can log most  text during 
boot process. The interface program can print the log and turn off logging. 
Saving the log only requires redirecting the output from the interface program 
to file.

It is looking very promising that it could be at least usable for T2304.

But, there are a couple things that still need done before that time. Mostly, 
that is the more complex logging required to capture text from programs that 
perform more complicated output. For instance, vecho (which displays many user 
messages, like “Welcome to FreeDOS”) don’t output text the same way as other 
programs and do not get captured at present. 

There is a lot of other stuff that I’d like to get done with Logger for the 
T2304 Interim Build. But, those are not critical functionality.

:-)

Jerome





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi Louis, 

> On Mar 23, 2023, at 11:41 PM, Louis Santillan  wrote:
> 
> 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 
> 

Did not know about those. So, I glanced at it.

The ROUTPUT is only vaguely similar in goals and general concept.
Is not open source. (Only, free for non-commercial use)
Written in C.
Would not work for boot logging. 
Is a single program that executes another, capturing that output.
Will consume far more conventional memory (program + 32k memory)
Does not have a flexible buffer.
Data exceeding 32k is lost.
Requires a writeable file system.
Only supports text output through BIOS TTY function 0x0E.
LOGGER is really completely different.

Is open source. (BSD 3-Clause)
Written in assembly (NASM).
Will work for boot message logging.
Is a pair of programs, that can continuously capture all text.
Consumes very little conventional memory (probably around 1-2k), and can be 
loaded into upper memory.
Has a default XMS buffer size of 256k, but will be able to make that larger or 
smaller.
Will employee a cyclic buffer. When/If full, it will discard older stuff to 
make room. (I could possible grow it’s buffer, but I don’t think that will be 
needed nor worth the overhead.)
Does not require a writable file system.
Uses a more complex method for capturing text.

Thats just the main differences. They only sort-of sound similar. They really 
are completely different.

Anyhow, I’m working on LOGGER at https://gitlab.com/DOSx86/logger 


:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[Louis Santillan]

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  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  wrote:
> >
> > Hi Louis,
> >
> > > On Mar 23, 2023, at 5:32 PM, Louis Santillan  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  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 
> > >>  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 
> > >>  wrote:
> > >>
> > >>> Hi,
> > >>>
> >  On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
> >   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. :-)

Re: [Freedos-devel] I wish I had a boot.log file

[Louis Santillan]

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  wrote:
>
> Hi Louis,
>
> > On Mar 23, 2023, at 5:32 PM, Louis Santillan  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  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 
> >>  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 
> >>  wrote:
> >>
> >>> Hi,
> >>>
>  On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>   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, 

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi Louis, 

> On Mar 23, 2023, at 5:32 PM, Louis Santillan  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  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 
>>  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 
>>  wrote:
>> 
>>> Hi, 
>>> 
 On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
  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, 

Re: [Freedos-devel] I wish I had a boot.log file

[Louis Santillan]

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/


On Thu, Mar 23, 2023 at 5:52 AM  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
>
>
>
> 

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

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 
>  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  
> wrote:
> 
>> Hi, 
>> 
>>> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>>> >> > 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 
>>>  mailto:jer...@shidel.net>> 
>>> wrote:
>>> 
 Hi Paul,
 
> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>  > 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 
> 
> 

Re: [Freedos-devel] I wish I had a boot.log file

[Mercury Thirteen via Freedos-devel]

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

> Hi,
>
>> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>>  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 
>>  wrote:
>>
>>> Hi Paul,
>>>
 On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
  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

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi, 

> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>  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  
> wrote:
> 
>> Hi Paul,
>> 
>>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>>> >> > 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

Re: [Freedos-devel] I wish I had a boot.log file

[Mercury Thirteen via Freedos-devel]

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

> Hi Paul,
>
>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>>  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

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi Paul,

> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>  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

Re: [Freedos-devel] I wish I had a boot.log file

[Rugxulo]

So you want a TEE utility? Or just to single step through it all (F8)?
Try pressing the Pause key. (Yes, I know that's timing sensitive,
sorry.)


On Sun, Mar 19, 2023 at 10:30 AM Paul Dufresne via Freedos-devel
 wrote:
>
> So many messages on boot I cannot scroll back.
> If only the boot process would also copy everything in a boot.log file!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[Mercury Thirteen via Freedos-devel]

It would be nice if FreeDOS had something like *nix's DMESG.

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Sunday, March 19th, 2023 at 11:29 AM, Paul Dufresne via Freedos-devel 
 wrote:

> So many messages on boot I cannot scroll back.
> If only the boot process would also copy everything in a boot.log file!___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel