[Freedos-kernel] Will retire the freedos-kernel email list
Hi freedos-kernel developers: I think everyone on this email list is also on freedos-devel, so you probably have seen the discussion there about the different communication channels for FreeDOS. We obviously use the freedos-devel and freedos-user email lists. But the freedos-kernel list is not used very much. Looking at the archive, this hasn't seen more than a few emails per *year* in the last several years. Because of the light traffic, let's consolidate our developer discussions! The freedos-kernel email list will be closed this week. Instead, please use the freedos-devel email list to discuss any FreeDOS kernel development topics. Thanks! Jim ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel bug fixes need backport from dosemu2 fdpp
Hi kernel readers :-) Looking at the development of dosemu2, I find that the many changes there have moved away from freedos SO far that backporting became hard, without me ever noticing. There was the announcement of fdpp in 9/2018, one year after development started, which morphs the kernel into a Linux lib for dosemu2: https://github.com/stsp/fdpp (excuse the extreme simplification of my description) But there apparently never was a discussion about the improvements in fdpp here, very few people at dosemu2 were in the mood to backport things, possibly inspired by the lack of bugzilla readers here and the very few original FreeDOS kernel people who took the effort to cherry pick patches apparently have not shared their capacity bottlenecks here. E.g. Andrew Bird has sent https://github.com/PerditionC/fdkernel and https://github.com/FDOS/kernel some patches and Jeremy has started some cherry picking himself? So what have we missed during all that time, 2.5 years? - fdpp solves obscure MCB / UMB related problems which made FreeDOS unable to use UMB at a000:0 including stack overflows and reboot troubles? - dosemu2 needs some FreeDOS-only "boot work-around" if hdiskboot -1, hdisks >0 and hdisk 0 is not bootable...? (probably to help us to boot from D: drive or similar) - some boot changes (not sure whether dosemu2 specific) on https://github.com/dosemu2/fdpp/commit/10507295bdea1dee3109ed115dc0dc38f98d2565#commitcomment-35887845 - FreedOS 1.2 and older has no int 2f.121f, just 2f.1217, but that might have been fixed back in FreeDOS recently? - many games work better with fdpp than with FreeDOS, says https://github.com/dosemu2/fdpp/releases/tag/beta-9 (Test Drive 2, Tetris Classic, Elite Frontier, Empire Soccer, Virtual Chess, Alone in the Dark, Alpha Waves) - however, for example int 21.71a6 in fdpp may only be used in conjunction with dosemu2, according to the same site?? - fdpp fixes something related to Volkov Commander: https://github.com/dosemu2/fdpp/releases/tag/rc-1 This also mentions 2 of the above games "resize PSP to 0 and then terminate it" which apparently MS DOS accepts - probably a lot more Note that fdpp development seems much faster than freedos kernel devel in part because dosemu2 disciples love their toolchain, but dispise the tools available for real DOS? Please, it is nice to have a few very active experts in a few DOS related projects, but why do I have to feel like an eavesdropper when figuring out which bugs get fixed and which features get added? It looks a lot like many of those probable improvements never made it to FreeDOS kernel sys because people fail to talk about them across projects. So please talk about those things on freedos-kernel! If you know about a bug in FreeDOS, talk about it. If you know about a fix in fdpp and lack the time to backport it to FreeDOS, at least mention it here. If you know about compatibility issues, do not just drop from this list and install fdpp or MS DOS. Talk about it! For those who have not experienced dosemu2 yet: Note that it has less magic guest drivers, so you WILL have to LOAD them in your config sys. Read their pre-installed config. Dosemu2 is a QUICKLY moving target and following their github feels like spying on a private chat, but most of the time the improvements outnumber the regressions and it work much better than the stalled classic dosemu :-) I hope there are still some people HERE who are keen on kernel improvements. Maybe we can wake up and at least find out how FreeDOS 1.3 (and up) kernels COULD improve. Thank you! Regards, Eric PS: Excuse the cross-post CC to freedos-devel. It is for the case that there are not enough kernel readers left. _______ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS
Hi Jeremy, > Hi perditi...@gmail.com, > >> Thank you. I will try to get to this by the weekend. > > Thanks! :-) > > Regarding the "Space between value and currency symbol" bit errors: > I checked my statement about a space between value and the € sign. > Various Internet sources, e.g., > <https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>, > <http://buerojob-blog.de/2012/11/19/schreibweise-euro/>, > <https://publications.europa.eu/code/de/de-370303.htm#position>, tell, > that there should be a space between. > > *** From publications.europa.eu: *** > Das Symbol € steht hinter dem Betrag und ist von diesem durch einen > Zwischenraum getrennt: > > ein Betrag von 30 € > > Anmerkung: > Im Englischen, Irischen, Maltesischen und im Niederländischen steht der > Code vor dem Betrag: > > an amount of €30 (ohne Zwischenraum) > *** > > "the amount is followed by a hard space and the euro sign" (except > English, Dutch, Irish, and Maltese) > > I've attached an updated diff file for German. Did my changes make it to the repo meanwhile? I don't see at <https://github.com/PerditionC/fdkernel/blob/master/kernel/country.asm>, but maybe it's the wrong URL? Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS
Hi perditi...@gmail.com, > Thank you. I will try to get to this by the weekend. Thanks! :-) Regarding the "Space between value and currency symbol" bit errors: I checked my statement about a space between value and the € sign. Various Internet sources, e.g., <https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>, <http://buerojob-blog.de/2012/11/19/schreibweise-euro/>, <https://publications.europa.eu/code/de/de-370303.htm#position>, tell, that there should be a space between. *** From publications.europa.eu: *** Das Symbol € steht hinter dem Betrag und ist von diesem durch einen Zwischenraum getrennt: ein Betrag von 30 € Anmerkung: Im Englischen, Irischen, Maltesischen und im Niederländischen steht der Code vor dem Betrag: an amount of €30 (ohne Zwischenraum) *** "the amount is followed by a hard space and the euro sign" (except English, Dutch, Irish, and Maltese) I've attached an updated diff file for German. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ --- COUNTRY-orig.ASMSun Jun 26 21:05:00 2011 +++ COUNTRY.ASM Fri Jan 24 15:32:37 2020 @@ -192,11 +192,11 @@ __pl_858 dw 12, 48,858,0,0 dd _pl_858 __de_858 dw 12, 49,858,0,0 dd _de_858 __de_850 dw 12, 49,850,0,0 dd _de_850 -__de_437 dw 12, 49,858,0,0 +__de_437 dw 12, 49,437,0,0 dd _de_437 __ar_858 dw 12, 54,858,0,0 dd _ar_858 __ar_850 dw 12, 54,850,0,0 dd _ar_850 @@ -3088,13 +3088,13 @@ no_865 cnf 47,865,DMY,"K","r", 0,0,0," no_850 cnf 47,850,DMY,"K","r", 0,0,0,".",",",".",":",2,2,_24; Norway no_858 cnf 47,858,DMY,"K","r", 0,0,0,".",",",".",":",2,2,_24; Norway pl_852 cnf 48,852,YMD,"Z",88h, 0,0,0,".",",","-",":",0,2,_24; Poland Michal pl_850 cnf 48,850,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland pl_858 cnf 48,858,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland -de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany Tom -de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",".",1,2,_24; Germany -de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany +de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany Tom +de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",":",3,2,_24; Germany +de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany ar_850 cnf 54,850,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina ar_858 cnf 54,858,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina ar_437 cnf 54,437,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina br_850 cnf 55,850,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil br_858 cnf 55,858,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS
Thank you. I will try to get to this by the weekend. Jeremy On Thu, Jan 23, 2020, 3:11 PM Robert Riebisch wrote: > Hi > > for Germany COUNTRY.SYS reports "." (dot) for the time separator, when > it should be ":" (colon). > > I noticed the error in FD 1.3 RC2 and FD 1.2, when using: > > !COUNTRY=049,,C:\FDOS\BIN\COUNTRY.SYS > > in FDCONFIG.SYS. > > I didn't test FD 1.1. > > FD 1.0 behaves differently: Although it reports 001 for the current > country code (BX on return from AX=3800h, int21h), the time separator is > correct. > > I tracked the error down to: > > Bad data: > de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany > Tom > de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",".",1,2,_24; Germany > de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany > > Good data: > de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany > Tom > de_858 cnf 49,858,DMY,0D5h, 0,0,0,0,".",",",".",":",1,2,_24; Germany > de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany > > In HELP -> "country" (not "country.sys") it is stated correctly as ":". > > If you don't patch 850 to 858 COUNTRY.SYS doesn't load with: > > !COUNTRY=049,858,C:\FDOS\BIN\COUNTRY.SYS > > because 49 858 are no valid combination. > > This is how I patched current COUNTRY.SYS to make it work: > 3984: 2E 3A > 3995: 52 5A > 39A4: 2E 3A > 39C4: 2E 3A > > > And I think, for Austria the time separator should also be ":". (see > lines 3075-3077 of COUNTRY.ASM) > > *** > > I just found a second data error. > If you use: > > !COUNTRY=049,437,C:\FDOS\BIN\COUNTRY.SYS > > loading COUNTRY.SYS aborts with error "could not find country info for > country ID 49". > > I fixed this by patching: > 041B: 5A B5 > 041C: 03 01 > > *** > > A third data error is regarding the "Space between value and currency > symbol" bit. It is reported as NO for codepage 437 and codepage 850. It > should be YES, because the symbol is "EUR" then. > For codepage 858 symbol is "€", so NO is correct here. > > I fixed this by patching: > 3986: 01 03 > 39C6: 01 03 > > *** > > Fourth error (?) > German MS-DOS 6.22 and Windows XP SP3 report ";" as the data-list > separator. > > I didn't find, where this is defined. So no patch from me. > > > As this mail and patch list got (and took) longer than expected, I'm > attaching a diff file. > > Maybe someone with access to the kernel sources can integrate this fix. > Thanks in advance! > > *** > > By the way: > To study the error and practice DOS programming I wrote a little tool to > show country information as reported by AX=3800h/INT 21h in some > "obscure" Pascal dialect from Japan called Cabezon. > The EXE file is currently available at > <https://www.bttr-software.de/tmp/COUNTRY.ZIP>. > I can provide source code too, if anyone is interested, but may be > currently of little use, because it depends on my expanded run-time > library for Cabezon, which is still pre-beta code. > > Output will be similar to: > # > Country code : 49 > Date format: 0001h (dd mm yy) > Time format: 01h (Bit 0: 24-hour clock = YES) > Thousands separator: . > Decimal separator : , > Date separator : . > Time separator : : > Data-list separator: , > Currency symbol : EUR > Currency format: 01h (Bit 0: Currency symbol follows value = YES > Bit 1: Space between value and currency symbol > = NO > Bit 2: Currency symbol replaces decimal point > = NO) > Currency precision : 2 > Case map routine : 00D8:11EF > # > > Cheers, > Robert > -- > +++ BTTR Software +++ > Home page: https://www.bttr-software.de/ > DOS ain't dead: https://www.bttr-software.de/forum/ > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Codepage and time separator data errors in COUNTRY.SYS
uot;,".",":",2,2,_24; Norway pl_852 cnf 48,852,YMD,"Z",88h, 0,0,0,".",",","-",":",0,2,_24; Poland Michal pl_850 cnf 48,850,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland pl_858 cnf 48,858,YMD,"P","L","N",0,0,".",",","-",":",0,2,_24; Poland -de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany Tom -de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",".",1,2,_24; Germany -de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany +de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany Tom +de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",":",1,2,_24; Germany +de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",":",3,2,_24; Germany ar_850 cnf 54,850,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina ar_858 cnf 54,858,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina ar_437 cnf 54,437,DMY,"$",0,0,0,0,".",",","/",".",0,2,_24; Argentina br_850 cnf 55,850,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil br_858 cnf 55,858,DMY,"C","r","$",0,0,".",",","/",":",2,2,_24; Brazil ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS
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
> the FreeDOS kernel is seriously slower then MSDOS when doing > larger copy/xcopy operations. > the cause: the disk I/O code avoids transfers that cross a 64K > boundary, and splits these transfers into 3 (smaller) transfers. > this was needed for floppy controllers in the 1980's, but is certainly > not necessary for harddisks after the IBM XT. > just skip > /* avoid overflowing 64K DMA boundary */ > count = DMA_max_transfer(buffer, totaltodo); > for harddisks, and everything should be *much* faster (at least on > rotating media in a non-emulated machine) investigating in this a bit more, the 64K boundary was/is a problem with ISA DMA, used only for floppies (and sometimes serial/parallel ports), but is no problem for UDMA. skipping this test for drives with 0x80 set should be save, and result in a significant speedup of large disk transfers. Tom ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Checking NUL directory/drive is broken in 2042
if exist K:\NUL echo K: is present is broken in kernel 2042 the bug is caused by a change in TrueName(), where code was changed from cdsEntry = get_cds(result); if (cdsEntry == NULL) return DE_PATHNOTFND; to dhp = IsDevice(src); cdsEntry = get_cds(result); if (cdsEntry == NULL) { /* workaround for a device prefixed with invalid drive (e.g. "@:NUL") */ /* (MS-DOS always return drive P: for invalid drive. Why P:?) */ if (dhp) { result = default_drive; cdsEntry = get_cds(result); if (cdsEntry == NULL) return DE_PATHNOTFND; } else return DE_PATHNOTFND; } now truename("e:\NUL") returns not 'path not found', but 'isDevice' probably by fixing one bug, another bug was introduced. Unfortunately I don't know what bug the changed is supposed to fix... who introduced this change and why? comments? Tom _______ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] announce: fdpp, a 64bit DOS in C++
Hi all DOS fans! After a year of development, I am glad to announce the new 64bit DOS. But as we know, all new is well-forgotten old, so this actually is a freedos kernel port to 64 bits. Some of you have probably already heard about this project, as it was pre-announced on fosdem-18, but at that time it could barely display the copyright msg. So I bet no one believed this is even possible. :) And here we go: https://github.com/stsp/fdpp The description of the project and the usage instructions are in the readme: https://github.com/stsp/fdpp/blob/master/README.md The current status is on the releases page: https://github.com/stsp/fdpp/releases This is going to be the primary DOS for dosemu2, but I hope it will be useful for other projects too. For example the freedos-32 project: http://freedos-32.sourceforge.net/ can likely get a very good use of it. I don't know if the main freedos project can be interested in a 64bit port of it, but I think there were some talks in the past, including Pat V himself, which I unfortunately can't google out now. Let's see what people think. The next target is going to be a 64bit command.com. While it is in some distant future, the 32bit command.com is already here: https://github.com/stsp/comcom32 So lets move on to 64bits! Happy DOSing. :) ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] boot sector woes
this patch is a suggestion for the bootsector to boot on older (like my XT) machines where the drive requires a few retries before loading a sector. The resulting binary might be too big actually. In this case I would like a bit of help fitting it in there. yours, - Mdasoh Kyaeppd --- boot.ori/boot.asm 2017-01-30 02:08:55.835437500 -0700 +++ boot/boot.asm 2017-01-31 13:06:37.742679500 -0700 @@ -423,7 +423,7 @@ ; setup LBA disk block mov LBA_SECTOR_32,bx; bx is 0 if extended 13h mode supported mov LBA_SECTOR_48,bx - + mov si,1 mov ah,042h jmp shortdo_int13_read @@ -472,12 +472,20 @@ inc cx ; make sector 1-based (1-63) les bx,[LBA_OFF] + mov si,5 +do_chs_read: mov ax, 0x0201 do_int13_read: mov dl, [drive] -int 0x13 -jc boot_error ; exit on error +int 0x13 ; read data from disk + jnc did_int13_read + xor ax,ax + int 0x13 + dec si +jz boot_error ; exit on error + jmp do_chs_read ; prod it a few times +did_int13_read: mov ax, word [bsBytesPerSec] pushdi -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Checking NUL directory/drive is broken in 2042
Hi, > Was using FreeDOS 1.1 2040 kernel? previously and could check for > drive or directory existence with the NUL device: > If exist c:\nul echo C: exists > If exist c:\mydir\nul echo C:\mydir exists > This behavior is broken with 2042, no longer being able to identify if a > drive/dir exists anymore. I tried to reproduce this here, and I think that it behaves exactly as it should. can you be more specific how it fails ? Tom -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Checking NUL directory/drive is broken in 2042
Was using FreeDOS 1.1 2040 kernel? previously and could check for drive or directory existence with the NUL device: If exist c:\nul echo C: existsIf exist c:\mydir\nul echo C:\mydir exists This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore. Can the devs please add the previous behaviour with NUL drive/directory identification? Thank you -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] How do I compile just the bootsector and kernel?
See the FreeDOS Spec [0]. OpenWatcom C/C++ (1.9?) (and by extension WASM/JWASM? for ASM??) and NASM (no version either though many are based on 0.98.x) are the reference compilers/assemblers/linker. I was able to able to compile a recent kernel version with the non-reference compiler Borland C/C++ 4.5.2 (the last Borland C/C++ compiler to support DOS compiling executables). I had to make minor changes to the Makefiles to successfully compile the kernel. See the mailing list archives for my notes. [0] http://wiki.freedos.org/wiki/index.php/FreeDOS_Spec#Programming_tools On Wed, Jan 4, 2017 at 11:17 PM, Mateusz Viste <mate...@nospam.viste.fr> wrote: > On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote: >> Of all the many files in the FreeDOS sourcecode, which files will I need >> if I just want to compile the bootsector and the kernel? > > You'll need the source files present in the "KERNEL" package, > unsurprisingly. You can also fetch these sources on-line here: > https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/ > >> And also, what is the recommended free compiler (I'm >> not about to spend money to buy one) for use in compiling the FreeDOS >> bootsector and kernel? > > The FreeDOS kernel can supposedly be compiled with the following > compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C. > >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both > are free (no cost). Using Turbo C requires to change a few lines of > comments though, as I wrote here the 26th November of last year (still > not fixed on SVN). > > Mateusz > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?
>>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?
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?
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
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
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
Method 1 is the traditional DOS way of installing software. Maybe some advanced usage of JOIN & SUBST is what you are looking for? Another alternative (though slightly messy) would be to combine Methods 1 & 4. By that, I mean, leave the *.bats in C:\DOS. The *.bats will temporarily create a new Environment & PATH extended as the application expects and then remove the adjustment. This will slow down many types of computing, as HPA mentioned, SW builds come to mind -L. On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste <mate...@nospam.viste.fr> wrote: > On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote: >> But why the batch file in the first place? It truly makes no sense: it >> pollutes the namespace equally, and can just cause problems (e.g. in the >> case of more than 9 arguments.) Not to mention slowing down a make. > > Here's the thing: I, as a user, store lots of useful software on my PC. > Many of these programs are so useful that I like to have them available > immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG, > QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on. > > To achieve this, I know of four ways. Each comes with some limitations. > > Method 1: Store every program in its own directory, and add each > directory to the %PATH%. Problem: obviously the environment will get very > bloated, very fast. Besides, some programs come with add-on tools that I > do not want to be available from within my path. > > Method 2: Trim out the programs from everything besides a single exe, and > put them all in a single directory declared in my %PATH%. But this poses > two problems that I cannot live with: first, not every program can be > trimmed out to a single executable file (data files, config files, etc), > and second - almost all programs come with their respective README files > and other valuable documentation that I really want to keep within the > vicinity of the executable (ie. in the same directory). > > Method 3: Store each tool in its own directory, and place a COPY of its > executable inside a directory in the %PATH%. Well, this is just messy - > upgrading the program needs to think about replacing the executable each > time in both places, and it's simply a waste of disk space. > > Method 4: Keep each program in its own directory with all its original > files, and only store *.bat "links" in a single directory somewhere in > the PATH. This mitigates the troubles of methods 1 and 2, at the cost, > unfortunately, of *.bat's own limitations (max 9 args and '=' processing > weirdness). > > The method 4 is what I started doing back in the nineties, and as of > today I still didn't find a better (or let's say, less worse) way. That's > a lifetime project it would seem. > > The method 4 is also something that I implemented last year inside FDNPKG > (the FreeDOS package manager), but since I discovered recently how oddly > the '=' character is processed in %1-like arguments (there's a separate > thread about that on freedos-devel), I will have to figure out some > improved method... first thought pointed to computing some COM loader > relying on INT21,4Bh but that's far less trivial than the current batch > method, and hobby time is scarce. > > Mateusz > > > ------ > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel ------ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time
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
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
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
On 11/24/16 00:59, Mateusz Viste wrote: > > Hi, > > Your problem is related to the fact that your "nasm" command doesn't call > nasm.exe directly. Instead, it calls a batch file named nasm.bat which > has been placed in your %PATH% by the FDNPKG installer. This nasm.bat > file is pretty straight-forward: > > @ECHO OFF > C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9 > > While in theory such trick should work (and it does work with most other > utilities out there), somehow it doesn't play out right with nasm. Simply > edit your CONFIG.BAT to set its XNASM variable to the full path to your > copy of nasm.exe, and you're done. Enjoy! > And pray tell, why? -hpa ------ ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] ke2042 doesn't compile with Turbo C 2.01
Hello, I noticed that the ke2042 svn tag doesn't compile using Turbo C 2.01. The reason is quite trivial: config.c: Error config.c 407: Expression syntax in function PreConfig2 Indeed, config.c contains two commented line at 407 and 408: // if (UmbState == 2) //umb_init(); I have no idea why these lines are commented, but the fact is that they are commented using non-C89 comments. Simply replacing them with ANSI C /* */ comments solves the issue. It's nothing important, an annoyance more than anything, but perhaps it would be worth "fixing" it in svn to avoid frustrating other users that might try compiling the kernel with Turbo C or something else that doesn't know about '//' comments... Mateusz -- _______ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] ke2042: nasm fails to assemble files during build time
Hello group, I am trying to compile the FreeDOS kernel from svn's tag ke2042, but it appears that build.bat fails to assemble several files. For instance: nasm -DTC2 -DWITHFAT32 -i../hdr/ -DXCPU=86 -f obj floppy.asm nasm: error: more than one input file specified nasm: error: more than one input file specified Not sure why this happens, the command looks sane. If I redo the nasm command by hand, I get the same message. Trying to compile on DOSEMU, using nasm v2.12.02. Have I missed something obvious? Any clue? regards, Mateusz -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
On August 26, 2016 12:26:52 AM PDT, Eric Auer <e.a...@jpberlin.de> wrote: > >Hi HPA! The boot sector takes a BIOS drive number of the >to-be-booted drive from the MBR, which can take it from >the BIOS. There also are patches to take the MBR item by >pointer from the MBR, but those are not used by default. > >So I guess the kernel could take the drive number from a >boot sector, which at the moment is easy because the boot >sector stores the value from the MBR in the drive byte of >the boot sector loaded into RAM, which is a predictable >location in general. Might be fun for booting from 0x81. > >>> support for EXT3 in the kernel would indeed be large/complex. > >Would not do that, but would boot DOS by MEMDISK and load a >full EXT3 driver from there later :-) Same for ISO9660, but >there "read files from ISO root dir" might be quite small, >so boot without MEMDISK might be interesting as well... > >>> Regarding the idea to have the kernel "natively boot from a >>> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well, >>> on modern computers it should not be a problem to "hog" the >>> drive letter of the A: floppy drive - you probably have at >>> most ONE real floppy next to that ramdisk anyway and letter >>> B: is still free :-) So in that sense, MEMDISK is ok for me. > >Exactly :-) > >> So this is a horribly stale discussion, but it seems that all that is >> needed is the ability to hide somewhere a preferred drive letter for >the >> FreeDOS kernel to pick up and use. It is trivial to add support for >> passing such information along in MEMDISK. >> >> -hpa Hi! Memdisk already supports being a disk number other than 0x00 or 0x80, and the DL register will reflect that. However, I was thinking of provided a more explicit hint, so that scripts can reply on the ramdisk being, say, R: -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. ---------- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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
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?
Hi again, I have tried to investigate this problem further by comparing 3 files: > https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32lb.asm > https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32.asm > https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot.asm > Left-bound text is about LBA or FAT1x code, while > indented text is about FAT32 CHS in this email. Some items are at different places but hopefully (?) do not get overwritten: > boot32lb: fat_secshift [selfmodifying] > fat_sector@+0x44 fat_start@+0x48 data_start@+0x4c > boot32: fat_secshift@+0x68, CHS boot sector > fat_sector@+0x48 fat_start@+0x5e data_start@+0x62 fat_secmask@+0x66 The initial calculations seem to achieve the same in different ways: > fat_sector = dd 0 > done much later in CHS case, but early enough as far as I can tell > fat_start = data_start = dd nHidden + word bsResSectors > di:si and fat_start okay, check data_start > data_start += dd (byte followed by 2 dw 0?) [bsFATs] *signed dd [xsectPerFat] > ax = db bsFATs cbw > di += ax * dw xsectPerFat HIGH, ignoring overflows > data_start = dx:ax = di:si + (ax * dw xsectPerFat LOW), 16x16=32 bit However, the "secshift" calculations are rather different here... Note that the FAT12 / FAT16 boot sector reads the entire FAT into RAM first, so THAT does not have to know which sector of the FAT contains info about which cluster. > fat_secshift = 7 for 128 FAT items per 512 byte sector > ax = 512 > while ax not bsBytesPerSec > ax <<= 1 > fat_secshift++ > endwhile > cx = fat_secmask = (dw bsBytesPerSec >> 2) - 1 > cx++, now (dw bsBytesPerSec >> 2) which is FAT items per sector > ax expected to be 0 after movsw > do > ax++ > cx >>= 1 > while cx not 1 > fat_secshift = AL, low byte of ax > fat_sector LOW = fat_sector HIGH = cx-- (is 0 now) Mixed other differences which might be relevant: > only boot32lb uses 386+ code and calls print which modifies AX BX SI > convert_cluster: cmp eax,fff fff8 jnc EOF > convert_cluster: cmp dx,fff jnz okay cmp ax,fff8 jnc EOF? > > next_cluster uses shr dx,1 rcr ax,1 in a loop to shr DX:AX by fat_secshift > ... ((di and secmask) << 2) + fat_start ... And from the comparison FAT32 CHS to FAT12 / FAT16 boot code: > note: FAT12 / FAT16 boot sector readDisk changes CX, ADD COMMENT HERE! > note: FAT1x boot does not retry in readDisk, plus used extra buffers > "inc ah or cl,ah" versus "or cl,ah inc cx" for 1-based sector The next_cluster, convert_cluster and readDisk calls all juggle with plenty of registers in strictly defined ways, I might have overlooked some unintended register changes somewhere. Cheers, Eric ---------- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FAT32 CHS boot sector problems since we introduced FAT32 LBA support?
As SYS is part of the kernel sources, maybe somebody on the kernel mailing list has an idea for me...? Thanks! :-) Hi everybody, apparently the same SYS update which introduced FAT32 LBA support also broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always fails, but his BIOS lacks LBA support. After installing MBR-based disk drivers to add LBA support and support for 4 instead of 2 harddisks, FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector. I was busy trying to find out what broke and when, but cannot find it. Maybe you can help me out here... :-) - old SYS sets drive number to -1 but it gets overwritten on boot anyway - new SYS sets drive number to 0x80 but it gets overwritten on boot, too - new SYS uses signed byte to word comparison in cluster code (fff fff8 versus fff -8) but source code is unchanged, maybe a NASM auto tune?) - r751 moves the load location far pointer to inside the code, while it was at +5a in the variable area before. Not sure why that was changed? Apparently both good and bad are AFTER this diff, so that should be safe? The r321 to r343 patch makes CHS calculations small but obscure: > https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/boot32.asm?diff=321 This leaves the main "calculate parameters at runtime, instead of using SYS to hardcode them" patch as suspicious change. We have this patch to keep FAT32 partitions bootable even when you resize them with 3rd party tools. Of course the patch adds yet more obscure code to the boot sect: > https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/boot32.asm?diff=382 Note that this r382 to r652 patch also drops the last call of "print", so we could drop that function to gain some space for making the code a bit less unreadable by "un-optimizing" some bits. Apparently somebody simply forgot to drop print after dropping the last place using it ;-) Not sure why, but the patch also moves around the offsets of 4 variables by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which makes the before / after the patch situation a bit harder to "diff" now. The basic function of the patch is to add some code after the setup of stack, segments and registers and relocation to 1FE0:, but before the first call to "find sector for cluster" and "read sector from disk" after which the root directory is scanned and, when a kernel is found, the kernel file is loaded by cluster chain: dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e] DI = DI + (byte fats [+10] * word sec per fat HIGH [+26]) [+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI word sec mask [+66] = CX ... = (AX >> 2) - 1 AX = 1 ... do CX >>= 1 AX++ while CX not 1 byte sec shift [+68] = AL (the above is my attempt to summarize what the code actually does, see the source code for the description of what it wants to do - as said, I fail to see a problem here, but the symptom still is a failed boot!) Thanks for helping out! Cheers, Eric PS: Of course the boot sector stores DL to byte drive [+40] before it starts juggling with DX:AX, so that value seems to be safe as well. ---------- _______ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] KERNEL 2042 and its attachments (AKA SYS)
I downloaded and installed the new kernel, and looked a bit and tested a bit. There is a version history file included and it lists a few detail improvements. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt <- outdated Are there some major applications that previously didn't work but now should work (Watcom debugger ? DGJPP ? ...) ? shots: http://www.xaver.me/drdoswiki/index.php?n=Main.Gallery#toc18 - (C) still says "2012" There is a "SYS.COM" 3.6 included recompiled with new date but not consistent with "SYS.COM" 3.7 or 3.8 from here: http://www.fdos.org/kernel/sys ... what's the point of those 2 branches of SYS? The source code looks inconsistent (2 branches developed separately ?), some files differ by whitespace only. Unfortunately there doesn't seem to be any history file for "SYS.COM". What is the preferable version of SYS ? -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2042 release
> Freedos-kernel] Kernel 2042 release Thanks :-) (I'll test) -- Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] UMB question
Hi kernel experts, I vaguely remember that there is a pending patch where the kernel is using a memcopy-style function residing in memory that already got "freed" at that moment during boot, so I guess the gurus are awake at the moment... QUESTION: Would it be possible to improve UMB handling such that the kernel supports SEVERAL providers of UMB at the same time, for example UMBPCI for hardware-UMB and in addition EMM386 to "map" a few more UMB to areas where normally a memory gap would be, such as the "monochrome video memory" area? Might be interesting to have even more UMB flexibility :-) Regards, Eric -- Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BUG: problems with INSTALL=, reported by Bret Johnson
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
On May 12, 2016 2:05 PM, "Tom Ehlert" <t...@drivesnapshot.de> wrote: > > > INTERLINK issue has not been resolved, and still requires > > option to load low. > > Why not? > > crashing the kernel when a driver calls DosAlloc() is not so smart an > idea. disabling dosalloc for drivers is possibly suboptimal, but at least > prevents a crashing kernel. > > of course a better fix would be nice but I won't hold my breath. > > IMO planning a 'release' with a known problem AND fix is stupid. > > Tom > There is not a fix. While your suggestion should work, it doesn't for me. The flag variable to fast fail had the wrong value in my test kernel. Something is wrong and it will take me time to track down the issue or fix properly. In the meantime, there are important changes that I want to ensure make it into next distribution released. Jeremy -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2042 release
Kernel 2042 is tagged. Source and 8086+ builds are staged on SF (admins can view now, everyone else in a few days). 386+ builds are not yet available. Builds with FAT12/16 only and FAT12/16/32, source archive, and fdpkg files are also available http://www.fdos.org/kernel/release/LATEST/ and will include 386+ versions once I build them. This release includes mostly bug fixes, please see docs/history file or revision control logs for details. I have not yet committed all the changes/patches/pull requests in my queue, but I did not want to delay the release any longer to ensure it makes it into FreeDOS 1.2 release as it fixes several important issues. INTERLINK issue has not been resolved, and still requires option to load low. Please note that although a version of sys is still in the sources and included in the releases, it is not the latest version; a future change will remove sys from the kernel sources and move it into its own package; possibly the same for share and country so they can be updated separately from the kernel. Jeremy -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] INTERLINK
Hi, https://sourceforge.net/p/freedos/bugs/147/ located the bug in freedos kernel. this the first driver *at all* that uses dos_alloc (int 21 ah=48) INTERLNK.EXE does (pseudocode) is running at 426:2951 if (dos_version < 5)// try load high to UMB goto continue_load; 426:2965 seg = dos_alloc(driversize);// driversize ~= 2f0 para JC continue_load // // move driver up to UMB // relocate interrupt vectors, driver list, ... continue_load: unfortunately dos_alloc(driversize) succeeds, but returns 425 - the very segment the driver is currently running at. OUCH! MCB looks like 2D3:0 'M' --> 4d3:0 'Z' 2 problems: the space for the driver is not allocated while the driver is loaded INTERLNK does tries to get some UMB memory, but has not called INT21 AH=58. why would MSDOS return MCB memory? while this is a real bug, I'm not certain this should be fixed as rethinking the driver load and memory allocation at init time is far from trivial. Tom am 5. Februar 2016 um 18:05 schrieben Sie: > Have tried with latest* kernel, there is a fixed bug in int 25/26 that may > effect it. > You may want to try RIFS as well, it has source, but I don't > recall if it used serial, parallel, or either but did work with > FreeDOS kernel as well as it did with PCDOS. > * I'm releasing updated version this weekend if time permits after I commit > changes from git to svn. > On Feb 5, 2016 11:04 AM, "Tom Ehlert" <t...@drivesnapshot.de> wrote: > Bret, > >> Eric/Tom: > >> I used to use INTERxxx a lot many years ago using the special >> parallel cables designed for that purpose (I think I still have a >> couple of those cables in my "spare cable box"). Parallel is MUCH >> faster than serial (null modem) cables. > I also used it *A LOT*. in times when there were no network cards a > commodity. (the times they are a changing ...) > >> I believe Eric is correct when he says INTERxxx is sector-based >> rather than file-based as Tom states. I do know that the client >> (INTERLNK) must be capable of "understanding" the file system of the >> server (INTERSVR). For example, if the client is MS-DOS 6.2 (which >> doesn't understand FAT32) and the server is MS-DOS 7.x (which does >> understand FAT32) and you're trying to access a FAT32 disk on the >> server, it doesn't work. I know this for sure because I've tried >> it. If INTERxxx was file-based, it wouldn't matter which version of >> FAT was on either computer (and could even work on non-FAT drives >> the server had mounted, like CD's and network drives). > > you are right, my memory was plain wrong on this. > > and - while debugging the crashing problem - I also saw that it > installs itself as handler for INT 25/26 'DOS DISK READ/WRITE' > > Tom > > > > -- > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 > ___ > Freedos-user mailing list > freedos-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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
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
> 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 6:35 GMT+01:00 H. Peter Anvin <h...@zytor.com>: > I wanted to ask: to what degree does FreeDOS implement the redirector > interface? Are there any known incompatibilities? I didn't find any while implementing my own redirector. > The reason I am asking is that I started a project that I was never able > to find time finish (and don't expect to have any more for the > forseeable future) to write a 9pfs redirector for DOS, which would let > DOS access a filesystem (as opposed to a disk image) using Qemu. ...and, therefore, using KVM. Great! :) > If there is interest, the code so far is at: > > http://git.zytor.com/dos/virtio9p.git/ > > It contains a lot of infrastructure work done (tested under MS-DOS 6.22) > but not much of the actual file operations. > > This also requires that any protected mode memory manager (EMM386 etc) > implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API. I will look into that, thank you. Eduardo. -- ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
On 08/14/15 15:00, Till wrote: > > Quoting João Jerónimo <j_j_b_o_de...@yahoo.com>: > >> Wouldn't it be better to use a redirector? This can be done with a TSR. >> >> João Jerónimo >> > > > A TSR redirector would be great for assigning an EXT3 drive to a drive > letter for standard I/O operations. However a kernel driver would > allow freeDOS to boot and run from an EXT3 journaling partition, I can > only imagine that the benefits from this would be huge. > You can do this anyway by using an auxiliary bootloader, e.g. Syslinux or Grub. The idea is that you load the basic DOS into a ramdisk from the bootloader (e.g. via memdisk) and then you can load your TSR. What *might* be useful could be a way to have some way for the FreeDOS kernel to natively boot from a ramdisk in high memory, or at least have a way to not have the ramdisk become drive A or C. -hpa ---------- ___________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FreeDOS and redirectors
I wanted to ask: to what degree does FreeDOS implement the redirector interface? Are there any known incompatibilities? The reason I am asking is that I started a project that I was never able to find time finish (and don't expect to have any more for the forseeable future) to write a 9pfs redirector for DOS, which would let DOS access a filesystem (as opposed to a disk image) using Qemu. If there is interest, the code so far is at: http://git.zytor.com/dos/virtio9p.git/ It contains a lot of infrastructure work done (tested under MS-DOS 6.22) but not much of the actual file operations. This also requires that any protected mode memory manager (EMM386 etc) implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API. -hpa -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] hmmmm
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
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
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
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
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
I am interested in writing a new driver, one that would allow you to boot and run dos on a EXT3 partition. booting from EXT3 would require to make EXT3 part of the kernel. not going to happen. otoh there is virtually no disadvantage to have a loadable TSR to make EXT3 available as a redirector. In your other message you said that ETX3 was a multithreaded fs. In that case it would be wiser to first add multithreaded support to the FreeDOS kernel. It will be hard, but well worth the time I believe. don't wait for multithreading support from kernel. in the good old times, when DOS was still active, disk caching software implemented 'multithreading' by chaining into TIMER and IDLE interrupts. just because so far no FreeDOS disk cache supports write caching doesn't mean it doesn't exist Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] EXT3 support
Greetings, I was reading the FreeDOS development wish-list and adding ext3 support to the FreeDOS kernel is on the list. Is anyone working on this at this time? Thank you for your time. God Bless. Till -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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
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
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
I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS Kernel. Would it be fine if I began setting up a multiuser/multitasking system like Digital Research's DOS 5, and begin the work to get Forth into the kernel? the kernel is definitively not the right place to integrate Forth into, be it multiuser or not. there is zero disadvantage to have FORTH.EXE doing all the magic of course feel free to experiment (thats one of the reasons open source exists), but the the probablity that this would ever get integrated into the FreeDOS kernel has 8 leading zero's This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus whenever I read emails like this, I wonder what prevents a virus from adding such a line to its malicious postings ;) Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Questions about Kernel editions
I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS Kernel. Would it be fine if I began setting up a multiuser/multitasking system like Digital Research's DOS 5, and begin the work to get Forth into the kernel? I am just going to make a branch to test each of these, and if you like it then I will make a commit. If not it will be a short lived fork. I have been following this project, and I would love to see it get more attention. I have a Tandon 80386SX machine with 1MB of ram (hopefully getting it up to 8MB) and rock a 5.25 drive in my main rig with modern hardware. I don't want to see this go away just because it's old. I will be doing all my tests on the Tandon while it has 1MB. Does that sound alright? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Unable to use drive number 32 with some functions
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
Hello, That's right, I was not expecting NDN will use it as it is already out of the spec. You can change the else if (((r-BL = 'A') (r-BL = 'Z')) || ((r-BL = 'a') (r-BL = 'z'))) /* NDN feeds the actual ASCII drive letter to this function */ used_drive = (r-BL 0x1f) - 1; into else if (((r-BL = 'A') (r-BL = '`')) || ((r-BL = 'a') (r-BL = 'z'))) /* NDN feeds the actual ASCII drive letter to this function */ used_drive = (r-BL - 1) 0x1f; I think the lowercase case can remain as it is (there is no correspondance between lower and upper case for letters above 'z' and more over it goes outside of 7 bits ASCII range). Regards, Damien perditi...@gmail.com wrote: Thank you. I will try to get a fix implemented this week. Your patch corrects supporting the 32nd drive if provided as value 1 thru 32 (0 is default) but still doesn't handle if passed as ascii value ` (0x60). Jeremy On Apr 26, 2015 3:51 PM, Damien Guibouret damien.guibou...@partition-saving.com wrote: Hello, I found a small problem in ioctl code that leads to drive number 32 to not be usable with device related functions (int 0x21, ah=0x44..) and leading to returning information about another drive without signaling any error. As I suppose this is not widely used (drive 27 to 32 are most often not known by users), I think this is quite minor. I wrote a patch, but did not test nor even compile it. In this patch I keep some code that from interface point of view is wrong but that is the way I understood the NDN related comment. Regards, Damien --- ioctl.c.orig2015-04-26 21:01:18.0 +0200 +++ ioctl.c 2015-04-26 21:26:48.0 +0200 @@ -164,6 +164,7 @@ { struct dpb FAR *dpbp; unsigned attr; + BYTE used_drive; /* This line previously returned the deviceheader at r-bl. But, DOS numbers its drives starting at 1, not 0. A=1, B=2, and so @@ -173,9 +174,18 @@ */ /* JPP - changed to use default drive if drive=0 */ /* JT Fixed it */ - - /* NDN feeds the actual ASCII drive letter to this function */ - dpbp = get_dpb((r-BL 0x1f) == 0 ? default_drive : (r-BL 0x1f) - 1); + if (r-BL == 0) +used_drive = default_drive; + else if ((r-BL = 1) (r-BL = 32)) +used_drive = r-BL - 1; + else if (((r-BL = 'A') (r-BL = 'Z')) || + ((r-BL = 'a') (r-BL = 'z'))) +/* NDN feeds the actual ASCII drive letter to this function */ +used_drive = (r-BL 0x1f) - 1; + else +return DE_INVLDDRV; + + dpbp = get_dpb(used_drive); if (dpbp) { CharReqHdr.r_unit = dpbp-dpb_subunit; @@ -196,7 +206,7 @@ { /* note from get_dpb()*/ /* that if cdsp == NULL then dev must be NULL too */ - struct cds FAR *cdsp = get_cds1(r-BL 0x1f); + struct cds FAR *cdsp = get_cds(used_drive); if (cdsp == NULL) return DE_INVLDDRV; if (cdsp-cdsFlags CDSSUBST) -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Unable to use drive number 32 with some functions
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?
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?
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.
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.
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.
On 9/15/2014 1:42 PM, Tom Ehlert wrote: it would help if you would tell us what PDOS is. I a fairly certain that he is referring to this http://sourceforge.net/projects/pdos/ Ralf --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Free tools for FreeDos
I would like to put some of my old tools (still useful) on the public domain. I think these tools can be a good addition to FreeDos. Have a peek at: https://www.dropbox.com/sh/lv923nbdf2s36yj/wYKfMbOYDE The folder contains source code and some documentation. The BOOT and DOS Probes are written is dense assembly with the goal of small footprint (around 20K). Hopefully, asm sources are readable enough. Please let me know your thoughts on this or if you need further information. Regards, Mehdi Sotoodeh. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Free tools for FreeDos
imagefd is useful softprobe too -- -chris Digitalatoll Solutions Group Tawhaki Software http://digitalatoll.com/ http://tawakisoft.com/ On Sun, Mar 23, 2014 at 6:43 PM, Mehdi Sotoodeh mehdisotoo...@gmail.comwrote: I would like to put some of my old tools (still useful) on the public domain. I think these tools can be a good addition to FreeDos. Have a peek at: https://www.dropbox.com/sh/lv923nbdf2s36yj/wYKfMbOYDE The folder contains source code and some documentation. The BOOT and DOS Probes are written is dense assembly with the goal of small footprint (around 20K). Hopefully, asm sources are readable enough. Please let me know your thoughts on this or if you need further information. Regards, Mehdi Sotoodeh. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Run Freedos on top of the Nova hypervisor?
I was reading some article about the future of FreeDOS and I was asking myself if FreeDOS could and would profit from running on top of Nova Hypervisor: http://hypervisor.org/ I learned about it through the Genode project, which recently managed to have VirtualBox ported to run nicely on top of Nova. Truely, it seems that Nova have been used mostly to run Linux on top, but I suppose the 16 bits nature of DOS still allows it to be run on Nova, although I am not completely sure of that. The good point is Nova allows to use modern CPU virtualization features for devices, so that FreeDOS VM could think they have access to the real devices. I am more following projects than an active developpers, so I post here to let you bright guys evaluate if it can be done, and if it is usefull for the FreeDOS project. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1
Thanks for reporting and fixing FreeDOS kernel BUG's :-) -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] A question about the behavior of the NUL device in FreeDOSS 1.1
Please note that I have not followed any of the FreeDOS mailing lists on a regular base. This means that I may report something that is already well known. Also I do not know if this is the right mailing list to post this bug report. Please inspect the small code snippet below: #include unistd.h #include fcntl.h #include stdio.h #define SIZE 256 int main(int argc, char *argv[]) { char buffer[SIZE]; // int handle = open(argc 1 ? argv[1] : /dev/null, O_RDONLY); int handle = open(argc 1 ? argv[1] : NUL, O_RDONLY); int len = read(handle, buffer, SIZE); printf(len=%d\n, len); if (len 0) { int i, k; for (i = 0; i len; i += 16) { for (k = 0; k 16 i + k len; k++) printf( %02X, (unsigned char)buffer[i + k]); printf(\n); } } return 0; } This code has been compiled on MSDOS and Windows using DJGPP. It has also been compiled on linux as reference. All programs behave as expected on all tested operating systems, this means that /dev/null (aka NUL) provides nothing and the program prints: len=0 as it must be. If the same program runs on FreeDOS 1.1 it produces the following output: len=256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 No offending intention here, but have the developers confound /dev/null with /dev/zero? IMHO the NUL device seems to be broken. This issue is critical when bash configure scripts of GNU software packages contain lines like this: awk 'BEGIN {getline /dev/null}' making the configuration step abort and thus the complete build of the software impossible if FreeDOS is used instead of MSDOS or Windows. Please note that I have also tried NUL instead of /dev/null in the code and the program fails in the same way. This means this is certainly not a DJGPP bug. The program fails in the same way if compiled with OpenWATCOM 1.9. If more information is required, please contact me. Regards, Juan M. Guerrero -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
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?
rating of a typical USB2 stick and the overhead of only using USB1 to talk to it and you see why sorting your family pics on that stick or some SD card is not very smooth inside DOS. You could try to write a layer of cleverness and pooling for some cache, or a complete cache, but note that people might actually prefer basic: You write it, it is slow, but you can unplug that USB stick or even your whole PC after a fraction of a second and the data already is there and consistent... Maybe we should discuss the roadmap again in the first place? I'd like to see more discussion. In the mean time, I'll keep experimenting. Enjoy :-) As Tom said between the lines, the (more long term) roadmap is more visionary and less based on consensus or some practical what do we NEED to add NEXT considerations. The roadmap for 1.0 and 1.1 was more like that. Today I would say the question is more which bits you want to ADD and less what you want to CHANGE DOS as a whole into. Because after all, it is quite good that DOS is what it is. It does not need to be a weak imitation of something else which already is good, too. Regards, Eric :-) -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
. You get similar issues with disk I/O, DOS caches rarely pool your I/O to read-ahead megabytes of your MPEG or combine several FAT changes before writing them in some smart and safe way. Instead, expect DOS apps to read your MPEG 32 kB at a time and update the FAT at a ratio of a few bytes at a time. Combine that with the IOPS rating of a typical USB2 stick and the overhead of only using USB1 to talk to it and you see why sorting your family pics on that stick or some SD card is not very smooth inside DOS. You could try to write a layer of cleverness and pooling for some cache, or a complete cache, but note that people might actually prefer basic: You write it, it is slow, but you can unplug that USB stick or even your whole PC after a fraction of a second and the data already is there and consistent... Maybe we should discuss the roadmap again in the first place? I'd like to see more discussion. In the mean time, I'll keep experimenting. Enjoy :-) As Tom said between the lines, the (more long term) roadmap is more visionary and less based on consensus or some practical what do we NEED to add NEXT considerations. The roadmap for 1.0 and 1.1 was more like that. Today I would say the question is more which bits you want to ADD and less what you want to CHANGE DOS as a whole into. Because after all, it is quite good that DOS is what it is. It does not need to be a weak imitation of something else which already is good, too. Regards, Eric :-) -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
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?
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?
Hi Louis, sort of a long response - it seems hard to make a short point here: FreeDOS Roadmap, as goals and stretch goals for the project. I read (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit The fd32 project works or worked on the DPMI aspect. As far as I remember, the performance gain was minimal, but consider interest in terms of style to consider a protected mode kernel which has both DPMI and VM86 visibility. It would be a sort of DOSBOX then. Regarding built-in networking and USB, I am personally more for the existing loadable driver model. The BIOS gives you enough support to reach the point where you can load drivers in config sys. Even when booting via network (PXE) or from CD/DVD/BD, you can still use a MEMDISK (bootable ramdisk) to get started... On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables. The latter would have significant practical use. Not the former: When you boot from CD/DVD/BD, you do typically want a writeable ramdisk anyway, so you can just as well boot with the help of a MEMDISK which lets you load DOS CD/... drivers from there, making drivers for that as fixed parts of the kernel less interesting. Also, they are harder to update than separate drivers and you cannot easily skip them at boot to save DOS memory. Good question whether you want built-in USB: I would say no, you already need the BIOS to help to boot from USB. After that, you want a modular system of USB drivers (unless the BIOS provides support for all relevant USB devices) to let you access disks, sticks, mice, keyboards and so on. Also, devices for which there is no popular DOS or BIOS interface, such as network or sound, cannot have kernel drivers in a useful way. For networking, the packet driver interface is just one facet in a complex world, we could think about some additions to make it easier to write new drivers or to do common things with the network. For sound, the lack of popular interfaces means that you basically have to use protected mode to simulate a popular HARDWARE (SoundBlaster etc) and then let your actual driver play whatever the soundblaster would have played given the detected I/O with the simulation. 64-bit support, device driver imports, automated regression testing. Some automated or semi-automatic quality checks seem interesting. One could think of code style checks, audits, automated comparison of how well different artificial test cases or real software runs work with different kernel (micro-) versions in some VM etcetera. Regarding 64 bit support, there are some experiments with letting DPMI drivers use more than 4 GB of RAM. To make better use of it, you would have to define new interfaces (XMS, EMS, DPMI, VCPI...) and hope that DOS software would be written which uses them. Just using 32- or 64-bit calculations (not RAM addresses) is another story: Probably the kernel can be smaller by using more 32-bit calc but not really faster. Using memcopy optimized for more modern CPU (32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real difference, as the DOS kernel itself does not move a lot of data. In short, there are certainly points in which DOS can be extended, but I personally doubt that many or even any of them should start in the kernel. Separate drivers and other software fit better. Maybe we should discuss the roadmap again in the first place? Regards, Eric -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?
Whoops, didn't realize that I replied to fd-user instead of kernel. One other note, all kernels are slightly bigger withe options I set. -L -- Forwarded message -- From: Louis Santillan lpsan...@gmail.com Date: Sun, May 5, 2013 at 9:01 AM Subject: Re: [Freedos-user] Any interest in 486, 586, 686 kernels? To: Discussion and general questions about FreeDOS. freedos-u...@lists.sourceforge.net Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles. Read ( ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections 2.3.x 3.5. Enlightening and disappointing. There does not seem to be a way to get 32-bit instructions out of wcc as Tom had mentioned. 3.5 recommends The recommended options for generating the fastest 16-bit Intel code are: Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6 Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5 486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3 386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3 286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2 186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87 8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87 -ot of -onatx -zp8 contradict the original makefile's code -os -zp1 (optimize execution time vs. executable size align on byte vs. 8-byte, respectively). Also, the -fp*'s opts don't apply and wcc barfs on -oi+. So in mkfiles\watcom.mk I added some code to add -6-onaxlkh-ei (for 686). This will reorder instruction significantly and replace some call nears with jmps in a comparison of 386 timed code vs. 686 timed code. Code is larger on the 686 side. So far, not very impressed with OW 1.9's optimizer. Rather minimal improvements. Anybody play with BCC 5.5 HX-DOS recently? -L On Sat, May 4, 2013 at 3:27 AM, Tom Ehlert t...@drivesnapshot.de wrote: Hallo Herr Louis Santillan, https://sites.google.com/site/lpsantil/Home/386DIS.ZIP https://sites.google.com/site/lpsantil/Home/686DIS.ZIP https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP https://sites.google.com/site/lpsantil/Home/kernels.zip the differenz is an empty memdisk.lst (for whatever reason) everything else is *identical* I'm not impressed Tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-user mailing list freedos-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?
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?
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?
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?
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?
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?
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?
What's the difference between wcc wcc386? code generation for 16 bit (DOS) or 32 bit (windows) Does wcc386 generate code that could be used in the kernel? no Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions. But just an idea right now. the kernel doesn't copy (much). nothing to be gained. tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.
Dear Developers of FreeDOS-Kernel. I use the Kernel 2041 and found follow strange: If I press the F8 key for singlestepping and then the ESC key to skip a command, the singlestepping-process of the FDCONFIG.SYS is skipped. Under MS-DOS the ESC key skips only the current command and doesn't skip the singlestepping-process. Under the commando-processor (I use the FreeCOM) the ESC key skips only the current command, too. I think to skip the singlestepping-process is a good thing, but its better to do this with another key, like the SPACE key. Best regards Christian Pfaller -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.
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
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
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
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
Jack, kernel people (now CCed), When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software ... How does DOS ever detect that any hardware is unreliable?? I do not know, but earlier in this thread, somebody said that the numbering of FAT filesystem exists, among other reasons, to help DOS detect floppy changes even if there is no change line available. As you know, int 13.15 can even report that a floppy has no change line at all. MS DOS might, on top of that, have a list of BIOS versions with weak change lines? Related kernel sources: init_readdasd, make_ddt, maybe also DosDefinePartition. Apparently FreeDOS has drive types hard- disk, floppy with change line, and other here... Int 13.16 which actually queries the change line can return invalid command, drive not ready / not present, no change or change line active or not supported. NOTE that calling the check also clears the status, so only ONE caller will notice each change and only ONCE! Lbacache takes special care here. Related kernel sources: FL_DISKCHANGED, fl_diskchanged, floppy_change, mediachk, diskchange... If you have NO change line, diskchange returns not changed if you very recently accessed the disk, and unknown otherwise, I believe?) For M_DONT_KNOW, mediachk returns disk changed iff the serial of the filesystem changed compared to the current DDT info. Finally, media_check is described to trigger on unknown, changed or definitely changed. It does setinvld and calls the D_BLDBPB block device driver function and converts the BPB to DPB then. Note that int 21.7302 get ext dpb calls flush_buffers, flags a fake disk change, calls media_check. DosGetFree can behave similarily depending on arguments... Maybe update_dcb is also related. I think D_BLDBPB is done by rqblockio and the bldbpb function and getbpb, which also calls RWzero to re-read the boot sector? As you see, a very long chain of events exists around all DOS block device related things, but that is necessary to be fully compatible with MS DOS... You also see that I did NOT mention calls to int 13.0 disk reset here - I have not seen any (apart from fl_reset / FL_RESET calls in reaction to I/O errors deeper in the RWzero chained LBA_Transfer). I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an Int 13h drive reset command which in turn can be caught by the UIDE2 driver and treated as a flush cache for THAT drive event? ... What do you mean maybe?? You and others are the kernel experts for FreeDOS, not me, as I still run V6.22 MS-DOS!! As you see above, handling of floppies and their changes is a complicated thing which is not easy to walk through, even for me :-) Also, I say again that I am NOT interested in any specific logic from the MS-DOS kernel, or the FreeDOS kernel, or in fact ANY kernel, for detecting diskette changes. My worry is that such logic may NOT be generic, and I want... As far as I can tell, you could make int 13.0 (disk reset) and reads of the boot sector flush events. That might flush a bit more often than necessary, but at least not LESS often than necessary, assuming that you ALSO trap int 13.16 return values already and trigger flushes when you see change line activity :-) UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes See above - if you ACTIVELY call int 13.16, you could hide the floppy change from DOS because int 13.16 returns changed status only for the first call after a disk change even with working change lines... Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS system calls and I also want to keep THAT I agree that it is good to not call DOS in a DISK cache and actually it should not be necessary to call DOS either :-) Note that things might be different for block device based caches instead of BIOS / hardware based caches like ours... By the way, any chance to work around the VirtualBox huge-delay problem? Not without knowing WHY they take such a huge delay! In any case, UIDE and UIDE2 must scan for PCI-bus devices... If I understand your code correctly, you scan all 256 bus, 32 device and 8 function locations which can be expressed, using the BIOS. You could save a lot of time by scanning only those bus numbers that are used and not scanning sub functions for devices that are installed at all. It also is a lot faster to use mechanism #1 port I/O and not call the BIOS for each access, but you might be using the BIOS deliberately to also support ancient mechanism #2 boards? If the VirtualBox people cannot fix the huge delay... I think UIDE2 now takes 2-3 minutes on VirtualBox when that uses a virtual PIIX3 chipset, so if you really do a scan of all locations, scanning only those locations where
Re: [Freedos-kernel] Commit 1705
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
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
Hi Bernd, (untested, just history.txt __IS__ updated this time) but nobody annouced it :-D Yes, why?? I forward a message from RayeR in the forum below. It's a secret to everybody! (hm, too much Zelda) The pre-386/memdisk detection is a good thing, finally a unified kernel. For the VERY exotic case that you have a bootdisk which boots from memdisk on 386 and without on older 386, if you can still find any... And the exotic case where the two styles of booting still share the same config sys? Right until someone does a append FD={INSTALL=FORMAT C: /Z:SERIOUSLY} You might want to use a login to protect advanced boot menu options. However, if people can boot DOS from a memdisk - I assume this is NOT now they boot from C:! then they can just boot ANYTHING from another portable boot drive and whether they can mess up how your DOS portable boot drive acts is a relatively small worry. Having 2041 out when maintainers had time for it relieves them from pressure for implementing stuff and releasing new versions. I do not understand... Anyway, here is what RayeR says: posted by RayeR(R) Homepage, CZ, 19.02.2012, 17:39 Thx for notification. Let's see what's new: 2012 Feb 07 - Build 2041 Jeremy Davis + Changes Jeremy * r1637 fix out of range byte in country.asm * r1685 add int 2f subfunc 122B and 122D from Eduardo Casino * r1697 from Pete Batard, do not display CHS mismatch warning during booting when forcing LBA mode option set * r1702 improve handling for sectors not 512 bytes in size (up to 2048 bytes, larger sizes not yet working) * r1705 add cpu detection so memdisk args supported in 8086 build Seems like minor changes except the support for 2048 sectors? Where is it used? I know that CDROM use 2kB sectores but it was handled by driver for a long time. I also read that some new HDDs have 4kB sectors but AFAIK they still emulate 512B sectors for system. --- DOS gives me freedom to unlimited HW access. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] screen full of kernel warnings
Could someone please verify that a screen full of kernel warnings is shown when running option 2 from the following bootdisk? : [ http://www.reactos.org/bugzilla/attachment.cgi?id=7374 ]. A simple workaround I could do is commenting out the textline that gets printed and recompile. Cause of these warnings is that the bootdisk is hiding int13 drives (which I do on purpose to not mount any harddisk FAT partitions at boot-time as I like to use C: for a ramdisk occasionally). Bernd -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
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)
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
Hi Czerno / Bertho, Hi Eric! On the freedos-kernel list, you voiced such opinion about the future of big sector disks: that has low priority imho, as drives with large sectors are a temporary thing, will be gone with GPT partitions. This refers to the following quote from an earlier 4 kB related mail: I stumbled upon a couple pages that say otherwise : the industry has agreed to sell AF disks only *until the end of 2014*! It was actually you yourself who said that on 25 Jan 2012 ;-) AF = Advanced Format = 4096 byte per sector, i.e. Advanced meaning if you find 512 byte better, you are not modern :-p It is a bit like APS Advanced Photo System - a nice buzzword for a strange idea that is made look good for the end user. Also, advanced format lets more data share less ECC error correction data, squeezing out a tiny bit of extra capacity and a bit of extra resistance to data errors... Wikipedia claims that Windows Vista, 7 and 2008 have hotfixes for drives with natively larger sectors which allow access in 512 byte emulated sectors - in other words, the hotfix is just fixing the performance loss caused by not knowing that the underlying hardware sectors are big - while those Windows versions apparently do NOT support native big sectors yet, at least not for the boot drive... Reference for this: http://support.microsoft.com/kb/2510009 In other words, Windows Vista / 7 / 2008 makes sure to always access aligned blocks of 8 sectors of 512 bytes together, to improve performance, when it knows that the physical disk has 4 kB sector size but uses 512 byte per sector I/O protocols. That is very vaguely similar to what LBACACHE TICKLE and other read-ahead tools can do for you, if configured properly... ;-) Manufacturers have no interest to reverting to 512 bytes sectors - since 4K sects allows them to advertise higher capacities No. As Tom said, large sectors are only a workaround for WinXP and similar MBR partitioned operating systems. With GPT, you have no relevant limit to the number of sectors any more and sectors can be small again :-) On the other hand, everything is pretty virtual today anyway, and SSD / flash have better performance with access in larger blocks, but that does not mean that block has to equal sector. It could also equal cluster and FORMAT already supports making clusters of 4 kB or bigger align with 4 kB boundaries... ;-) The virtuality will also mean that you eventually have to load a PC BIOS interrupts legacy API module for EFI BIOSes. Luckily those also exist as open source, if vendors get lazy. Eric PS: As you say you read this on freedos-kernel, but are only on freedos-user (where you mailed) I took the freedom to CC both. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Commit 1705
Hi, Commit 1705 renames a particular LoL field CPULevel and adds a comment correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0 otherwise. The commit however makes the boot loader store the detected CPU level (0, 1, 2, or 3) there instead. I don't think it's necessary to use the field in an incompatible manner, and neither is the new 21.33 subfunction that the commit adds, because no one uses it yet. Even so, the subfunction does not require using that particular field to store the detected CPU level. Regards, C. Masloch -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
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
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)
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