[Freedos-devel] libm-0.4

[Gregory Pietsch]

I sent Jim libm-0.4, which includes new complex arctangent functions. -- Gregory___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] CPU flags register not updating on interrupt calls

[rehsd.info]

I ended up with "retf 2" and it seems to be working fine. I will see if I can 
switch out the retf 2 with stack frame manipulation, like you show.

Thanks!

Rich

-Original Message-
From: C. Masloch  
Sent: Monday, May 1, 2023 3:31 AM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] CPU flags register not updating on interrupt calls

On at 2023-04-30 17:19 -0500, rehsd.i...@gmail.com wrote:
> Not sure if it’s bad etiquette to reply to your own post, but… I may 
> just need to change out my “iret” with “ret 2”. I’m doing some 
> testing…
> 
> Rich

In NASM you can indeed use this as an alternative, but you need *far* return, 
that is "retf 2". However, I do not recommend this choice.

Instead, you can use a lahf or rcr \ rol trick to pass back either all 
arithmetic status flags (excepting the Overflow Flag) or only the Carry Flag. 
The core of your problem is that you were trying to set the current flags *in 
the interrupt handler*. But once you run an iret instruction, it pops the flags 
off the interrupt return stack frame. So to return flags to your caller, you 
either have to go with retf 2 (with all its problems) or modify the flags image 
in the stack frame before you run iret.

I recently commented on similar problems in [1] and [2]. I also gave an example 
from my SEEKEXT tool [3]:

.iret_CF:
push bp
mov bp, sp
rcr byte [bp + 6], 1; flip
rol byte [bp + 6], 1; flop
pop bp
iret

One of the reports [2] also contains an lahf example:

push bp
mov bp, sp
push ax
lahf
; bp + 0 = saved bp
; bp + 2 = ip
; bp + 4 = cs
; bp + 6 = fl
mov byte [bp + 6], ah
pop ax
pop bp
iret


[1]: https://github.com/640-KB/GLaBIOS/issues/20
[2]: https://github.com/MobyGamer/softhddi/issues/1
[3]: https://hg.pushbx.org/ecm/seekext/file/bbfcfa0d1c0b/resident.asm#l254


Regards,
ecm

> *From:* rehsd.i...@gmail.com 
> *Sent:* Sunday, April 30, 2023 4:53 PM
> *To:* freedos-devel@lists.sourceforge.net
> *Subject:* CPU flags register not updating on interrupt calls
> 
> Hi, everyone. I’m new here. This is my first post. 
> 
> I am currently working on getting FreeDOS running on my homebrew 286 
> system. I am running into an issue where interrupt calls from FreeDOS 
> to my BIOS are not showing updated values for the CPU flags register 
> after the call. This happens with built-in interrupt calls in FreeDOS 
> or custom calls I am making. Here’s a simple test function that I 
> added to FreeDOS’s main.c (I call it just before signon()):
> 
> *void test_interrupt()*
> 
> *{*
> 
> *iregs regs;*
> 
> *regs.a.x = 0x1122;*
> 
> *regs.b.x = 0x0033;*
> 
> **
> 
> *regs.c.x = 0x4455;*
> 
> *regs.d.x = 0x6677;*
> 
> *regs.di = 0x8899;*
> 
> *regs.si = 0xaabb;*
> 
> **
> 
> *init_call_intr(0x15, );*
> 
> **
> 
> *printf("\nInt test: ");*
> 
> *printf("ax=%04X  bx=%04X  cx=%04X  dx=%04X  di=%04X  si=%04X
> flags=%04X\n",regs.a.x,regs.b.x,regs.c.x,regs.d.x,regs.di,regs.si,regs
> .flags);*
> 
> *}*
> 
> In the assembly code for the BIOS interrupt service routine (I’m just 
> using interrupt 0x15 for testing), I update the flags register. When I 
> try to read the updated flags register back in FreeDOS, I am not 
> getting the values that I expect. For example, if I use something like 
> the following in my interrupt service routine, when I read regs.flags 
> in
> test_interupt() above, the carry flag may or may not be set properly 
> (same with the zero flag).
> 
> *  mov  ah, 0b0101  ;SF, ZF, AF, PF, 
> and CF flags (bits 7, 6, 4, 2, haveand 0, respectively) – other flags 
> are left unchanged by CPU*
> 
> *  sahf*
> 
> *iret*
> 
> In, kernel/pcb.h 
> ,
> I see some notes about “offsets must match the assembly process” and a 
> couple of different layouts for the offsets. Could this be related to 
> the issue I am having? I am using NASM 2.16.01 and Watcom 1.9.
> 
> Suggestions or things I could look into?
> 
> I have posted additional details here 
>  etween-bios-and-freedos>, including a video walk-through of what I am 
> seeing.
> 
> Thank you!
> 
> Rich
> 
> 
> 
> ___
> 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

