freedos-kernel — Questions and discussion related to FreeDOS kernel development

[Freedos-kernel] Will retire the freedos-kernel email list

[Jim H. <jh...@fr...>]

Hi freedos-kernel developers:

I think everyone on this email list is also on freedos-devel, so you
probably have seen the discussion there about the different
communication channels for FreeDOS.

We obviously use the freedos-devel and freedos-user email lists. But
the freedos-kernel list is not used very much. Looking at the archive,
this hasn't seen more than a few emails per *year* in the last several
years.

Because of the light traffic, let's consolidate our developer
discussions! The freedos-kernel email list will be closed this week.
Instead, please use the freedos-devel email list to discuss any
FreeDOS kernel development topics.

Thanks!

Jim

[Freedos-kernel] Kernel bug fixes need backport from dosemu2 fdpp

[Eric A. <e....@jp...>]

Hi kernel readers :-)

Looking at the development of dosemu2, I find that the
many changes there have moved away from freedos SO far
that backporting became hard, without me ever noticing.

There was the announcement of fdpp in 9/2018, one year
after development started, which morphs the kernel into
a Linux lib for dosemu2: https://github.com/stsp/fdpp
(excuse the extreme simplification of my description)

But there apparently never was a discussion about the
improvements in fdpp here, very few people at dosemu2
were in the mood to backport things, possibly inspired
by the lack of bugzilla readers here and the very few
original FreeDOS kernel people who took the effort to
cherry pick patches apparently have not shared their
capacity bottlenecks here. E.g. Andrew Bird has sent

https://github.com/PerditionC/fdkernel and
https://github.com/FDOS/kernel some patches and
Jeremy has started some cherry picking himself?

So what have we missed during all that time, 2.5 years?

- fdpp solves obscure MCB / UMB related problems which
  made FreeDOS unable to use UMB at a000:0 including
  stack overflows and reboot troubles?

- dosemu2 needs some FreeDOS-only "boot work-around" if
  hdiskboot -1, hdisks >0 and hdisk 0 is not bootable...?
  (probably to help us to boot from D: drive or similar)

- some boot changes (not sure whether dosemu2 specific) on
https://github.com/dosemu2/fdpp/commit/10507295bdea1dee3109ed115dc0dc38f98d2565#commitcomment-35887845

- FreedOS 1.2 and older has no int 2f.121f, just 2f.1217,
  but that might have been fixed back in FreeDOS recently?

- many games work better with fdpp than with FreeDOS, says
  https://github.com/dosemu2/fdpp/releases/tag/beta-9
  (Test Drive 2, Tetris Classic, Elite Frontier, Empire
  Soccer, Virtual Chess, Alone in the Dark, Alpha Waves)

- however, for example int 21.71a6 in fdpp may only be used
  in conjunction with dosemu2, according to the same site??

- fdpp fixes something related to Volkov Commander:
  https://github.com/dosemu2/fdpp/releases/tag/rc-1
  This also mentions 2 of the above games "resize PSP to 0
  and then terminate it" which apparently MS DOS accepts

- probably a lot more

Note that fdpp development seems much faster than freedos
kernel devel in part because dosemu2 disciples love their
toolchain, but dispise the tools available for real DOS?

Please, it is nice to have a few very active experts in a
few DOS related projects, but why do I have to feel like
an eavesdropper when figuring out which bugs get fixed and
which features get added? It looks a lot like many of those
probable improvements never made it to FreeDOS kernel sys
because people fail to talk about them across projects.

So please talk about those things on freedos-kernel!

If you know about a bug in FreeDOS, talk about it.

If you know about a fix in fdpp and lack the time to
backport it to FreeDOS, at least mention it here.

If you know about compatibility issues, do not just drop
from this list and install fdpp or MS DOS. Talk about it!

For those who have not experienced dosemu2 yet: Note that
it has less magic guest drivers, so you WILL have to LOAD
them in your config sys. Read their pre-installed config.

