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


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


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


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


Re: [Freedos-kernel] EXT3 support

2016-08-26 Thread H. Peter Anvin
On August 26, 2016 12:26:52 AM PDT, Eric Auer  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


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


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


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


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


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


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


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


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


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


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

Hi!

Your vision on DOS is somewhat, well, interesting ;-) So
there is a lot to chat about, although I am not sure if
the KERNEL list is the right place for this topic. DPMI:

 I would expect performance gain to be minimal.  Maybe there could be
 Low/HMA/UMB memory savings with a different architecture.  Hard to say.

Well there could, but why would it matter? More heavy DOS
software normally uses DOS extenders / DPMI anyway, which
means it does not care about how much low DOS RAM is free.

The HMA is mostly used for the kernel and buffers, so as
long as the kernel fits in there, no others have a heavy
need for it. Only a few drivers may use it UMB style.
Also, caches put bigger buffers in XMS, not needing HMA.

Finally UMB is mostly used for drivers: You could write
drivers that use DOS extenders / DPMI if you really have
a lack of space. Actually the simulation of SoundBlaster
16 that comes with SoundBlaster PCI works like that.

Probably also some commercial NTFS drivers, because NTFS
is complex and you do not want to spend 100s of kilobytes
of DOS memory only for loading a filesystem driver...

USB, PXE and CD/DVD/BD drivers as drivers / in memdisk:

 I lean this way too w/respect to drivers.  Built-in's biggest advantage is

You still have to configure built-in drivers, you only
avoid the risk that you forget to include the file in
your boot disk ;-)

 simplicity in user configuration. However, networking seems to be lacking
 throughput speed with either mTCP or Watt32 apps.  I'm not sure if it's a
 packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue.

Networking in DOS means that your app has a compiled-in
network stack which communicates with a packet driver to
get the low-level hardware stuff done. You often have a
small buffer for that and little concurrency. There may
be a bit of IRQ and DMA, but big operating systems are
more relaxed about juggling with multiple streams of net
data with support from complex chips on your network card.
Note that this is just an educated guess: Ask our experts!

 guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy
 networking, and the switch between kernel and app.  I've seen some

No switch: The kernel does not network at all and there is
only one app at a time using the network. Depending on how
your packet driver and network stack library work, you do
not need many steps of copying either and the transfer to
or from a buffer is unlikely to be a big bottleneck with
modern CPU, I think. However, as said, you probably work
with little bits of data and small buffers in DOS, because
you may have less orchestration between stack and driver.

 reference to the same ... USB drivers as well (USB 1.1 speed from USB
 2.0 devices or 3.0 devices).  And there seems to be 3 ways to get USB

That problem far much more trivial than you might think:
USB 2 and 3 are controlled in ways that differ a lot from
USB 1, so many drivers simply do not talk USB 2 or 3 at
all. This is not like AGP, PCI or PCIe where you flip a
few bits and suddenly I/O to your graphics card is fast.

It is more like the difference between paged graphics at
a000:0 and a linear framebuffer, to stay in the example.
However, there is no linear USB. Talking USB the 2 or 3
way is just a quite different language, but as you know,
at least one shareware driver speaks it and knows the
dialect of at least some relatively widespread chips...

 working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play

Enjoy :-) And maybe do some benchmarks. Even the shareware
driver should work long enough for that - I think it just
blocks after a while after each boot, but is not locked in
terms of how many days or years you have it installed.

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

 Yes! I agree!  The FD Kernel needs to speak MBR, GPT, ISO9660  UDF
 (including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as
 well.  Linux and/or FUSE should be helpful here.

Uhm no. You do not agree ;-) Yes the kernel should speak both
MBR and GPT. Something about 4k sector size is also a good
idea. However, El Torito is only so-so as CD/DVD/BD driver
and Jack's drivers are probably better. It would be fun from
an academic point of view to have ElTorito-ISO9660-GPT in a
kernel, but even Linux works great with kernels-without-any-
disk-drivers when you put the drivers in the boot-ramdisk to
load them as separate files from there. DOS with MEMDISK is
basically the same.

Having (separately loaded) drivers for ISO9660 (we do, even
with long file name support) and UDF (only experimental and
abandoned??) is indeed important for DOS. Also, somebody may
want to undust the old EXT2 semi-drivers called LTOOLS, they
probably still have some sort of ancient limitation such as
lacking LBA support or getting 

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

2013-05-21 Thread Chris Evans
I still think having true functions in batch files would be a good thing
turn batch files into more capable language