[Freedos-devel] FreeDOS T2305

[jerome]

Hi All, 

The FreeDOS Interim Test Build T2305 for May is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


:-)

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

Re: [Freedos-devel] Logger

[C. Masloch]

On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:

Hi All,

Logger is coming along great and I’m currently working on the final ALPHA-8 
version. Once that is done, it will be time for a BETA or two. Then finally 
version 1.0.


Your IISP headers could store the required retf at a place other than 
after the header. This would save the short jump that you use to skip 
the retf. If you put the int 2Dh handler right after the resident device 
strategy handler, you could re-use the strategy handler's retf for the 
int 2Dh IISP header. Likewise the int 10h IISP header if it is close enough.


In my IISP header macro, iispentry [1], I can pass a label to use for 
the retf in one of the parameters. Also, it now by default aligns the 
IISP header to a word-boundary to slightly speed up accesses of the 
ieNext pointer.


It is good that your ieEntry jump already is the expected 10EBh, a jump 
to what I call ieStart. This is required for fully standard IISP 
headers, and Ralf Brown's programs expect this exact value there.


Other than that I didn't look at all your code yet for more optimisations.


[1]: https://hg.pushbx.org/ecm/ldebug/file/ab7d7f8b72d5/source/AMIS.MAC#l44



For fun, I decided to implement a single binary compiler directive. When 
enabled, it generates a single COM that acts as both the driver and interface 
program. But, I am unsure if I will use that or the dual (SYS+COM) build for 
the 1.0 release.

