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

2020-05-17 Thread Jim Hall
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 mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2020-04-22 Thread Eric Auer


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.



_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2020-03-19 Thread Robert Riebisch
Hi Jeremy,

> Hi perditi...@gmail.com,
> 
>> 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/


___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2020-01-24 Thread Robert Riebisch
Hi perditi...@gmail.com,

> 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/
--- COUNTRY-orig.ASMSun Jun 26 21:05:00 2011
+++ COUNTRY.ASM Fri Jan 24 15:32:37 2020
@@ -192,11 +192,11 @@ __pl_858 dw 12, 48,858,0,0
 dd _pl_858
 __de_858 dw 12, 49,858,0,0
 dd _de_858
 __de_850 dw 12, 49,850,0,0
 dd _de_850
-__de_437 dw 12, 49,858,0,0
+__de_437 dw 12, 49,437,0,0
 dd _de_437
 __ar_858 dw 12, 54,858,0,0
 dd _ar_858
 __ar_850 dw 12, 54,850,0,0
 dd _ar_850
@@ -3088,13 +3088,13 @@ no_865 cnf  47,865,DMY,"K","r",  0,0,0,"
 no_850 cnf  47,850,DMY,"K","r", 0,0,0,".",",",".",":",2,2,_24; Norway
 no_858 cnf  47,858,DMY,"K","r", 0,0,0,".",",",".",":",2,2,_24; Norway
 pl_852 cnf  48,852,YMD,"Z",88h, 0,0,0,".",",","-",":",0,2,_24; Poland  
 Michal
 pl_850 cnf  48,850,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland
 pl_858 cnf  48,858,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland
-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
+de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany
Tom
+de_858 cnf  49,850,DMY,0D5h,   0,0,0,0,".",",",".",":",3,2,_24; Germany
+de_437 cnf  49,437,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany
 ar_850 cnf  54,850,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 ar_858 cnf  54,858,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 ar_437 cnf  54,437,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 br_850 cnf  55,850,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil
 br_858 cnf  55,858,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2020-01-23 Thread perditionc
Thank you.  I will try to get to this by the weekend.

Jeremy

On Thu, Jan 23, 2020, 3:11 PM Robert Riebisch  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:
> 3984: 2E 3A
> 3995: 52 5A
> 39A4: 2E 3A
> 39C4: 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:
> 041B: 5A B5
> 041C: 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:
> 3986: 01 03
> 39C6: 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
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
>
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2020-01-23 Thread Robert Riebisch
uot;,".",":",2,2,_24; Norway
 pl_852 cnf  48,852,YMD,"Z",88h, 0,0,0,".",",","-",":",0,2,_24; Poland  
 Michal
 pl_850 cnf  48,850,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland
 pl_858 cnf  48,858,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland
-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
+de_850 cnf  49,850,DMY,"E","U","R",0,0,".",",",".",":",3,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,".",",",".",":",3,2,_24; Germany
 ar_850 cnf  54,850,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 ar_858 cnf  54,858,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 ar_437 cnf  54,437,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina
 br_850 cnf  55,850,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil
 br_858 cnf  55,858,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2018-11-05 Thread C. Masloch
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


_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2018-11-05 Thread Tom Ehlert
> 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 mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2018-10-30 Thread Tom Ehlert


   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 mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2018-09-08 Thread Stas Sergeev via Freedos-kernel

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. :)


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


[Freedos-kernel] boot sector woes

2017-01-31 Thread Mdasoh Kyappd
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 shortdo_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]

 pushdi

--
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
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2017-01-26 Thread Tom Ehlert

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


--
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
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2017-01-25 Thread Nando Eva
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


--
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
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2017-01-05 Thread Louis Santillan
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 <mate...@nospam.viste.fr> 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
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
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
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2016-12-09 Thread Tom Ehlert
>>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



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2016-12-09 Thread David Kay
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.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2016-12-09 Thread Mateusz Viste
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


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-12-05 Thread Jason Hood
On 6/12/2016 7:23, Robert Riebisch wrote:
> I have used http://www.bttr-software.de/freesoft/menu.htm#linkln for
> many years.

Yeah, that sounds like the one I was thinking of (and the Free
Software list is probably where I came across it).  I don't think
I ever used it (stopped using DOS around that time), just curious
to how it worked.

-- 
Jason.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread Jason Hood
On 30/11/2016 8:54, Mateusz Viste wrote:
> Here's the thing: I, as a user, store lots of useful software on my PC. 
> Many of these programs are so useful that I like to have them available 
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG, 
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
> 
> To achieve this, I know of four ways. Each comes with some limitations.

Simtel had two programs that create links: exelink2.zip and linkln10.zip.
I though I had the former, but apparently no longer; iirc it used a text
file to store the links and a TSR to hook the EXEC call.

-- 
Jason.

--
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread Louis Santillan
Method 1 is the traditional DOS way of installing software.

Maybe some advanced usage of JOIN & SUBST is what you are looking for?

Another alternative (though slightly messy) would be to combine
Methods 1 & 4.  By that, I mean, leave the *.bats in C:\DOS.  The
*.bats will temporarily create a new Environment & PATH extended as
the application expects and then remove the adjustment.  This will
slow down many types of computing, as HPA mentioned, SW builds come to
mind

-L.

On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste <mate...@nospam.viste.fr> wrote:
> On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
>> But why the batch file in the first place?  It truly makes no sense: it
>> pollutes the namespace equally, and can just cause problems (e.g. in the
>> case of more than 9 arguments.)  Not to mention slowing down a make.
>
> Here's the thing: I, as a user, store lots of useful software on my PC.
> Many of these programs are so useful that I like to have them available
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
>
> To achieve this, I know of four ways. Each comes with some limitations.
>
> Method 1: Store every program in its own directory, and add each
> directory to the %PATH%. Problem: obviously the environment will get very
> bloated, very fast. Besides, some programs come with add-on tools that I
> do not want to be available from within my path.
>
> Method 2: Trim out the programs from everything besides a single exe, and
> put them all in a single directory declared in my %PATH%. But this poses
> two problems that I cannot live with: first, not every program can be
> trimmed out to a single executable file (data files, config files, etc),
> and second - almost all programs come with their respective README files
> and other valuable documentation that I really want to keep within the
> vicinity of the executable (ie. in the same directory).
>
> Method 3: Store each tool in its own directory, and place a COPY of its
> executable inside a directory in the %PATH%. Well, this is just messy -
> upgrading the program needs to think about replacing the executable each
> time in both places, and it's simply a waste of disk space.
>
> Method 4: Keep each program in its own directory with all its original
> files, and only store *.bat "links" in a single directory somewhere in
> the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
> unfortunately, of *.bat's own limitations (max 9 args and '=' processing
> weirdness).
>
> The method 4 is what I started doing back in the nineties, and as of
> today I still didn't find a better (or let's say, less worse) way. That's
> a lifetime project it would seem.
>
> The method 4 is also something that I implemented last year inside FDNPKG
> (the FreeDOS package manager), but since I discovered recently how oddly
> the '=' character is processed in %1-like arguments (there's a separate
> thread about that on freedos-devel), I will have to figure out some
> improved method... first thought pointed to computing some COM loader
> relying on INT21,4Bh but that's far less trivial than the current batch
> method, and hobby time is scarce.
>
> Mateusz
>
>
> ------
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

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


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread Mateusz Viste
On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
> But why the batch file in the first place?  It truly makes no sense: it
> pollutes the namespace equally, and can just cause problems (e.g. in the
> case of more than 9 arguments.)  Not to mention slowing down a make.

Here's the thing: I, as a user, store lots of useful software on my PC. 
Many of these programs are so useful that I like to have them available 
immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG, 
QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.

To achieve this, I know of four ways. Each comes with some limitations.

Method 1: Store every program in its own directory, and add each 
directory to the %PATH%. Problem: obviously the environment will get very 
bloated, very fast. Besides, some programs come with add-on tools that I 
do not want to be available from within my path.

Method 2: Trim out the programs from everything besides a single exe, and 
put them all in a single directory declared in my %PATH%. But this poses 
two problems that I cannot live with: first, not every program can be 
trimmed out to a single executable file (data files, config files, etc), 
and second - almost all programs come with their respective README files 
and other valuable documentation that I really want to keep within the 
vicinity of the executable (ie. in the same directory).

Method 3: Store each tool in its own directory, and place a COPY of its 
executable inside a directory in the %PATH%. Well, this is just messy - 
upgrading the program needs to think about replacing the executable each 
time in both places, and it's simply a waste of disk space.

Method 4: Keep each program in its own directory with all its original 
files, and only store *.bat "links" in a single directory somewhere in 
the PATH. This mitigates the troubles of methods 1 and 2, at the cost, 
unfortunately, of *.bat's own limitations (max 9 args and '=' processing 
weirdness).

The method 4 is what I started doing back in the nineties, and as of 
today I still didn't find a better (or let's say, less worse) way. That's 
a lifetime project it would seem.

The method 4 is also something that I implemented last year inside FDNPKG 
(the FreeDOS package manager), but since I discovered recently how oddly 
the '=' character is processed in %1-like arguments (there's a separate 
thread about that on freedos-devel), I will have to figure out some 
improved method... first thought pointed to computing some COM loader 
relying on INT21,4Bh but that's far less trivial than the current batch 
method, and hobby time is scarce.

Mateusz


--
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread H. Peter Anvin
On 11/29/16 12:50, Travis Siegel wrote:
>
> Because, apparently the nasm being called isn't in c:\devel\nasm, so 
> change the path in the nasm.bat file to point to the proper place, and 
> the problem should be solved.  Either solution will work.
> 

But why the batch file in the first place?  It truly makes no sense: it
pollutes the namespace equally, and can just cause problems (e.g. in the
case of more than 9 arguments.)  Not to mention slowing down a make.

-hpa



--
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread Travis Siegel


On 11/29/2016 3:32 PM, H. Peter Anvin wrote:
> On 11/24/16 00:59, Mateusz Viste wrote:
>> Hi,
>>
>> Your problem is related to the fact that your "nasm" command doesn't call
>> nasm.exe directly. Instead, it calls a batch file named nasm.bat which
>> has been placed in your %PATH% by the FDNPKG installer. This nasm.bat
>> file is pretty straight-forward:
>>
>>@ECHO OFF
>>C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9
>>
>> While in theory such trick should work (and it does work with most other
>> utilities out there), somehow it doesn't play out right with nasm. Simply
>> edit your CONFIG.BAT to set its XNASM variable to the full path to your
>> copy of nasm.exe, and you're done. Enjoy!
>>
> And pray tell, why?
>
>   -hpa
>
>
>
Because, apparently the nasm being called isn't in c:\devel\nasm, so 
change the path in the nasm.bat file to point to the proper place, and 
the problem should be solved.  Either solution will work.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-29 Thread H. Peter Anvin
On 11/24/16 00:59, Mateusz Viste wrote:
> 
> Hi,
> 
> Your problem is related to the fact that your "nasm" command doesn't call 
> nasm.exe directly. Instead, it calls a batch file named nasm.bat which 
> has been placed in your %PATH% by the FDNPKG installer. This nasm.bat 
> file is pretty straight-forward:
> 
>   @ECHO OFF
>   C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9
> 
> While in theory such trick should work (and it does work with most other 
> utilities out there), somehow it doesn't play out right with nasm. Simply 
> edit your CONFIG.BAT to set its XNASM variable to the full path to your 
> copy of nasm.exe, and you're done. Enjoy!
> 

And pray tell, why?

-hpa



------
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] ke2042 doesn't compile with Turbo C 2.01

2016-11-24 Thread Mateusz Viste
Hello,

I noticed that the ke2042 svn tag doesn't compile using Turbo C 2.01. The 
reason is quite trivial:

config.c:
Error config.c 407: Expression syntax in function PreConfig2

Indeed, config.c contains two commented line at 407 and 408:

//  if (UmbState == 2)
//umb_init();

I have no idea why these lines are commented, but the fact is that they 
are commented using non-C89 comments.
Simply replacing them with ANSI C /* */ comments solves the issue.

It's nothing important, an annoyance more than anything, but perhaps it 
would be worth "fixing" it in svn to avoid frustrating other users that 
might try compiling the kernel with Turbo C or something else that 
doesn't know about '//' comments...

Mateusz


--
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] ke2042: nasm fails to assemble files during build time

2016-11-23 Thread Mateusz Viste
Hello group,

I am trying to compile the FreeDOS kernel from svn's tag ke2042, but it 
appears that build.bat fails to assemble several files. For instance:

  nasm -DTC2 -DWITHFAT32 -i../hdr/ -DXCPU=86 -f obj floppy.asm
  nasm: error: more than one input file specified
  nasm: error: more than one input file specified

Not sure why this happens, the command looks sane. If I redo the nasm 
command by hand, I get the same message. Trying to compile on DOSEMU, 
using nasm v2.12.02.

Have I missed something obvious? Any clue?

regards,
Mateusz


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


Re: [Freedos-kernel] EXT3 support