On Tuesday, May 21, 2013, Eric Auer wrote:


 Hi!

 Your vision on DOS is somewhat, well, interesting ;-) So
 there is a lot to chat about, although I am not sure if
 the KERNEL list is the right place for this topic. DPMI:

  I would expect performance gain to be minimal.  Maybe there could be
  Low/HMA/UMB memory savings with a different architecture.  Hard to say.

 Well there could, but why would it matter? More heavy DOS
 software normally uses DOS extenders / DPMI anyway, which
 means it does not care about how much low DOS RAM is free.

 The HMA is mostly used for the kernel and buffers, so as
 long as the kernel fits in there, no others have a heavy
 need for it. Only a few drivers may use it UMB style.
 Also, caches put bigger buffers in XMS, not needing HMA.

 Finally UMB is mostly used for drivers: You could write
 drivers that use DOS extenders / DPMI if you really have
 a lack of space. Actually the simulation of SoundBlaster
 16 that comes with SoundBlaster PCI works like that.

 Probably also some commercial NTFS drivers, because NTFS
 is complex and you do not want to spend 100s of kilobytes
 of DOS memory only for loading a filesystem driver...

 USB, PXE and CD/DVD/BD drivers as drivers / in memdisk:

  I lean this way too w/respect to drivers.  Built-in's biggest advantage
 is

 You still have to configure built-in drivers, you only
 avoid the risk that you forget to include the file in
 your boot disk ;-)

  simplicity in user configuration. However, networking seems to be lacking
  throughput speed with either mTCP or Watt32 apps.  I'm not sure if it's a
  packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue.

 Networking in DOS means that your app has a compiled-in
 network stack which communicates with a packet driver to
 get the low-level hardware stuff done. You often have a
 small buffer for that and little concurrency. There may
 be a bit of IRQ and DMA, but big operating systems are
 more relaxed about juggling with multiple streams of net
 data with support from complex chips on your network card.
 Note that this is just an educated guess: Ask our experts!

  guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy
  networking, and the switch between kernel and app.  I've seen some

 No switch: The kernel does not network at all and there is
 only one app at a time using the network. Depending on how
 your packet driver and network stack library work, you do
 not need many steps of copying either and the transfer to
 or from a buffer is unlikely to be a big bottleneck with
 modern CPU, I think. However, as said, you probably work
 with little bits of data and small buffers in DOS, because
 you may have less orchestration between stack and driver.

  reference to the same ... USB drivers as well (USB 1.1 speed from USB
  2.0 devices or 3.0 devices).  And there seems to be 3 ways to get USB

 That problem far much more trivial than you might think:
 USB 2 and 3 are controlled in ways that differ a lot from
 USB 1, so many drivers simply do not talk USB 2 or 3 at
 all. This is not like AGP, PCI or PCIe where you flip a
 few bits and suddenly I/O to your graphics card is fast.

 It is more like the difference between paged graphics at
 a000:0 and a linear framebuffer, to stay in the example.
 However, there is no linear USB. Talking USB the 2 or 3
 way is just a quite different language, but as you know,
 at least one shareware driver speaks it and knows the
 dialect of at least some relatively widespread chips...

  working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play

 Enjoy :-) And maybe do some benchmarks. Even the shareware
 driver should work long enough for that - I think it just
 blocks after a while after each boot, but is not locked in
 terms of how many days or years you have it installed.

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

  Yes! I agree!  The FD Kernel needs to speak MBR, GPT, ISO9660  UDF
  (including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as
  well.  Linux and/or FUSE should be helpful here.

 Uhm no. You do not agree ;-) Yes the kernel should speak both
 MBR and GPT. Something about 4k sector size is also a good
 idea. However, El Torito is only so-so as CD/DVD/BD driver
 and Jack's drivers are probably better. It would be fun from
 an academic point of view to have ElTorito-ISO9660-GPT in a
 kernel, but even Linux works great with kernels-without-any-
 disk-drivers when you put the drivers in the boot-ramdisk to
 load them as separate files from there. DOS with MEMDISK is
 basically the same.

 Having (separately loaded) drivers for ISO9660 (we do, even
 with long file name 

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


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


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 a 

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


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


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


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

2012-02-06 Thread Eric Auer

Hi Jeremy, Chris, others,

 I am aware they are different...

That is risky - even for a demonstration implementation,
consistency seems important to keep code maintainable...

 dynamically adjusted same as MSDOS.  That currently is not done.

that has low priority imho, as drives with large sectors
are a temporary thing, will be gone with GPT partitions.

For the same reason, I suggest to NOT put efforts into
incompatible put 8 small sectors in each 4k buffer on
mixed sector size computers BUFFERS code of any sorts.

Note that larger caches already do put multiple sectors
in one slot, but for other reasons and without mixing.



 BUFFERS=COUNT#,READAHEAD#,SECTORSIZE# or would it be better to add a
 whole new command MAXSECSIZE=SECTORSIZE#  ?  (the latter seems simpler
 so the one I will plan on for now).

MAXSECSIZE will be fine, thanks :-) And really useful.
Changeable drives are en vogue, so figuring out needed
sector sizes at boot time is not always useful, and it
is probably a lot of work as well...

For my personal taste, a MAXSECSIZE, with a default of
512, would be a good small-amount-of-code way of having
enough large sector support for those who need it. When
you encounter a drive/partition with unsuitable sector
sizes for the current settings, skip it with a message.

 agreed, though currently any value  3KB causes memory corruption

evil again... you said you already have an idea to debug?



 I don't see us using max sector size  512, but using tdsk with
 smaller than 512 sector size does seem to work - though at this

The last time when we discussed OTHER sector sizes on the lists,
it was exactly for that reason - small RAMDISKS with small sectors
and less fragmentation at the expense of slightly larger FATs.

So I do think it would be useful to support BUT only with sectors
of at least 64 bytes size (FAT32: 128, although without FSINFO).

I suggest to NOT spend any code for BPB wraps sectors or such:
sectors below 128 bytes are just way too exotic and support for
dir entry sized micro sectors is more a theoretical exercise.

Fun extra exercise: Make a bootable FAT12/16/32 sector with 128
bytes per sector, loading a 2nd stage loader (reserved sectors).
Then construct a drive and BIOS for such drives, or ROM/MEMDISK.

Regards, Eric