Dosemu2 is a QUICKLY moving target and following their
github feels like spying on a private chat, but most of
the time the improvements outnumber the regressions and
it work much better than the stalled classic dosemu :-)

I hope there are still some people HERE who are keen on
kernel improvements. Maybe we can wake up and at least
find out how FreeDOS 1.3 (and up) kernels COULD improve.

Thank you! Regards, Eric

PS: Excuse the cross-post CC to freedos-devel. It is for
the case that there are not enough kernel readers left.

Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS

[Robert R. <rr...@bt...>]

Hi Jeremy,

> Hi per...@gm...,
> 
>> Thank you.  I will try to get to this by the weekend.
> 
> Thanks! :-)
> 
> Regarding the "Space between value and currency symbol" bit errors:
> I checked my statement about a space between value and the € sign.
> Various Internet sources, e.g.,
> <https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>,
> <http://buerojob-blog.de/2012/11/19/schreibweise-euro/>,
> <https://publications.europa.eu/code/de/de-370303.htm#position>, tell,
> that there should be a space between.
> 
> *** From publications.europa.eu: ***
> Das Symbol € steht hinter dem Betrag und ist von diesem durch einen
> Zwischenraum getrennt:
> 
>     ein Betrag von 30 €
> 
> Anmerkung:
> Im Englischen, Irischen, Maltesischen und im Niederländischen steht der
> Code vor dem Betrag:
> 
>     an amount of €30 (ohne Zwischenraum)
> ***
> 
> "the amount is followed by a hard space and the euro sign" (except
> English, Dutch, Irish, and Maltese)
> 
> I've attached an updated diff file for German.

Did my changes make it to the repo meanwhile?

I don't see at
<https://github.com/PerditionC/fdkernel/blob/master/kernel/country.asm>,
but maybe it's the wrong URL?

Cheers,
Robert
-- 
              +++ BTTR Software +++
     Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/

Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS

[Robert R. <rr...@bt...>]

Hi per...@gm...,

> Thank you.  I will try to get to this by the weekend.

Thanks! :-)

Regarding the "Space between value and currency symbol" bit errors:
I checked my statement about a space between value and the € sign.
Various Internet sources, e.g.,
<https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>,
<http://buerojob-blog.de/2012/11/19/schreibweise-euro/>,
<https://publications.europa.eu/code/de/de-370303.htm#position>, tell,
that there should be a space between.

*** From publications.europa.eu: ***
Das Symbol € steht hinter dem Betrag und ist von diesem durch einen
Zwischenraum getrennt:

    ein Betrag von 30 €

Anmerkung:
Im Englischen, Irischen, Maltesischen und im Niederländischen steht der
Code vor dem Betrag:

    an amount of €30 (ohne Zwischenraum)
***

"the amount is followed by a hard space and the euro sign" (except
English, Dutch, Irish, and Maltese)

I've attached an updated diff file for German.

Cheers,
Robert
-- 
              +++ BTTR Software +++
     Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/

Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS

[<per...@gm...>]

Thank you.  I will try to get to this by the weekend.

Jeremy

On Thu, Jan 23, 2020, 3:11 PM Robert Riebisch <rr...@bt...> wrote:

> Hi
>
> for Germany COUNTRY.SYS reports "." (dot) for the time separator, when
> it should be ":" (colon).
>
> I noticed the error in FD 1.3 RC2 and FD 1.2, when using:
>
>         !COUNTRY=049,,C:\FDOS\BIN\COUNTRY.SYS
>
> in FDCONFIG.SYS.
>
> I didn't test FD 1.1.
>
> FD 1.0 behaves differently: Although it reports 001 for the current
> country code (BX on return from AX=3800h, int21h), the time separator is
> correct.
>
> I tracked the error down to:
>
> Bad data:
> de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany
>     Tom
> de_858 cnf  49,850,DMY,0D5h,   0,0,0,0,".",",",".",".",1,2,_24; Germany
> de_437 cnf  49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany
>
> Good data:
> de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany
>     Tom
> de_858 cnf  49,858,DMY,0D5h,   0,0,0,0,".",",",".",":",1,2,_24; Germany
> de_437 cnf  49,437,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany
>
> In HELP -> "country" (not "country.sys") it is stated correctly as ":".
>
> If you don't patch 850 to 858 COUNTRY.SYS doesn't load with:
>
>         !COUNTRY=049,858,C:\FDOS\BIN\COUNTRY.SYS
>
> because 49 858 are no valid combination.
>
> This is how I patched current COUNTRY.SYS to make it work:
> 00003984: 2E 3A
> 00003995: 52 5A
> 000039A4: 2E 3A
> 000039C4: 2E 3A
>
>
> And I think, for Austria the time separator should also be ":". (see
> lines 3075-3077 of COUNTRY.ASM)
>
> ***************************************************************************
>
> I just found a second data error.
> If you use:
>
>         !COUNTRY=049,437,C:\FDOS\BIN\COUNTRY.SYS
>
> loading COUNTRY.SYS aborts with error "could not find country info for
> country ID 49".
>
> I fixed this by patching:
> 0000041B: 5A B5
> 0000041C: 03 01
>
> ***************************************************************************
>
> A third data error is regarding the "Space between value and currency
> symbol" bit. It is reported as NO for codepage 437 and codepage 850. It
> should be YES, because the symbol is "EUR" then.
> For codepage 858 symbol is "€", so NO is correct here.
>
> I fixed this by patching:
> 00003986: 01 03
> 000039C6: 01 03
>
> ***************************************************************************
>
> Fourth error (?)
> German MS-DOS 6.22 and Windows XP SP3 report ";" as the data-list
> separator.
>
> I didn't find, where this is defined. So no patch from me.
>
>
> As this mail and patch list got (and took) longer than expected, I'm
> attaching a diff file.
>
> Maybe someone with access to the kernel sources can integrate this fix.
> Thanks in advance!
>
> ***************************************************************************
>
> By the way:
> To study the error and practice DOS programming I wrote a little tool to
> show country information as reported by AX=3800h/INT 21h in some
> "obscure" Pascal dialect from Japan called Cabezon.
> The EXE file is currently available at
> <https://www.bttr-software.de/tmp/COUNTRY.ZIP>.
> I can provide source code too, if anyone is interested, but may be
> currently of little use, because it depends on my expanded run-time
> library for Cabezon, which is still pre-beta code.
>
> Output will be similar to:
> #####
> Country code       : 49
> Date format        : 0001h (dd mm yy)
> Time format        : 01h (Bit 0: 24-hour clock = YES)
> Thousands separator: .
> Decimal separator  : ,
> Date separator     : .
> Time separator     : :
> Data-list separator: ,
> Currency symbol    : EUR
> Currency format    : 01h (Bit 0: Currency symbol follows value = YES
>                           Bit 1: Space between value and currency symbol
> = NO
>                           Bit 2: Currency symbol replaces decimal point
> = NO)
> Currency precision : 2
> Case map routine   : 00D8:11EF
> #####
>
> Cheers,
> Robert
> --
>               +++ BTTR Software +++
>      Home page: https://www.bttr-software.de/
> DOS ain't dead: https://www.bttr-software.de/forum/
> _______________________________________________
> Freedos-kernel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
>

[Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS

[Robert R. <rr...@bt...>]

Hi

for Germany COUNTRY.SYS reports "." (dot) for the time separator, when
it should be ":" (colon).

I noticed the error in FD 1.3 RC2 and FD 1.2, when using:

	!COUNTRY=049,,C:\FDOS\BIN\COUNTRY.SYS

in FDCONFIG.SYS.

I didn't test FD 1.1.

FD 1.0 behaves differently: Although it reports 001 for the current
country code (BX on return from AX=3800h, int21h), the time separator is
correct.

I tracked the error down to:

Bad data:
de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany
    Tom
de_858 cnf  49,850,DMY,0D5h,   0,0,0,0,".",",",".",".",1,2,_24; Germany
de_437 cnf  49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany

Good data:
de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany
    Tom
de_858 cnf  49,858,DMY,0D5h,   0,0,0,0,".",",",".",":",1,2,_24; Germany
de_437 cnf  49,437,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany

In HELP -> "country" (not "country.sys") it is stated correctly as ":".

If you don't patch 850 to 858 COUNTRY.SYS doesn't load with:

	!COUNTRY=049,858,C:\FDOS\BIN\COUNTRY.SYS

because 49 858 are no valid combination.

This is how I patched current COUNTRY.SYS to make it work:
00003984: 2E 3A
00003995: 52 5A
000039A4: 2E 3A
000039C4: 2E 3A


And I think, for Austria the time separator should also be ":". (see
lines 3075-3077 of COUNTRY.ASM)

***************************************************************************

I just found a second data error.
If you use:

	!COUNTRY=049,437,C:\FDOS\BIN\COUNTRY.SYS

loading COUNTRY.SYS aborts with error "could not find country info for
country ID 49".

I fixed this by patching:
0000041B: 5A B5
0000041C: 03 01

***************************************************************************

A third data error is regarding the "Space between value and currency
symbol" bit. It is reported as NO for codepage 437 and codepage 850. It
should be YES, because the symbol is "EUR" then.
For codepage 858 symbol is "€", so NO is correct here.

I fixed this by patching:
00003986: 01 03
000039C6: 01 03

***************************************************************************

Fourth error (?)
German MS-DOS 6.22 and Windows XP SP3 report ";" as the data-list separator.

I didn't find, where this is defined. So no patch from me.


As this mail and patch list got (and took) longer than expected, I'm
attaching a diff file.

Maybe someone with access to the kernel sources can integrate this fix.
Thanks in advance!

***************************************************************************

By the way:
To study the error and practice DOS programming I wrote a little tool to
show country information as reported by AX=3800h/INT 21h in some
"obscure" Pascal dialect from Japan called Cabezon.
The EXE file is currently available at
<https://www.bttr-software.de/tmp/COUNTRY.ZIP>.
I can provide source code too, if anyone is interested, but may be
currently of little use, because it depends on my expanded run-time
library for Cabezon, which is still pre-beta code.

Output will be similar to:
#####
Country code       : 49
Date format        : 0001h (dd mm yy)
Time format        : 01h (Bit 0: 24-hour clock = YES)
Thousands separator: .
Decimal separator  : ,
Date separator     : .
Time separator     : :
Data-list separator: ,
Currency symbol    : EUR
Currency format    : 01h (Bit 0: Currency symbol follows value = YES
                          Bit 1: Space between value and currency symbol
= NO
                          Bit 2: Currency symbol replaces decimal point
= NO)
Currency precision : 2
Case map routine   : 00D8:11EF
#####

Cheers,
Robert
-- 
              +++ BTTR Software +++
     Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/

[Freedos-kernel] Added line by line comments to the boot loaders

[aoi k. <aoi...@gm...>]

Hi All,

I have added line by line comments to the four boot loaders `boot.asm`,
`boot32.asm`, `boot32lb.asm`, and `oemboot.asm`. Check out [this post]
<https://aoik.me/blog/posts/freedos-source-code-study-boot-sector>. Are you
interested in merging these comments into the code base?

Regards
Aoik

Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS

[C. M. <cm...@bt...>]

On at 2018-11-05 15:51 +0100, Tom Ehlert wrote:
>> the FreeDOS kernel is seriously slower then MSDOS when doing
>> larger copy/xcopy operations.
> 
>> the cause: the disk I/O code avoids transfers that cross a 64K
>> boundary, and splits these transfers into 3 (smaller) transfers.
> 
>> this was needed for floppy controllers in the 1980's, but is certainly
>> not necessary for harddisks after the IBM XT.
> 
> 
>> just skip
> 
> 
>>           /* avoid overflowing 64K DMA boundary */
>>     count = DMA_max_transfer(buffer, totaltodo);
> 
>> for harddisks, and everything should be *much* faster (at least on
>> rotating media in a non-emulated machine)
> 
> investigating in this a bit more, the 64K boundary was/is a problem
> with ISA DMA, used only for floppies (and sometimes serial/parallel
> ports), but is no problem for UDMA.
> 
> skipping this test for drives with 0x80 set should be save, and result
> in a significant speedup of large disk transfers.

Another possibility is to depend on the error code (ah = 09h, RBIL lists
this as "data boundary error (attempted DMA across 64K boundary or >80h
sectors)") and retry the calls to avoid 64 KiB boundaries only then.
I've had success with that when loading from an actual diskette drive;
the error is properly reported and handled this way.

Regards,
ecm

Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS

[Tom E. <te...@dr...>]

> the FreeDOS kernel is seriously slower then MSDOS when doing
> larger copy/xcopy operations.

> the cause: the disk I/O code avoids transfers that cross a 64K
> boundary, and splits these transfers into 3 (smaller) transfers.

> this was needed for floppy controllers in the 1980's, but is certainly
> not necessary for harddisks after the IBM XT.


> just skip


>           /* avoid overflowing 64K DMA boundary */
>     count = DMA_max_transfer(buffer, totaltodo);

> for harddisks, and everything should be *much* faster (at least on
> rotating media in a non-emulated machine)

investigating in this a bit more, the 64K boundary was/is a problem
with ISA DMA, used only for floppies (and sometimes serial/parallel
ports), but is no problem for UDMA.

skipping this test for drives with 0x80 set should be save, and result
in a significant speedup of large disk transfers.

Tom

[Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS

[Tom E. <te...@dr...>]

Hi everybody,

the FreeDOS kernel is seriously slower then MSDOS when doing
larger copy/xcopy operations.

the cause: the disk I/O code avoids transfers that cross a 64K
boundary, and splits these transfers into 3 (smaller) transfers.

this was needed for floppy controllers in the 1980's, but is certainly
not necessary for harddisks after the IBM XT.


just skip


          /* avoid overflowing 64K DMA boundary */
    count = DMA_max_transfer(buffer, totaltodo);

for harddisks, and everything should be *much* faster (at least on
rotating media in a non-emulated machine)

Tom

[Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Tom E. <te...@dr...>]

   if exist K:\NUL echo K: is present

is broken in kernel 2042


the bug is caused by a change in TrueName(), where code was changed
from

  cdsEntry = get_cds(result);
  if (cdsEntry == NULL)
    return DE_PATHNOTFND;


to

  dhp = IsDevice(src);

  cdsEntry = get_cds(result);
  if (cdsEntry == NULL)
  {
    /* workaround for a device prefixed with invalid drive (e.g. "@:NUL") */
    /* (MS-DOS always return drive P: for invalid drive. Why P:?) */
    if (dhp)
    {
      result = default_drive;
      cdsEntry = get_cds(result);
      if (cdsEntry == NULL)
        return DE_PATHNOTFND;
    }
    else
      return DE_PATHNOTFND;
  }


now truename("e:\NUL") returns not 'path not found', but 'isDevice'


probably by fixing one bug, another bug was introduced.
Unfortunately I don't know what bug the changed is supposed to fix...

who introduced this change and why?

comments?

Tom

[Freedos-kernel] announce: fdpp, a 64bit DOS in C++

[Stas S. <st...@li...>]

Hi all DOS fans!

After a year of development, I am glad to announce
the new 64bit DOS. But as we know, all new is well-forgotten old,
so this actually is a freedos kernel port to 64 bits.
Some of you have probably already heard about
this project, as it was pre-announced on fosdem-18,
but at that time it could barely display the copyright
msg. So I bet no one believed this is even possible. :)
And here we go:
https://github.com/stsp/fdpp

The description of the project and the usage
instructions are in the readme:
https://github.com/stsp/fdpp/blob/master/README.md

The current status is on the releases page:
https://github.com/stsp/fdpp/releases

This is going to be the primary DOS for dosemu2,
but I hope it will be useful for other projects too.
For example the freedos-32 project:
http://freedos-32.sourceforge.net/
can likely get a very good use of it.

I don't know if the main freedos project can be
interested in a 64bit port of it, but I think there
were some talks in the past, including Pat V himself,
which I unfortunately can't google out now. Let's
see what people think.

The next target is going to be a 64bit command.com.
While it is in some distant future, the 32bit command.com
is already here:
https://github.com/stsp/comcom32

So lets move on to 64bits! Happy DOSing. :)