2016-08-26 Thread H. Peter Anvin
On August 26, 2016 12:26:52 AM PDT, Eric Auer <e.a...@jpberlin.de> wrote:
>
>Hi HPA! The boot sector takes a BIOS drive number of the
>to-be-booted drive from the MBR, which can take it from
>the BIOS. There also are patches to take the MBR item by
>pointer from the MBR, but those are not used by default.
>
>So I guess the kernel could take the drive number from a
>boot sector, which at the moment is easy because the boot
>sector stores the value from the MBR in the drive byte of
>the boot sector loaded into RAM, which is a predictable
>location in general. Might be fun for booting from 0x81.
>
>>> support for EXT3 in the kernel would indeed be large/complex.
>
>Would not do that, but would boot DOS by MEMDISK and load a
>full EXT3 driver from there later :-) Same for ISO9660, but
>there "read files from ISO root dir" might be quite small,
>so boot without MEMDISK might be interesting as well...
>
>>> Regarding the idea to have the kernel "natively boot from a
>>> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
>>> on modern computers it should not be a problem to "hog" the
>>> drive letter of the A: floppy drive - you probably have at
>>> most ONE real floppy next to that ramdisk anyway and letter
>>> B: is still free :-) So in that sense, MEMDISK is ok for me.
>
>Exactly :-)
>
>> So this is a horribly stale discussion, but it seems that all that is
>> needed is the ability to hide somewhere a preferred drive letter for
>the
>> FreeDOS kernel to pick up and use.  It is trivial to add support for
>> passing such information along in MEMDISK.
>> 
>>  -hpa

Hi!

Memdisk already supports being a disk number other than 0x00 or 0x80, and the 
DL register will reflect that.  However, I was thinking of provided a more 
explicit hint, so that scripts can reply on the ramdisk being, say, R:
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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


Re: [Freedos-kernel] EXT3 support

2016-08-26 Thread Eric Auer

Hi HPA! The boot sector takes a BIOS drive number of the
to-be-booted drive from the MBR, which can take it from
the BIOS. There also are patches to take the MBR item by
pointer from the MBR, but those are not used by default.

So I guess the kernel could take the drive number from a
boot sector, which at the moment is easy because the boot
sector stores the value from the MBR in the drive byte of
the boot sector loaded into RAM, which is a predictable
location in general. Might be fun for booting from 0x81.

>> support for EXT3 in the kernel would indeed be large/complex.

Would not do that, but would boot DOS by MEMDISK and load a
full EXT3 driver from there later :-) Same for ISO9660, but
there "read files from ISO root dir" might be quite small,
so boot without MEMDISK might be interesting as well...

>> Regarding the idea to have the kernel "natively boot from a
>> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
>> on modern computers it should not be a problem to "hog" the
>> drive letter of the A: floppy drive - you probably have at
>> most ONE real floppy next to that ramdisk anyway and letter
>> B: is still free :-) So in that sense, MEMDISK is ok for me.

Exactly :-)

> So this is a horribly stale discussion, but it seems that all that is
> needed is the ability to hide somewhere a preferred drive letter for the
> FreeDOS kernel to pick up and use.  It is trivial to add support for
> passing such information along in MEMDISK.
> 
>   -hpa



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


Re: [Freedos-kernel] EXT3 support

2016-08-25 Thread H. Peter Anvin
On 01/13/16 08:33, Eric Auer wrote:
> 
> Hi HPA and Joao,
> 
> support for EXT3 in the kernel would indeed be large/complex.
> 
> Only supporting EXT3 READS already would take circa 10 kB of
> code, taking the size of the EXT2/3/4 GRUB module as example.
> 
> I like MEMDISK bootable ramdisk style: MEMDISK can be booted
> by boot loaders which are able to boot Linux, and it can use
> any diskimage accessible by such boot loaders, including an
> image on EXT3 disks. Boot loaders either pre-compute a list
> of sectors to read files or load extra driver modules, which
> only have to support reading and which are not kept in RAM.
> 
> Regarding the idea to have the kernel "natively boot from a
> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
> on modern computers it should not be a problem to "hog" the
> drive letter of the A: floppy drive - you probably have at
> most ONE real floppy next to that ramdisk anyway and letter
> B: is still free :-) So in that sense, MEMDISK is ok for me.
> 

So this is a horribly stale discussion, but it seems that all that is
needed is the ability to hide somewhere a preferred drive letter for the
FreeDOS kernel to pick up and use.  It is trivial to add support for
passing such information along in MEMDISK.

-hpa


----------
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

2016-08-24 Thread Eric Auer

Hi again,

I have tried to investigate this problem further by comparing 3 files:

> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32lb.asm
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32.asm
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot.asm

> Left-bound text is about LBA or FAT1x code, while
> indented text is about FAT32 CHS in this email.

Some items are at different places but hopefully (?) do not get overwritten:

> boot32lb: fat_secshift [selfmodifying]
> fat_sector@+0x44 fat_start@+0x48 data_start@+0x4c
> boot32: fat_secshift@+0x68, CHS boot sector
> fat_sector@+0x48 fat_start@+0x5e data_start@+0x62 fat_secmask@+0x66

The initial calculations seem to achieve the same in different ways:

> fat_sector = dd 0
> done much later in CHS case, but early enough as far as I can tell
> fat_start = data_start = dd nHidden + word bsResSectors
> di:si and fat_start okay, check data_start
> data_start += dd (byte followed by 2 dw 0?) [bsFATs] *signed dd [xsectPerFat]
> ax = db bsFATs cbw
> di += ax * dw xsectPerFat HIGH, ignoring overflows
> data_start = dx:ax = di:si + (ax * dw xsectPerFat LOW), 16x16=32 bit

However, the "secshift" calculations are rather different here...

Note that the FAT12 / FAT16 boot sector reads the entire FAT
into RAM first, so THAT does not have to know which sector of
the FAT contains info about which cluster.

> fat_secshift = 7 for 128 FAT items per 512 byte sector
> ax = 512
> while ax not bsBytesPerSec
>   ax <<= 1
>   fat_secshift++
> endwhile
> cx = fat_secmask = (dw bsBytesPerSec >> 2) - 1
> cx++, now (dw bsBytesPerSec >> 2) which is FAT items per sector
> ax expected to be 0 after movsw
> do
>   ax++
>   cx >>= 1
> while cx not 1
> fat_secshift = AL, low byte of ax
> fat_sector LOW = fat_sector HIGH = cx-- (is 0 now)

Mixed other differences which might be relevant:

> only boot32lb uses 386+ code and calls print which modifies AX BX SI
> convert_cluster: cmp eax,fff fff8 jnc EOF
> convert_cluster: cmp dx,fff jnz okay cmp ax,fff8 jnc EOF?
> 
> next_cluster uses shr dx,1 rcr ax,1 in a loop to shr DX:AX by fat_secshift
> ... ((di and secmask) << 2) + fat_start ...

And from the comparison FAT32 CHS to FAT12 / FAT16 boot code:

> note: FAT12 / FAT16 boot sector readDisk changes CX, ADD COMMENT HERE!

> note: FAT1x boot does not retry in readDisk, plus used extra buffers
> "inc ah or cl,ah" versus "or cl,ah inc cx" for 1-based sector

The next_cluster, convert_cluster and readDisk calls all juggle with
plenty of registers in strictly defined ways, I might have overlooked
some unintended register changes somewhere.

Cheers, Eric



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


[Freedos-kernel] FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

2016-08-24 Thread Eric Auer

As SYS is part of the kernel sources, maybe somebody on the
kernel mailing list has an idea for me...? Thanks! :-)



Hi everybody,

apparently the same SYS update which introduced FAT32 LBA support also
broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always
fails, but his BIOS lacks LBA support. After installing MBR-based disk
drivers to add LBA support and support for 4 instead of 2 harddisks,
FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he
had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector.

I was busy trying to find out what broke and when, but cannot find it.
Maybe you can help me out here... :-)

- old SYS sets drive number to -1 but it gets overwritten on boot anyway

- new SYS sets drive number to 0x80 but it gets overwritten on boot, too

- new SYS uses signed byte to word comparison in cluster code (fff fff8
  versus fff -8) but source code is unchanged, maybe a NASM auto tune?)

- r751 moves the load location far pointer to inside the code, while it
  was at +5a in the variable area before. Not sure why that was changed?

Apparently both good and bad are AFTER this diff, so that should be
safe? The r321 to r343 patch makes CHS calculations small but obscure:

> https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/boot32.asm?diff=321

This leaves the main "calculate parameters at runtime, instead of using
SYS to hardcode them" patch as suspicious change. We have this patch to
keep FAT32 partitions bootable even when you resize them with 3rd party
tools. Of course the patch adds yet more obscure code to the boot sect:

> https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/boot32.asm?diff=382

Note that this r382 to r652 patch also drops the last call of "print",
so we could drop that function to gain some space for making the code
a bit less unreadable by "un-optimizing" some bits. Apparently somebody
simply forgot to drop print after dropping the last place using it ;-)

Not sure why, but the patch also moves around the offsets of 4 variables
by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which
makes the before / after the patch situation a bit harder to "diff" now.

The basic function of the patch is to add some code after the setup of
stack, segments and registers and relocation to 1FE0:, but before
the first call to "find sector for cluster" and "read sector from disk"
after which the root directory is scanned and, when a kernel is found,
the kernel file is loaded by cluster chain:

dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e]

DI = DI + (byte fats [+10] * word sec per fat HIGH [+26])
[+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI

word sec mask [+66] = CX ... = (AX >> 2) - 1
AX = 1 ...
do
  CX >>= 1
  AX++
while CX not 1
byte sec shift [+68] = AL

(the above is my attempt to summarize what the code actually does, see
the source code for the description of what it wants to do - as said,
I fail to see a problem here, but the symptom still is a failed boot!)

Thanks for helping out!

Cheers, Eric

PS: Of course the boot sector stores DL to byte drive [+40] before it
starts juggling with DX:AX, so that value seems to be safe as well.


----------
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] KERNEL 2042 and its attachments (AKA SYS)

2016-07-13 Thread dos386
I downloaded and installed the new kernel, and looked a bit and tested a bit.

There is a version history file included and it lists a few detail improvements.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt
<- outdated

Are there some major applications that previously didn't work but now
should work (Watcom debugger ? DGJPP ? ...) ?

shots: http://www.xaver.me/drdoswiki/index.php?n=Main.Gallery#toc18 -
(C) still says "2012"

There is a "SYS.COM" 3.6 included recompiled with new date but not
consistent with "SYS.COM" 3.7 or 3.8 from here:
http://www.fdos.org/kernel/sys ... what's the point of those 2
branches of SYS? The source code looks inconsistent (2 branches
developed separately ?), some files differ by whitespace only.
Unfortunately there doesn't seem to be any history file for "SYS.COM".
What is the preferable version of SYS ?

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2042 release

2016-07-08 Thread dos386
> Freedos-kernel] Kernel 2042 release

Thanks :-) (I'll test)

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] UMB question

2016-06-30 Thread Eric Auer

Hi kernel experts,

I vaguely remember that there is a pending patch where the kernel
is using a memcopy-style function residing in memory that already
got "freed" at that moment during boot, so I guess the gurus are
awake at the moment...

QUESTION: Would it be possible to improve UMB handling such that
the kernel supports SEVERAL providers of UMB at the same time, for
example UMBPCI for hardware-UMB and in addition EMM386 to "map" a
few more UMB to areas where normally a memory gap would be, such
as the "monochrome video memory" area?

Might be interesting to have even more UMB flexibility :-)

Regards, Eric


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] BUG: problems with INSTALL=, reported by Bret Johnson

2016-06-10 Thread Tom Ehlert
the problem, brought up by Bret:

during config.sys processing,

INSTALL= \freedos\MEM.EXE /F

will report ~24 K used at 99f0:0

however the kernel will crash if memory below this is overwritten.

source for the bug:


CONFIG.C, DoInstall() sets up a memory arena, and releases memory
below the INIT CODE segment, based on the assumption that 'normal' code
is no longer needed. this is *almost* true.

unfortunately

   STATIC void kernel()
   {
 CommandTail Cmd;

 strcpy(master_env, "PATH=.");
 fmemcpy(MK_FP(DOS_PSP + 8, 0), master_env, sizeof(master_env));

 memset(Cmd.ctBuffer, 0, sizeof(Cmd.ctBuffer));
 strcpy(Cmd.ctBuffer, Config.cfgInitTail);



will use strcpy() and memset(), located at CS:11ee and freed by
DoInstall, and potentially overwritten.


probably the easiest solution: write some quick

   init_memcpy() ...

to be used at *this* location by Kernel().

I'm away for a week; will continue work when back.




Tom




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2042 release

2016-05-12 Thread perditionc
On May 12, 2016 2:05 PM, "Tom Ehlert" <t...@drivesnapshot.de> wrote:
>
> > INTERLINK issue has not been resolved, and still requires
> > option to load low.
>
> Why not?
>
> crashing the kernel when a driver calls DosAlloc() is not so smart an
> idea. disabling dosalloc for drivers is possibly suboptimal, but at least
> prevents a crashing kernel.
>
> of course a better fix would be nice but I won't hold my breath.
>
> IMO planning a 'release' with a known problem AND fix is stupid.
>
> Tom
>
There is not a fix.  While your suggestion should work, it doesn't for me.
The flag variable to fast fail had the wrong value in my test kernel.
Something is wrong and it will take me time to track down the issue or fix
properly.  In the meantime, there are important changes that I want to
ensure make it into next distribution released.

Jeremy
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Kernel 2042 release

2016-05-11 Thread perditionc
Kernel 2042 is tagged.  Source and 8086+ builds are staged on SF
(admins can view now, everyone else in a few days).  386+ builds are
not yet available.
Builds with FAT12/16 only and FAT12/16/32, source archive, and fdpkg
files are also available http://www.fdos.org/kernel/release/LATEST/
and will include 386+ versions once I build them.

This release includes mostly bug fixes, please see docs/history file
or revision control logs for details.

I have not yet committed all the changes/patches/pull requests in my
queue, but I did not want to delay the release any longer to ensure it
makes it into FreeDOS 1.2 release as it fixes several important
issues.  INTERLINK issue has not been resolved, and still requires
option to load low.  Please note that although a version of sys is
still in the sources and included in the releases, it is not the
latest version; a future change will remove sys from the kernel
sources and move it into its own package; possibly the same for share
and country so they can be updated separately from the kernel.

Jeremy

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] INTERLINK