--
Try before you buy = See our experts in action!
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-dev2
___
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-05 Thread C. Masloch
 - First, dsk.h defines the maximum sector size (MAX_SEC_SIZE) as 2048  
 (as
 the commit comment says) while the relevant LoL entry (maxsecsize) in
 kernel.asm is initialised to 4096.

 Yes - this is simply for testing purposes; I plan to default both to
 512.  I would prefer both set from the same define to ensure they stay
 in sync - I am aware they are different, I am tracking down how to fix
 support for larger than 2KB sectors and MAX_SEC_SIZE will be set to
 4096 to test or possibly eliminated in favor of using only maxsecsize.

Ah, yes, Eric speculated that this might be a proof of concept for now,  
lacking an unstable branch. I happen to keep track of kernel commits  
recently. Sorry that I already reviewed this premature implementation!

Values should definitely be tied later, either by consistently using  
MAX_SEC_SIZE, or (preferably) by initialising maxsecsize and the init  
buffer's size with MAX_SEC_SIZE and then always referring to maxsecsize  
afterwards.

 - Third, if I'm not entirely mistaken, the patch makes all buffers grow  
 to
 2048 bytes, even in the absence of any block devices with large sectors.
 This will unnecessarily waste memory on most systems.


 yes, buffers are allocated using size of max sector size so will waste
 lots of memory if  512 byte sectors are used.  I will be committing
 updates to ensure max sector size defaults to 512 so as to avoid waste
 of space.

Regarding that, I once considered that unused buffer space could be used  
to load multiple smaller sectors. Say, if you use 4096-byte buffers but a  
particular drive has 512-byte sectors, you can load eight sectors at once  
whenever reading. Would have to align sector reads to those boundaries  
though, plus a special check for the end of the file system. Additionally,  
the written bit would either have to be expanded to a bitmap, or you'd  
have to write eight sectors together all the time too. This would probably  
abandon any MS-DOS compatibility of the buffer layout, if the kernel  
currently does have any (not sure).

 This scheme could obviously be extended by additional tools/interfaces  
 to
 increase the buffer size later on, and a CONFIG option to artificially
 increase it in anticipation of a post-CONFIG requirement.

 agreed, a config option to allow manually specifying a larger value
 than needed at boot time - should buffers be extended to
 BUFFERS=COUNT#,READAHEAD#,SECTORSIZE# or would it be better to add a
 whole new command MAXSECSIZE=SECTORSIZE#  ?  (the latter seems simpler
 so the one I will plan on for now).

Yes, Eric suggested that one too. Plus, I think it's preferable because  
then a user can specify MAXSEXSIZE without having to specify the first two  
values for BUFFERS.

 I don't see us using max sector size  512, but using tdsk with
 smaller than 512 sector size does seem to work - though at this time I
 don't see me researching  if it correctly works or merely happens to
 work on my test setup.

I think you need to review at least dsk.c around line 388, where it says  
pbpbarray-bpb_nbyte % 512 now. I didn't look into what that check  
actually does, but it sure seems like it would have to be adjusted. While  
you're at it, you can make it the proper check for powers of two between  
32 (or 64,128, regarding (E)(N)BPB size) and 8192 (or 2048 for now).

 currently any value  3KB causes memory corruption if
 too many buffers are specified (I have successfully gotten 4KB sectors
 to finish booting by changing buffers=2).

 I currently have tracked down
 part of my issue to allocation problems if buffers is too large, but
 still working on relearning the init time segment relocations and
 order to determine a proper fix for buffer allocations.  It would help
 if printf worked correctly in all the init code...

The virtues of high-level language kernel development ;)

Regards,
C. Masloch

--
Try before you buy = See our experts in action!
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-dev2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2012-01-20 Thread Travis Siegel

On Jan 14, 2012, at 5:26 PM, Eric Auer wrote:

 are simply too small to be bootable anyway. I wonder if you should be
 able to boot from nonstandard sector sizes at all - for example a CD-
 ROM does not even have a FAT filesystem, so why would you boot from a
 (raw!) CD-ROM then?
Booting from cds and raw cd images would be extremely useful.  If I  
had a pure dos system, I'd be more than happy to fiddle with these  
changes.  Problems are, I'm not the worlds best assembly programmer,  
and I've unfortunately got no way to (currently) test such changes.
However, booting from cd should be supported if possible.
As you pointed out, the sector size is embeded (or should be) in the  
boot info, so I see no reason why this couldn't be handled  
automatically.  It can simply assume 512 bytes if no data is  
available, and then boot normally.
I for one would find the ability to boot from different sector sizes  
useful (as mentioned above), and I'm sure others would too.  What we  
really could use in dos is the ability to designate a drive for  
booting (like osx has) so you could change your boot drive  
dynamically during os execution, so if you wanted to boot from second  
hd or cd, or floppy regardless of what cmos is configured to, this  
could be done.  I realize this would be not a trivial modification,  
but especially if iso images could be used for this purpose, it would  
make dos an extremely valuable troubleshooting tool, as well as  
allowing a person to access all drives regardless of what os / 
versions might be on them.
Plus, the ability to boot from iso images would allow a whole lot of  
flexibility for testing and other uses as well.
I'd of course have no idea how to do such things, but I'm always  
willing to learn. :)



--
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] [Freedos-user] Re : Support for 4k byte sectors

2012-01-14 Thread Bernd Blaauw
Op 14-1-2012 19:48, Bertho Grandpied schreef:
 It's been a few days and I'm surprised my first mail hasn't been acknowledged 
 in any way, let alone answered; strange, I've been part of various lists 
 before, usually 'newbies' are greeted rather than ignored altogether. So I'll 
 reiterate and articulate the above question just in case it was not clear : 
 have I done something wrong ? should I try posting to the kernel or 
 developers lists instead ?