Re: [Freedos-kernel] boot sector woes

[Tom E. <te...@dr...>]

am 1. Februar 2017 um 01:23 schrieben Sie:

> this patch is a suggestion for the bootsector to boot on older (like my XT) machines
> where the drive requires a few retries before loading a sector.  The resulting binary
> might be too big actually.

that is a clear indication that you did not test this.

why do you expect that we do YOUR work ?

Tom



> In this case I would like a bit of help fitting it in there.

> yours,
>         - Mdasoh Kyaeppd

> --- boot.ori/boot.asm   2017-01-30 02:08:55.835437500 -0700
> +++ boot/boot.asm       2017-01-31 13:06:37.742679500 -0700
> @@ -423,7 +423,7 @@
>                                                  ; setup LBA disk block
>                  mov     LBA_SECTOR_32,bx        ; bx is 0 if extended 13h mode supported
>                  mov     LBA_SECTOR_48,bx
> -
> +               mov     si,1
>                  mov     ah,042h
>                  jmp short    do_int13_read

> @@ -472,12 +472,20 @@
>                  inc     cx                      ; make sector 1-based (1-63)

>                  les     bx,[LBA_OFF]
> +               mov     si,5
> +do_chs_read:
>                  mov     ax, 0x0201
>  do_int13_read:
>                  mov     dl, [drive]
> -                int     0x13
> -                jc      boot_error              ; exit on error
> +                int     0x13                   ; read data from disk
> +               jnc     did_int13_read