Mostly, it comes down to the size of the binary. At present, both the driver and 
interface programs are UPX compressible. Their uncompressed size are about 3k & 
6k respectively. So, when space may be tight on a boot floppy, the driver will only 
need about 2.5k (UPX’d) of diskette space. Also if the interface program is used in 
batch files to append debugging comment messages (not shown to the user) directly 
to the log, it requires loading just the 4k (UPX'ed) interface program .

When compiled as a single COM for both the driver and interface, UPX 
compression cannot be used and the binary is about 9k at present. Because there 
is some common (or at least similar code) shared between the driver and 
interface, this could most likely be reduced by 1 or 2k in some future version. 
But that level of optimization will not happen anytime soon. I have other 
things of much higher priorities that need doing.

So, the single COM will require almost 4 times the space of the dual binary 
format. While it may not matter much for Hard Drives, CD-ROMs and USB sticks, 
it could matter a lot for a floppy.

I guess for version 1.0, it could include the SYS and the single binary COM. 
But, that could be confusing. Probably better to go with either the dual 
binaries or just the single binary. And, I am leaning towards the dual binaries 
for version 1.0.


I adjusted my inicomp stage slightly, originally an lDOS boot iniload 
stage, to allow using it to compress the dual-mode (single binary) 
Logger. First change was to allow setting up a stack based on the flat 
.COM style entrypoint [2]. The second option is for a very small 
optimisation that disables boot-loaded mode entrypoints into the stage 
[3]. Then I modified Logger's log-drvr.asm to use the entrypoints 
expected by inicomp for the device header [4].


During rebuilding Logger I found that a very recent NASM version, like 
2.16 ish, is required to build. This is because you use the istruc 
support of struc local labels, which was added to the standard macros in 
[5]. Rebuilding also required to work around a new NASM problem [6]. The 
new macros could be used in an older NASM as well, if you included some 
%unmacro lines and the new macros in your sources. NASM is under the 
2-clause BSD license [7] so you could copy their macros.


Here's the results of building my compressed dual-mode Logger 
executable, compressed using LZIP (high ratio, slow) and LZSA2 (faster):


logger/BIN$ lzip -9vvfkc LOGGER.COM > logger.lz 
  LOGGER.COM:  1.650:1, 60.62% ratio, 39.38% saved, 9240 in, 
5601 out.  logger/BIN$ nasm ../../inicomp/inicomp.asm -I 
../../lmacros/ -I ../../inicomp/ -D_LZD -o loggerlz.com 
-D_PAYLOAD_FILE="'logger.lz'" -D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 
-D_DEVICE=1 -D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0

../../inicomp/lzd.asm:698: warning: localvariables has 14688 bytes [-w+user]
../../inicomp/inicomp.asm:1320: warning: inilz: 2992 bytes used for 
depacker [-w+user]
logger/BIN$ lzsa -c -f2 --prefer-ratio -v LOGGER.COM logger.sa2 
Compressed 'LOGGER.COM' in 0.072056 seconds, 0.12 Mb/s, 1141 
tokens (8.09816 bytes/token), 9240 into 6050 bytes ==> 65.4762 % 
   Compared 'logger.sa2' in 3.9e-05 seconds, 
225.947 Mb/s  logger/BIN$ nasm 
../../inicomp/inicomp.asm -I ../../lmacros/ -I ../../inicomp/ -D_LZSA2 
-o loggersa.com 

Re: [Freedos-devel] CPU flags register not updating on interrupt calls

[Rugxulo]

Hi,

On Sun, Apr 30, 2023 at 4:54 PM  wrote:
>
> In, kernel/pcb.h, I see some notes about “offsets must match the assembly 
> process”
> and a couple of different layouts for the offsets. Could this be related to 
> the issue I am having?
> I am using NASM 2.16.01 and Watcom 1.9.

Someone reported that there was a regression in OMF/OBJ for NASM
2.16.01 regarding 16-bit segments.

Try reverting to NASM 2.15.05 instead:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/

Or, for really having fun, try the ancient 0.98.39 16-bit version:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/


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

Re: [Freedos-devel] Logger

[C. Masloch]

A few additions to my prior mail:

On at 2023-05-01 13:04 +0200, C. Masloch wrote:

On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:

Hi All,

Logger is coming along great and I’m currently working on the final 
ALPHA-8 version. Once that is done, it will be time for a BETA or two. 
Then finally version 1.0.


Your IISP headers could store the required retf at a place other than 
after the header. This would save the short jump that you use to skip 
the retf. If you put the int 2Dh handler right after the resident device 
strategy handler, you could re-use the strategy handler's retf for the 
int 2Dh IISP header. Likewise the int 10h IISP header if it is close 
enough.


In my IISP header macro, iispentry [1], I can pass a label to use for 
the retf in one of the parameters. Also, it now by default aligns the 
IISP header to a word-boundary to slightly speed up accesses of the 
ieNext pointer.


It is good that your ieEntry jump already is the expected 10EBh, a jump 
to what I call ieStart. This is required for fully standard IISP 
headers, and Ralf Brown's programs expect this exact value there.


Other than that I didn't look at all your code yet for more optimisations.


[1]: https://hg.pushbx.org/ecm/ldebug/file/ab7d7f8b72d5/source/AMIS.MAC#l44


You can use a "jmp strict short" instruction in NASM to make sure that a 
short jump is assembled, and an error raised otherwise.


Here's the results of building my compressed dual-mode Logger 
executable, compressed using LZIP (high ratio, slow) and LZSA2 (faster):


This wasn't very readable so I will list the commands separately:

This is the LZIP compression command:

logger/BIN$ lzip -9vvfkc LOGGER.COM > logger.lz
LOGGER.COM:  1.650:1, 60.62% ratio, 39.38% saved, 9240 in, 5601 out.


This is the assembler command to build the inicomp stage:

logger/BIN$ nasm ../../inicomp/inicomp.asm -I ../../lmacros/ -I 
../../inicomp/ -D_LZD -o loggerlz.com -D_PAYLOAD_FILE="'logger.lz'" 
-D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 -D_DEVICE=1 
-D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0

../../inicomp/lzd.asm:698: warning: localvariables has 14688 bytes [-w+user]
../../inicomp/inicomp.asm:1320: warning: inilz: 2992 bytes used for 
depacker [-w+user]



The -I switches above are needed so that NASM finds the include files. 
The lmacros and inicomp repo are both available from my hg repositories [1].


The -D_LZD switch tells inicomp what depacker to use.

-o specifies the output filename.

-D_PAYLOAD_FILE= specifies the payload file, and must be passed twice 
quoted from bash to NASM so that NASM ends up with a quoted string define.


-D_IMAGE_EXE enables the exe mode handling. Likewise, -D_DEVICE enables 
the device mode handling.


-D_IMAGE_EXE_AUTO_STACK disables passthrough of the depacker's stack. 
Instead, the ss:sp is set up as -16:0FFFEh from the program image 
address. That is, ss = PSP and sp = 0FFFEh.


-D_DEVICE_ZERO_ENTRYPOINT enables the jump within the device header, 
required for flat .COM style dual-mode executables.


-D_DEVICE_ATTRIBUTE and -D_DEVICE_NAME should be set up to match the 
compressed device driver header's.


-D_IMAGE_EXE_CS and -D_IMAGE_EXE_IP set up the initial cs:ip as -16:256, 
matching the normal flat .COM style entry.


-D_IMAGE_EXE_GET_COM_STACK is required to set up the expected stack for 
the depacker. It uses ss as the upper limit of memory available to it 
for depacking.


-D_BOOTLDR=0 and -D_ALLOW_OVERLAPPING=0 are some small optimisations.


This is the LZSA2 compression command:

logger/BIN$ lzsa -c -f2 --prefer-ratio -v LOGGER.COM logger.sa2
Compressed 'LOGGER.COM' in 0.072056 seconds, 0.12 Mb/s, 1141 tokens 
(8.09816 bytes/token), 9240 into 6050 bytes ==> 65.4762 %

Compared 'logger.sa2' in 3.9e-05 seconds, 225.947 Mb/s


Finally, the assembler command to build the LZSA2-packed executable. 
This is the same as above but with -D_LZSA2 and the different output and 
payload filenames.


logger/BIN$ nasm ../../inicomp/inicomp.asm -I ../../lmacros/ -I 
../../inicomp/ -D_LZSA2 -o loggersa.com -D_PAYLOAD_FILE="'logger.sa2'" 
-D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 -D_DEVICE=1 
-D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0
../../inicomp/inicomp.asm:1320: warning: inilzsa2: 1392 bytes used for 
depacker [-w+user]



This is the resulting files:

logger/BIN$ ls -lgG
total 48
-rw-r--r-- 1 9240 May  1 11:10 LOGGER.COM
-rw-r--r-- 1 5601 May  1 12:21 logger.lz
-rw-r--r-- 1 8608 May  1 12:21 loggerlz.com
-rw-r--r-- 1 6050 May  1 12:21 logger.sa2
-rw-r--r-- 1 7456 May  1 12:21 loggersa.com
logger/BIN$


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/


___
Freedos-devel mailing list

Re: [Freedos-devel] CPU flags register not updating on interrupt calls

[bernd-freedos--- via Freedos-devel]

That was me.

I openend an issue in the FreeDOS Archive tracker thas OMF output seems to be 
broken in 2.16:

https://gitlab.com/FreeDOS/devel/nasm/-/issues/1

I also mailed H.P. Anvin and informed him about what I consider to be a bug. I 
do not know if they have / will fix it, or if it is a misunderstanding by me.

Greetings, Bernd


> Am 01.05.2023 um 08:45 schrieb Rugxulo :
> 
> Hi,
> 
> On Sun, Apr 30, 2023 at 4:54 PM  wrote:
>> 
>> In, kernel/pcb.h, I see some notes about “offsets must match the assembly 
>> process”
>> and a couple of different layouts for the offsets. Could this be related to 
>> the issue I am having?
>> I am using NASM 2.16.01 and Watcom 1.9.
> 
> Someone reported that there was a regression in OMF/OBJ for NASM
> 2.16.01 regarding 16-bit segments.
> 
> Try reverting to NASM 2.15.05 instead:
> 
> * 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/
> 
> Or, for really having fun, try the ancient 0.98.39 16-bit version:
> 
> * 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/
> 
> 
> ___
> 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] CPU flags register not updating on interrupt calls