Truth is we're not sure, this 4K sector size thing comes in several 
versions:
1) emulation with aligned 512byte sector emulation
2) emulation with non-aligned 512byte sector emulation
3) native 4K (especially USB bridges apparently)


 In other words, this is asking what the plan is for the FreeDOS kernel to be 
 able to mount mass storage devices having 4 kilobytes per sector ?

If the disk has traditional BIOS partitioning layout (MBR, 
primary/logical partitions with FAT16/FAT32 filesystems) then it might 
be possible for the kernel to work with this as long as it is a data 
disk. Booting from a partition without 512byte sector-size is probably 
more challenging, let alone guarantee file(-system) integrity and disk 
manipulating (defragmentation programs, filesystem checkers like CHKDSK 
and DOSFSCHK).

GPT partitioning scheme isn't supported at all (nor is EFI/UEFI without 
BIOS emulation).


 As said in previous message,
 I for one am ready to test development kernels against my
 USB disk appliance (1 TiB Iomega Prestige).

freedos-kernel would be most appropriate list as the developers on there 
have most expertise. However they're also the ones who are rarely 
present due to other interests or obligations, so getting answers can 
take a while.

You could also try freedos-devel for this specific technical question 
but answers might take as long as getting answers on the users list. 
People usually don't answer if they don't have the correct answer, thus 
things stay quiet for a while.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2012-01-14 Thread Eric Auer

Replaying a 12 May 2005 mail :-)

 [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes

Hi, I have browsed the CVS kernel a bit, and got the impression
that it would not be too hard to support sector sizes below 512
bytes (32, 64, 128 and 256 bytes should be possible). For sector
sizes above 512 bytes (e.g. 1024 and 2048), each element in
BUFFERS and the DiskTransferBuffer would have to be bigger. Are
there DOS versions which support big sectors? How do they solve
the buffering problem? I think sector sizes below 64 bytes cannot
contain enough of a BPB to be useful. Sector sizes below 32 bytes
are definitely not useful, not even a single dirent fits in them.
Sector sizes above 512 bytes are at most useful for the 1024 byte
(far-east 1.2 MB diskette format / drives which support full 64 MB
of a single XMS2 handle as ramdisk without having to support the
DOS3.x+ 32bit sector number calls) and 2048 byte (raw sector size
on CD-ROM and maybe on magneto-optical drives) cases.

Comments about useful sector sizes would be welcome:
Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others).

Next part: I believe that the BIOS / kernel drives (diskette,
harddisk) only have to handle 512 bytes per sector. Otherwise,
you would have to adjust: CalculateFATData, DosDefinePartitions,
the kernel driver IOCTLS (e.g. format track), LBA_Transfer,
max_transfer (the DMA wrap checker) and maybe floppy_bpb (and -_bpbs).

In case you have wondered, directory handling already reads the
current sector size from the BPB, so it is flexible.
If you want drives with bigger sectors to be detected at boot time,
you not only have to get BUFFERs and DiskTransferBuffer bigger and
adjust _maxbksize (in the global SDA data structure, which is, by
the way, not yet read by FreeDOS itself, as only 512 bytes per sector
are supported anyway) but you also have to make InitDiskTransferBuffer
bigger as well.

For boot purposes you just have to make SYS able to pad unused parts
of the boot sector to allow bigger sector sizes - BUT you also have
to make SYS able to adjust the boot sector code to that, I remember
that not all our boot sectors actually used the BPB bytes-per-sector
value (there was not enough space to process it). Smaller sector sizes
are simply too small to be bootable anyway. I wonder if you should be
able to boot from nonstandard sector sizes at all - for example a CD-
ROM does not even have a FAT filesystem, so why would you boot from a
(raw!) CD-ROM then?

So I suggest to support nonstandard sector sizes ONLY for drives which
are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...).
To make that possible, BUFFERS and DiskTransferBuffer handling would
have to get better (even for smaller sectors - for bigger sectors, the
BUFFERS and DiskTransferBuffers themselves, being only _maxbksize big,
will be the problem).
In addition, getbpb and dskxfer (THE central send/receive a sector to/
from a device driver function) have to be made independent from the
hardcoded SEC_SIZE. Instead, they have to use the sector size from the
BPB of the drive. Hint: getbpb assumes that the boot sector magic word
is at offsets 1fe and 1ff. This IMPLIES a sector size of 512 bytes, too.
The GOOD part is that FreeDOS hardly uses anything else than getbpb and
dskxfer to communicate disk contents (for which it uses BUFFERS and
DiskTransferBuffer as intermediate storage places). rqblockio does call
block device drivers directly, too, but not to access sectors, for
example, and the other functions all use dskxfer or getbpb directly or
indirectly.



I hope I have not overlooked things in this review... Summary:
- To support bigger sectors, raise _maxbksize and make each element
  of BUFFERS and DiskTransferBuffer bigger
- To support nonstandard sector sizes at boot time, CalculateFATData,
  InitDiskTransferBuffer and DosDefinePartitions have to be modified
- To support nonstandard sector sizes for harddisk / diskette (kernel
  built-in drivers), you have to adjust the IOCTLs (format track...),
  LBA_Transfer and max_transfer
- To support nonstandard sector sizes at all, you have to modify
  dskxfer and getbpb and the BUFFERS and DiskTransferBuffer handling
  has to accept sectors in other sizes than SEC_SIZE, including e.g.
  sectors which are smaller than _maxbksize...