> +               xor     ax,ax
> +               int     0x13
> +               dec     si
> +                jz      boot_error              ; exit on error
> +               jmp     do_chs_read             ; prod it a few times
> +did_int13_read:
>                  mov     ax, word [bsBytesPerSec]

>                  push    di

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Freedos-kernel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886

[Freedos-kernel] boot sector woes

[Mdasoh K. <mingdaisung@Safe-mail.net>]

this patch is a suggestion for the bootsector to boot on older (like my XT) machines
where the drive requires a few retries before loading a sector.  The resulting binary
might be too big actually.  In this case I would like a bit of help fitting it in there.

yours,
        - Mdasoh Kyaeppd

--- boot.ori/boot.asm   2017-01-30 02:08:55.835437500 -0700
+++ boot/boot.asm       2017-01-31 13:06:37.742679500 -0700
@@ -423,7 +423,7 @@
                                                 ; setup LBA disk block
                 mov     LBA_SECTOR_32,bx        ; bx is 0 if extended 13h mode supported
                 mov     LBA_SECTOR_48,bx
-
+               mov     si,1
                 mov     ah,042h
                 jmp short    do_int13_read

@@ -472,12 +472,20 @@
                 inc     cx                      ; make sector 1-based (1-63)

                 les     bx,[LBA_OFF]
+               mov     si,5
+do_chs_read:
                 mov     ax, 0x0201
 do_int13_read:
                 mov     dl, [drive]
-                int     0x13
-                jc      boot_error              ; exit on error
+                int     0x13                   ; read data from disk
+               jnc     did_int13_read

+               xor     ax,ax
+               int     0x13
+               dec     si
+                jz      boot_error              ; exit on error
+               jmp     do_chs_read             ; prod it a few times
+did_int13_read:
                 mov     ax, word [bsBytesPerSec]

                 push    di

[Freedos-kernel] kernel 2042 fdconfig.sys install param not passing switches to command