2016-02-05 Thread Tom Ehlert
Hi,

https://sourceforge.net/p/freedos/bugs/147/

located the bug in freedos kernel. this the first driver *at all* that
uses dos_alloc (int 21 ah=48)



INTERLNK.EXE does (pseudocode)


is running at

426:2951

   if (dos_version < 5)// try load high to UMB
  goto continue_load;

426:2965
   seg = dos_alloc(driversize);// driversize ~= 2f0 para

   JC continue_load

   //
   // move driver up to UMB
   // relocate interrupt vectors, driver list, ...

continue_load:


unfortunately  dos_alloc(driversize) succeeds, but returns 425 -
the very segment the driver is currently running at. OUCH!
MCB looks like

2D3:0  'M' -->
4d3:0  'Z'





2 problems:

the space for the driver is not allocated while the driver is loaded

INTERLNK does tries to get some UMB memory, but has not called
INT21 AH=58. why would MSDOS return MCB memory?


while this is a real bug, I'm not certain this should be fixed as
rethinking the driver load and memory allocation at init time is far
from trivial.

Tom



























am 5. Februar 2016 um 18:05 schrieben Sie:

> Have tried with latest* kernel, there is a fixed bug in int 25/26 that may 
> effect it.
>  You may want to try RIFS as well, it has source, but I don't
> recall if it used serial, parallel, or either but did work with
> FreeDOS kernel as well as it did with PCDOS.
>  * I'm releasing updated version this weekend if time permits after I commit 
> changes from git to svn.
>  On Feb 5, 2016 11:04 AM, "Tom Ehlert" <t...@drivesnapshot.de> wrote:

> Bret,
>  
 >> Eric/Tom:
>  
 >> I used to use INTERxxx a lot many years ago using the special
 >> parallel cables designed for that purpose (I think I still have a
 >> couple of those cables in my "spare cable box").  Parallel is MUCH
 >> faster than serial (null modem) cables.
>  I also used it *A LOT*. in times when there were no network cards a
>  commodity. (the times they are a changing ...)
>  
 >> I believe Eric is correct when he says INTERxxx is sector-based
 >> rather than file-based as Tom states.  I do know that the client
 >> (INTERLNK) must be capable of "understanding" the file system of the
 >> server (INTERSVR).  For example, if the client is MS-DOS 6.2 (which
 >> doesn't understand FAT32) and the server is MS-DOS 7.x (which does
 >> understand FAT32) and you're trying to access a FAT32 disk on the
 >> server, it doesn't work.  I know this for sure because I've tried
 >> it.  If INTERxxx was file-based, it wouldn't matter which version of
 >> FAT was on either computer (and could even work on non-FAT drives
 >> the server had mounted, like CD's and network drives).
>  
>  you are right, my memory was plain wrong on this.
>  
>  and - while debugging the crashing problem - I also saw that it
>  installs itself as handler for INT 25/26 'DOS DISK READ/WRITE'
>  
>  Tom
>  
>  
> 
> --
>  Site24x7 APM Insight: Get Deep Visibility into Application Performance
>  APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>  Monitor end-to-end web transactions and take corrective actions now
>  Troubleshoot faster and improve end-user experience. Signup Now!
>  http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>  ___
>  Freedos-user mailing list
>  freedos-u...@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/freedos-user
>  



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


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] EXT3 support

2016-01-13 Thread João Jerónimo

On 17-11-2015 05:36, H. Peter Anvin wrote:

A TSR redirector would be great for assigning an EXT3 drive to a drive
>letter for standard I/O operations.  However a kernel driver would
>allow freeDOS to boot and run from an EXT3 journaling partition, I can
>only imagine that the benefits from this would be huge.
>

You can do this anyway by using an auxiliary bootloader, e.g. Syslinux
or Grub.  The idea is that you load the basic DOS into a ramdisk from
the bootloader (e.g. via memdisk) and then you can load your TSR.

What*might*  be useful could be a way to have some way for the FreeDOS
kernel to natively boot from a ramdisk in high memory, or at least have
a way to not have the ramdisk become drive A or C.

Hello,
You are right. that's the most logical thing to do in DOS. And even 
better if, as you say, ramdisk becomes some drive letter other than A ou C.


JJ

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] EXT3 support

2016-01-13 Thread Eric Auer

Hi HPA and Joao,

support for EXT3 in the kernel would indeed be large/complex.

Only supporting EXT3 READS already would take circa 10 kB of
code, taking the size of the EXT2/3/4 GRUB module as example.

I like MEMDISK bootable ramdisk style: MEMDISK can be booted
by boot loaders which are able to boot Linux, and it can use
any diskimage accessible by such boot loaders, including an
image on EXT3 disks. Boot loaders either pre-compute a list
of sectors to read files or load extra driver modules, which
only have to support reading and which are not kept in RAM.

Regarding the idea to have the kernel "natively boot from a
RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
on modern computers it should not be a problem to "hog" the
drive letter of the A: floppy drive - you probably have at
most ONE real floppy next to that ramdisk anyway and letter
B: is still free :-) So in that sense, MEMDISK is ok for me.



A ramdisk is often very small in RAM, so I think the benefit
of compiling one into the kernel would be small compared to
simply using pre-existing 3rd party ramdisks like MEMDISK.

However, for the fans of really tiny settings, have a look at:

http://www.rayer.g6.cz/romos/romose.htm

This project features a "bios" version of the FreeDOS kernel,
by booting the kernel from a 63 kB virtual floppy. The module
including the floppy takes 64 kB in the option ROM area, so
you could compare it to booting FreeDOS from UMB ramdisk ;-)



In totally unrelated notes, I think it would be cool if the
FreeDOS kernel could parse GPT PARTITION TABLES and find FAT
partitions in them. And I think it might be interesting to
be able to read files from the root dir of ISO9660 media if
I/O is provided by BIOS ElTorito calls: That way, the kernel
could load config sys and a CD/DVD driver after some special
boot sector has loaded the kernel directly from CD/DVD :-)

Cheers, Eric

PS: I admit that the last idea is similar to having read-only
EXT3 support in the kernel, but I believe ISO takes << 10 kB.




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] FreeDOS and redirectors

2015-11-17 Thread Tom Ehlert

> I wanted to ask: to what degree does FreeDOS implement the redirector
> interface?  Are there any known incompatibilities?
it should right work.

all known redirectors

   CD/DVD drivers
   MS Lan Manager
   NTFSDOS
   NTFS4DOS
   VMSMOUNT (with source)

for DOS work without (known) problems

> This also requires that any protected mode memory manager (EMM386 etc)
> implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.
VDS is supported.

Tom


--
_______
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] FreeDOS and redirectors

2015-11-17 Thread Eduardo Casino
2015-11-17 6:35 GMT+01:00 H. Peter Anvin <h...@zytor.com>:
> I wanted to ask: to what degree does FreeDOS implement the redirector
> interface?  Are there any known incompatibilities?

I didn't find any while implementing my own redirector.

> The reason I am asking is that I started a project that I was never able
> to find time finish (and don't expect to have any more for the
> forseeable future) to write a 9pfs redirector for DOS, which would let
> DOS access a filesystem (as opposed to a disk image) using Qemu.

...and, therefore, using KVM. Great!  :)

> If there is interest, the code so far is at:
>
> http://git.zytor.com/dos/virtio9p.git/
>
> It contains a lot of infrastructure work done (tested under MS-DOS 6.22)
> but not much of the actual file operations.
>
> This also requires that any protected mode memory manager (EMM386 etc)
> implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.

I will look into that, thank you.

Eduardo.

--
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] EXT3 support

2015-11-16 Thread H. Peter Anvin
On 08/14/15 15:00, Till wrote:
> 
> Quoting João Jerónimo <j_j_b_o_de...@yahoo.com>:
> 
>> Wouldn't it be better to use a redirector? This can be done with a TSR.
>>
>> João Jerónimo
>>
> 
> 
> A TSR redirector would be great for assigning an EXT3 drive to a drive  
> letter for standard I/O operations.  However a kernel driver would  
> allow freeDOS to boot and run from an EXT3 journaling partition, I can  
> only imagine that the benefits from this would be huge.
> 

You can do this anyway by using an auxiliary bootloader, e.g. Syslinux
or Grub.  The idea is that you load the basic DOS into a ramdisk from
the bootloader (e.g. via memdisk) and then you can load your TSR.

What *might* be useful could be a way to have some way for the FreeDOS
kernel to natively boot from a ramdisk in high memory, or at least have
a way to not have the ramdisk become drive A or C.

-hpa



----------
___________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] FreeDOS and redirectors

2015-11-16 Thread H. Peter Anvin
I wanted to ask: to what degree does FreeDOS implement the redirector
interface?  Are there any known incompatibilities?

The reason I am asking is that I started a project that I was never able
to find time finish (and don't expect to have any more for the
forseeable future) to write a 9pfs redirector for DOS, which would let
DOS access a filesystem (as opposed to a disk image) using Qemu.

If there is interest, the code so far is at:

http://git.zytor.com/dos/virtio9p.git/

It contains a lot of infrastructure work done (tested under MS-DOS 6.22)
but not much of the actual file operations.

This also requires that any protected mode memory manager (EMM386 etc)
implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.

-hpa

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


Re: [Freedos-kernel] hmmmm

2015-08-20 Thread Travis Siegel
I don't know if it's still available, but pts dos has source that you're 
allowed to use in your projects.  I haven't looked at it recently, so I 
don't remember what license it was released under, (if any) but I do 
recall that as long as you held a license for pts dos, you were free to 
use the source for your own projects, so that may be an option for you, 
even though I don't remember the dtails.  I will have to dig out my copy 
and see what it said about distribution, I don't remember what that part 
of the license said.  As I said, it's been quite some time. :)



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


Re: [Freedos-kernel] hmmmm

2015-08-20 Thread Tom Ehlert
 Sorry for the link I haven't used thus machine to send emails in a long
 time.  The antivirus tags it with it.  I had suspected that I wouldn't
 be able to kernel merge, but it's nice to have thoughts. The multiuser
 will have to wait whilst I wait on the response from Caldera,  They have
 an open source codebase that is not gpl compatible.

the Caldera DRDOS is not very open at all; they published the source
for the kernel exactly once, with no source release before or after.

 Maybe they would
 change the licensing or discuss possibilities since I asked.
extremely unlikely; other people tried this (~10 years ago)

 I could
 ask for the DOS 4.0 codebase instead.  Seems reasonable.

good luck, but don't hold your breath

Tom


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


Re: [Freedos-kernel] EXT3 support

2015-08-17 Thread Alain Mouette
The basic idea is to start with a fresh install of an Ubuntu LTS server. 
Then a Script could install all the rest. I am already doing this on a 
project and it works very well, all scripts are posted on github: 
https://github.com/alainm/nfas (sorry, it's in portuguese due to local 
colaborators)


On basic script could install DOSEMU with an updated FreeDOS and maybe a 
few needed packages. I have a set of guidelines that I could translate


Another small script could create a DOSEMU instance. The default screen 
could be a FreeDOS console

Remember that dosemu can run a DOS program from de Linux command line ;-)

WHAT I DON'T KNOW is the minimum system to run graphics programs in 
FreeDOS+Dosemu+Linux, I have allways used with X


_Would you give it a try_? Just start with a plain Ubuntu 14.04 LTS 
32bits (use VirtualBox), it has a dosemu package that works prety well


Alain


Em 16-08-2015 03:09, Till escreveu:

Quoting Alain Mouette ala...@pobox.com:


Why not use all that effort to run FreeDOS over Linux? Dosemu works very
well...

It has already been done in the past, mas it was slackware based and as
soon as released had no mantainance, so it went dead.

*) you get all the drivers to run on any hardware
*) you can run multiple FreeDOS instances, it works very well
*) disk sharing works very well
*) networking via PacketDriver woks just fine, it may just be a bit
confusing to configure

and you can have background tasks in Linux for other tasks ans remote
access.

It would be just fine to make it over Ubuntu LTS, and I am willing to help.

PS: I have some legacy system runing in Dosemu and I use that regularly
for development


This is a brilliant idea that I would love to see come to life.  I'm
interested in hearing more about this.

Till


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



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


Re: [Freedos-kernel] EXT3 support

2015-08-17 Thread Travis Siegel
The only problem with virtual box is that it isn't accessible.  Any folks 
using screen readers are likely to need dosemu instead of virtual box.  It 
may work under orca, but I've not tested that here.
Just a point of interest for those who need/want to know.



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


Re: [Freedos-kernel] EXT3 support