[C. Masloch]

On at 2023-04-30 17:19 -0500, rehsd.i...@gmail.com wrote:
Not sure if it’s bad etiquette to reply to your own post, but… I may 
just need to change out my “iret” with “ret 2”. I’m doing some testing…


Rich


In NASM you can indeed use this as an alternative, but you need *far* 
return, that is "retf 2". However, I do not recommend this choice.


Instead, you can use a lahf or rcr \ rol trick to pass back either all 
arithmetic status flags (excepting the Overflow Flag) or only the Carry 
Flag. The core of your problem is that you were trying to set the 
current flags *in the interrupt handler*. But once you run an iret 
instruction, it pops the flags off the interrupt return stack frame. So 
to return flags to your caller, you either have to go with retf 2 (with 
all its problems) or modify the flags image in the stack frame before 
you run iret.


I recently commented on similar problems in [1] and [2]. I also gave an 
example from my SEEKEXT tool [3]:


.iret_CF:
push bp
mov bp, sp
rcr byte [bp + 6], 1; flip
rol byte [bp + 6], 1; flop
pop bp
iret

One of the reports [2] also contains an lahf example:

push bp
mov bp, sp
push ax
lahf
; bp + 0 = saved bp
; bp + 2 = ip
; bp + 4 = cs
; bp + 6 = fl
mov byte [bp + 6], ah
pop ax
pop bp
iret