[Nando E. <nan...@ym...>]

Hi,
I noticed was getting more messages appearing during my bootup with kernel 2042 compared to 2041. Upon investigation, I found it is not passing any switches given in fdconfig.sys install=<command> <swiches> to the command. This is the case also of installhigh.

eg fdconfig.sys lines:

2345?install=\DOS\ansi.com /q
6?install=\core\tm.exe /43 

Confirmed behaviour under kernel 2041* ansi.com quietly loads as directed (/q)* tm.exe (inkutils) switches to 80x43 mode as directed (/43)

Confirmed behaviour under 2042* ansi.com ignores /q and prints usage messages* tm.exe does not switch to 80x43 mode, instead reports current mode consistent as if no switch given.

This and the NUL drive/dir bug I reported several days ago, with a hotfix kernel provide by Tom,  are pretty big bugs. For now I've gone back to 2041 as am concerned about other nasties I've yet to discover. 
Nando

Re: [Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Nando E. <nan...@ym...>]

Tom, screenshots at http://imgur.com/a/h9x9c showing kernel 2042 always identifying e:\nul as present (attrib e:\nul or if exist e:\nul), even though it is not. Kernel 2041 correctly identifies it as not present.

A fix for this would be great so I can again check for drive/dir existence using the NUL filename.

Thank you,Nando

 

    On Friday, 27 January 2017, 3:42, Tom Ehlert <te...@dr...> wrote:
 

 
Hi,

> Was using FreeDOS 1.1 2040 kernel? previously and could check for
> drive or directory existence with the NUL device:


> If exist c:\nul echo C: exists
> If exist c:\mydir\nul echo C:\mydir exists


> This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore.

I tried to reproduce this here, and I think that it behaves exactly as
it should.

can you be more specific how it fails ?


Tom



   

Re: [Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Tom E. <te...@dr...>]

Hi,

> Was using FreeDOS 1.1 2040 kernel? previously and could check for
> drive or directory existence with the NUL device:


> If exist c:\nul echo C: exists
> If exist c:\mydir\nul echo C:\mydir exists


> This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore.

I tried to reproduce this here, and I think that it behaves exactly as
it should.

can you be more specific how it fails ?


Tom

[Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Nando E. <nan...@ym...>]

Was using FreeDOS 1.1 2040 kernel? previously and could check for drive or directory existence with the NUL device:
If exist c:\nul echo C: existsIf exist c:\mydir\nul echo C:\mydir exists
This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore.
Can the devs please add the previous behaviour with NUL drive/directory identification?
Thank you

Re: [Freedos-kernel] How do I compile just the bootsector and kernel?

[Louis S. <lps...@gm...>]

See the FreeDOS Spec [0].  OpenWatcom C/C++ (1.9?) (and by extension
WASM/JWASM? for ASM??) and NASM (no version either though many are
based on 0.98.x) are the reference compilers/assemblers/linker.

I was able to able to compile a recent kernel version with the
non-reference compiler Borland C/C++ 4.5.2 (the last Borland C/C++
compiler to support DOS compiling executables).  I had to make minor
changes to the Makefiles to successfully compile the kernel.  See the
mailing list archives for my notes.

[0] http://wiki.freedos.org/wiki/index.php/FreeDOS_Spec#Programming_tools

On Wed, Jan 4, 2017 at 11:17 PM, Mateusz Viste <ma...@no...> wrote:
> On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote:
>> Of all the many files in the FreeDOS sourcecode, which files will I need
>> if I just want to compile the bootsector and the kernel?
>
> You'll need the source files present in the "KERNEL" package,
> unsurprisingly. You can also fetch these sources on-line here:
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/
>
>> And also, what is the recommended free compiler (I'm
>> not about to spend money to buy one) for use in compiling the FreeDOS
>> bootsector and kernel?
>
> The FreeDOS kernel can supposedly be compiled with the following
> compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C.
> >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both
> are free (no cost). Using Turbo C requires to change a few lines of
> comments though, as I wrote here the 26th November of last year (still
> not fixed on SVN).
>
> Mateusz
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Freedos-kernel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] How do I compile just the bootsector and kernel?