2015-08-16 Thread Till
Quoting Alain Mouette ala...@pobox.com:

 Why not use all that effort to run FreeDOS over Linux? Dosemu works very
 well...

 It has already been done in the past, mas it was slackware based and as
 soon as released had no mantainance, so it went dead.

 *) you get all the drivers to run on any hardware
 *) you can run multiple FreeDOS instances, it works very well
 *) disk sharing works very well
 *) networking via PacketDriver woks just fine, it may just be a bit
 confusing to configure

 and you can have background tasks in Linux for other tasks ans remote
 access.

 It would be just fine to make it over Ubuntu LTS, and I am willing to help.

 PS: I have some legacy system runing in Dosemu and I use that regularly
 for development


This is a brilliant idea that I would love to see come to life.  I'm  
interested in hearing more about this.

Till


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


Re: [Freedos-kernel] EXT3 support

2015-08-15 Thread Tom Ehlert
 I am interested in writing a new driver, one that would allow you to
 boot and run dos on a EXT3 partition.

booting from EXT3 would require to make EXT3 part of the kernel.
not going to happen.

otoh there is virtually no disadvantage to have a loadable TSR to make
EXT3 available as a redirector.

 In your other message you said
 that ETX3 was a multithreaded fs.  In that case it would be wiser to
 first add multithreaded support to the FreeDOS kernel.  It will be
 hard, but well worth the time I believe.

don't wait for multithreading support from kernel.

in the good old times, when DOS was still active, disk caching
software implemented 'multithreading' by chaining into
TIMER and IDLE interrupts.

just because so far no FreeDOS disk cache supports write caching
doesn't mean it doesn't exist


Tom


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


[Freedos-kernel] EXT3 support

2015-08-14 Thread Daniel G.
Greetings,

I was reading the FreeDOS development wish-list and adding ext3  
support to the FreeDOS kernel is on the list.  Is anyone working on  
this at this time?
Thank you for your time.


God Bless.

Till






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


Re: [Freedos-kernel] EXT3 support

2015-08-14 Thread Ralf Quint
On 8/14/2015 12:38 AM, Daniel G. wrote:
 Greetings,

 I was reading the FreeDOS development wish-list and adding ext3
 support to the FreeDOS kernel is on the list.  Is anyone working on
 this at this time?

Doubtful. It's more likely just wishful thinking from someone who 
doesn't know what all might be involved in actually implementing this...

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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


Re: [Freedos-kernel] EXT3 support

2015-08-14 Thread Louis Santillan
Hiren's BootCD has had something called Paragon Mount Everything 3.0.
Or are you interested in writing a new driver?

On Fri, Aug 14, 2015 at 1:28 PM, Ralf Quint freedos...@gmail.com wrote:
 On 8/14/2015 12:38 AM, Daniel G. wrote:
 Greetings,

 I was reading the FreeDOS development wish-list and adding ext3
 support to the FreeDOS kernel is on the list.  Is anyone working on
 this at this time?

 Doubtful. It's more likely just wishful thinking from someone who
 doesn't know what all might be involved in actually implementing this...

 Ralf

 ---
 This email has been checked for viruses by Avast antivirus software.
 https://www.avast.com/antivirus


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

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


Re: [Freedos-kernel] EXT3 support

2015-08-14 Thread Louis Santillan
Maybe, but ext3 was designed as a multithreading FS.  The
multithreading becomes single threading so performance would far
worse, and possibly even worse than FAT16/32 or ext3 over redirector.

On Fri, Aug 14, 2015 at 3:00 PM, Till oran...@mygrande.net wrote:

 Quoting João Jerónimo j_j_b_o_de...@yahoo.com:

 Wouldn't it be better to use a redirector? This can be done with a TSR.

 João Jerónimo



 A TSR redirector would be great for assigning an EXT3 drive to a drive
 letter for standard I/O operations.  However a kernel driver would
 allow freeDOS to boot and run from an EXT3 journaling partition, I can
 only imagine that the benefits from this would be huge.



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

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


Re: [Freedos-kernel] Questions about Kernel editions

2015-08-04 Thread Tom Ehlert

 I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS
 Kernel.  Would it be fine if I began setting up a multiuser/multitasking
 system like Digital Research's DOS 5, and begin the work to get Forth 
 into the kernel?

the kernel is definitively not the right place
to integrate Forth into, be it multiuser or not.

there is zero disadvantage to have FORTH.EXE doing all the magic

of course feel free to experiment (thats one of the reasons open
source exists), but the the probablity that this would ever get
integrated into the FreeDOS kernel has 8 leading zero's

 This email has been checked for viruses by Avast antivirus software.
 https://www.avast.com/antivirus
whenever I read emails like this, I wonder what prevents a virus from
adding such a line to its malicious postings ;)



Tom


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


[Freedos-kernel] Questions about Kernel editions

2015-08-03 Thread Tom
I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS 
Kernel.  Would it be fine if I began setting up a multiuser/multitasking 
system like Digital Research's DOS 5, and begin the work to get Forth 
into the kernel?   I am just going to make a branch to test each of 
these, and if you like it then I will make a commit.  If not it will be 
a short lived fork.  I have been following this project, and I would 
love to see it get more attention.

  I have a Tandon 80386SX machine with 1MB of ram (hopefully getting it 
up to 8MB) and rock a 5.25 drive in my main rig with modern hardware.  
I don't want to see this go away just because it's old.  I will be 
doing all my tests on the Tandon while it has 1MB.  Does that sound 
alright?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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


Re: [Freedos-kernel] Unable to use drive number 32 with some functions

2015-04-29 Thread perditionc
Thank you.  I will try to get a fix implemented this week.  Your patch
corrects supporting the 32nd drive if provided as value 1 thru 32 (0 is
default) but still doesn't handle if passed as ascii value ` (0x60).

Jeremy

On Apr 26, 2015 3:51 PM, Damien Guibouret 
damien.guibou...@partition-saving.com wrote:

 Hello,

 I found a small problem in ioctl code that leads to drive number 32 to
not be
 usable with device related functions (int 0x21, ah=0x44..) and leading to
 returning information about another drive without signaling any error. As
I
 suppose this is not widely used (drive 27 to 32 are most often not known
by
 users), I think this is quite minor. I wrote a patch, but did not test
nor even
 compile it. In this patch I keep some code that from interface point of