- SYS and boot sectors can only support bigger, not smaller, sector
  sizes, and SYS might have to do extra patching for those of the boot
  sectors which do not actually use the boot sector BPB sector size info



We should probably start by using _maxbksize in BUFFERS and either only
DiskTransferBuffer or both DiskTransferBuffer and InitDiskTransferBuffer
to get things a bit clearer... Then we should make SYS and boot sectors
able to support bigger sector sizes (not because it is really useful but
because this part is more self-contained / easier to maintain than the
rest of the kernel).

Then the first WORKING support for nonstandard sector sizes can be
added by 

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

2012-01-14 Thread Kenneth Davis
On Sat, Jan 14, 2012 at 5:26 PM, Eric Auer e.a...@jpberlin.de wrote:

 Replaying a 12 May 2005 mail :-)

 [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes

 Hi, I have browsed the CVS kernel a bit, and got the impression
 that it would not be too hard to support sector sizes below 512
...

Thank you for reviewing and providing a suggested road map.
I have a few other things in my todo queue but once done I will look
further into this.  I would like to add support for GPT disks first,
which I think will be much simpler and I can test.  I will need to
find a drive that exposes 4KB sectors for testing - ramdisks may work
at least initially.   As usual my developing time is limited, most of
which I use trying to figure out where I left off :-) or persuing
other things (lately I have been playing around with Android and how
to build it) but I have a little bit of time off in February so maybe
I can make significant progress then.

Thank you,
Jeremy

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


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

2012-01-14 Thread Eric Auer

Hi Jeremy :-)

 Replaying a 12 May 2005 mail :-)
 [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes

 Thank you for reviewing and providing a suggested road map.

Well, that old mail is nice for reference, but I would still say:

 So I suggest to support nonstandard sector sizes ONLY for drives which
 are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...).
 To make that possible...

For my current taste, this also implies that we do not NEED any
support for sectors ABOVE 512 bytes. It makes memory footprints
of buffers etc larger and we would only support 4096 byte sector
size for non-boot disks for the moment anyway, where an EXTERNAL
(not in the kernel but loaded in config.sys) block device driver
could easily map things into a virtual 512 byte sector size.

Of course in general, it is nice to be flexible. And some users
of ramdisks and romdisks would be happy about support for some
SMALLER sector sizes. As for the LARGER than 512 byte sectors,
I would really like a CACHE based solution to make access more
large block oriented. Maybe including write pooling. SSDs and
USB flash sticks would be happy about 4 kB, 32 kB or even more
minimum write sizes, of course also with block-aligned writes.

I do NOT recommend a full delayed write cache: It is a lot of
work to make sure that writes always go to disk before you do
something stupid (reboot, crash, change disks) and you already
gain a lot of performance with a SMALL pooling buffer IMHO.

 I have a few other things in my todo queue but once done I will look
 further into this.  I would like to add support for GPT disks first,
 which I think will be much simpler and I can test...

I totally agree and as you see in my mail from a few hours ago,
GPT is not hard to implement as long as you only care about FAT.

 I have a little bit of time off in February so maybe
 I can make significant progress then.

Maybe a strange off-topic, but I have some time off this spring,
but instead of programming, I wanted to visit some FreeDOS people
in western Europe :-) If you are interested, contact me off-list.

Regards, Eric


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-devel] [PATCH] kernel - only print suspect partition warnings if FORCELBA is not in use

2011-12-18 Thread Bernd Blaauw
Op 18-12-2011 23:31, Pete Batard schreef:

 1. I am the developer of Rufus [1], which is a DOS-bootable USB flash
 drive creation utility for Windows. One of the versions of Rufus embeds
 FreeDOS (kernel + freecom) for installation as the default DOS, in lieu
 of the WinMe DOS that can be extracted from diskcopy.dll.

I've recently learned about your Rufus program from the Reboot.pro 
forums, it seems quite interesting indeed. Would likely be a nice 
addition from ReactOS (which you made use of already) but as that's GPL2 
while your program is GPL3 that won't be possible I guess.

 3. All the machines I have tried so far report the CHS vs LBA computed
 mismatch warnings. Considering that first time FreeDOS users might be
 put off because of these benign warnings, I would very much like to
 avoid them.

There's a list of warnings indeed. A big one at that, especially when 
using syslinux's nopassany directive to hide physical disk drive units.

 Could this patch be considered for the mainline tree then?

I can't answer this, as I'm no developer. It could be an interesting 
addition for kernel 2041 if any kernel maintainer is still active 
occasionally.

 PS: is there a reason why one must have an AUTOEXEC.BAT present, even a
 blank one, to avoid the prompts for datetime in FreeCOM? What is the
 purpose of mandatory prompting for those?

Remove your CMOS battery and you'll see. Basicly, ancient machines often 
had no battery and yet needed to have a time and date set. I guess 
FreeDOS follows MSDOS design in this aspect.

--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-devel] [PATCH] kernel - only print suspect partition warnings if FORCELBA is not in use

2011-12-18 Thread Kenneth J. Davis
...
  3. All the machines I have tried so far report the CHS vs LBA computed
  mismatch warnings. Considering that first time FreeDOS users might be
  put off because of these benign warnings, I would very much like to
  avoid them.

 There's a list of warnings indeed. A big one at that, especially when
 using syslinux's nopassany directive to hide physical disk drive units.

  Could this patch be considered for the mainline tree then?

 I can't answer this, as I'm no developer. It could be an interesting
 addition for kernel 2041 if any kernel maintainer is still active
 occasionally.