[Mateusz V. <ma...@no...>]

On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote:
> Of all the many files in the FreeDOS sourcecode, which files will I need
> if I just want to compile the bootsector and the kernel?

You'll need the source files present in the "KERNEL" package, 
unsurprisingly. You can also fetch these sources on-line here:
https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/

> And also, what is the recommended free compiler (I'm
> not about to spend money to buy one) for use in compiling the FreeDOS
> bootsector and kernel?

The FreeDOS kernel can supposedly be compiled with the following 
compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C.
>From those, I have tested successfully Open Watcom and Turbo C 2.01. Both 
are free (no cost). Using Turbo C requires to change a few lines of 
comments though, as I wrote here the 26th November of last year (still 
not fixed on SVN).

Mateusz

[Freedos-kernel] How do I compile just the bootsector and kernel?

[Ben H. <be...@gm...>]

Of all the many files in the FreeDOS sourcecode, which files will I need if
I just want to compile the bootsector and the kernel? I don't care to build
command.com, or any of the tools that normally come with a full copy of
FreeDOS. And also, what is the recommended free compiler (I'm not about to
spend money to buy one) for use in compiling the FreeDOS bootsector and
kernel?

Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?

[Tom E. <te...@dr...>]

>>From the point of view of protecting this system from counterfeiting &
> unauthorised access, is it possible to interrupt processing config.sys? I
> had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
> this can be disabled in config.sys.

modify kernel.sys by using

 sys config kernel.sys SKIPCONFIGSECONDS=-1

to disable F5/F8 completely.

OTOH, removing command.com will also completely disable tinkering with
the system.

> Another thought I have - what would the behaviour of the kernel be if my
> program (as the command processor) does terminate? Does it reboot, restart
> the command processor, or just hang?

most likely just hang. test yourself.

Tom

Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?

[David K. <dk...@qb...>]

Thanks! It looks like the shell directive does exactly what I want. It
defines what the kernel loads as the command processor. I'm in a funny
situation where I only have just over 6 months total experience with DOS,
and yet I'm writing DOS software for machinery which is 200 miles away...
Not ideal, but it is what it is.

>From the point of view of protecting this system from counterfeiting &
unauthorised access, is it possible to interrupt processing config.sys? I
had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
this can be disabled in config.sys. That seemed like a chicken and egg
situation to me - disabling processing of config.sys by executing config.sys
? What if F5 is pressed before config.sys is loaded? The system doesn't have
a keyboard plugged in, but it's not impossible to plug one in if you're
interested in poking around the system. However, if I completely removed
command.com and all other commands then the kernel wouldn't be able to load
anything. 

Another thought I have - what would the behaviour of the kernel be if my
program (as the command processor) does terminate? Does it reboot, restart
the command processor, or just hang?



--
View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25679.html
Sent from the FreeDOS - Kernel mailing list archive at Nabble.com.

Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?

[Mateusz V. <ma...@no...>]

On Fri, 09 Dec 2016 02:07:24 -0700, David Kay wrote:
> Is it possible to get the kernel to load my program directly instead of
> via autoexec.bat? Then my system would just be composed of the kernel
> and my program?

Have you tried to declare your program in CONFIG.SYS using the SHELL= 
directive ? Seems like an easy test that would provide you with the 
answer you look for. Renaming your program to COMMAND.COM is also a 
possible test, albeit perhaps less elegant. I wouldn't expect troubles, 
but as usual, testing it out is the only way to be sure.

cheers,
Mateusz

Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?

[David K. <dk...@qb...>]

Currently the program uses a separate DPMI host. But I believe I can prepend
my program with a DPMI host so that it starts directly in real mode?

Would renaming this executable to command.com enable the kernel to load it
directly?



--
View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25677.html
Sent from the FreeDOS - Kernel mailing list archive at Nabble.com.