view is
 wrong but that is the way I understood the NDN related comment.

 Regards,

 Damien

 --- ioctl.c.orig2015-04-26 21:01:18.0 +0200
 +++ ioctl.c 2015-04-26 21:26:48.0 +0200
 @@ -164,6 +164,7 @@
   {
 struct dpb FAR *dpbp;
 unsigned attr;
 +  BYTE used_drive;
   /*
  This line previously returned the deviceheader at r-bl. But,
  DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
 @@ -173,9 +174,18 @@
*/
   /* JPP - changed to use default drive if drive=0 */
   /* JT Fixed it */
 -
 -  /* NDN feeds the actual ASCII drive letter to this function */
 -  dpbp = get_dpb((r-BL  0x1f) == 0 ? default_drive : (r-BL 
0x1f) - 1);
 +  if (r-BL == 0)
 +used_drive = default_drive;
 +  else if ((r-BL = 1)  (r-BL = 32))
 +used_drive = r-BL - 1;
 +  else if (((r-BL = 'A')  (r-BL = 'Z')) ||
 +   ((r-BL = 'a')  (r-BL = 'z')))
 +/* NDN feeds the actual ASCII drive letter to this function */
 +used_drive = (r-BL  0x1f) - 1;
 +  else
 +return DE_INVLDDRV;
 +
 +  dpbp = get_dpb(used_drive);
 if (dpbp)
 {
   CharReqHdr.r_unit = dpbp-dpb_subunit;
 @@ -196,7 +206,7 @@
   {
 /* note from get_dpb()*/
 /* that if cdsp == NULL then dev must be NULL too */
 -  struct cds FAR *cdsp = get_cds1(r-BL  0x1f);
 +  struct cds FAR *cdsp = get_cds(used_drive);
 if (cdsp == NULL)
   return DE_INVLDDRV;
 if (cdsp-cdsFlags  CDSSUBST)


--
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Unable to use drive number 32 with some functions

2015-04-29 Thread Damien Guibouret
Hello,

That's right, I was not expecting NDN will use it as it is already out of the 
spec.
You can change the

else if (((r-BL = 'A')  (r-BL = 'Z')) ||
  ((r-BL = 'a')  (r-BL = 'z')))
   /* NDN feeds the actual ASCII drive letter to this function */
   used_drive = (r-BL  0x1f) - 1;

into

else if (((r-BL = 'A')  (r-BL = '`')) ||
  ((r-BL = 'a')  (r-BL = 'z')))
   /* NDN feeds the actual ASCII drive letter to this function */
   used_drive = (r-BL - 1)  0x1f;

I think the lowercase case can remain as it is (there is no correspondance 
between lower and upper case for letters above 'z' and more over it goes 
outside 
of 7 bits ASCII range).

Regards,

Damien

perditi...@gmail.com wrote:
 Thank you.  I will try to get a fix implemented this week.  Your patch
 corrects supporting the 32nd drive if provided as value 1 thru 32 (0 is
 default) but still doesn't handle if passed as ascii value ` (0x60).
 
 Jeremy
 
 On Apr 26, 2015 3:51 PM, Damien Guibouret 
 damien.guibou...@partition-saving.com wrote:
 
Hello,

I found a small problem in ioctl code that leads to drive number 32 to
 
 not be
 
usable with device related functions (int 0x21, ah=0x44..) and leading to
returning information about another drive without signaling any error. As
 
 I
 
suppose this is not widely used (drive 27 to 32 are most often not known
 
 by
 
users), I think this is quite minor. I wrote a patch, but did not test
 
 nor even
 
compile it. In this patch I keep some code that from interface point of
 
 view is
 
wrong but that is the way I understood the NDN related comment.

Regards,

Damien

--- ioctl.c.orig2015-04-26 21:01:18.0 +0200
+++ ioctl.c 2015-04-26 21:26:48.0 +0200
@@ -164,6 +164,7 @@
  {
struct dpb FAR *dpbp;
unsigned attr;
+  BYTE used_drive;
  /*
 This line previously returned the deviceheader at r-bl. But,
 DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
@@ -173,9 +174,18 @@
   */
  /* JPP - changed to use default drive if drive=0 */
  /* JT Fixed it */
-
-  /* NDN feeds the actual ASCII drive letter to this function */
-  dpbp = get_dpb((r-BL  0x1f) == 0 ? default_drive : (r-BL 
 
 0x1f) - 1);
 
+  if (r-BL == 0)
+used_drive = default_drive;
+  else if ((r-BL = 1)  (r-BL = 32))
+used_drive = r-BL - 1;
+  else if (((r-BL = 'A')  (r-BL = 'Z')) ||
+   ((r-BL = 'a')  (r-BL = 'z')))
+/* NDN feeds the actual ASCII drive letter to this function */
+used_drive = (r-BL  0x1f) - 1;
+  else
+return DE_INVLDDRV;
+
+  dpbp = get_dpb(used_drive);
if (dpbp)
{
  CharReqHdr.r_unit = dpbp-dpb_subunit;
@@ -196,7 +206,7 @@
  {
/* note from get_dpb()*/
/* that if cdsp == NULL then dev must be NULL too */
-  struct cds FAR *cdsp = get_cds1(r-BL  0x1f);
+  struct cds FAR *cdsp = get_cds(used_drive);
if (cdsp == NULL)
  return DE_INVLDDRV;
if (cdsp-cdsFlags  CDSSUBST)


 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Unable to use drive number 32 with some functions

2015-04-26 Thread Damien Guibouret
Hello,

I found a small problem in ioctl code that leads to drive number 32 to not be 
usable with device related functions (int 0x21, ah=0x44..) and leading to 
returning information about another drive without signaling any error. As I 
suppose this is not widely used (drive 27 to 32 are most often not known by 
users), I think this is quite minor. I wrote a patch, but did not test nor even 
compile it. In this patch I keep some code that from interface point of view is 
wrong but that is the way I understood the NDN related comment.

Regards,

Damien

--- ioctl.c.orig2015-04-26 21:01:18.0 +0200
+++ ioctl.c 2015-04-26 21:26:48.0 +0200
@@ -164,6 +164,7 @@
  {
struct dpb FAR *dpbp;
unsigned attr;
+  BYTE used_drive;
  /*
 This line previously returned the deviceheader at r-bl. But,
 DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
@@ -173,9 +174,18 @@
   */
  /* JPP - changed to use default drive if drive=0 */
  /* JT Fixed it */
-
-  /* NDN feeds the actual ASCII drive letter to this function */
-  dpbp = get_dpb((r-BL  0x1f) == 0 ? default_drive : (r-BL  0x1f) - 1);
+  if (r-BL == 0)
+used_drive = default_drive;
+  else if ((r-BL = 1)  (r-BL = 32))
+used_drive = r-BL - 1;
+  else if (((r-BL = 'A')  (r-BL = 'Z')) ||
+   ((r-BL = 'a')  (r-BL = 'z')))
+/* NDN feeds the actual ASCII drive letter to this function */
+used_drive = (r-BL  0x1f) - 1;
+  else
+return DE_INVLDDRV;
+
+  dpbp = get_dpb(used_drive);
if (dpbp)
{
  CharReqHdr.r_unit = dpbp-dpb_subunit;
@@ -196,7 +206,7 @@
  {
/* note from get_dpb()*/
/* that if cdsp == NULL then dev must be NULL too */
-  struct cds FAR *cdsp = get_cds1(r-BL  0x1f);
+  struct cds FAR *cdsp = get_cds(used_drive);
if (cdsp == NULL)
  return DE_INVLDDRV;
if (cdsp-cdsFlags  CDSSUBST)

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] removing functions?

2015-02-09 Thread Roy
In Fri, 30 Jan 2015 17:03:08 +0800, Eric Auer e.a...@jpberlin.de wrote:


 Hi Roy,

 Is there any guide that can help on compiling custom kernel with  
 less-used
 function(for example, NLS functions) removed/stubified?

 Well FAT32 is a compile time option and I think RayeR made
 a slightly stripped kernel for his DOS in your flash BIOS
 chip micro... ehh... distro, but there is no one size fits
 all answer to your question. If you can make a list of the
 things you want to remove, then people on this list could
 tell you how much size difference it would make and how bad
 of a hack removing those functions would be :-) Note that
 you do not want to spend much effort for this: Most users
 have much bigger disks and with DOS extenders and already
 by simply having DOS=HIGH in the HMA, kernel size is not
 an issue anyway. Also, the FreeDOS kernel is designed to
 be nice and small compared to the big feature set... :-)

If I want to remove fdconfig.sys support, break, numlock, echo, switches,  
country, HLT idle, and menus in CONFIG.SYS options,
and hardcoded NLS page, and all NLS stuff(replaced with stub)

How much I can shrink?


 Regards, Eric



 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is  
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take  
 a
 look and join the conversation now. http://goparallel.sourceforge.net/


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] removing functions?

2015-01-30 Thread Eric Auer

Hi Roy,

 Is there any guide that can help on compiling custom kernel with less-used  
 function(for example, NLS functions) removed/stubified?

Well FAT32 is a compile time option and I think RayeR made
a slightly stripped kernel for his DOS in your flash BIOS
chip micro... ehh... distro, but there is no one size fits
all answer to your question. If you can make a list of the
things you want to remove, then people on this list could
tell you how much size difference it would make and how bad
of a hack removing those functions would be :-) Note that
you do not want to spend much effort for this: Most users
have much bigger disks and with DOS extenders and already
by simply having DOS=HIGH in the HMA, kernel size is not
an issue anyway. Also, the FreeDOS kernel is designed to
be nice and small compared to the big feature set... :-)

Regards, Eric



--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-devel] Regarding Issue with FreeDOS.

2014-09-15 Thread Louis Santillan
Autoexec.bat and config.sys would likely be useful here, especially to
understand the value of LASTDRIVE and to know if any other disk drive
drivers are installed (CDROM, SATA, USB, Zip, etc.).

Ideally, everyone matches MS-DOS, so knowing what functest returns there
might help.

On Sunday, September 14, 2014, Anil Nair anilcol...@gmail.com wrote:

 Hello All,

 We were working on PDOS development particularly interrupt number Int
 21/AH=0Eh(Select Default Drive). While testing the PDOS function i came
 across a particular behaviour in FreeDOS, according to the description
 given in the documentation http://www.ctyme.com/intr/rb-2570.htm;

 Return: AL = number of potentially valid drive letters.

 When tested using a function PDOS returns,

 Booting from Hard Disk...
 welcome to PDOS-16
 welcome to pcomm

 C:\functest

 The return value is x 4 x

 C:\

 While testing the same behaviour in FreeDOS,

 C:\DEVEL\PDOS\SRCfunctest

 The return value is x 5 x

 C:\DEVEL\PDOS\SRC

 Is this expected? Please let me know if anybody needs more details.

 --
 Regards,
 Anil Nair

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-devel] Regarding Issue with FreeDOS.

2014-09-15 Thread Anil Nair
Louis after testing the application in MSDOS it returned me the value 26.

On Mon, Sep 15, 2014 at 7:52 PM, Louis Santillan lpsan...@gmail.com wrote:

 Autoexec.bat and config.sys would likely be useful here, especially to
 understand the value of LASTDRIVE and to know if any other disk drive
 drivers are installed (CDROM, SATA, USB, Zip, etc.).

 Ideally, everyone matches MS-DOS, so knowing what functest returns there
 might help.


 On Sunday, September 14, 2014, Anil Nair anilcol...@gmail.com wrote:

 Hello All,

 We were working on PDOS development particularly interrupt number Int
 21/AH=0Eh(Select Default Drive). While testing the PDOS function i came
 across a particular behaviour in FreeDOS, according to the description
 given in the documentation http://www.ctyme.com/intr/rb-2570.htm;

 Return: AL = number of potentially valid drive letters.

 When tested using a function PDOS returns,

 Booting from Hard Disk...
 welcome to PDOS-16
 welcome to pcomm

 C:\functest

 The return value is x 4 x

 C:\

 While testing the same behaviour in FreeDOS,

 C:\DEVEL\PDOS\SRCfunctest

 The return value is x 5 x

 C:\DEVEL\PDOS\SRC

 Is this expected? Please let me know if anybody needs more details.

 --
 Regards,
 Anil Nair



 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 Perforce version control. Predictably reliable.

 http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel




-- 
Regards,
Anil Nair
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Regarding Issue with FreeDOS.

2014-09-15 Thread Ralf Quint
On 9/15/2014 1:42 PM, Tom Ehlert wrote:

 it would help if you would tell us what PDOS is.

I a fairly certain that he is referring to this
http://sourceforge.net/projects/pdos/

Ralf

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Free tools for FreeDos

2014-03-23 Thread Mehdi Sotoodeh
I would like to put some of my old tools (still useful) on the public
domain. I think these tools can be a good addition to FreeDos. Have a peek
at:
https://www.dropbox.com/sh/lv923nbdf2s36yj/wYKfMbOYDE

The folder contains source code and some documentation. The BOOT and DOS
Probes are written is dense assembly with the goal of small footprint
(around 20K). Hopefully, asm sources are readable enough.

Please let me know your thoughts on this or if you need further information.

Regards,

Mehdi Sotoodeh.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Free tools for FreeDos

2014-03-23 Thread Chris Evans
imagefd is useful softprobe too

--
-chris
Digitalatoll Solutions Group
Tawhaki Software
http://digitalatoll.com/
http://tawakisoft.com/


On Sun, Mar 23, 2014 at 6:43 PM, Mehdi Sotoodeh mehdisotoo...@gmail.comwrote:

 I would like to put some of my old tools (still useful) on the public
 domain. I think these tools can be a good addition to FreeDos. Have a peek
 at:
 https://www.dropbox.com/sh/lv923nbdf2s36yj/wYKfMbOYDE

 The folder contains source code and some documentation. The BOOT and DOS
 Probes are written is dense assembly with the goal of small footprint
 (around 20K). Hopefully, asm sources are readable enough.

 Please let me know your thoughts on this or if you need further
 information.

 Regards,

 Mehdi Sotoodeh.


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Run Freedos on top of the Nova hypervisor?

2014-03-18 Thread Paul Dufresne
I was reading some article about the future of FreeDOS and I was
asking myself if FreeDOS could and would profit from running
on top of Nova Hypervisor:
http://hypervisor.org/

I learned about it through the Genode project, which recently managed
to have VirtualBox ported to run nicely on top of Nova.

Truely, it seems that Nova have been used mostly to run Linux on top,
but I suppose the 16 bits nature of DOS
still allows it to be run on Nova, although I am not completely sure of that.

The good point is Nova allows to use modern CPU virtualization
features for devices, so that FreeDOS VM could think
they have access to the real devices.

I am more following projects than an active developpers, so I post
here to let you bright guys evaluate if it can be done,
and if it is usefull for the FreeDOS project.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1

2014-01-01 Thread dos386
Thanks for reporting and fixing FreeDOS kernel BUG's :-)

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1

2013-12-18 Thread Juan Manuel Guerrero
Please note that I have not followed any of the FreeDOS mailing lists on a
regular base.  This means that I may report something that is already well
known.  Also I do not know if this is the right mailing list to post this
bug report.


Please inspect the small code snippet below:

#include unistd.h
#include fcntl.h
#include stdio.h

#define SIZE  256


int main(int argc, char *argv[])
{
   char buffer[SIZE];
//  int handle = open(argc  1 ? argv[1] : /dev/null, O_RDONLY);
   int handle = open(argc  1 ? argv[1] : NUL, O_RDONLY);
   int len = read(handle, buffer, SIZE);
   printf(len=%d\n, len);
   if (len  0)
   {
 int i, k;
 for (i = 0; i  len; i += 16)
 {
   for (k = 0; k  16  i + k  len; k++)
 printf( %02X, (unsigned char)buffer[i + k]);
   printf(\n);
 }
   }
   return 0;
}


This code has been compiled on MSDOS and Windows using DJGPP.  It has also been
compiled on linux as reference.  All programs behave as expected on all tested
operating systems, this means that /dev/null (aka NUL) provides nothing and the
program prints:

len=0

as it must be.  If the same program runs on FreeDOS 1.1 it produces the
following output:

len=256
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


No offending intention here, but have the developers confound /dev/null
with /dev/zero?  IMHO the NUL device seems to be broken.


This issue is critical when bash configure scripts of GNU software packages
contain lines like this:
   awk 'BEGIN {getline  /dev/null}'
making the configuration step abort and thus the complete build of the software
impossible if FreeDOS is used instead of MSDOS or Windows.

Please note that I have also tried NUL instead of /dev/null in the code and the
program fails in the same way.  This means this is certainly not a DJGPP bug.
The program fails in the same way if compiled with OpenWATCOM 1.9.
If more information is required, please contact me.

Regards,
Juan M. Guerrero


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-21 Thread Tom Ehlert
 I'm not sure how you can say the FreeDOS project isn't interested in a BC5
 kernel.
because I was around when the kernel was ported to MSVC, BC5, OW (in
that order)

 The BC5 makefiles I found in the kernel sources I didn't write.
  Bart last worked on them 9 years ago.
right. an since OW became an *free* option, MSVC and BC were dropped

Bit rotten for sure
the last time I checked bits don't rot

and OW became
 usable in that time.  So yes, priorities change, but I'm taking the posted
 FreeDOS Roadmap, as goals and stretch goals for the project.  I read
 (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
  64-bit support, device driver imports, automated regression testing.
all great - and so far off reality that is isn't even funny.
is was never even discussed, let alone agreed upon.

 I've
 done a couple of simple tests and I am getting 32-bit register code from my
 copy of BC5.
of course this is a huge step towards 'built in USB, 64 bit, bla'

 The Roadmap is reason enough for me, personally, to continue
 to 'experiment' as you say.  There's no way of getting 32-bit real mode
 code from OW.
OW outputs enough 32-bit real mode code to get the job done.
is the BC5 code smaller/faster in a significant way ?


 Again, I'm not doing any porting.  And I do intend to work this issue.
  However, software development, like many human endeavors, is best done
 collaboratively  socially, IMO.  If someone in the last 9 years has
 compiled the kernel with BC5, they might have tips for me.  Heck, I
 remember when the kernel was TASM/BC only, and only a select few could
 afford to contribute.  I advocated back then (almost 15 years ago) for
 porting to open tools.  I'm glad the early FreeCOM/Kernel developers had
 made the effort to port to open tools.
it was a pleasure ;)


tom


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-21 Thread Eric Auer
rating of a typical USB2 stick and the overhead of only using
USB1 to talk to it and you see why sorting your family pics
on that stick or some SD card is not very smooth inside DOS.

You could try to write a layer of cleverness and pooling for
some cache, or a complete cache, but note that people might
actually prefer basic: You write it, it is slow, but you can
unplug that USB stick or even your whole PC after a fraction
of a second and the data already is there and consistent...

 Maybe we should discuss the roadmap again in the first place?

 I'd like to see more discussion.  In the mean time, I'll keep
 experimenting.

Enjoy :-) As Tom said between the lines, the (more long term)
roadmap is more visionary and less based on consensus or some
practical what do we NEED to add NEXT considerations. The
roadmap for 1.0 and 1.1 was more like that. Today I would say
the question is more which bits you want to ADD and less what
you want to CHANGE DOS as a whole into. Because after all, it
is quite good that DOS is what it is. It does not need to be
a weak imitation of something else which already is good, too.

Regards, Eric :-)



--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-21 Thread Chris Evans
. You get similar issues
 with disk I/O, DOS caches rarely pool your I/O to read-ahead
 megabytes of your MPEG or combine several FAT changes before
 writing them in some smart and safe way. Instead, expect DOS
 apps to read your MPEG 32 kB at a time and update the FAT at
 a ratio of a few bytes at a time. Combine that with the IOPS
 rating of a typical USB2 stick and the overhead of only using
 USB1 to talk to it and you see why sorting your family pics
 on that stick or some SD card is not very smooth inside DOS.

 You could try to write a layer of cleverness and pooling for
 some cache, or a complete cache, but note that people might
 actually prefer basic: You write it, it is slow, but you can
 unplug that USB stick or even your whole PC after a fraction
 of a second and the data already is there and consistent...

  Maybe we should discuss the roadmap again in the first place?

  I'd like to see more discussion.  In the mean time, I'll keep
  experimenting.

 Enjoy :-) As Tom said between the lines, the (more long term)
 roadmap is more visionary and less based on consensus or some
 practical what do we NEED to add NEXT considerations. The
 roadmap for 1.0 and 1.1 was more like that. Today I would say
 the question is more which bits you want to ADD and less what
 you want to CHANGE DOS as a whole into. Because after all, it
 is quite good that DOS is what it is. It does not need to be
 a weak imitation of something else which already is good, too.

 Regards, Eric :-)




 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net javascript:;
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-20 Thread ht-lab