[1]: https://github.com/640-KB/GLaBIOS/issues/20
[2]: https://github.com/MobyGamer/softhddi/issues/1
[3]: https://hg.pushbx.org/ecm/seekext/file/bbfcfa0d1c0b/resident.asm#l254


Regards,
ecm


*From:* rehsd.i...@gmail.com 
*Sent:* Sunday, April 30, 2023 4:53 PM
*To:* freedos-devel@lists.sourceforge.net
*Subject:* CPU flags register not updating on interrupt calls

Hi, everyone. I’m new here. This is my first post. 

I am currently working on getting FreeDOS running on my homebrew 286 
system. I am running into an issue where interrupt calls from FreeDOS to 
my BIOS are not showing updated values for the CPU flags register after 
the call. This happens with built-in interrupt calls in FreeDOS or 
custom calls I am making. Here’s a simple test function that I added to 
FreeDOS’s main.c (I call it just before signon()):


*void test_interrupt()*

*{*

*    iregs regs;*

*    regs.a.x = 0x1122;*

*    regs.b.x = 0x0033;*

**

*regs.c.x = 0x4455;*

*    regs.d.x = 0x6677;*

*    regs.di = 0x8899;*

*    regs.si = 0xaabb;*

**

*init_call_intr(0x15, );*

**

*printf("\nInt test: ");*

*    printf("ax=%04X  bx=%04X  cx=%04X  dx=%04X  di=%04X  si=%04X 
flags=%04X\n",regs.a.x,regs.b.x,regs.c.x,regs.d.x,regs.di,regs.si,regs.flags);*


*}*

In the assembly code for the BIOS interrupt service routine (I’m just 
using interrupt 0x15 for testing), I update the flags register. When I 
try to read the updated flags register back in FreeDOS, I am not getting 
the values that I expect. For example, if I use something like the 
following in my interrupt service routine, when I read regs.flags in 
test_interupt() above, the carry flag may or may not be set properly 
(same with the zero flag).


*  mov  ah, 0b0101  ;SF, ZF, AF, PF, and 
CF flags (bits 7, 6, 4, 2, haveand 0, respectively) – other flags are left 
unchanged by CPU*


*  sahf*

*iret*

In, kernel/pcb.h , 
I see some notes about “offsets must match the assembly process” and a 
couple of different layouts for the offsets. Could this be related to 
the issue I am having? I am using NASM 2.16.01 and Watcom 1.9.


Suggestions or things I could look into?

I have posted additional details here 
, 
including a video walk-through of what I am seeing.


Thank you!

Rich



___
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] CPU flags register not updating on interrupt calls

[C. Masloch]

On at 2023-05-01 01:45 -0500, Rugxulo wrote:

Hi,