Thank you, I will look at the patch this week.

  PS: is there a reason why one must have an AUTOEXEC.BAT present, even a
  blank one, to avoid the prompts for datetime in FreeCOM? What is the
  purpose of mandatory prompting for those?

 Remove your CMOS battery and you'll see. Basicly, ancient machines often
 had no battery and yet needed to have a time and date set. I guess
 FreeDOS follows MSDOS design in this aspect.


Yes, it is the way MS/PC DOS command works due to not all computers having
a real time clock so the time and date would need to be set on boot, or
something like that - I could be recalling this incorrectly.  :-)

Jeremy
--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] ..

2011-12-07 Thread Diego Rodriguez
.. http://koag.tym.cz/christmas.html?uCID=y9i1

--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] (no subject)

2011-11-26 Thread Diego Rodriguez
hello! http://islamy.unidar.ac.id/winterpharm.html?jrtopicid=o5o5

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] possible to disable initdisk?

2011-08-21 Thread Eric Auer

Hoi Bernd,

 I'm in a situation where I got Syslinux bootloader on an USB flash 
 drive. It loads the MEMDISK ramdisk module with a floppy image as 
 contents which is then executed (as drive A:).
 I'd like to get into a situation where the USB flash disks doesn't get a 
 driveletter assigned by the kernel when it loads but only after the DOS 
 USB driver stack is loaded.

You can hook int 13 function 8 (get drive parameters) and make
sure that for dl = 80 or higher, it always returns carry set
and dl = 0 to pretend having no harddisks. Of course DOS does
a lot of work for you to parse partitions, so it is a bit odd
to pretend you have none only to do that again manually later.

 To that end there seem to be 2 options:
 1) /memdisk initrd=floppy.img pause followed by removing USB disk and 
 pressing a key to continue. Later on, insert again.

You could also do the above and/or temporarily make int 13
access to all harddisks behave as if all disks are empty
bit buckets. I hope you will not try to format later ;-)

 2) keep kernel disk scanning/enumerating code intact but don't execute 
 it for drive 0x80 and up, at startup at least. This way the drivers can 
 be loaded, set interface to max supported speed, recognise devices, and 
 get a driveletter assigned (C: likely)

See above. You can do it with a relatively simply int 13 fake.

 Is the kernel designed to allow such a specific scenario #2 ?

There is no built-in function in the kernel, although you can
SYS CONFIG the lba support away and hide your partitions after
the first 1024 cylinders. Later, when you load USB drivers to
do the processing on DOS block device level, you can get along
completely without int 13 CHS / LBA access anyway, depending
on what style of USB drivers you use, I guess. Again, in this
scenario, the USB driver will have to do all partition table
(MBR, chain of extra partitions) processing itself because DOS
and int 13 itself has not int 13 disk hot-plugging. Luckily it
is okay for DOS to have many drive letters managed by 1 driver.

 It's very 
 un-DOS-like to delay giving out driveletters. Initdisk.c seems to 
 suggest scanning can be disabled [SCAN_PRIMARY], but I guess that's a 
 permanent option instead of only for boot-time.

The scan constants are only for doing some things in some passes
of scanning the partition table and other things in other, with
some things being skipped then. It is not about skipping disks.

Eric :-)


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] possible to disable initdisk?

2011-08-21 Thread Bernd Blaauw
Op 22-8-2011 0:47, Eric Auer schreef:
 You can hook int 13 function 8 (get drive parameters) and make
 sure that for dl = 80 or higher, it always returns carry set
 and dl = 0 to pretend having no harddisks. Of course DOS does
 a lot of work for you to parse partitions, so it is a bit odd
 to pretend you have none only to do that again manually later.

No idea how to do such a thing, all modifications would have to happen 
at the kernel I guess as that's the first thing loading, and actually 
assigning those driveletters.
Then, again, Syslinux/memdisk documentation lists a nopassany 
parameter to disable showing harddisk. Gotta test that next I guess :)

 You could also do the above and/or temporarily make int 13
 access to all harddisks behave as if all disks are empty
 bit buckets. I hope you will not try to format later ;-)

I've had a DIR E: at some point and ended up with batchfile content 
being listed. Talk about memory corruption..

 There is no built-in function in the kernel, although you can
 SYS CONFIG the lba support away and hide your partitions after
 the first 1024 cylinders. Later, when you load USB drivers to
 do the processing on DOS block device level, you can get along
 completely without int 13 CHS / LBA access anyway, depending
 on what style of USB drivers you use, I guess. Again, in this
 scenario, the USB driver will have to do all partition table
 (MBR, chain of extra partitions) processing itself because DOS
 and int 13 itself has not int 13 disk hot-plugging. Luckily it
 is okay for DOS to have many drive letters managed by 1 driver.

The USB drive is typically formatted with FAT32 so all FAT32/LBA code 
needs to stay intact or I can't access the filesystem on the USB flash 
drive after loading drivers. Using a FAT16 kernel would've been too 
easy, hehe.

 The scan constants are only for doing some things in some passes
 of scanning the partition table and other things in other, with
 some things being skipped then. It is not about skipping disks.

There's an option for *showing* partition info (of which the output is 
can't get partition info half of the time anyway), as well as an 
option for the scan order (MSDOS style, or general style), unfortunately 
nothing for only scanning partial stuff.
I'll try the Syslinux stuff for starters, see if it works.
Thanks for your response

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] possible to disable initdisk?

2011-08-21 Thread Bernd Blaauw
Op 22-8-2011 0:58, Bernd Blaauw schreef:
 Then, again, Syslinux/memdisk documentation lists a nopassany
 parameter to disable showing harddisk. Gotta test that next I guess :)