On 20/05/2013 02:11, Louis Santillan wrote:

I apologize for mis-posting to fd-user previously.

On Thu, May 16, 2013 at 10:47 AM, Tom Ehlert t...@drivesnapshot.de 
mailto:t...@drivesnapshot.de wrote:


Dear Louis,

a few points

a) the FreeDOS project isn't very interested in a BC5 compiled
kernel because BC5 isn't freely available/open source;
I also doubt the output of BC5 will be significant better then the OW
output.
feel free to experiment, but don't expect us to be excited ;)


I'm not sure how you can say the FreeDOS project isn't interested in a 
BC5 kernel.


Tom meant to say don't expect me to be excited ;) he is obviously not 
speaking for everybody on this mailing list. I for one would be 
interested to see size/speed numbers for any compiler free or commercial.


Good luck with BC5,

Hans
www.ht-lab.com

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-19 Thread Louis Santillan
I apologize for mis-posting to fd-user previously.

On Thu, May 16, 2013 at 10:47 AM, Tom Ehlert t...@drivesnapshot.de wrote:

 Dear Louis,

 a few points

 a) the FreeDOS project isn't very interested in a BC5 compiled
 kernel because BC5 isn't freely available/open source;
 I also doubt the output of BC5 will be significant better then the OW
 output.
 feel free to experiment, but don't expect us to be excited ;)


I'm not sure how you can say the FreeDOS project isn't interested in a BC5
kernel.  The BC5 makefiles I found in the kernel sources I didn't write.
 Bart last worked on them 9 years ago.  Bit rotten for sure and OW became
usable in that time.  So yes, priorities change, but I'm taking the posted
FreeDOS Roadmap, as goals and stretch goals for the project.  I read
(paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
 64-bit support, device driver imports, automated regression testing. I've
done a couple of simple tests and I am getting 32-bit register code from my
copy of BC5.  The Roadmap is reason enough for me, personally, to continue
to 'experiment' as you say.  There's no way of getting 32-bit real mode
code from OW.  So for now, until someone teaches OW some new tricks, I'll
work with BC5.



  So, something in the make files/build files is skipping building a
 concrete
  GLOBAL for ReturnAnyDosVersionExpected for BC5.  There's a MAIN define
  checked but the build process doesn't seem to get defined anywhere. :/

 b) when trying to port the kernel to a new compiler, you should be
 able to fix such issues yourself. generate assembler output, see what
 is wrong. you will need this as the FreeDOS uses the
  'interesting memory model (TM)'


Again, I'm not doing any porting.  And I do intend to work this issue.
 However, software development, like many human endeavors, is best done
collaboratively  socially, IMO.  If someone in the last 9 years has
compiled the kernel with BC5, they might have tips for me.  Heck, I
remember when the kernel was TASM/BC only, and only a select few could
afford to contribute.  I advocated back then (almost 15 years ago) for
porting to open tools.  I'm glad the early FreeCOM/Kernel developers had
made the effort to port to open tools.


  Need to do more digging.
 c) no need to write 'need more digging' type of mails. use your
 twitter account for that.


I don't have a twitter account.  Feel free to filter emails from me to your
spambox.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-19 Thread Eric Auer

Hi Louis,

sort of a long response - it seems hard to make a short point here:

 FreeDOS Roadmap, as goals and stretch goals for the project.  I read
 (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit

The fd32 project works or worked on the DPMI aspect. As far as I
remember, the performance gain was minimal, but consider interest
in terms of style to consider a protected mode kernel which has
both DPMI and VM86 visibility. It would be a sort of DOSBOX then.

Regarding built-in networking and USB, I am personally more for
the existing loadable driver model. The BIOS gives you enough
support to reach the point where you can load drivers in config
sys. Even when booting via network (PXE) or from CD/DVD/BD, you
can still use a MEMDISK (bootable ramdisk) to get started...

On the other hand, I think it would be an interesting experiment
to have a kernel which can load files from at least the root dir
of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can
directly interpret GPT partition tables. The latter would have
significant practical use. Not the former: When you boot from
CD/DVD/BD, you do typically want a writeable ramdisk anyway, so
you can just as well boot with the help of a MEMDISK which lets
you load DOS CD/... drivers from there, making drivers for that
as fixed parts of the kernel less interesting. Also, they are
harder to update than separate drivers and you cannot easily
skip them at boot to save DOS memory.

Good question whether you want built-in USB: I would say no, you
already need the BIOS to help to boot from USB. After that, you
want a modular system of USB drivers (unless the BIOS provides
support for all relevant USB devices) to let you access disks,
sticks, mice, keyboards and so on. Also, devices for which there
is no popular DOS or BIOS interface, such as network or sound,
cannot have kernel drivers in a useful way. For networking, the
packet driver interface is just one facet in a complex world, we
could think about some additions to make it easier to write new
drivers or to do common things with the network. For sound, the
lack of popular interfaces means that you basically have to use
protected mode to simulate a popular HARDWARE (SoundBlaster etc)
and then let your actual driver play whatever the soundblaster
would have played given the detected I/O with the simulation.

  64-bit support, device driver imports, automated regression testing.

Some automated or semi-automatic quality checks seem interesting.
One could think of code style checks, audits, automated comparison
of how well different artificial test cases or real software runs
work with different kernel (micro-) versions in some VM etcetera.

Regarding 64 bit support, there are some experiments with letting
DPMI drivers use more than 4 GB of RAM. To make better use of it,
you would have to define new interfaces (XMS, EMS, DPMI, VCPI...)
and hope that DOS software would be written which uses them.

Just using 32- or 64-bit calculations (not RAM addresses) is another
story: Probably the kernel can be smaller by using more 32-bit calc
but not really faster. Using memcopy optimized for more modern CPU
(32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real
difference, as the DOS kernel itself does not move a lot of data.

In short, there are certainly points in which DOS can be extended,
but I personally doubt that many or even any of them should start
in the kernel. Separate drivers and other software fit better.

Maybe we should discuss the roadmap again in the first place?

Regards, Eric



--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-05 Thread Louis Santillan
Whoops, didn't realize that I replied to fd-user instead of kernel.

One other note, all kernels are slightly bigger withe options I set.

-L

-- Forwarded message --
From: Louis Santillan lpsan...@gmail.com
Date: Sun, May 5, 2013 at 9:01 AM
Subject: Re: [Freedos-user] Any interest in 486, 586, 686 kernels?
To: Discussion and general questions about FreeDOS. 
freedos-u...@lists.sourceforge.net


Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.  Read (
ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
2.3.x  3.5.  Enlightening and disappointing.  There does not seem to be a
way to get 32-bit instructions out of wcc as Tom had mentioned.  3.5
recommends

The recommended options for generating the fastest 16-bit Intel code are:
Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87

-ot of -onatx  -zp8 contradict the original makefile's code -os  -zp1
(optimize execution time vs. executable size  align on byte vs. 8-byte,
respectively).  Also, the -fp*'s opts don't apply and wcc barfs on -oi+.

So in mkfiles\watcom.mk I added some code to add -6-onaxlkh-ei (for 686).
 This will reorder instruction significantly and replace some call nears
with jmps in a comparison of 386 timed code vs. 686 timed code.  Code is
larger on the 686 side.

So far, not very impressed with OW 1.9's optimizer. Rather minimal
improvements.  Anybody play with BCC 5.5  HX-DOS recently?

-L



On Sat, May 4, 2013 at 3:27 AM, Tom Ehlert t...@drivesnapshot.de wrote:

 Hallo Herr Louis Santillan,


  https://sites.google.com/site/lpsantil/Home/386DIS.ZIP
  https://sites.google.com/site/lpsantil/Home/686DIS.ZIP
  https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP
  https://sites.google.com/site/lpsantil/Home/kernels.zip

 the differenz is an empty memdisk.lst (for whatever reason)
 everything else is *identical*

 I'm not impressed

 Tom



 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Freedos-user mailing list
 freedos-u...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

2013-05-05 Thread Bernd Blaauw
Louis Santillan schreef op 5-5-2013 18:28:
 Whoops, didn't realize that I replied to fd-user instead of kernel.

 One other note, all kernels are slightly bigger withe options I set.

I guess it depends on what the compilers do:
[1] optimize for certain processor architecture(s)
[2] also keep backwards compatibility or not with lowest desired level

if [2] then the binary might be larger on disk.

If someone likes a real challenge, a smaller kernel can be produced 
using UPX --8086 --lzma --ultra-brute
(instead of UPX --8086 --best) but the end-result is not bootable, 
requiring a decompressor stub. Savings is about 3KB disk footprint.

As for the MEMDISK support there's additional support implemented at 
https://github.com/PerditionC/fdkernel but it requires me to first 
create additional testcases using some kind of floppy image file.
Basically it allows specifying a CONFIG.SYS line at Syslinux menu so you 
can alternate memory driver in a menu for example, or specify UMB 
regions, that kind of stuff

DEVICE?= and JEMMEX are quite revealing in option parsing :)

(and some ctrl-alt-del issues crashing FreeCOM in VMware)

Bernd

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-04 Thread ht-lab
On 03/05/2013 15:55, Tom Ehlert wrote:

 In the past, we compiled kernels for 8086, 186 and
 386 separately afair. I guess we got lazy and have
 dropped 186 because very few users have 186/286 as
 their CPU? They either have modern or REALLY old.
 this is not about 'lazy'
 it's easier for the user to select between 2 choices then between
 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.

 there's not much use for a 186 kernel as NOBODY has 186/286 machines
 these days,
Really, NOBODY.

Hans
www.ht-lab.com




--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-04 Thread Louis Santillan
Haha...I'd be interested if you ever developed a 586 core at 1GHz that
could utilize DDR-3 upto 4GB.


On Sat, May 4, 2013 at 1:43 AM, ht-lab han...@ht-lab.com wrote:

 On 03/05/2013 15:55, Tom Ehlert wrote:

  In the past, we compiled kernels for 8086, 186 and
  386 separately afair. I guess we got lazy and have
  dropped 186 because very few users have 186/286 as
  their CPU? They either have modern or REALLY old.
  this is not about 'lazy'
  it's easier for the user to select between 2 choices then between
  4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
 
  there's not much use for a 186 kernel as NOBODY has 186/286 machines
  these days,
 Really, NOBODY.

 Hans
 www.ht-lab.com





 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-03 Thread Louis Santillan
On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote:


 Hi Louis,

 if I understand your patch correctly, you only changed the
 build configuration to check how it affects the size of
 the compiled kernel before UPX compression, which also is
 an indicator of RAM size of the kernel? You changed the
 config.b, build.bat, buildall.bat files and generic.mak
 and watcom.mak and the resulting kernel sizes give the
 impression that in fact you only have FOUR distinct CPU
 optimizations, rather than seven cases...

 Yes.  And just ran md5sum's against the kernels to verify this

3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
623498bd71a46d16bcef211e743a9bed  kwc38616.sys
c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

69eb7732f791db340632f722c9dbce16  kwc8632.sys
f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
1e4fd656603fd09171d9d85631e77045  kwc28632.sys
b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
know much about 586+ arch's but can use the instructions in special
situations.  And this makes sense when you consider when Watcom fell out of
favor commercially and probably saw it's last real optimizer work.


 Kernels without FAT32:

 086: 64158 bytes
 186: 63028 bytes (286 same)
 386: 62164 bytes
 486: 62068 bytes (586 and 686 same)

 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)

 [SNIP]

 Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
in the kernel now and possibly the string functions.  But just an idea
right now.

-L
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-03 Thread Louis Santillan
What's the difference between wcc  wcc386?  I noticed that wcc386 adds
-5s, -5r, -fp5 (-6 equivalents) for stack, register and fpu optimization.
 Does wcc386 generate code that could be used in the kernel?

-L


On Fri, May 3, 2013 at 5:57 AM, Louis Santillan lpsan...@gmail.com wrote:

 On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote:


 Hi Louis,

 if I understand your patch correctly, you only changed the
 build configuration to check how it affects the size of
 the compiled kernel before UPX compression, which also is
 an indicator of RAM size of the kernel? You changed the
 config.b, build.bat, buildall.bat files and generic.mak
 and watcom.mak and the resulting kernel sizes give the
 impression that in fact you only have FOUR distinct CPU
 optimizations, rather than seven cases...

 Yes.  And just ran md5sum's against the kernels to verify this

 3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
 40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
 2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
 623498bd71a46d16bcef211e743a9bed  kwc38616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

 69eb7732f791db340632f722c9dbce16  kwc8632.sys
 f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
 1e4fd656603fd09171d9d85631e77045  kwc28632.sys
 b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

 ...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
 the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
 know much about 586+ arch's but can use the instructions in special
 situations.  And this makes sense when you consider when Watcom fell out of
 favor commercially and probably saw it's last real optimizer work.


 Kernels without FAT32:

 086: 64158 bytes
 186: 63028 bytes (286 same)
 386: 62164 bytes
 486: 62068 bytes (586 and 686 same)

 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)

 [SNIP]

  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
 in the kernel now and possibly the string functions.  But just an idea
 right now.

 -L

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-03 Thread Tom Ehlert
 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)



 It is interesting that even 186 instructions do make a
 quite big difference and that there is a difference at
 all between 386 and 486. With 186, you get pusha and
 popa, shift/rotate by fixed numbers of bits.