On Sun, Apr 30, 2023 at 4:54 PM  wrote:


In, kernel/pcb.h, I see some notes about “offsets must match the assembly 
process”
and a couple of different layouts for the offsets. Could this be related to the 
issue I am having?
I am using NASM 2.16.01 and Watcom 1.9.


Someone reported that there was a regression in OMF/OBJ for NASM
2.16.01 regarding 16-bit segments.

Try reverting to NASM 2.15.05 instead:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/

Or, for really having fun, try the ancient 0.98.39 16-bit version:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/


Please point to the exact bug report if you make claims like this. It 
wasn't actually anything to do with such a regression however.


Regards,
ecm


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

[Freedos-devel] Logger v0.1 (beta)

[jerome]

Hi All, 

Yesterday, I released the new version of Logger. It has come a long way since 
the first Alpha release and works great. I made some final decisions on a 
couple aspects and it is now in the Beta stage. Other than some probable byte 
squeezing, there is only one other possible feature I might add before the 
final version 1.0 is released (see below). 

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


Here is a summary of the major changes and final decisions I made since the 
Alpha-7 release:

Interface can export the log as HTML in full color.
Driver supports VESA mode changes.
Driver supports AMIS and IISP.
Driver provides the ability to check status, enable/disable logging, clear and 
append the log through an API.
API is usable through AMIS or by direct far call to driver by other programs.
Driver and Interface will be released as a single dual-mode binary. (popular 
request)
Release includes very small and simple API examples. (For example, a 141 byte 
COM program with source to append the log.)
Release includes UPX’d driver only version for usage on limited capacity media 
like boot floppies when needed.

Adding AMIS, IISP and the API increased the memory resident footprint of the 
driver by approximately 30%. But, that is still only a total memory footprint 
of 1,472 bytes for the 0.1-BETA version. I think those features are worth the 
couple hundred bytes required for their support. There is no API documentation 
at present. Instead, I included simple examples that include all the different 
API functions. 

The addition of the API and inclusion of the UPX’ed driver only version makes 
the size of the single dual-mode binary much less important for usage on boot 
floppy diskettes. For example, if it were used with the FreeDOS install media, 
only 2.6kb would be required for the driver. If non-user visible debug messages 
are desired, the simple 141 byte demo “add message” program could be used. This 
would consume about 3kb of disk space instead of the roughly 10kb used buy the 
dual-mode binary. As a bonus, having a batch execute the small demo program 
repeatedly would be much faster than launching the bigger program to simply 
append the log. 

The API only supports the functions mentioned earlier. It does not support 
reading the log. I think that would be of very limited use and most likely not 
worth the additional cost in memory to provide those functions. However, those 
may be added in future versions if there is enough demand for them.

The only other feature I am considering adding before the version 1.0 release 
is triple-mode support to the binary. Along with behaving like a device driver 
for loading in the CONFIG.SYS, it would be (very, very) useful to be able to 
simply run the binary from the command line and use the driver portion as a 
TSR. However, I’m tired of working on Logger and may put this feature off until 
version 1.1. We will see.

What will not be in version 1.0 is NLS support. Other than the help, status 
information and a couple error messages, Logger really does not have much user 
facing text of itself. The primary reason for eventually adding NLS support is 
because of the HTML output. As most of you are aware, many DOS ASCII characters 
are not displayed by HTML directly. Many symbol and special characters require 
remapping to HTML sequences. For example, simple characters like “<“ need 
converted to “”. The HTML output by logger already does this for some 
characters. But, many more should be added. Eventually, it will get NLS support 
and the capability to use alternate mappings for different languages. 

On a side note… Logger has seen some “real world” use over the last week. One 
of my DOS machines was causing another developers programs to have a couple 
issues. Using Logger made it very easy to record the program output and other 
information which I was able to easily share with the developer in order to 
solve the issues. This is where I really have grown to like the HTML output a 
lot. With the inclusion of color, they look really nice when viewed on common 
desktop operating systems like macOS and Linux. 

Oh, I also updated the Logger demo boot diskette image that can use either the 
LiveCD from FreeDOS 1.3 or any of the Interim Test Builds to start a Live 
Environment. 

https://fd.lod.bz/redist/system/ 

:-)

Jerome


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