This works like a charm, however FreeDOS kernel happily lists about 50 
lines with 'illegal partition table, drive nn, sector 00'

FDISK also results in errorlevel 6 (no harddisk present) as intended.
The USB driver stack seems to work except for happily killing keyboard 
input upon access to the USB drive. Not tested FDISK yet.

Anyway, one issue semi-solved by 'nopassany' parameter, sleep well :)

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] FreeDOS kernel UPX'ing and versionning chaos

2011-08-01 Thread cm
 Most FreeDOS kernels released so far were UPX'ed and not un-UPX'able.

 The kernel almost-2040 included on 1.1test3 CD distro is NOT UPX'ed.

 Problem: with UPX'ed kernel, you can't check the version without
 booting the kernel.

 Suggestion: at the beginning or end of the file, add a string allowing to
 identify the kernel with compile date and other crucial info:

 K2040D2011-07-31C32F16B
 K2041D2011-08-31C16F28W

 C is CPU (16 aka 8086 or 32 AKA 80386)

 F is FAT (16 or 28)

 W and B are compilers (or is Boreland now dead ?).

+1

Extend that CONFIG area at the beginning of the file, that's left
uncompressed anyway.

Providing the build and version information on an exclusive API for the
currently running kernel would be useful too. Currently, there's a string
with some 21.33Fx (.33FD ?) API, but that's just a string (difficult to
parse; format changes happen), and then, 21.3000 returns the (low byte of
the?) version number in cx or bx or somewhere, but that's unreliable
because 21.30 is often intercepted and modified by version faking
software.

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] FreeDOS kernel UPX'ing and versionning chaos

2011-08-01 Thread e . auer

Hi Bernd,

general question: How much do we want to know about a kernel
without booting it? Because a lot of the information below is
available AFTER booting the kernel, be it by human reading of
the version description string (21.33xx) or by querying some
int 21 functions to check FAT32 support or revision number.

I agree that it would be good to have some thing visible in
an easy to access area. Because we would probably use tools
like SYS CONFIG to show it,  the uncompressed CONFIG kernel
data area is a nice place, but we do not have to use text.

Instead of K 2040 D 2011-07-31 C 32 F 16 B or the shorter
K 40 11-07-31 0 6 W, the encoded data could be for example
byte:40 dosdateword:2011-07-31 and one byte-of-bits: FAT32
no, 386+ no, upx yes, cross-compile no, borland no, other
reserved features no (actually I think only the first two
feature flags are REALLY interesting at the moment).

This encoding only needs FOUR bytes (1 byte, 1 word and
some bits) to encode a machine readable binary form :-)

We can offer a simple Perl script or similar for those who
want to know which kernel binary they have but who cannot
run SYS /SHOW-ME-THE-VERSION-OF X:SOMEKERNEL because SYS
does not run in their operating system.

I think we should not try to put a version string in the
config area which would be visible in a text editor. All
suggestions shown below use cryptic text anyway and they
are even MEANT to be more machine- than human-readable.

In short, I suggest a small, binary version encoding :-)

Eric

 K2040D2011-07-31C32F16B
 K2041D2011-08-31C16F28W

 C is CPU (16 aka 8086 or 32 AKA 80386)
 F is FAT (16 or 28)
 W and B are compilers (or is Boreland now dead ?).

...

 In typical pre-Y2K-style I'd suggest:
 K4011073106W

 K  -- kernel
 40 -- kernel 2040 (to 2099)
 11 -- year (to 99 so 2099)
 07 -- month (01..12)
 31 -- day (01..29/30/31)
   0 -- 086+ (valid options [0,3] for 086+/386+)
   6 -- FAT12/FAT16 (valid options [6,7] for filesystems that MSDOS 
 6/7
 understand)
 W -- Watcom


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-08-01 Thread e . auer
 License evilness. Better to have the EDR DOS style
 hack for files above 4 GB file size than that.

 Than what that ??? Isn't it the same thing ???

I thought there was some discussion about exfat or whatever the
MS thing for big files on embedded devices is, as that is not FAT
in the DOS sense at all and highly proprietary...

 How about 64 kB?

 Heh ??? DOS can read or write full 64 KiB

I was only talking about cluster sizes, not about the
amount of data that you can read or write in a single
int 21 call. The latter is indeed 65535 bytes, but I
would prefer a multiple of the cluster size or 4096.