ENTER
LEAVE

 In the past, we compiled kernels for 8086, 186 and
 386 separately afair. I guess we got lazy and have
 dropped 186 because very few users have 186/286 as
 their CPU? They either have modern or REALLY old.
this is not about 'lazy'
it's easier for the user to select between 2 choices then between
4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.

there's not much use for a 186 kernel as NOBODY has 186/286 machines
these days,

 Also, we keep offering 8086 compiles for the sake
 of good old times and for people with emulators.



 The 386 optimization is useful and we already used
 it: Having 32 bit computations helps even for DOS.
 There are also some new bit string opcodes, SETCC
 (conditional set a byte)
nothing of this is used by the compiler

  JCXZ
was always supported

  and near conditional
 jumps and loops that are supported starting at 386.
*far* conditional jumps started with 386.

however what *IS* used by wcc is
   the additional FS and GS register
some (few)
 push DWORD constant

what would be useful, but is not used by WCC
 dword arithmetic
filesystem code uses long variables everywhere



 Your 486 to 686 kernels are the same size and 486s
 only XADD and BSWAP (and CMPXCHG). It is impressive
 that those actually make any (100 byte) difference!

strange enough, compiling here with -3 and -6 makes exactly no
difference. using watcom 1.9

could you post the compiled files, or even

  for %i in (*.obj) do wdis -l -a -s %i

for -3 and -6 and show us the differences ?


 Maybe your compiles assume that 486 does and 386
 does not have FPU? That would not be very accurate.
pointless as the kernel doesn't use any FPU code



 As with 286, the news in 586 is mostly protected
 mode related (simply speaking). Neither CMPXCHG8B
 nor the time stamp counter nor CPUID bothers DOS.


 The main news in 686 would be CMOV, a conditional
 MOV, but looking only at kernel sizes, it is likely
 that the compiler just does not use CMOV for 686.
 It is odd to get exactly the same size otherwise.
it doesn't use cmov


 For even newer CPU, you could use FPU and vector
 (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
 SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
 but it is highly unlikely that those make any DOS
 difference. At most they could speed up memmove.
as the kernel doesn't much memcpy/memmove, you can't accelerate it
by any significant amount.otherwise we *would* have
  rep movsD

tom


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

2013-05-03 Thread Tom Ehlert

 What's the difference between wcc  wcc386?
code generation for 16 bit (DOS) or 32 bit (windows)

  Does wcc386 generate code that could be used in the kernel?
no

  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
 in the kernel now and possibly the string functions.  But just an idea
 right now.
the kernel doesn't copy (much). nothing to be gained.

tom


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.

2012-12-22 Thread MR-LEGO
Dear Developers of FreeDOS-Kernel.

I use the Kernel 2041 and found follow strange:

If I press the F8 key for singlestepping and then the ESC key to skip a 
command, the
singlestepping-process of the FDCONFIG.SYS is skipped.

Under MS-DOS the ESC key skips only the current command and doesn't skip the 
singlestepping-process.
Under the commando-processor (I use the FreeCOM) the ESC key skips only the 
current command, too.

I think to skip the singlestepping-process is a good thing, but its better to 
do this with another
key, like the SPACE key.


Best regards

Christian Pfaller



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.

2012-12-22 Thread Tom Ehlert
 I use the Kernel 2041 and found follow strange:

 If I press the F8 key for singlestepping and then the ESC key to skip a 
 command, the
 singlestepping-process of the FDCONFIG.SYS is skipped.
I implemented it this way because AFAICT MSDOS 6.2 behaves this way

 Under MS-DOS the ESC key skips only the current command and
 doesn't skip the singlestepping-process.
I may be wrong (it's a lonnng time ago), but I'm fairly sure that ESC finishes
config.sys single stepping for MSDOS 6.2

 Under the commando-processor (I use the FreeCOM) the ESC key
 skips only the current command, too.
that's a completely different thing

 I think to skip the singlestepping-process is a good thing, but its better to 
 do this with another
 key, like the SPACE key.
better: use the same key that MSDOS uses. what is the MSDOS key for
that ?

Tom


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] FreeDOS Boot Disc

2012-09-27 Thread Eric Auer

Hi Chris,

 I'll link to the 1.0 boot floppy image, under the FreeDOS 1.0 section.
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img

That is a bit old so I am still preferring Ruffidea ;-)
Also because it is easier to delete than to add stuff,
for the latter you have to download things first. On
the other hand, I think Jeremy once had some sort of
automated builds with always fresh kernels online? For
people like Georg who need just a minimal bootable DOS
this would be a good source of boot floppy images.

 Kernel on that image uses 386+ instructions... and it seems as if it
 does that without (properly) checking for the presence of a 386.

That is correct, as a kernel cannot be both optimized
for 386 and compatible with 8086 at the same time. We
had some specifically PC-XT compatible boot floppies
mentioned on the list in the past, e.g. by somebody
who made a virtual PC-XT in Java if I remember right?

 That it's a 386+ kernel is just an oversight (or should be documented for  
 the image), but if 386+ kernels really do not abort with an appropriate  
 message on non-386 CPUs, that's a bug.

I disagree here. Without a kernel, you cannot do any
useful DOS stuff. However, I once made some tools for
Bernd to have a boot disk which automatically picks
boot files depending on your available CPU, as far as
I remember also related to MEMDISK detection? You CAN
make a NON minimal boot disk which automatically can
fall back to 8086 that way. However it is VERY rare
to find pre-386 hardware today, so I would really say
that it is better to have separate downloads: Normal
boot floppy for 386+ and special 8086 compatible boot
floppy for people with really ancient hardware (or a
virtual ancient computer, as the one mentioned above).

Of course it is a different story for EMM386, HIMEM,
USB drivers and similar: THOSE can automatically say
that they cannot load on incompatible hardware, then
return to DOS. Users can still use DOS then and sure
it is nice to not crash on old hardware but show some
message. But a kernel? It cannot skip itself and jump
to a command prompt with only the 8086 part loaded ;-)

 The file kernel.asm (SVN r1705) is this one:  
 http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/kernel.asm?revision=1705view=markup
 
 Note lines 194 to 196, where precisely in this latest r1705, Kenneth added  
 the comment TODO display error if built for 386 running on 8086 etc.

Well if it really makes you happy... Note that also a
number of boot loaders only work with 386 anyway now.

Regards, Eric



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] FreeDOS Boot Disc

2012-09-27 Thread C. Masloch
Hi Eric,

 Kernel on that image uses 386+ instructions... and it seems as if it
 does that without (properly) checking for the presence of a 386.

 That is correct, as a kernel cannot be both optimized
 for 386 and compatible with 8086 at the same time.

Well, yes it could (look at FreeDOS DEBUG/X's sources for table-based  
load-time patch method), but that's not the point.

The point is that software requiring a particular instruction set should  
usually check whether that's available (before using it), and more or less  
gracefully abort if not. The kernel itself has no reason to not show a  
little more grace here, especially now that the _check_ for 386+ is  
already implemented, just the conditional branch out and showing an error  
message then rebooting not yet.

 but if 386+ kernels really do not abort with an appropriate
 message on non-386 CPUs, that's a bug.

 THOSE can automatically say
 that they cannot load on incompatible hardware, then
 return to DOS. Users can still use DOS then and sure
 it is nice to not crash on old hardware but show some
 message. But a kernel? It cannot skip itself and jump
 to a command prompt with only the 8086 part loaded ;-)

Yes it could sort of, which is again not the point.

Just look at the boot sector loaders, maybe their earlier revisions though  
(with as far as I remember more descriptive error messages). Nothing  
prevents the 386+ kernel from appropriately branching out, displaying  
This is a 386+ build of the FreeDOS kernel, please obtain a different one  
for this non-386 CPU. Press any key to reboot. (using Int10.0E like all  
other messages from the loaders), then calling Int16.00 and Int19.

 Note lines 194 to 196, where precisely in this latest r1705, Kenneth  
 added
 the comment TODO display error if built for 386 running on 8086 etc.

 Well if it really makes you happy...

Well, if it makes you happy (not really the topic what would make whom  
happy?), you can of course refrain from writing the code necessary for  
that or alternatively asking for a patch.

 Note that also a
 number of boot loaders only work with 386 anyway now.

Including at least some MS-DOS 7+ boot loaders, and FreeDOS's current  
FAT32 FS boot sector loaders, thankyou I'm aware. That's still no reason  
to hold onto this user-unfriendly behaviour everywhere. (The FAT32 FS boot  
sector loader has a restriction as designed which makes it at least  
somewhat sensible to not emit a nice diagnostic on failure. This is not  
true of the kernel at the stage we're examining.)

And yeah, I do think it could genuinely put a user off. Imagine someone  
gets that image, maybe extracts the files to put them onto a smaller  
format floppy. Loading an actual machine with that, or emulated,  
regardless. This image specifically described as Great for booting  
FreeDOS on old PCs on the website right now. And the kernel just crashes.  
What if that person is unable/unwilling to step through the kernel's early  
load phase (including UPX decompression) to figure out what caused the  
crash? Maybe they'll ask on the list for help with a mysterious crash, but  
I wouldn't guess it'd make a particularly good (first) impression.

And it's so easily avoidable.

So many words. What a waste. I should condense more next time.

Regards,
Chris

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

2012-05-23 Thread C. Masloch
 When DOS detects an unreliable floppy change line hardware,
 it should use the floppy label / serial / similar to detect
 changes in software ...

 How does DOS ever detect that any hardware is unreliable??

 I do not know, but earlier in this thread, somebody said that
 the numbering of FAT filesystem exists, among other reasons,
 to help DOS detect floppy changes even if there is no change
 line available. As you know, int 13.15 can even report that
 a floppy has no change line at all. MS DOS might, on top of
 that, have a list of BIOS versions with weak change lines?

I think this excerpt might be relevant; from Geoff Chappell's DOS  
Internals, chapter 16 (Low-Level Disk Support), after the section  
heading Floppy Disk Drives, on page 605:


As a normal part of its initialization, IO.SYS categorizes the available  
floppy disk drives. For this purpose, it relies on the BIOS to report the  
drive's capabilities. Int 13h function 08h (Get Drive Parameters) returns  
the maximum supported values for the cylinder, head and sector parameters.  
In the context of assigning drive types, it is sometimes helpful to know  
whether or not the BIOS supports change-line detection (i.e., the drive  
can detect whether the drive door is open) for the drive in question. One  
indirect inference is available since the low-capacity 5 1/4  drives are  
unable to provide a change-line facility.


It doesn't go into more details regarding the change-line detection  
support detection right there, but I'll report in another reply (to this  
message) if I find more elsewhere.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

2012-05-22 Thread Eric Auer

Jack, kernel people (now CCed),

 When DOS detects an unreliable floppy change line hardware,
 it should use the floppy label / serial / similar to detect
 changes in software ...
 
 How does DOS ever detect that any hardware is unreliable??

I do not know, but earlier in this thread, somebody said that
the numbering of FAT filesystem exists, among other reasons,
to help DOS detect floppy changes even if there is no change
line available. As you know, int 13.15 can even report that
a floppy has no change line at all. MS DOS might, on top of
that, have a list of BIOS versions with weak change lines?

Related kernel sources: init_readdasd, make_ddt, maybe also
DosDefinePartition. Apparently FreeDOS has drive types hard-
disk, floppy with change line, and other here...

Int 13.16 which actually queries the change line can return
invalid command, drive not ready / not present, no change or
change line active or not supported. NOTE that calling the
check also clears the status, so only ONE caller will notice
each change and only ONCE! Lbacache takes special care here.

Related kernel sources: FL_DISKCHANGED, fl_diskchanged,
floppy_change, mediachk, diskchange... If you have NO change
line, diskchange returns not changed if you very recently
accessed the disk, and unknown otherwise, I believe?) For
M_DONT_KNOW, mediachk returns disk changed iff the serial
of the filesystem changed compared to the current DDT info.
Finally, media_check is described to trigger on unknown,
changed or definitely changed. It does setinvld and calls
the D_BLDBPB block device driver function and converts the
BPB to DPB then. Note that int 21.7302 get ext dpb calls
flush_buffers, flags a fake disk change, calls media_check.
DosGetFree can behave similarily depending on arguments...
Maybe update_dcb is also related. I think D_BLDBPB is done
by rqblockio and the bldbpb function and getbpb, which also
calls RWzero to re-read the boot sector?

As you see, a very long chain of events exists around all
DOS block device related things, but that is necessary to
be fully compatible with MS DOS... You also see that I did
NOT mention calls to int 13.0 disk reset here - I have not
seen any (apart from fl_reset / FL_RESET calls in reaction
to I/O errors deeper in the RWzero chained LBA_Transfer).

 I agree that it is nice to disable floppy caches, but maybe
 the kernel actually does something detectable in REACTION to
 detecting a floppy change?  For example it might issue an Int
 13h drive reset command which in turn can be caught by the
 UIDE2 driver and treated as a flush cache for THAT drive
 event? ...
 
 What do you mean maybe??   You and others are the kernel
 experts for FreeDOS, not me, as I still run V6.22 MS-DOS!!