Also, a cache can extend reads (read-ahead) or pool
writes to larger chunks. Limits for that depend on
the BIOS, e.g. 1 track or 127 sectors for floppy or
older BIOSes but more when using LBA - at least the
int 13.42 and 43 data block uses a WORD for number
of to be read or written sectors, but I doubt that
any BIOS would be happy to transfer 65535 sectors
(almost 32 MB) in one call ;-)

 I think some hacks even support 128 kB

 I would highly nonrecommend hacks using 128 KiB clusters
 (maybe that's what you meant ?).

Yes, and I agree. Even 64 kB clusters are a bit evil.

Eric



--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-30 Thread dos386
 License evilness. Better to have the EDR DOS style
 hack for files above 4 GB file size than that.

Than what that ??? Isn't it the same thing ???

 How about 64 kB?

Heh ??? DOS can read or write full 64 KiB (DX=0 ??? or is it only
64'000 Byte's ???).

 I think some hacks even support 128 kB

I would highly nonrecommend hacks using 128 KiB clusters
(maybe that's what you meant ?).


-- 
~~~ wow ~~~

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-20 Thread Bernd Blaauw
Op 20-7-2011 3:50, Bart Oldeman schreef:
 It's probably best to make things explicit (unless the goal is a true
 Win32-DOS cross-compile), using DOS16 utilities, by changing the last
 part of mkfiles\watcom.mak to:

 CFLAGS1 = -os-s-wx-bt=dos

 #   *Implicit Rules*
 .obj.exe:
   $(BINPATH)\wlink sys dos f $  lib
 $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q
 .c.obj:
   $(CC) $  @$(CFG)

 But I haven't tested this!

And now the fun part: compiling on Windows x64. No support for running 
16bit programs at all.

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks  Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-20 Thread Bart Oldeman
On 20 July 2011 13:36, Bernd Blaauw bbla...@home.nl wrote:
 And now the fun part: compiling on Windows x64. No support for running
 16bit programs at all.

Sure, for that you *need* a true cross-compilation. Just like on Linux.

The FreeDOS-kernel build's utility programs (patchobj.exe) are also
16-bit DOS if you compile on Windows, so I don't think anybody has
used Windows x64 to compile the kernel yet.

Bart

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks  Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-20 Thread Kenneth J. Davis
On Jul 20, 2011 1:37 PM, Bernd Blaauw bbla...@home.nl wrote:

 Op 20-7-2011 3:50, Bart Oldeman schreef:
  It's probably best to make things explicit (unless the goal is a true
  Win32-DOS cross-compile), using DOS16 utilities, by changing the last
  part of mkfiles\watcom.mak to:
 
  CFLAGS1 = -os-s-wx-bt=dos
 
  #   *Implicit Rules*
  .obj.exe:
$(BINPATH)\wlink sys dos f $  lib
  $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q
  .c.obj:
$(CC) $  @$(CFG)
 
  But I haven't tested this!

 And now the fun part: compiling on Windows x64. No support for running
 16bit programs at all.

 

Thanks, worked like a charm (see below).

It shouldn't be too difficult if someone actually wanted to (I use virtual
machines with DOS and WinXP instead of my native Win7x64 so have no
desire).  The utilities all [except LOAD_ICD.exe] compile and seem to work
properly with a simple wcl name.c after removing (or modifying) the #ifdef
memory model to ensure far data pointers to build win32 versions (assuming
Win32 version of Watcom used).

I tested and committed Bart's suggestion above as it makes the build work
much better and should have minimal impact on anyone else who might be
building -- the big gotcha is that config.std (after copying to config.mak)
needs to be modified to change
..\scripts\echoto $(CFG) $(INCLUDEPATH)
to
ECHO $(CFLAGS1)  $(CFG)

as echoto treats = as a separator character same as space i.e. the -bt=DOS
into -bt DOS.

Jeremy
--
5 Ways to Improve  Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-20 Thread Kenneth J. Davis
And Bart is too quick, he already adjusted the watcom.mak so it just works.  :-)

Thank you,
Jeremy

--
5 Ways to Improve  Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] Kernel 2040 released

2011-07-19 Thread Kenneth J. Davis
On Sat, Jun 25, 2011 at 4:40 PM, Bernd Blaauw bbla...@home.nl wrote:
 Op 25-6-2011 16:06, Kenneth J. Davis schreef:
 Hello all.

...
 Are there any verified/stable working compiled versions available of the
 following?
 * COMMAND (there's an openwatcom CVS/SVN version somewhere?)
I finally managed to built the OW version (had issues with the utility
programs being built as win16 executables, so modified the makefiles
to build them as win32 [native], and have yet to build the installable
command loading program - didn't even know it existed) so you can now
find OW builds of command.com on fdos.org
http://www.fdos.org/kernel/command/FreeCom/command.com
Note: this has not been very well tested, especially given my changes
to the build.

 * SHARE (thought there were 2 versions or so?)
the most up to date version is with the kernel (no recent changes,
just latest source floating around put into svn)
(as soon as I upload a build, latest will also be found at
http://www.fdos.org/kernel/share/
)
...

Jeremy

--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Re: [Freedos-kernel] [Freedos-user] Kernel 2040 16-bit

2011-07-14 Thread Bernd Blaauw
Op 14-7-2011 5:09, Marcos Favero Florence de Barros schreef:
  I'm now using the 32-bit 2040 kernel, because none of these
 errors has ever appeared under the previous 32-bit kernels, and
 I'm hoping they will not appear under the new one either
 [fingers crossed].

  Any advice is welcome.

Thanks for reporting the issues you're experiencing with the FAT16 
kernels, multiple versions. Do you have a way of verifying 
file/filesystem/disk integrity outside of FreeDOS?

FreeDOS has no 32bit kernels, there's a FreeDOS32 project somewhere but 
that hasn't gotten very far yet. The 16 and 32 for FreeDOS kernels 
purely indicate what they support:
* either FAT12 and FAT16 filesystems
* or FAT12 and FAT16, but also FAT32 filesystems
(or rather partitions using these filesystems)

It's usually fine to run FAT32-enabled kernels. However that's no reason 
to have FAT16-only kernels contain certain bugs.

I've not tried FAT16 kernel and CHKDSK as you have. I've not tried using 
CHKDSK either on FAT32 drives, doubt it supports it.

Latest FreeDOS CHKDSK is 0.92
( http://users.telenet.be/imre/FreeDOS/ckdsk092.zip ).

maybe I'll find some opportunity to try and see if I can reproduce your 
issues (CHKDSK on FAT16 kernels reporting errors with files, while on 
FAT32 kernels no such issues).

Bernd

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
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   >