As you see above, handling of floppies and their changes is
a complicated thing which is not easy to walk through, even
for me :-)

 Also, I say again that I am NOT interested in any specific
 logic from the MS-DOS kernel, or the FreeDOS kernel, or in
 fact ANY kernel, for detecting diskette changes.   My worry
 is that such logic may NOT be generic, and I want...

As far as I can tell, you could make int 13.0 (disk reset)
and reads of the boot sector flush events. That might flush
a bit more often than necessary, but at least not LESS often
than necessary, assuming that you ALSO trap int 13.16 return
values already and trigger flushes when you see change line
activity :-)

 UIDE2 to run on all DOS systems.   Checking the BIOS media-
 change status has always worked in my drivers for diskettes

See above - if you ACTIVELY call int 13.16, you could hide
the floppy change from DOS because int 13.16 returns changed
status only for the first call after a disk change even with
working change lines...

 Finally, as noted before in this forum, UIDE and UIDE2 make
 NO run-time DOS system calls and I also want to keep THAT

I agree that it is good to not call DOS in a DISK cache and
actually it should not be necessary to call DOS either :-)

Note that things might be different for block device based
caches instead of BIOS / hardware based caches like ours...



 By the way, any chance to work around the VirtualBox
 huge-delay problem?
 
 Not without knowing WHY they take such a huge delay! In any
 case, UIDE and UIDE2 must scan for PCI-bus devices...

If I understand your code correctly, you scan all 256 bus,
32 device and 8 function locations which can be expressed,
using the BIOS. You could save a lot of time by scanning
only those bus numbers that are used and not scanning sub
functions for devices that are installed at all. It also
is a lot faster to use mechanism #1 port I/O and not call
the BIOS for each access, but you might be using the BIOS
deliberately to also support ancient mechanism #2 boards?

 If the VirtualBox people cannot fix the huge delay...

I think UIDE2 now takes 2-3 minutes on VirtualBox when
that uses a virtual PIIX3 chipset, so if you really do
a scan of all locations, scanning only those locations
where

Re: [Freedos-kernel] Commit 1705

2012-02-19 Thread dos386
Kernel 2041 seems to be out:

http://sourceforge.net/projects/freedos/files/Kernel/2041/

(untested, just history.txt __IS__ updated this time)

but nobody annouced it :-D

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Commit 1705

2012-02-19 Thread Bernd Blaauw
Op 19-2-2012 10:57, dos386 schreef:

 (untested, just history.txt __IS__ updated this time)

 but nobody annouced it :-D

It's a secret to everybody!
(hm, too much Zelda)

The pre-386/memdisk detection is a good thing, finally a unified kernel.
Right until someone does a append FD={INSTALL=FORMAT C: /Z:SERIOUSLY}

Having 2041 out when maintainers had time for it relieves them from 
pressure for implementing stuff and releasing new versions.

Bernd

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Commit 1705

2012-02-19 Thread Eric Auer

Hi Bernd,

 (untested, just history.txt __IS__ updated this time)

 but nobody annouced it :-D

Yes, why?? I forward a message from RayeR in the forum below.

 It's a secret to everybody!
 (hm, too much Zelda)
 
 The pre-386/memdisk detection is a good thing, finally a unified kernel.

For the VERY exotic case that you have a bootdisk which
boots from memdisk on 386 and without on older 386, if
you can still find any... And the exotic case where the
two styles of booting still share the same config sys?

 Right until someone does a append FD={INSTALL=FORMAT C: /Z:SERIOUSLY}

You might want to use a login to protect advanced boot
menu options. However, if people can boot DOS from a
memdisk - I assume this is NOT now they boot from C:!
then they can just boot ANYTHING from another portable
boot drive and whether they can mess up how your DOS
portable boot drive acts is a relatively small worry.

 Having 2041 out when maintainers had time for it relieves them from 
 pressure for implementing stuff and releasing new versions.

I do not understand... Anyway, here is what RayeR says:

 posted by RayeR(R) Homepage, CZ, 19.02.2012, 17:39
 
 Thx for notification. Let's see what's new:
 
 2012 Feb 07 - Build 2041
  Jeremy Davis
 
 + Changes Jeremy
 * r1637 fix out of range byte in country.asm
 * r1685 add int 2f subfunc 122B and 122D from Eduardo Casino
 * r1697 from Pete Batard, do not display CHS mismatch warning
 during booting when forcing LBA mode option set
 * r1702 improve handling for sectors not 512 bytes in size
 (up to 2048 bytes, larger sizes not yet working)
 * r1705 add cpu detection so memdisk args supported in 8086 build
 
 Seems like minor changes except the support for 2048 sectors?
 Where is it used? I know that CDROM use 2kB sectores but it was
 handled by driver for a long time. I also read that some new HDDs
 have 4kB sectors but AFAIK they still emulate 512B sectors for system.
 
 ---
 DOS gives me freedom to unlimited HW access.


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] screen full of kernel warnings

2012-02-14 Thread Bernd Blaauw
Could someone please verify that a screen full of kernel warnings is 
shown when running option 2 from the following bootdisk? :
[ http://www.reactos.org/bugzilla/attachment.cgi?id=7374 ].

A simple workaround I could do is commenting out the textline that gets 
printed and recompile.

Cause of these warnings is that the bootdisk is hiding int13 drives 
(which I do on purpose to not mount any harddisk FAT partitions at 
boot-time as I like to use C: for a ramdisk occasionally).

Bernd

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

2012-02-09 Thread C. Masloch
 Note that the 1702 changes were effectively reversed by 1704.

 The 1705 changes are unrelated.

Wrong From

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

2012-02-08 Thread Tom Ehlert

 Dear PerditionC,

    UBYTE DiskTransferBuffer[MAX_SEC_SIZE];

 wastes 3,5 KB low memory for *everybody*, not only when it's needed.
 regarding how much time we have spend until we had 64 byte free
 I think this is a bad idea


 please see my previous messages, I know exactly how much space is
 wasted and clearly stated this along with statement 512 will be
 default (and was already changed to such earlier)


 I also think that these experiments should NOT be in the stable
 branch.

 fork it, and make another 'unstable' branch if you want to experiment,
 but don't experiment with code that is supposed to be stable.

 Regards, Tom


 These are not experiments,
these are - in the current state - even useless experiments.

 this is me working to improve compatibility
 with MSDOS and existing though rare disks.

a) the only problematic disks have a 4K sectors. your fix doesn't work
with them.

b) these disks don't exist, as there is currently no USB stack that
supports 4K sectors

I don't mind if you work on an unstable branch, or on your own local
copy of the freedos kernel.

however generating AGAIN an unstable kernel 2041 is a real bad idea.

and tagging current state (after the questionable 1705) '2041' without
further discussion is shit.

Tom


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Re : Support for 4k byte

2012-02-08 Thread Eric Auer

Hi Czerno / Bertho,

 Hi Eric! On the freedos-kernel list, you voiced such opinion about 
 the future of big sector disks:
 
  that has low priority imho, as drives with large sectors are a 
 temporary thing, will be gone with GPT partitions. 

This refers to the following quote from an earlier 4 kB related mail:

 I stumbled upon a couple pages that say otherwise : the industry
 has agreed to sell AF disks only *until the end of 2014*!

It was actually you yourself who said that on 25 Jan 2012 ;-)

AF = Advanced Format = 4096 byte per sector, i.e. Advanced
meaning if you find 512 byte better, you are not modern :-p

It is a bit like APS Advanced Photo System - a nice buzzword
for a strange idea that is made look good for the end user.

Also, advanced format lets more data share less ECC error
correction data, squeezing out a tiny bit of extra capacity
and a bit of extra resistance to data errors...



Wikipedia claims that Windows Vista, 7 and 2008 have hotfixes
for drives with natively larger sectors which allow access
in 512 byte emulated sectors - in other words, the hotfix is
just fixing the performance loss caused by not knowing that
the underlying hardware sectors are big - while those Windows
versions apparently do NOT support native big sectors yet, at
least not for the boot drive... Reference for this:

http://support.microsoft.com/kb/2510009

In other words, Windows Vista / 7 / 2008 makes sure to always
access aligned blocks of 8 sectors of 512 bytes together, to
improve performance, when it knows that the physical disk has
4 kB sector size but uses 512 byte per sector I/O protocols.

That is very vaguely similar to what LBACACHE TICKLE and other
read-ahead tools can do for you, if configured properly... ;-)



 Manufacturers have no interest to reverting to 512 bytes sectors - 
 since 4K sects allows them to advertise higher capacities

No. As Tom said, large sectors are only a workaround for WinXP
and similar MBR partitioned operating systems. With GPT, you
have no relevant limit to the number of sectors any more and
sectors can be small again :-)

On the other hand, everything is pretty virtual today anyway,
and SSD / flash have better performance with access in larger
blocks, but that does not mean that block has to equal sector.
It could also equal cluster and FORMAT already supports making
clusters of 4 kB or bigger align with 4 kB boundaries... ;-)

The virtuality will also mean that you eventually have to
load a PC BIOS interrupts legacy API module for EFI BIOSes.
Luckily those also exist as open source, if vendors get lazy.

Eric

PS: As you say you read this on freedos-kernel, but are only on
freedos-user (where you mailed) I took the freedom to CC both.



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Commit 1705

2012-02-07 Thread C. Masloch
Hi,

Commit 1705 renames a particular LoL field CPULevel and adds a comment  
correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0  
otherwise. The commit however makes the boot loader store the detected CPU  
level (0, 1, 2, or 3) there instead. I don't think it's necessary to use  
the field in an incompatible manner, and neither is the new 21.33  
subfunction that the commit adds, because no one uses it yet. Even so, the  
subfunction does not require using that particular field to store the  
detected CPU level.

Regards,
C. Masloch

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

2012-02-07 Thread Tom Ehlert
Dear PerditionC,

UBYTE DiskTransferBuffer[MAX_SEC_SIZE];

wastes 3,5 KB low memory for *everybody*, not only when it's needed.
regarding how much time we have spend until we had 64 byte free
I think this is a bad idea

I also think that these experiments should NOT be in the stable
branch.

fork it, and make another 'unstable' branch if you want to experiment,
but don't experiment with code that is supposed to be stable.

Regards, Tom


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Commit 1705

2012-02-07 Thread Eric Auer

Hi Chris, Jeremy,

 Commit 1705 renames a particular LoL field CPULevel and adds a comment  
 correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0  
 otherwise. The commit however makes the boot loader store the detected CPU  
 level (0, 1, 2, or 3) there instead. I don't think it's necessary to use  
 the field in an incompatible manner, and neither is the new 21.33  

I totally agree. Reporting 386 versus older is more compatible and
good enough. Only in rare cases when you want to know exactly, you
would have to fall back to a tool such as CPULEVEL, but for a kernel
flag, 32 bit CPU is exact enough information :-)

 subfunction that the commit adds, because no one uses it yet. Even so,

You do not need an unused API function to read a rarely read field
because the very few tools interested in the field can read LoL :-)

 the subfunction does not require using that particular field to store
 the detected CPU level.

Even that... And by the way, I agree with Tom that flexible sector
sizes are a bit shaky and the default compile should use 512 byte.

However, a CONFIG.SYS option to modify the max sector size at boot
would be a good compromise between hardcoding this at compile time
and spending code and effort on automatic sizing at boot initdisk.

Eric


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

2012-02-07 Thread Kenneth J. Davis
On Tue, Feb 7, 2012 at 9:51 AM, Tom Ehlert t...@drivesnapshot.de wrote:
 Dear PerditionC,

    UBYTE DiskTransferBuffer[MAX_SEC_SIZE];

 wastes 3,5 KB low memory for *everybody*, not only when it's needed.
 regarding how much time we have spend until we had 64 byte free
 I think this is a bad idea


please see my previous messages, I know exactly how much space is
wasted and clearly stated this along with statement 512 will be
default (and was already changed to such earlier)


 I also think that these experiments should NOT be in the stable
 branch.

 fork it, and make another 'unstable' branch if you want to experiment,
 but don't experiment with code that is supposed to be stable.

 Regards, Tom


These are not experiments, this is me working to improve compatibility
with MSDOS and existing though rare disks.  I purposely left a default
value larger than needed so I could track down a kernel issue with
memory allocation during initialization.  This issue still exists and
I believe may be one of the reasons  why there are occasional reports
of invalid opcode/crash during boot.

MSDOS sets the value based on known devices during startup, this is
documented in books describing it.  The FD kernel has been hardcoded
for 512 bytes.  My plan was first to ensure sizes  512 bytes work
then make the changes to allow user to choose larger size than 512 so
only those who need the different value are penalized with increased
memory usage and can use FD kernel with their drive while everyone
else only has minimally larger kernel but more like MSDOS.  Part 1,
the changes so sizes 512 can be used was committed and uncovered a
memory allocation issue.  I put part 2 on hold because this seemed
important to find - instead I will leave the 512 hard coded which
rarely triggers the bug.

The experimental 4K build is based on my forked 0xdc (DOSC OEM id)
kernel, and it is where I do most of my changes before merging/testing
with the 0xfd kernel.

Jeremy.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


  1   2   3   4   5   6   7   8   9   10   >