Re: [Freedos-kernel] re: test bootdisk
Hi! 15-Сен-2004 19:31 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> About DISPLAY: >> UPX first, COM2EXE next, produces smallest size. EA> bad idea. COM2EXE cannot detect de-UPX-ed size! So the exe header This is unimportnat, because (my) COM2EXE doesn't "detects" size at all. It simply points in header, that should be allocated 64k. _If_ you run COM2EXE with option, which reduces requested size, then _you_ should know, how much of memory should be allocated at program run (after unpacking). EA> NCACHE2 only works if max 31.x MB XMS are free? No. Not works only autodection for "ext" option (without argument), but you may not allocate all memory (omit "ext" option) or point allocated memory explictily, as argument of "ext". EA> Then in must be quite old, 1994. :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: test bootdisk
Aitor wrote: > By the way, does anyone know how to mount a drive or > directory as a drive for VMWARE? (something like DOSEMU's > lredir). I never had VMWARE myself (why spend US $189 when you don't need to?) but from what I've read about it has a virtual network card so you could use a SMB client in it (like MSNET) and use that to connect to the real machine and mount a drive. Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: test bootdisk
Hi, Eric Auer escribió: About DISPLAY: UPX first, COM2EXE next, produces smallest size. bad idea. COM2EXE cannot detect de-UPX-ed size! So the exe header will tell how much space the compressed COM needs. But the whole idea of using COM2EXE was to let DOS know the de-UPX-ed size explicitly: As far as I recall, the idea of using COM2EXE is that there is a bug in kernel about loading high COM programs that resize their chunks (when there is no room, it aborts instead of loading low), and to avoid this problem. The experiments by Bernd showed that under MS-DOS it works fine (a growing COM file). UPXing EXE files has that ad*antage... ...that we don't need because the problem [might] doesn't happen for EXE files. If you load an UPXed COM into a too small memory block (or an com2exed UPXed com), you can end up in the situation 'upx stub sees that there is not enough memory, so it throws int 20 (exit with errorlevel 0, no message) instead of unpacking and running the program'... Well, maybe. But Bernd has showed in those strange-MEM experiments that DISPLAY loads high this way well. As far as for resident size, it doesn't change at all. So I could just try and revert the order of the steps for the next version. The only thing that will change is that DISPLAY.EXE will grow a bit (but it will be the LAST COM/EXE version anyway). All my testing is done in VMware 4.5.2, btw. No Bochs/Qemu/DosEMU/VirtualPC etc. By the way, does anyone know how to mount a drive or directory as a drive for VMWARE? (something like DOSEMU's lredir). Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Bernd Blaauw escribió: no idea if the DISPLAY binary has been UPX'd, and if that has any affect. UPX first, COM2EXE next, produces smallest size. I'm still confused by syntax for DISPLAY/MODE/KEYB.., so it's good to have working examples at hand. I think what you are using is ok. It's equal than for MS, except that (both being fixed now) - DISPLAY is a COM/EXE and not a SYS - KEYB does not admit many layout bunch files (such as KEYBOARD.SYS, which is mostly a DATA file), but single files, such as SP.KL or IT.KL or GR.KL... If you have troubles, ask what troubles you or tell me what you want to get. Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] test bootdisk
Hi! 15-Сен-2004 13:45 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to [EMAIL PROTECTED]: >> 2) DISPLAY loads low (see MEM /C /P), while plenty of (UMB)memory is >> available, and being the FIRST driver loaded. very strange! >> 3) DISPLAY loads high and ATAPICDD/CDRCACHE load low, if removing the >> REM from MEM /C in the beginning of autoexec.bat ASM> You are using DISPLAY.EXE, right? This is what is obtained from Arkady's ASM> COM2EXE, so he might now if there is something strange about this. If I doubt. :) If DISPLAY loads high without MEM before it and low with MEM - this not relates to COM2EXE. --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
alright, MEM display is a MEM bug as Bart indicated, Lucho fixed, as final public developers's work for his part, the 'remainig' -> 'remaining' cosmetic bug. now only this strange bug of why DISPLAY loads high if MEM is first run, and loads low (and atapicdd/cdrcache load high instead) if MEM isn't run. Keyb seems alright afterall, but I thought 1) 'keyb partially loading --> unnamed block eating UMB' 2) 'keyb loaded with valid parameters' --> MEM /C shows alright. My conclusion then: must be KEYB. Conclusion now: must be MEM displaying something wrong (as Bart indicates). no idea if the DISPLAY binary has been UPX'd, and if that has any affect. Bart, I'm not distributing a 386/BorlandC/Apack kernel, this was just an experimental bootdisk image to show some troubles I experienced. bootdisk will be 8086+, and I hope the SHSUCDX/SHSUCDHD parts can also become 8086+ in no way is this a full-featured usable bootdisk, but it does show how to load the various drivers. I'm still confused by syntax for DISPLAY/MODE/KEYB.., so it's good to have working examples at hand. I'm planning to use a 8086/Openwatcom/UPX version of either Jeremy's or Lucho's sources, and to distribute a 2035A (the conservative tree) as kernel for harddisk. Haven't figured out why not everything (except UDMA ofcourse due to lack of VDS) loads high. Plenty of UMB space (48K). perhaps I should test against official 2035, to see if self-UMB-loading programs work there. All my testing is done in VMware 4.5.2, btw. No Bochs/Qemu/DosEMU/VirtualPC etc. Bernd --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Bart Oldeman escribió: On Wed, 15 Sep 2004, Bernd Blaauw wrote: Bernd Blaauw wrote: Hello all, I've put online a new bootdisk with which I, and you, can easily experiment. Download it from: http://fdos.org/ripcord/beta9-final/test/testing.zip [274KB, 1.44MB unzipped] OK, just uploaded a new version, now includes fixed autoexec.bat and mounting. program for small ISO file. http://fdos.org/ripcord/beta9-final/test/testing.zip Bart, do you see the unnamed program, eating 48KB (probably just a viewing problem)? Yes, even in DOSEMU -- a few drivers can't be loaded but the effect is the same. It's a bug in mem (line 1124 of mem.c can be changed to if (mlist->owner && (is_psp(mlist->seg) || mlist->owner == mlist->seg + 1)) to fix it -- here's a freed memory block but there's a PSP directly following the MCB and that confused mem). Well this weekend at the latest I'll try to release 1.7 with the German, Italian and new Dutch translations then. Bart, didn't you get my file with the Spanish translation to MEM? Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] test bootdisk
Hi, Bernd Blaauw escribió: 2) DISPLAY loads low (see MEM /C /P), while plenty of (UMB)memory is available, and being the FIRST driver loaded. very strange! 3) DISPLAY loads high and ATAPICDD/CDRCACHE load low, if removing the REM from MEM /C in the beginning of autoexec.bat You are using DISPLAY.EXE, right? This is what is obtained from Arkady's COM2EXE, so he might now if there is something strange about this. If you want, I could try and pass to you a DISPLAY.COM and see if you have the same result. The size required by DISPLAY.COM is close to 64KB. Although for the COM we knew of that kernel bug that doesn't like to allocate a whole segment... 5) MEM /C shows some strange empty thing eating almost all UMB-space, when KEYB partially fails to load (done by explicitly entering wrong codepage info, namely XUS instead of US) It's strange, because at this version KEYB is not doing anything strange with memory when it aborts, I wasn't able to reproduce it at a first approach, I'll try to download the boot disk and do testings... If you know any way to reproduce this without rebooting the machine please contact me in private. Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Hi, Bernd Blaauw escribió: Bernd Blaauw wrote: Hello all, I've put online a new bootdisk with which I, and you, can easily experiment. Download it from: http://fdos.org/ripcord/beta9-final/test/testing.zip [274KB, 1.44MB unzipped] OK, just uploaded a new version, now includes fixed autoexec.bat and mounting. program for small ISO file. http://fdos.org/ripcord/beta9-final/test/testing.zip Bart, do you see the unnamed program, eating 48KB (probably just a viewing problem)? Un-UPX-ed KEYB executable is around 20KBs, it is compiled for 2KB stack and no heap... Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Hi! 15-Сен-2004 12:04 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: >>BB> CTMOUSE 3,328(3K) 0(0K) 3,328(3K) >>BB> 48,704 (48K) 0(0K) 48,704 (48K) >>BB> Free 623,024 (608K)622,880 (608K)144(0K) >> Bernd, may you try: (1) MEM 1.6, (2) my MEM and (3) review complete >>lisintg (/F for Bart's MEM, /A in my)? BB> I'll do that. Problem probably is in KEYB not loading completely successfull. ? --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Arkady V.Belousov wrote: BB> Bart, do you see the unnamed program, eating 48KB (probably just a BB> viewing problem)? BB> CTMOUSE 3,328(3K) 0(0K) 3,328(3K) BB> 48,704 (48K) 0(0K) 48,704 (48K) BB> Free 623,024 (608K)622,880 (608K)144(0K) Bernd, may you try: (1) MEM 1.6, (2) my MEM and (3) review complete lisintg (/F for Bart's MEM, /A in my)? I'll do that. Problem probably is in KEYB not loading completely successfull. Bernd --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: test bootdisk
Hi! 15-Сен-2004 03:44 [EMAIL PROTECTED] (Bernd Blaauw) wrote to All: BB> Bart, do you see the unnamed program, eating 48KB (probably just a BB> viewing problem)? BB> CTMOUSE 3,328(3K) 0(0K) 3,328(3K) BB> 48,704 (48K) 0(0K) 48,704 (48K) BB> Free 623,024 (608K)622,880 (608K)144(0K) Bernd, may you try: (1) MEM 1.6, (2) my MEM and (3) review complete lisintg (/F for Bart's MEM, /A in my)? --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Lucho gives up arguing with Arkady
Alain escribió: Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. By whom? By the Boss? Who is the Boss? Arkady? Hi Lucho, don't feel hurt, he is just sayint what we yelled at him so many times :) The boss is ... gess who? the comunity, represented in this list... Cheer-up ;-) Alain I agree entirely :) Aitor --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Lucho gives up arguing with Arkady
Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. By whom? By the Boss? Who is the Boss? Arkady? Hi Lucho, don't feel hurt, he is just sayint what we yelled at him so many times :) The boss is ... gess who? the comunity, represented in this list... Cheer-up ;-) Alain --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
On Tue, 14 Sep 2004, Luchezar Georgiev wrote:
> > #include
> > #include
> > #include
> >
> > int main(void)
> > {
> > int fd = open("fool.dat", O_WRONLY|O_CREAT|O_TRUNC);
> > write(fd, "hello", 5);
> > close(fd);
> > sleep(2);
> > fd = open("fool.dat", O_WRONLY);
> > write(fd, "hello bye", 9);
> > close(fd);
> > return 0;
> > }
>
> Thanks, Bart. Seems that as I already have written so, I AM THE FOOL HERE!
> Tested, and it's really as you say. Then why my files I worked over in
> FreeDOS were all with creation times = write times?
>
> No, I will resign from kernel development. Let me leave it to the more
> competent and young. No, seriously!!!
what is going on? I simply provided a counter-example. Everyone makes
mistakes.
People provide counter-examples to me as well, then you simply
have to accept that, you learned something new, and life goes on. Don't
see this as a personal failure. "fool.dat" was more a tongue-in-cheek
filename, basically I already had a file named foo.dat so played with
that ;)
Bart
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Goodbye from Lucho (this time forever)
Hello Luchezar, Tuesday, September 14, 2004, 12:18:08 PM, you wrote: > Sorry Bart, I was wrong AGAIN. I will add creation times again, and this > will END my participation in the FreeDOS project. I feel that I'm NOT good > for such activity anymore. Jack R.Ellis was right to never participate in > mailing lists. At the age of 45, So you are REALLY, REALLY OLD (you think) unfortunately, I was 44 when I *started* with the Freedos Kernel, being 48 real soon. so that's no excuse to quit - back to work again ;) tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
#include
#include
#include
int main(void)
{
int fd = open("fool.dat", O_WRONLY|O_CREAT|O_TRUNC);
write(fd, "hello", 5);
close(fd);
sleep(2);
fd = open("fool.dat", O_WRONLY);
write(fd, "hello bye", 9);
close(fd);
return 0;
}
Thanks, Bart. Seems that as I already have written so, I AM THE FOOL HERE!
Tested, and it's really as you say. Then why my files I worked over in
FreeDOS were all with creation times = write times?
No, I will resign from kernel development. Let me leave it to the more
competent and young. No, seriously!!!
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
The question is: does anyone know what does MS-DOS do? What now unstable FreeDOS does - ZERO creation time/date and access date on each directory entry write. Verified. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
On Tue, 14 Sep 2004, Luchezar Georgiev wrote: > Not speaking about access date, which > shouldn't be set in DOS as it would mean unexpected writes. I don't understand why access dates are different in DOS than other OSes. If the volume is r/o you can't change the access date, sure. I wonder though about this in RBIL: D-216C00- INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE AX = 6C00h BL = open mode as in AL for normal open (see also AH=3Dh) bit 7: inheritance bits 4-6: sharing mode bit 3 reserved bits 0-2: access mode 100 read-only, do not modify file's last-access time (DOS 7.0) why would a 100 flag be needed if the last-access time would never be modified? > In summary, I > didn't do this change only to be reverted back because Bart doesn't like > it. Don't apply it to his stable branch, but *leave* it in our unstable, > please. I don't care about the branch it's in really. Neither of the two branches are mine -- but I have write access to both. So I could have simply reverted your change but decided to be a little more polite and tell you why I don't agree. I just want to say that, if I did not like it myself then I would never have implemented it in the first place... The argumentation given by you was given in the CVS commit -- which I don't think is valid but I understand why in some cases you may not want to fiddle with these times (hence the config.sys idea). Then you have another one (it was broken anyway) by email which I can disprove. Or do I gather from you that you absolutely *need* a kernel that is <40k (exactly why is a mystery to me, but it looks like a ROM where everything but exactly 39.5K is taken up by something else) and that one component now uses one extra sector so you desperately need to shave off another sector? Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
On Mon, 13 Sep 2004, Luchezar Georgiev wrote:
> Bart wrote:
> > I wonder about those creation time set removals. It looks like your
> > removing a useful feature here. Sure a reason given is "MSDOS 7.10
> > doesn't do this". Well, I say, who cares about this specific DOS,
>
> Isn't *this* specific OS what we try to emulate as closely as possible
> (including even its bugs)?
no. We want to be compatible with it. That's a subtle but important
difference. It means that we should feel free to implement features in
FreeDOS not present in any other DOS, as long as it doesn't break existing
DOS programs (which of course proved harder than it seems :( ).
The reason why the FAT32 version reports 7.10 is simply because "5.00"
would mislead some programs into believing that FAT32 support is not present.
> It didn't actually do that. FreeDOS did *always* set the creation time
> *equal* to the write time.
No way. init_direntry set the creation time equal to the write time but
only for created or replaced files (status != S_OPENED), and in mkdir.
The place where write time starts to be different from creation time is
in
fnp->f_dir.dir_time = dos_gettime();
fnp->f_dir.dir_date = dos_getdate();
in dos_close().
Since you sound so confident I wrote a small program that creates a file
where the creation time is not equal to the write time.
> So the creation time didn't hold even a single
> of bit of information and was therefore misleading. Making it set the
> creation time *only* once, when a file is created, is surprisingly
> difficult (I tried and failed), and is not required for a DOS anyway.
> Let's not try to be bigger catholics than the pope.
There's nothing religious about this. It's simply a feature.
Bart
#include
#include
#include
int main(void)
{
int fd = open("fool.dat", O_WRONLY|O_CREAT|O_TRUNC);
write(fd, "hello", 5);
close(fd);
sleep(2);
fd = open("fool.dat", O_WRONLY);
write(fd, "hello bye", 9);
close(fd);
return 0;
}
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Hola Eduardo, Not really. In the worst case, only the 4 bytes for the empty DBCS table will be unused. The idea is to overwrite the hardcoded tables for CTYINFO, UCASE, FCHAR, and COLLATE and allocate new memory (if needed) for FUCASE, LCASE and DBCS _only_. What about a combination of your (1) and (3) methods - increase static memory only for FUCASE (by 130 bytes or so) and not support DBCS in COUNTRY.SYS? Arkady wrote that MS-DOS 6.2 doesn't support LCASE for codepage 866 either. I don't see the point. You have the array of nlsPointer structures, which tells you where the tables are for each subfunction. If you have a look at nls_hc.asm, maybe it will be clearer. Indeed, now I see an array ot SEG Table? pointers there. Eduardo, let's keep it simple. If you do the changes to NLS_HC.ASM needed to support the *current* information in COUNTRY.SYS, I'll change CONFIG.C as per your (1) and (3) methods. I detest having to dynamically allocate NLS memory in the kernel. Thanks, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
Hi, Luchezar Georgiev escribiÃ: I wonder about those creation time set removals. It looks like your I will consider reverting it, but a config.sys option is overkill. Yes, it is. It'll be difficult to revert it as it leaded to numerous other optimisations. Besides, I already explained why I removed it. Why add back an useless feafure without solid argumentation? (Useless as it was setting creation time on each write.) Unless you can make it set creation times only once, which is difficult. Not speaking about access date, which shouldn't be set in DOS as it would mean unexpected writes. In summary, I didn't do this change only to be reverted back because Bart doesn't like it. Don't apply it to his stable branch, but *leave* it in our unstable, please. The question is: does anyone know what does MS-DOS do? Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Lucho gives up arguing with Arkady
CVS isn't accesible for me. Sorry, I can't help you. Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. By whom? By the Boss? Who is the Boss? Arkady? So "don't ask me more" is not in given case. Eric, read and remember forever! I SWEAR TO NEVER EVER DO ANYTHING YOU WISH ANYMORE!!! Now, please continue the argument with Arkady as I'm sick and tired of this wasting of my and everyone's time! No, GPL means *current* version, and the URL points to it. URL is reduced for convenience, but for law clarity (for which you at all mention license) you should mention complate license name. Explicitly. I do this. "GNU General Public License". Period. If we continue such idiotic discussions, I'll leave FreeDOS development. I don't need it anymore anyway. Whoever wants to keep arguing with Arkady, please go on. I give up. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
BTW, Lucho, if you wish, I may prepare for you macroses in TASM to ease writing more readable and safer country.asm. Probably, someone then may translate these macro to NASM? Such translation will be very difficult if not impossible because NASM is too incompatible :-( So, don't bother with it. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot drive incompatibility with other boot sectors
The trouble is that most SYSes don't bother to set this value - they just copy the whole data area from the old boot sector and replace only the code and OEM ID. So the FF remains there. Verified. _And_ their boot code reuse this field? Yes. No DOS boot sector trusts BIOS DL value like us... (Because as I wrote it just can't be trusted very much) Well, right now I look at boot code of MS-SYS6, and found, that it not uses 24h offset itself Wrong. The read sector subroutine does use it. See http://www.kzin.com/bootsec/dos5pbra.txt but pass value from there to kernel. So the kernel uses it too, thus it's even more important. I not check what SYS does with original 24h field, but image inside SYS contains 80h value, so I doubt that MS-SYS preserves this field. That the image in SYS contains 80 doesn't prove nothing. Again, it hurts to be smart when eveyone else is dumb :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
I wonder about those creation time set removals. It looks like your I will consider reverting it, but a config.sys option is overkill. Yes, it is. It'll be difficult to revert it as it leaded to numerous other optimisations. Besides, I already explained why I removed it. Why add back an useless feafure without solid argumentation? (Useless as it was setting creation time on each write.) Unless you can make it set creation times only once, which is difficult. Not speaking about access date, which shouldn't be set in DOS as it would mean unexpected writes. In summary, I didn't do this change only to be reverted back because Bart doesn't like it. Don't apply it to his stable branch, but *leave* it in our unstable, please. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Hi, Luchezar Georgiev escribiÃ: I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/ If nobody will use them, then your option (1) is the one to implement. Chinese, Japanese and Korean friends, please express your opinion now. Last not least, we don't have these tables yet, and may not have them. Japanese is different from the other two, at least keyboardwise. Japanese-style DOS allows that the keyboard driver outputs simple characters, thus KEYB is valid, and furthermore, I am precisely implementing the last required bit so that FD-KEYB is good for Japanese. The problem is that one needs another sofware, called Front-end Processor (I seem to recall, someone correct me) that collects bytes from keyboard and also the status of KEYB through some API (being now implemented) so that you have Japanese keyboard support. I don't know much what happens respect to the display adapter. And I know nothing about Korean or Chinese, so I can't help, sorry. Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12-Сен-2004 13:54 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> Show this, please. LG> See it in the CVS, along with the nice additions of Eduardo. CVS isn't accesible for me. >> Let me ask reverse question: why you add this _another FreeDOS specific >> function, which duplicates another specific function_, whereas only some >> version probably support this function (and RBIL is not very clear how!). LG> It's not FreeDOS-specific. It's MS-DOS 4.0 specific. And some software LG> uses it. Why then you not add other-DOSes-specific functions? For example, "INT21/20: S/DOS 1.0+ & PTS-DOS 6.51+ - GET OEM REVISION"? Or INT21/92? "Some" software also use these functions. In case of INT2F/122F "some" software mean mythical Matthias' FREEVER, which noone of us seen it, and it even unknown if this function need for FREEVER at all. LG> Don't ask me more. Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. So "don't ask me more" is not in given case. >> Now your patches mention GPL (which associated with GPL1) LG> No, GPL means *current* version, and the URL points to it. URL is reduced for convenience, but for law clarity (for which you at all mention license) you should mention complate license name. Explicitly. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hi! 12-Сен-2004 14:23 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> * There is no room for the LCASE table, so it won't be possible to load >> the ru/866 pair. BTW, in contary to RBIL (which says that INT21/6503 is present only in "DOS 6.2+ COUNTRY.SYS" and "supports only CP866") MS-DOS with CP866 installed doesn't supports LCASE. B-\ --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hi! BTW, Lucho, if you wish, I may prepare for you macroses in TASM to ease writing more readable and safer country.asm. Probably, someone then may translate these macro to NASM? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12-Сен-2004 14:08 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> I don't understand this. SYS writes 0/FF only into its own images, >> builtin into SYS executables. And, if _after_ SYS someone will change >> boot loader, then 0/FF value also will be replaced. Where is trouble? LG> The trouble is that most SYSes don't bother to set this value - they just LG> copy the whole data area from the old boot sector and replace only the LG> code and OEM ID. So the FF remains there. Verified. _And_ their boot code reuse this field? If not, then this in unimportant, what those SYSes remain in 24h field. >> I think, current behavior (use fixed drive# in case of A:/C: and BIOS >> value in other cases, including HDs), is good and flexible way. LG> Currently, fixed drive number 0 is used for floppies, but for hard disks, LG> FF is used, which is troublesome if FreeDOS is replaced by another DOS LG> later. Well, right now I look at boot code of MS-SYS6, and found, that it not uses 24h offset itself, but pass value from there to kernel. I not check what SYS does with original 24h field, but image inside SYS contains 80h value, so I doubt that MS-SYS preserves this field. LG> Now Jeremy added an option to set the boot drive to an arbitrary LG> value, which solves the issue. But FF is still default for hard disks. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel asmsupt.asm,1.23,1.24 entry.asm,1.27,1.28 fatfs.c,1.70,1.71
Bart Oldeman wrote: On Sun, 12 Sep 2004, Kenneth Davis wrote: merge in some changes from UNSTABLE I wonder about those creation time set removals. It looks like your ... Maybe it should be a config.sys option if it did hurt in certain I will consider reverting it, but a config.sys option is overkill. ... batch files no change just line ending issue which is pretty annoying if you check out on Linux -- I'll really have to ... I'm tired of this issue, if the file is in cvs as a text file, then it should have the proper line ending, end of discussion. If you really insist on a specified control character sequence for the line ending, then the files need to be marked binary and suffer from cvs lack of diff/patch support. Jeremy --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot drive incompatibility with other boot sectors
No, they state several times that ONLY 0 AND 80 may be boot drives. Ok. What about boot managers? The option mentioned below is for boot managers too. For this, an option of SYS will revert back to DL = boot drive Hm. Your arguments sounds reasonable. But I continue to _feel_, that using BIOS info instead fixed value is better (except buggy BIOSes, which pass wrong drive#). Did you read my other message about these BIOSes? I repeat it below. You _suggest_, that _some_ SYS (may) remain untouched 24h field when it overwrite boot sector _and_ its boot code reuse this value? Or you know such _known and usable_ SYS with such (strange!) behavior? If first, then we shouldn't worry about this; if second, then, probably, we should force bugfixing of those SYS. It's like waiting a letter from a dead person, as we say here ;-) Let me repeat my other message, because it seems that it vanished. Award BIOS dated 1999 for Intel i810, and the original IBM PC/AT BIOS don't seem to pass anything in DL on Int 19h. How did I verify it? For those who can't guess, let this be my little secret ;-G (Table 00653) Values Bootstrap loader is called with (IBM BIOS): CS:IP = h:7C00h DH = access bits 7-6,4-0: don't care bit 5: =0 device supported by INT 13 DL = boot drive 00h first floppy 80h first hard disk The above excerpt from the RBIL also proves that not all BIOSes pass boot drive in DL on Int 19h, and even if they do (e.g. IBM BIOS), they pass *only* 0 or 80h. Period. (And end of FF kludge ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
El lun, 13-09-2004 a las 19:19, Luchezar Georgiev escribió: > > In a private mail, Eric suggested a fourth option: Check if there is > > enough room for loading the package and, if not, allocate extra memory > > only for the additional tables. > > > > This will keep the kernel size unchanged and optimze the memory useage, > > as only a percentage of NLS packages are bigger than the default. > > The problem is that the already statically allocated memory for hard-coded > tables will be lost. Not really. In the worst case, only the 4 bytes for the empty DBCS table will be unused. The idea is to overwrite the hardcoded tables for CTYINFO, UCASE, FCHAR, and COLLATE and allocate new memory (if needed) for FUCASE, LCASE and DBCS _only_. > > I've been thinking about how to implement this, and I've come up with > > this: > > > > We could insert a null pointer for subfunction 0 just before subfunction > > 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as > > subfunction 0 does not exist (example patch below). This will add just 5 > > bytes to the tables and can be used as a placeholder for subfunction 3 > > (LCASE). This maintains all the pointers into predictable indexes and > > prevents moving the CTYINFO table when loading a package with LCASE. > > > > When loading a package from COUNTRY.SYS, we should do something like the > > following pseudocode before actually reading the data: > > > > extra_memory = 0; > > > > if (LCASE_is_present) > > extra_memory += 258; /* sizeof(WORD) + actual length */ > > > > if (UCASE_offset != FUCASE_offset) > > extra_memory += 130; > > > > if (DBCS_length != 0) > > extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ > > > > allocate(extra_memory); > > > > And then, read the info overwriting the harcoded tables for UCASE, > > FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for > > LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) > > But we will have a common memory for all the information and could not > distinguish between the beginnings of the different structures. It's > better to allocate memory separately for each one. I don't see the point. You have the array of nlsPointer structures, which tells you where the tables are for each subfunction. If you have a look at nls_hc.asm, maybe it will be clearer. > I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT > SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there > are complete Chinese, Korean and Japanese packages that install their own > font, NLS and keyboard support, and most people will use them and not our > inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY > + KEYBOARD + whatever :-/ > > If nobody will use them, then your option (1) is the one to implement. Not only DBCS. Also LCASE (for Russian) or FUCASE, for other languages. But yes, it is only a percentage. > Chinese, Japanese and Korean friends, please express your opinion now. > > Last not least, we don't have these tables yet, and may not have them. > > Regards, > Lucho Regards, Eduardo. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 13-Сен-2004 19:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> This warning may be only because authors of tose spec may know about >> existance of buggy BIOSes. LG> No, they state several times that ONLY 0 AND 80 may be boot drives. Ok. What about boot managers? >> No, not better. For example: if you use boot manager, which supports LG> For this, an option of SYS will revert back to DL = boot drive Hm. Your arguments sounds reasonable. But I continue to _feel_, that using BIOS info instead fixed value is better (except buggy BIOSes, which pass wrong drive#). >> Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot >> sector, by some strange/buggy reason will preserve FD's boot record >> _field_ "drive number" (offset 0x24) and then its boot code will reuse >> this field? LG> Yes. >> How this alien buggy SYS relates to our boot code and dependence from >> BIOS info? LG> I already explained. If it overwrites our boot sector, it won't boot. You _suggest_, that _some_ SYS (may) remain untouched 24h field when it overwrite boot sector _and_ its boot code reuse this value? Or you know such _known and usable_ SYS with such (strange!) behavior? If first, then we shouldn't worry about this; if second, then, probably, we should force bugfixing of those SYS. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Hola Eduardo, I don't mind adding the changes to nls_hc.asm, but I'm not sure that I like that option. Neither do I like it very much, but (1) and (3) are most straightforward and easiest to implement. In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables. This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default. The problem is that the already statically allocated memory for hard-coded tables will be lost. I've been thinking about how to implement this, and I've come up with this: We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE. When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data: extra_memory = 0; if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */ if (UCASE_offset != FUCASE_offset) extra_memory += 130; if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ allocate(extra_memory); And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) But we will have a common memory for all the information and could not distinguish between the beginnings of the different structures. It's better to allocate memory separately for each one. I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/ If nobody will use them, then your option (1) is the one to implement. Chinese, Japanese and Korean friends, please express your opinion now. Last not least, we don't have these tables yet, and may not have them. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Ie., second disk was enumerated as 80h (and, for example, partitions from it was labeled earlier, than from first disk)? Yes, exactly. This warning may be only because authors of tose spec may know about existance of buggy BIOSes. No, they state several times that ONLY 0 AND 80 may be boot drives. No, not better. For example: if you use boot manager, which supports loading boot record from second disk, then (your) boot code will not work in such configurations, if it will contain 80h. And vice versa: let suggest, that BIOS swaps disks numbers. In this cases you can't boot (your) boot record, if it will contain 81h. For this, an option of SYS will revert back to DL = boot drive Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot sector, by some strange/buggy reason will preserve FD's boot record _field_ "drive number" (offset 0x24) and then its boot code will reuse this field? Yes. How this alien buggy SYS relates to our boot code and dependence from BIOS info? I already explained. If it overwrites our boot sector, it won't boot. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
El lun, 13-09-2004 a las 12:36, Luchezar Georgiev escribió: > Eduardo, couldn't we divide the work between ourselves? If you do the > changes in nls_hc.asm for the third option you offered (make enough room), > I will add the necessary code in config.c ;-) Hi Lucho, I don't mind adding the changes to nls_hc.asm, but I'm not sure that I like that option. In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables. This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default. I've been thinking about how to implement this, and I've come up with this: We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE. When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data: extra_memory = 0; if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */ if (UCASE_offset != FUCASE_offset) extra_memory += 130; if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ allocate(extra_memory); And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) Comments? Eduardo. --- unstable/kernel/kernel/nls_hc.asm 2002-12-09 01:17:14.0 +0100 +++ unstable.new/kernel/kernel/nls_hc.asm 2004-09-13 16:29:08.831007552 +0200 @@ -12,7 +12,7 @@ GLOBAL _nlsPackageHardcoded _nlsPackageHardcoded: DB 000h, 000h, 000h, 000h, 001h, 000h, 0b5h, 001h - DB 00fh, 000h, 059h, 000h, 04eh, 000h, 006h, 000h + DB 00fh, 000h, 059h, 000h, 04eh, 000h, 007h, 000h DB 002h DW ?table2, SEG ?table2 DB 004h @@ -23,6 +23,8 @@ DW ?table6, SEG ?table6 DB 007h DW ?table7, SEG ?table7 + DB 000h + DW 000h , 000h ; Placeholder for table3 (LCASE) GLOBAL _nlsCountryInfoHardcoded _nlsCountryInfoHardcoded: DB 001h --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 13-Сен-2004 12:48 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >>> My AwardBIOS here for example does have such a feature. However, when I >>> look at the boot record of my second hard drive, I see again boot drive >>> = 80. >> Do you try to boot from second drive with this boot record (which >> contains 80h)? And it boots fine (without accessing first disk)? LG> Yes, of course. >>> So, BIOS probably swaps LG> Not probably - surely. Ie., second disk was enumerated as 80h (and, for example, partitions from it was labeled earlier, than from first disk)? >> "Probably"?! In this case it not need to pass to boot code information >> about boot drive! LG> The BIOS Boot specification LG> (http://www.phoenix.com/resources/specs-bbs101.pdf) warns that only 0 and LG> 80h can be safely considered as boot devices, albeit it recommends (but LG> doesn't require) that BIOS passes boot device in DL on Int 19h. The 0/80h LG> limitation "warn" != "limitation". This warning may be only because authors of tose spec may know about existance of buggy BIOSes. LG> is due to the MS-DOS boot sectors, of course. So, whatever we LG> decide, we should remove the FF kludge in any case. I already expressed my LG> opinion - I agree with Jeremy and Eric that choice (2) is better for LG> compatibility reasons. No, not better. For example: if you use boot manager, which supports loading boot record from second disk, then (your) boot code will not work in such configurations, if it will contain 80h. And vice versa: let suggest, that BIOS swaps disks numbers. In this cases you can't boot (your) boot record, if it will contain 81h. >> "Will"? Do you mean, that currend FD boot record (with FFh mask) doesn't >> work when loading FD from second disk?! LG> It works until replaced by another boot sector that tries to boot off LG> drive FF. ?! Lucho, please, reread your sentence! We don't discuss _some_ _buggy_ boot code, which by some strange reason uses FFh as boot drive # (how this relates to FD boot code?), we discuss, should _FD boot code_ expect drive# from BIOS or use fixed values. Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot sector, by some strange/buggy reason will preserve FD's boot record _field_ "drive number" (offset 0x24) and then its boot code will reuse this field? How this alien buggy SYS relates to our boot code and dependence from BIOS info? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
The BIOS Boot specification warns that only 0 and 80h can be [...] [...] interesting enough... Nevertheless, trying it gives me 404... Moved - http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 2F-122F
Hi! 13-Сен-2004 12:04 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >>> In addition, the MS-ish interface allows "revert to real version >>> number" by passing a value of zero. >> RBIL doesn't says this. LG> It does say this. D-2F122F says: DX = DOS version number (h = return LG> true DOS version). Hm, I miss this. Anyway, "return" is ambiguous in this context. :) LG> RBIL also says this is supported by Matthias Paul's LG> FREEVER.COM. Do you see now why I won't remove it? No, I don't see. _If_ freever.com supports only this function, then it useless in (all other versions of) MS-DOS. Why it should be useful in FreeDOS (especially because we have Eric's CALLVER, which (may) use INT21/33FC)? I don't think, that "Matthias" as author of FREEVER doesn't makes this interrupt more important for FreeDOS. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
RE: Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi, >The BIOS Boot specification >(http://www.phoenix.com/resources/specs-bbs101.pdf) warns that only >0 and >80h can be safely considered as boot devices, albeit it recommends The link looks interesting enough... Nevertheless, trying it gives me 404... Do I have to be subscribed? Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hello, Award BIOS dated 1999 for Intel i810, and the original IBM PC/AT BIOS don't seem to pass anything in DL on Int 19h. How did I verify it? For those who can't guess, let this be my little secret ;-G (Table 00653) Values Bootstrap loader is called with (IBM BIOS): CS:IP = h:7C00h DH = access bits 7-6,4-0: don't care bit 5: =0 device supported by INT 13 DL = boot drive 00h first floppy 80h first hard disk The above excerpt from the RBIL also proves that not all BIOSes pass boot drive in DL on Int 19h, and even if they do (e.g. IBM BIOS), they pass *only* 0 or 80h. Period. (And end of FF kludge ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fixing near f-nodes
Hallo Bart, There is really no need to allocate the near fnodes, they can simply be chosen fixed. Sure - great idea! In this case Tom's patch can be removed. That would require split_path and dir_open to take the near fnode as a parameter, etc, and e.g. dos_rename() to do: split_path(path2, fcbname, &fnode2); split_path(path1, fcbname, &fnode1); where fnode1 and fnode2 are the two near fnodes. This is the other real solution I can think of, it's a little more intrusive though. It'd be good. Unfortunately I'm not competent enough to do this change :( Could you try to do it? Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July applied in its full glory :)
Do you mean http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html yes (It doesn't contain other comments but those in the patch.) If you confirm, I can apply it. yes. Just applied and committed (and updated binary on my site ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Eduardo, couldn't we divide the work between ourselves? If you do the changes in nls_hc.asm for the third option you offered (make enough room), I will add the necessary code in config.c ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
Hallo Bart, merge in some changes from UNSTABLE If Bart doesn't like some changes, I don't mind if they're not merged them into "stable" ;-) I wonder about those creation time set removals. It looks like your removing a useful feature here. Sure a reason given is "MSDOS 7.10 doesn't do this". Well, I say, who cares about this specific DOS, Isn't *this* specific OS what we try to emulate as closely as possible (including even its bugs)? many other OS'es *do* set the creation time. Did it hurt that FreeDOS did this? It didn't actually do that. FreeDOS did *always* set the creation time *equal* to the write time. So the creation time didn't hold even a single of bit of information and was therefore misleading. Making it set the creation time *only* once, when a file is created, is surprisingly difficult (I tried and failed), and is not required for a DOS anyway. Let's not try to be bigger catholics than the pope. Maybe it should be a config.sys option if it did hurt in certain (documented) circumstances. Too complex. I like the KISS principle (Keep It Simple, Stupid = KISS :) which is pretty annoying if you check out on Linux -- I'll really have to push a patch to Steffen to allow FreeCOM not to choke on LF-ended batch files... Now when AUTOEXEC.BAT is just one line ending with LF, not CRLF, FreeCOM happily processes it ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
My AwardBIOS here for example does have such a feature. However, when I look at the boot record of my second hard drive, I see again boot drive = 80. Do you try to boot from second drive with this boot record (which contains 80h)? And it boots fine (without accessing first disk)? Yes, of course. So, BIOS probably swaps Not probably - surely. "Probably"?! In this case it not need to pass to boot code information about boot drive! The BIOS Boot specification (http://www.phoenix.com/resources/specs-bbs101.pdf) warns that only 0 and 80h can be safely considered as boot devices, albeit it recommends (but doesn't require) that BIOS passes boot device in DL on Int 19h. The 0/80h limitation is due to the MS-DOS boot sectors, of course. So, whatever we decide, we should remove the FF kludge in any case. I already expressed my opinion - I agree with Jeremy and Eric that choice (2) is better for compatibility reasons. "Will"? Do you mean, that currend FD boot record (with FFh mask) doesn't work when loading FD from second disk?! It works until replaced by another boot sector that tries to boot off drive FF. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July
Hello Luchezar, > Do you mean > http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html yes > (It doesn't contain other comments but those in the patch.) If you > confirm, I can apply it. yes. >> it happens if a int24 handler returns to itself directly, instead of the >> 'normal' way to return to DOS with some error code. > But an Int 24h handler returns with an IRET, so to return to itself means > that it's re-entrant! has nothing to do with reentrancy. a) program installs it's own int24handler. b) critical error happens, int24() gets called. *usually* this sets carry flag etc. and returns to DOS (and DOS gets a chance to free_fnode() etc.) in the observed case (which probably came from some Turbo Pascal library, floating in the net), the program instead pops all (DOS saved) registers from stack, sets some magic flag in the application, and returns immediately to the user adress on the stack - no chance for DOS to reset errorlevel, no chance to free_fnode(). tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Although I dislike the idea of patching the bootsector, choice 2 does seem most compatible and is slightly smaller boot code (as the logic is moved to sys). I agree and prefer method 2 too. The distance between this new patched boot sector offset and the existing boot segment offset seems constant for all boot sectors, so patch location IS uniform ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 2F-122F
In addition, the MS-ish interface allows "revert to real version number" by passing a value of zero. RBIL doesn't says this. It does say this. D-2F122F says: DX = DOS version number (h = return true DOS version). RBIL also says this is supported by Matthias Paul's FREEVER.COM. Do you see now why I won't remove it? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2F-122F
On Mon, 13 Sep 2004, [UTF-8] Aitor SantamarÃa Merino wrote: > Arkady V.Belousov escribiÃ: > > >>>And we even don't may prove this or check how those MS-DOS editions > >>>support this function. > >>> > >>> > >LG> From what I tested, it's only in MS-DOS 4.0 indeed. But I've said I won't > >LG> remove it, period. > > > > But why you add it?! > > > > > I have to agree with Arkady. Two things why I feel it could be inconvenient: > - the extra few bytes it takes > - the fact that, being unique to MS-DOS 4.0, some app may be using this > as MS-DOS 4.0 proof, thus believing that they are living in MS-DOS 4.0, > whereas FreeDOS kernel is more similar to 5.X or 7.X... One problem is that having a user-callable int2f-12 function is a little inconsistent. These guys are all meant to be called from within DOS (perhaps via MSCDEX/NLSFUNC) Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12-Сен-2004 14:28 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev <[EMAIL PROTECTED]>: >>> and removes (parts? of) tom's patch. >> As you wrote youself, it's better to have the whole patch than parts of >> it. And even better is to solve entirely the problem which this kludge >> solves partially. But we don't know the problem :-( te> at least I know the problem - and described it when publishing the patch. tom, please, publish _diff-file_ with your patch, and I think, no one will complain to include your patch. Previously you publish only plain text with quotes. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12-Сен-2004 14:30 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev <[EMAIL PROTECTED]>: >> Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS extensions" ;-) te> are you SURE ? How strange. B-\ I receive this letter two minutes back, whereas I answer yesterday to Lucho's letter, where was answer to this letter. Somewhere works time machine? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 2F-122F
Hi! 13-Сен-2004 04:19 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> how to use it that way ;-). In addition, the MS-ish interface allows EA> "revert to real version number" by passing a value of zero. The extra RBIL doesn't says this. EA> few bytes are really VERY few bytes and they should be in HMA anyway. EA> By having a "set reported version number" function in the kernel, EA> programs like CALLVER / SETVER do not have to hook int 21 themselves and You already have INT21/33FC. Why to introduce _another_ FreeDOS specific function (which not present neither in MS-DOS 5-8, DR-DOS, ROM-DOS, etc)? PS: BTW, Eric, may you recall URL for your CALLVER? Unfortunately, I lost it, but it was need me sometime (because I need to run, say, MS-SYS6 under MS-DOS7). EA> (SETVER is quite complex and changes the version number dynamically, It requres changes in config.sys, and it changes itself. :( --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2F-122F
Hi, Arkady V.Belousov escribiÃ: And we even don't may prove this or check how those MS-DOS editions support this function. LG> From what I tested, it's only in MS-DOS 4.0 indeed. But I've said I won't LG> remove it, period. But why you add it?! I have to agree with Arkady. Two things why I feel it could be inconvenient: - the extra few bytes it takes - the fact that, being unique to MS-DOS 4.0, some app may be using this as MS-DOS 4.0 proof, thus believing that they are living in MS-DOS 4.0, whereas FreeDOS kernel is more similar to 5.X or 7.X... Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12-Сен-2004 12:41 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD> So the options are: KJD> 1) current KJD> Cons: if one needs compatibility with other boot sectors or KJD> has a buggy value passed to the boot sector, one must KJD> explicitly provide the drive value to use (via sys /B # KJD> or with a disk editor) KJD> 2) Alternate KJD> - the boot sector code has at a fixed location KJD> useBIOSorNotFixedLocation: KJD> mov [drive], dl KJD> - SYS is then responsible for determining if BIOS provided value KJD> is used As I understand, there is not possible to determine, if BIOS is buggy or conformant. KJD> Cons: another position specific chunk of code in the boot code Yes. And another stone on the way of optimization. Also, as "kernel.sys" name at end of boot record requires additional code to reuse it. KJD> is moved to sys). Please indicate which choice you prefer, or if you KJD> feel the alternate should be done a simpler method, please specify. I prefer method 1 - it may troublesome on some buggy systems, but on normal machines allows to be more flexible. For example, move bootable disk from one machine to other. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi Tom, On Sun, 12 Sep 2004, tom ehlert wrote: > the only real solution that comes to my mind is to undo the > alloc_fnode() change, even if that costs a few byte in low memory; > if you don't have UMB's, it even saves a few byte (the memory used by > the 2 near_fnodes) If you undo the change than all fnodes are in low RAM (near allocated). Now they're in the HMA (not UMB). If you don't have HMA it would save a few bytes indeed. There is really no need to allocate the near fnodes, they can simply be chosen fixed. That would require split_path and dir_open to take the near fnode as a parameter, etc, and e.g. dos_rename() to do: split_path(path2, fcbname, &fnode2); split_path(path1, fcbname, &fnode1); where fnode1 and fnode2 are the two near fnodes. This is the other real solution I can think of, it's a little more intrusive though. Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Boot sector drive incompatibility with other boot sectors
Hi! 12-Сен-2004 18:06 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> Therefore I vote for a SYS option which lets you decide whether or not >> the 0x80 in the boot sector will be used. The DEFAULT should be, in my >> opinion, to accept the value from the boot manager / MBR / BIOS for >> harddisks. For floppy, 0 will be in the boot sector, and the DEFAULT >> should probably be to ignore the value from the BIOS / boot manager. LG> Why discriminate between floppy and hard disk? As was discussed earlier, there is trouble with some old BIOSes, which not pass boot drive number into boot code. After this discussion was decided to remain fixed value 0 for boot code on diskettes and FFh mask for HDs. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12-Сен-2004 16:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG> Hallo Tom, "D:"==second disk? Second disk is a 81h value. >>> Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS >>> extensions" ;-) >> are you SURE ? Strange, I not seen letters with these discussions (after I send my letter with sentence from top). B-\ LG> Just checked that, and now I'm even more sure. (Rhetoric question) How you checked this? Anyway, you may store into boot record fixed value for boot drive or even precompute partition properties, but sure: later, with advanced tools, you will have the troubles (like there was troubles with Partition Magic, which resizes partition, when our boot code was contains some precomputed by SYS values). So, again: why not use BIOS information which it passes to us (and, thus, make less flexible/rocksolid solution)?! >> I remember a BIOS that had the option to boot from 2'nd drive. >> this only makes sense if DOS then boots from 0x81. LG> My AwardBIOS here for example does have such a feature. However, when I LG> look at the boot record of my second hard drive, I see again boot drive = LG> 80. Do you try to boot from second drive with this boot record (which contains 80h)? And it boots fine (without accessing first disk)? LG> So, BIOS probably swaps "Probably"?! In this case it not need to pass to boot code information about boot drive! LG> the hard drives in this case, much the same LG> way it can swap the floppy drives A: and B:, if that feature is enabled. See the difference: _swap_ A/B and _boot_ C or D. LG> And if so, our "extensions" will be in conflict with the BIOS. "Will"? Do you mean, that currend FD boot record (with FFh mask) doesn't work when loading FD from second disk?! LG> Therefore, LG> I propose to set the default boot drive to 0 for A/B (as it is now), 80 LG> for C/D and FF in all other cases, unless /B specified. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2F-122F
Hi! 12-Сен-2004 17:45 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >>> RBIL is not very clear how! LG> RBIL is correct that it's only for MS-DOS 4.0. I mean, that it not explains, that "zero value should restore original version", that "changed version affects only INT21/30", that "input value checked or not checked", etc. >> And we even don't may prove this or check how those MS-DOS editions >> support this function. LG> From what I tested, it's only in MS-DOS 4.0 indeed. But I've said I won't LG> remove it, period. But why you add it?! --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] break.c, inithma.c
Hi!
12-Сен-2004 18:42 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>>> unsigned char check_handle_break(struct dhdr FAR **pdev)
>>> {
>>> - unsigned char c;
>>> + unsigned char c = 0;
>>>if (ctrl_break_pressed() ||
>>> (c = (unsigned char)ndread(&syscon)) == CTL_C
>>> ||
>>>*pdev != syscon && (c = (unsigned char)ndread(pdev))== CTL_C)
>>>{
>>> handle(break(pdev, -1);
>>>}
>>>return c;
>>> }
>> Wrong. If no Ctrl-break (ctrl_break_pressed() returns false), then
>> called second part of condition (c = ndread()). So, my code _is_
>> correct, and this extra assignemnt is useless code spending.
LG> *You* are wrong. If "ctrl_break_pressed()" returns true, "c" (and
LG> therefore the function return value) would be *undefined* without my patch!
If ctrl_break_pressed() returns true, then handle_break() is called,
and it never returns! Note: _I_ place "return" after "if()" with call to
handle_break() only because BC doesn't support "aborts" pragma, and I wish
to eliminate warnings.
>> Unfortunately, newer standards prohibit to assign nonterminated strings
>> to arrays (ie. 5-character string "VDISK" _plus_ trerminating zero not
>> fit into 5-bytes array, so newer compilers should compain).
LG> Surprisingly, even OpenWatcom 1.3 (so new that it's not even announced!)
LG> doesn't complain! ;-)
By "new" I mean not "latest", but "supporting latest standards". OW
supports not all latest introductions in standards. For example, WPP (was)
not support "int main()" without "return".
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: Improve DBCS support
Hola, Eduardo! This patch adds DBCS support to DOS-65-23 (Determine if a character represents yes/no response) as specified by RBIL, and fixes DOS-63-00 (Get Double Byte Character Set lead-byte table.) It now returns the DBCS table from the active NLS package, not the harcoded one. Applies to up-to-date CVS UNSTABLE. It's at http://perso.wanadoo.es/samelborp/dbcs.zip Thanks. I saw, applied, built, committed it and updated my binary ;-) Now let's see what can we do for reading the new parts of COUNTRY.SYS Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
So the options are: 1) current - use 0xFF in BPB.drive to indicate to boot code to use BIOS provided drive in DL, otherwise use value in BPB.drive - the boot sector code can be anywhere and is similar to: cmp [BPB.drive], 0xFF jmp dont_use_bios mov [BPB.drive], dl dont_use_bios: - sys defaults to setting BPB.drive to 0 for floppy (A: or B:) and 0xFF for any other drive, but using /B # option you can have it set any arbitrary value you want Pros: the detection code is in the boot sector, default behavior handles whatever BIOS drive booted from even if changed since SYS was performed and no fixed position code. No position specific code to keep in sync with sys. [This also works with both our FD bootsector and the OEM one.] Cons: if one needs compatibility with other boot sectors or has a buggy value passed to the boot sector, one must explicitly provide the drive value to use (via sys /B # or with a disk editor) 2) Alternate - use 0 or 80 only in the boot sector (or really any value the user wants, but default to 0 or 80) - the boot sector code has at a fixed location useBIOSorNotFixedLocation: mov [drive], dl - SYS is then responsible for determining if BIOS provided value is used or not by patching useBIOSorNotFixedLocation with NOPs if BPB.drive is to be used or not touching it to use provided value e.g. SYS C: /USEBPBDRIVE sets BPB.drive to 0x80 and NOPs out the mov [drive], dl code, but SYS C: /B 81 only sets the BPB.drive to 0x81 still using the provided boot drive not the value in BPB.drive (so the 0x81 is for other programs). A value of 0xFF will no longer be a magic value. Pros: seems most compatible as our boot sector will have 0 or 80 most of the time, user can still specify arbitrary value Cons: another position specific chunk of code in the boot code for sys to keep up with. Needs another option or to change the option to indicate both value in the BPB and whether to patch out the use of the provided value or not. (In case your curious, we only need to set [BPB.drive] once as later we reload and use the value in [BPB.drive], which if not overwritten by DL will be the value put in the BPB by sys.) Although I dislike the idea of patching the bootsector, choice 2 does seem most compatible and is slightly smaller boot code (as the logic is moved to sys). Please indicate which choice you prefer, or if you feel the alternate should be done a simpler method, please specify. Thanks, Jeremy --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] break.c, inithma.c
unsigned char check_handle_break(struct dhdr FAR **pdev)
{
- unsigned char c;
+ unsigned char c = 0;
if (ctrl_break_pressed() ||
(c = (unsigned char)ndread(&syscon)) == CTL_C
||
*pdev != syscon && (c = (unsigned char)ndread(pdev))== CTL_C)
{
handle(break(pdev, -1);
}
return c;
}
Wrong. If no Ctrl-break (ctrl_break_pressed() returns false), then
called second part of condition (c = ndread()). So, my code _is_
correct, and this extra assignemnt is useless code spending.
*You* are wrong. If "ctrl_break_pressed()" returns true, "c" (and
therefore the function return value) would be *undefined* without my patch!
+static struct { /* Boot sector of a RAM-Disk */
+ UBYTE dummy1[3];/* HIMEM.SYS uses 3, but FDXMS uses
2 */
+ char Name[5];
[...]
+} VDISK_BOOT_SECTOR = {
+ {0xcf,' ',' '},
+ {"VDISK"},
Unfortunately, newer standards prohibit to assign nonterminated strings
to arrays (ie. 5-character string "VDISK" _plus_ trerminating zero not
fit into 5-bytes array, so newer compilers should compain).
Surprisingly, even OpenWatcom 1.3 (so new that it's not even announced!)
doesn't complain! ;-)
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July
Hallo Tom, at least I know the problem - and described it when publishing the patch. Do you mean http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html (It doesn't contain other comments but those in the patch.) If you confirm, I can apply it. it happens if a int24 handler returns to itself directly, instead of the 'normal' way to return to DOS with some error code. But an Int 24h handler returns with an IRET, so to return to itself means that it's re-entrant! In that case the near f_nodes are never freed (until the program terminates) the only real solution that comes to my mind is to undo the alloc_fnode() change, even if that costs a few byte in low memory; if you don't have UMB's, it even saves a few byte (the memory used by the 2 near_fnodes) You mean, to undo Bart's changes? Only Bart can do this... Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Boot sector drive incompatibility with other boot sectors
Hallo, Therefore I vote for a SYS option which lets you decide whether or not the 0x80 in the boot sector will be used. The DEFAULT should be, in my opinion, to accept the value from the boot manager / MBR / BIOS for harddisks. For floppy, 0 will be in the boot sector, and the DEFAULT should probably be to ignore the value from the BIOS / boot manager. Why discriminate between floppy and hard disk? So: - no more 0xff - always write 0 or 0x80 I agree with both of the above. - allow control (patching, e.g. "mov variable,reg <-> mov reg,variable") of the actual source (value from caller versus value in boot sector) of the used boot drive number. Can you give more details for the above? I don't like patching boot sectors at non-uniform places. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] showing off with low RAM?
Hallo Eric, we already do have 622k low DOS RAM free in a quite straightforward configuration (in DOSEMU, where HIMEM / EMM386 take almost no memory, even 627k), and I never met any program which really needed more than 590k, so this is only about bragging. Exactly. I have 629 KB free in FreeDOS and that's enough for me. More interesting and useful would definitely be something like my suggested "checksum some/all SFT entry fields and force an update of the corresponding f_node if a SFT entry is found to be changed from outside. I believe this would be necessary to allow DOS boxes to work inside Win 3.x standard mode (DSWAP/WSWAP)." Then go ahead, what are you waiting for? You do have write CVS access, don't you? ;-) But remember what Tom said about the 3m long stick (that he won't touch the unstable kernel). Got the hint? ;-) programs which call int 13 directly have to check for DMA boundaries themselves) nor do we have the "original int vectors 10/13/15/19/1b" data at 70:100 or the DDPT at 0:522 (we have it at 70:0). Hard to tell which compatibility problems those details could cause. If I remember correctly, Bart had some solid arguments against moving from 60:0 to 70:0... Bonus question: Does MS DOS actually call int 25/26 itself or does it - like FreeDOS - only offer int 25/26 for disk tools, but calls the device drivers directly for everything else? It's like FreeDOS - doesn't call Int 25h/26h itself but calls the device drivers directly. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2F-122F
RBIL is not very clear how! RBIL is correct that it's only for MS-DOS 4.0. And we even don't may prove this or check how those MS-DOS editions support this function. From what I tested, it's only in MS-DOS 4.0 indeed. But I've said I won't remove it, period. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hallo Tom, "D:"==second disk? Second disk is a 81h value. Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS extensions" ;-) are you SURE ? Just checked that, and now I'm even more sure. I remember a BIOS that had the option to boot from 2'nd drive. this only makes sense if DOS then boots from 0x81. My AwardBIOS here for example does have such a feature. However, when I look at the boot record of my second hard drive, I see again boot drive = 80. So, BIOS probably swaps the hard drives in this case, much the same way it can swap the floppy drives A: and B:, if that feature is enabled. And if so, our "extensions" will be in conflict with the BIOS. Therefore, I propose to set the default boot drive to 0 for A/B (as it is now), 80 for C/D and FF in all other cases, unless /B specified. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12-Сен-2004 14:28 Arkady V.Belousov wrote to [EMAIL PROTECTED]: >>> And what about INT2F/122F? LG>> Although only MS-DOS 4.0 had it, I won't remove it AVB> Let me ask reverse question: why you add this _another FreeDOS AVB> specific AVB> function, which duplicates another specific function_, whereas only some AVB> version "only some _MS-DOS_ versions" AVB> probably support this function (and RBIL is not very clear how!). And we even don't may prove this or check how those MS-DOS editions support this function. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hello Luchezar, >> and removes (parts? of) tom's patch. > As you wrote youself, it's better to have the whole patch than parts of > it. And even better is to solve entirely the problem which this kludge > solves partially. But we don't know the problem :-( at least I know the problem - and described it when publishing the patch. it happens if a int24 handler returns to itself directly, instead of the 'normal' way to return to DOS with some error code. In that case the near f_nodes are never freed (until the program terminates) the only real solution that comes to my mind is to undo the alloc_fnode() change, even if that costs a few byte in low memory; if you don't have UMB's, it even saves a few byte (the memory used by the 2 near_fnodes) tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hello Luchezar, >> "D:"==second disk? Second disk is a 81h value. > Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS > extensions" ;-) are you SURE ? I remember a BIOS that had the option to boot from 2'nd drive. this only makes sense if DOS then boots from 0x81. tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hola, Eduardo! OK, done again. New patch in: http://perso.wanadoo.es/samelborp/country3.zip It also adds complete NLS info for (de,at)/(850,858,437), and keeps the entry for tr/850, but makes tr/857 the default. Thanks! Just applied it, tested, uploaded the 7K binary to my page, and committed to CVS. Please, do it yourself. However, you should keep in mind the following limitations if you overwrite the kernel hardcoded tables: * The hardcoded NLS package points the UCASE and FUCASE pointers to the same table. This is OK for the most of the country/codepage pairs, but will not allow loading info for codepage 852. * The harcoded package does not have enough space for a non-empty DBCS table, so it won't be possible to load the info for Japanese, Chinese or any other language with DBCS. * There is no room for the LCASE table, so it won't be possible to load the ru/866 pair. Hmm... these limitations make me doubt that I can cope well enough :-( Any other volunteers? I see three options: - Overwrite the hardcoded tables for "compatible" packages and just throw a message like "NLS package too complex. Use NLSFUNC" if the package has FUCASE, LCASE or non-empty DBCS (I don't remember who suggested that) - Leave the hardcoded pages untouched and allocate memory for the new package, then chain to nlsInfo.chain and make it the active package. This is what FD NLSFUNC does and what I think that Steffen had in mind when designing the nls support. - This one will not make me very popular :-) : Make enough room in the hardcoded tables. This will mean 258 (LCASE) + 130 (FUCASE) + 132 (DBCS) = 520 more bytes. Probably 132 bytes for DBCS is way too much and 16 or 32 should be enough in practice, but this is the theoretical maximum, AFAIK. I'd prefer the last approach. But let's hear other's opinions too before starting to write it. Thanks, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
I don't understand this. SYS writes 0/FF only into its own images, builtin into SYS executables. And, if _after_ SYS someone will change boot loader, then 0/FF value also will be replaced. Where is trouble? The trouble is that most SYSes don't bother to set this value - they just copy the whole data area from the old boot sector and replace only the code and OEM ID. So the FF remains there. Verified. "D:"==second disk? Second disk is a 81h value. Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS extensions" ;-) I think, current behavior (use fixed drive# in case of A:/C: and BIOS value in other cases, including HDs), is good and flexible way. Currently, fixed drive number 0 is used for floppies, but for hard disks, FF is used, which is troublesome if FreeDOS is replaced by another DOS later. Now Jeremy added an option to set the boot drive to an arbitrary value, which solves the issue. But FF is still default for hard disks. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Здравствуйте, Аркадий! Show this, please. See it in the CVS, along with the nice additions of Eduardo. Let me ask reverse question: why you add this _another FreeDOS specific function, which duplicates another specific function_, whereas only some version probably support this function (and RBIL is not very clear how!). It's not FreeDOS-specific. It's MS-DOS 4.0 specific. And some software uses it. Don't ask me more. Now your patches mention GPL (which associated with GPL1) No, GPL means *current* version, and the URL points to it. and removes (parts? of) tom's patch. As you wrote youself, it's better to have the whole patch than parts of it. And even better is to solve entirely the problem which this kludge solves partially. But we don't know the problem :-( Пока, Лъчо --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 10-Сен-2004 10:50 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> above shown MASM/TASM style, when _text_ with delimiters (spaces and/or >> comas) enclosed into brackets (<99h,0,0,0,0>). This allows to pass >> enclosed content as one argument. This is need, because list my be >> different: eg, <"RUB",0,0>. How deal with this in NASM, I don't know. LG> Neither do I. May be, Bart help us? LG> Anyway, it's now converted to the old nice table format ;-) Show this, please. >> And what about INT2F/122F? LG> Although only MS-DOS 4.0 had it, I won't remove it Let me ask reverse question: why you add this _another FreeDOS specific function, which duplicates another specific function_, whereas only some version probably support this function (and RBIL is not very clear how!). LG> (and it affects os_setver_m**or as I noted ;-) ? ...(Speech about GPL1 usage)... >> "rare" not equal to "nonexisting". :) LG> Exactly as the case with the Tom's f_nodes kludge ;-) And? Now your patches mention GPL (which associated with GPL1) and removes (parts? of) tom's patch. PS: what about other issues: - MK_UWORD() instead "<< 8 |" in INT21/30? - notes and questions about history.txt? About history.txt. After carefull rereading, I _suggest_ I understand what there mentioned. Let me rephrase: > +- zero serial number of Int 21h/30h (else buggy 32RTM thrashed stack) > +- added Int 2Fh/2Fh processing to set DOS version as per MS-DOS 4.0 > +* autoexec.bat now single-line for FreeCOM compatibility when EOL=LF > +* config.sys: all commands removed as they were close to defaults > + - (with Bart) LoL pointer made const (saves some size for Watcom) > + - revision sequence now initialised along with DOS version in LoL > +* makefile: object files reordered to gain ~300B packed size - clear CX after INT21/30, else buggy Borland's 32RTM trashes stack. - added another FreeDOS specific function INT2F/122F, which duplicates INT21/33FC and, probably, similr to one, which supported by (some?) MS-DOS 4.0 (only) editions. - autoexec.bat now contains only one line, without trailing LF or CRLF (this eases FreeCOM compatability, because MS-DOS shells doesn't parses LF as line end). - config.sys now empty, because kernel defaults are optimal. - (by Bart) LoL pointers... - LoL->rev_number now initialized along with DOS version in main.c. - makefile: object files reordered, this reduces packed kernel by ~300 bytes. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hi! 15-Авг-2004 20:24 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: >> - lr.BH = OEM_ID; >> - lr.CH = REVISION_MAJOR; /* JPP */ >> - lr.CL = REVISION_MINOR; >> - lr.BL = REVISION_SEQ; >> + lr.BX = (OEM_ID << 8) | REVISION_SEQ; >> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes BO> tabs?). There's also a pointless "optimization", that the compiler can do BO> for us as well. "Can" != to "will" and/or "my". Yes, Watcom (but not, say, Borland) (sometime) may join adjacent memory writes into memory, but there writes into BX are interspersed. Also, to make more readable code, I add macro MK_UWORD(): "lr.BX = MK_UWORD (OEM_ID, REVISION_SEQ);". --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 10-Сен-2004 20:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG> "brain-dead" BIOSes if the boot drive is A: (but not if it's C:), the FF LG> value written to by SYS causes a compatibility problem. What happens if LG> someone decides to overwrite our boot sector later with a boot sector from LG> another DOS? The FF will remain there (I checked that with PC-DOS) and the LG> new boot sector will try to boot off drive FF, which will fail. Being too LG> smart sometimes hurts (if everyone else is dumb ;-) I don't understand this. SYS writes 0/FF only into its own images, builtin into SYS executables. And, if _after_ SYS someone will change boot loader, then 0/FF value also will be replaced. Where is trouble? Or, do you mean, that someone will _add_ own boot sector _into SYS_? But added boot sectors should follow some rules, including "boot drive field" (which, of course, internally may be ignored). LG> So, I propose that SYS stores 0 if the drive is A: or B:, 80 if the drive LG> is C: or D:, "D:"==second disk? Second disk is a 81h value. LG> and FF in all other cases, and that we add a special boot LG> drive option that can be used by advanced users to store whatever value LG> they like. We could also just leave that value unchanged from the old boot LG> sector as most other SYSes doo, For this, SYS should verify, that it knows old boot record andr that mask is placed at expected position. Too fuzzy and ambuguous. LG> thus placing the responcibility on FORMAT LG> ;-) Please express your opinions on this issue. Changing the SYS behaviour LG> is easy, but taking the right decision isn't. I think, current behavior (use fixed drive# in case of A:/C: and BIOS value in other cases, including HDs), is good and flexible way. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hi! 15-Авг-2004 21:59 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO> BC isn't a target for freedos optimizations; there's one and only one BO> target to optimize for : WATCOM. BO> so BC specific optimization is a waste of time (ours and yours) BO> This just being tom's opinion but I still agree -- I agree too, but _small_ optimizations, like discussed joined write into lr.BX, _may_ be applied, because they (may) help for other compilers too. BO> I even agree more than BO> I did a couple months ago, that's why I rejected my own idea of using BO> "_seg *" pointers. I played for a while again with Turbo C++ back then but BO> in the end decided that the difference was just too big. After my playing with _seg (you may see its usage in "unstable" branch through MK_SEG_PTR()) I see the noticeable code reduction for Borland. Though, Borland contains bug also there, it related to conversion literal values to far pointers. :( --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel source zips Re:...
Arkady V.Belousov wrote: ... (I'm reading his question from the archive, never getting it myself) ... http://freedos.sourceforge.net/kernel.UNSTABLE.tgz will be http://freedos.sourceforge.net/kernel/kernel.UNSTABLE.tgz and updated regulary once sourceforge reenables cronjobs, currently it and /kernel/kernel.tgz are not updated on sf except manually (and I don't have write access to /kernel/kernel.tgz). The fdos.org/bootdisks/autogen/source_core*.zip will remain and continue to be updated when I update the boot disks. These contain both kernel and freecom source and are packaged for others to redistribute the source if they redistribute the bootdisks. The purpose of this page is to provide examples and hopefully useful FreeDOS boot disks, including source to help ensure licenses are followed; the kernel source here is just an artifact of this and was initially simpler for me to point others here. [I did finally update my script as you suggested to store the seperate freecom/kernel zips and then compress the single source_core one.] The fdos.org/bootdisks/autogen/kernel.* should not be used, instead use the fdos.org/kernel/ ones. Any kernel related stuff (information, builds, source, etc) will be in the kernel directory to keep it separate from my bootdisk work. To reiterate: The cvs source on sourceforge should be the primary location for obtaining source if possible. It contains both the stable branch and the development branch and tags for all release builds. When sourceforge reenables cron, nightly tarballs will be available on http://freedos.sourceforge.net/kernel/kernel*.tgz and contains a snapshot of the cvs sources. On my site I have a dedicated page for my involvement with kernel development, http://www.fdos.org/kernel/ which already includes daily zips of the cvs source from the stable and development branches and will contain builds once I get around to writing the batch files to do so. Hope everyone is clear now, Jeremy :-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hi, Lucho, El sáb, 11-09-2004 a las 19:56, Luchezar Georgiev escribió: > Thanks! But earlier, I changed the format of the CTYINFO table back to the > old, much more readable format, by using a macro (idea by Arkady). So it > won't apply. Would it be too difficult for you to modify it for the new > COUNTRY.ASM? You can update it from unstable CVS branch. When I can apply OK, done again. New patch in: http://perso.wanadoo.es/samelborp/country3.zip It also adds complete NLS info for (de,at)/(850,858,437), and keeps the entry for tr/850, but makes tr/857 the default. > it successfully, I can try to write a code to read the tables from > COUNTRY.SYS into the kernel tables (unless you want to do this yourself, > of course ;-) Please, do it yourself. However, you should keep in mind the following limitations if you overwrite the kernel hardcoded tables: * The hardcoded NLS package points the UCASE and FUCASE pointers to the same table. This is OK for the most of the country/codepage pairs, but will not allow loading info for codepage 852. * The harcoded package does not have enough space for a non-empty DBCS table, so it won't be possible to load the info for Japanese, Chinese or any other language with DBCS. * There is no room for the LCASE table, so it won't be possible to load the ru/866 pair. I see three options: - Overwrite the hardcoded tables for "compatible" packages and just throw a message like "NLS package too complex. Use NLSFUNC" if the package has FUCASE, LCASE or non-empty DBCS (I don't remember who suggested that) - Leave the hardcoded pages untouched and allocate memory for the new package, then chain to nlsInfo.chain and make it the active package. This is what FD NLSFUNC does and what I think that Steffen had in mind when designing the nls support. - This one will not make me very popular :-) : Make enough room in the hardcoded tables. This will mean 258 (LCASE) + 130 (FUCASE) + 132 (DBCS) = 520 more bytes. Probably 132 bytes for DBCS is way too much and 16 or 32 should be enough in practice, but this is the theoretical maximum, AFAIK. Eduardo. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PRF.C test fails for [far] pointers
On Sat, 11 Sep 2004, Luchezar Georgiev wrote: > By the way, why are they so different in various compilers, I don't know. > and why Bruce BCC macros were chosen? There were simple and worked. You can see that older prf.c versions did not use the va_* macros at all, so I looked for a working set to avoid having to depend on compiler headers for the kernel compilation. The Watcom implementation of va_* is a little unusual, and comparing it we can even see that the bcc macros give more compact code than #include . Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Boot sector drive incompatibility with other boot sectors
Hallo Eric, I think there should be a command line option for SYS, yes. Jeremy already implemented an option to choose the exact value of stored boot drive if the target SYS drive is not a floppy. The default value is FF, as it was before. I'd use 80, for example. For floppy, I vote for default 00. Of course. For harddisk, I am undecided. Only very few boot managers fail to pass the correct drive number to the boot sector. Some even need the boot sector to follow the value (e.g. you should be able to boot FreeDOS from drive 0x81 with help of the LILO "table" option). I remember that Bart or someone else pointed out to a buggy Toshiba BIOS which had inspired the FF kludge. But I doubt that there are other such buggy BIOSes to justify keeping that kludge further. My suggestion - maybe kludgy - would be to STORE a value of 80 but to USE the value passed by the MBR / boot manager! Good suggestion! I agree with you, however patching the boot sector isn't something I like :-/ Recently we had a boot sector which used "shift register by 4 bits" opcode. Oops. Jeremy already fixed that. Rejoyce, 8088-ers ;-) I don't like very much having to patch one more value in the boot sector... The latest SYS now has the option, so the issue is now somewhat solved. Jeremy will decide whether to follow your advice. Thanks, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hola Eduardo, This patch adds complete NLS tables to COUNTRY.SYS for the following country/codepage pairs: es/850, es/437, us/437, us/850, uk/850, uk/437, ar/850, ar/437, la/850, la/437, au/437, au/850 Includes an extension: table 23 (Yes and No chars). As it is a bit long, you can download it from: http://perso.wanadoo.es/samelborp/country.zip Thanks! But earlier, I changed the format of the CTYINFO table back to the old, much more readable format, by using a macro (idea by Arkady). So it won't apply. Would it be too difficult for you to modify it for the new COUNTRY.ASM? You can update it from unstable CVS branch. When I can apply it successfully, I can try to write a code to read the tables from COUNTRY.SYS into the kernel tables (unless you want to do this yourself, of course ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PRF.C test fails for [far] pointers
Hello Bart - it's nice to hear from you again! the only thing wrong is the comment: you have to use -DFORSYS. Otherwise the libc printf (not the one in prf.c) is used, and in the small model this prints indeed a near pointer for %p and 1234:5678 (simply 5678). Thank you for this explanation. (Tom also answered me that with -DFORSYS everything works fine.) Today I understood this myself while trying to fix the %l bug I had introduced with my unstable PRF.C optimisation two days ago. I didn't realise that I got a bug, because I did the test without -DFORSYS and the libc printf worked fine except for %p - same as the unstable version. Fortunately I fixed the bug. Also I changed PRF.C to include the internal printf even if only TEST is defined. This way the variable argument macros are included in the test too, as they're used by the kernel. By the way, why are they so different in various compilers, and why Bruce BCC macros were chosen? Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
El sáb, 11-09-2004 a las 01:08, Aitor Santamaría Merino escribió: > What about adding CP 858 for those for which 850 is standard? > It is exactly equal to 850, except that it replaces the turk dotless i > (850 does not make sense for Turkey) with the EURO character. > Henrique knows more about this (the position of the euro in the table). > As this does not make a change into collating tables, > uppercasing/lowercasing, etc, it will not make a big difference, except > when NLSFUNC calls all devices: DISPLAY (and indirectly KEYB) are ready > for 858, which I (and I guess many more users) prefer over 850 because > of the possibility to use the EURO sign (even if 850 is widely used as > "standard"). OK, done. I've added CP858 entries for all the countries that also use CP850. For those countries that use the euro currency, I've updated the country specific info to use the euro sign with CP858 (character 0D5h). I've also added new collation tables for Spanish and English, as in cp858 the character 0D5h collates as '$', not as 'I'. Also, I've changed the entry for Turkey to use CP857 instead of CP850. I've uploaded a new patch to: http://perso.wanadoo.es/samelborp/country2.zip Eduardo. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
What about adding CP 858 for those for which 850 is standard? It is exactly equal to 850, except that it replaces the turk dotless i (850 does not make sense for Turkey) with the EURO character. Henrique knows more about this (the position of the euro in the table). As this does not make a change into collating tables, uppercasing/lowercasing, etc, it will not make a big difference, except when NLSFUNC calls all devices: DISPLAY (and indirectly KEYB) are ready for 858, which I (and I guess many more users) prefer over 850 because of the possibility to use the EURO sign (even if 850 is widely used as "standard"). Aitor Eduardo Casino escribió: Hello, This patch adds complete NLS tables to COUNTRY.SYS for the following country/codepage pairs: es/850, es/437, us/437, us/850, uk/850, uk/437, ar/850, ar/437, la/850, la/437, au/437, au/850 --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PRF.C test fails for [far] pointers
On Fri, 10 Sep 2004, Luchezar Georgiev wrote: > Tom, the PRF.C test for %p (far pointers) fails for both kernel branches > (shows just 5678 instead of 1234:5678). I think that you've written most > of the code there, so could you please take a closer look - what could be > wrong with it? Thank you... Hi Lucho, the only thing wrong is the comment: you have to use -DFORSYS. Otherwise the libc printf (not the one in prf.c) is used, and in the small model this prints indeed a near pointer for %p and 1234:5678 (simply 5678). Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
above shown MASM/TASM style, when _text_ with delimiters (spaces and/or comas) enclosed into brackets (<99h,0,0,0,0>). This allows to pass enclosed content as one argument. This is need, because list my be different: eg, <"RUB",0,0>. How deal with this in NASM, I don't know. Neither do I. Anyway, it's now converted to the old nice table format ;-) Also, what about reference from __il to _me (instead _il?)? Fixed. (Has nothing to do with the Israeli/Arab conflict ;-) And what about INT2F/122F? Although only MS-DOS 4.0 had it, I won't remove it (and it affects os_setver_m**or as I noted ;-) "rare" not equal to "nonexisting". :) Exactly as the case with the Tom's f_nodes kludge ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hello, I uploaded the wrong patch to my page. I have updated it now, so please download it again from the same location: http://perso.wanadoo.es/samelborp/country.zip Sorry for the inconvenience. Eduardo. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Informer by Kondakov K.V.
Hi Justin, My sound card is a Creative Labs Sound Blaster 16/AWE32 ISA. With a slightly earlier card (Creative Labs Sound Blaster 16/PnP ISA) Informer happily works on my other machine under the same unstable kernel. NSSI works there only if I disable the CD-ROM driver (no UDMA drives there) but then creates bad report file (CHKDSK complains) for some reason :-( Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 9-Сен-2004 20:56 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> Of course, entry may be defined through macro. Someting like: >> ENTRY 1,437,MDY,<"$",0,0,0,0>, ",",".","-",":",0,2,_12 ; US >> ENTRY 785,864,DMY,<0A4h,0,0,0,0>,".",",","/",":",3,3,_12 ; Middle East >> ENTRY 972,862,DMY,<99h,0,0,0,0>, ",","."," ",":",2,2,_24 ; Israel LG> Good idea (You're king of macros ;-) Unfortunately, I not known with NASM macro language. :( LG> I'll try to implment it... Note: above shown MASM/TASM style, when _text_ with delimiters (spaces and/or comas) enclosed into brackets (<99h,0,0,0,0>). This allows to pass enclosed content as one argument. This is need, because list my be different: eg, <"RUB",0,0>. How deal with this in NASM, I don't know. Also, what about reference from __il to _me (instead _il?)? And what about INT2F/122F? >> I think, here is mistake, because me use GPL2, not plain GPL. LG> The first version of the GPL is now very rare. "rare" not equal to "nonexisting". :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel source zips Re:...
Hi! 8-Сен-2004 19:32 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD> If sourceforge has cron working, tarballs are there still, additionally: KJD> http://www.fdos.org/kernel/kernel.HEAD.zip for stable sources KJD> http://www.fdos.org/kernel/kernel.UNSTABLE.zip for dev sources BTW, what about next pathes: http://freedos.sourceforge.net/kernel.UNSTABLE.tgz http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip http://www.fdos.org/bootdisks/autogen/source_core.zip http://www.fdos.org/bootdisks/autogen/kernel.UNSTABLE.zip http://www.fdos.org/bootdisks/autogen/kernel.zip --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel source zips Re:...
Hi! 8-Сен-2004 19:32 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: >> Third (or 5th?) times of asking (without answer): where and how >> download latest (unstable) kernel sources? And, as I understand, there is KJD> If sourceforge has cron working, tarballs are there still, additionally: KJD> http://www.fdos.org/kernel/kernel.HEAD.zip for stable sources KJD> http://www.fdos.org/kernel/kernel.UNSTABLE.zip for dev sources Fine. What is "HEAD"? Original 2035? "UNSTABLE" - is where you apply reviewed by you patches? But, as I understand, Lucho makes more patches, than you already apply. (BTW, Lucho, I note, you apply (most) of my code optimizations and cleanups. Thank you. :) KJD> The fdos.org sources will be updated regularly and not change KJD> (for a good while anyway). Fine. I wrote these pathes and review these archives. KJD> I will be adding bilds to the kernel/ directory to, ? KJD> just haven't had a chance to set it up. >> now 4 alternate trees: 2035, 2035-tom, 2035-Lucho and 2035-Jeremy? KJD> No. There is the stable branch (which should be similar to Tom's, KJD> though yes he has his own as others may?), and then the unstable/dev KJD> branch, which is where Lucho changes and some stuff that I'm doing KJD> that I haven't tested enough to be considered stable. You mean, you apply _all_ patches from Lucho? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel source zips Re:...
Hi! 8-Сен-2004 19:32 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: >> Third (or 5th?) times of asking (without answer): where and how >> download latest (unstable) kernel sources? And, as I understand, there is KJD> If sourceforge has cron working, tarballs are there still, additionally: KJD> http://www.fdos.org/kernel/kernel.HEAD.zip for stable sources KJD> http://www.fdos.org/kernel/kernel.UNSTABLE.zip for dev sources Fine. What is "HEAD"? Original 2035? "UNSTABLE" - is where you apply reviewed by you patches? But, as I understand, Lucho makes more patches, than you already apply. (BTW, Lucho, I note, you apply (most) of my code optimizations and cleanups. Thank you. :) KJD> The fdos.org sources will be updated regularly and not change KJD> (for a good while anyway). Fine. I wrote these pathes and review these archives. KJD> I will be adding bilds to the kernel/ directory to, ? KJD> just haven't had a chance to set it up. >> now 4 alternate trees: 2035, 2035-tom, 2035-Lucho and 2035-Jeremy? KJD> No. There is the stable branch (which should be similar to Tom's, KJD> though yes he has his own as others may?), and then the unstable/dev KJD> branch, which is where Lucho changes and some stuff that I'm doing KJD> that I haven't tested enough to be considered stable. You mean, you apply _all_ patches from Lucho? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] NSSI Works!!!
Hallo Tom, Thanks for the information! Unfortunately if UDMA or CD-ROM driver is loaded, it hangs at the "checking memory for viruses" stage under the unstable CVS kernel. these were my results also - with boring, rock stable now DOES IT WORK ON UNSTABLE OR NOT ? As I wrote, it works, if neither UDMA nor CD-ROM driver is loaded. But for Justin it works with a CD-ROM driver. The difference is that my CD-ROM driver supports UDMA while his probably doesn't... WHICH UNSTABLE ? Current CVS version. but scince NSSI is under active developement, the author can probably tell us what we are doing wrong. Or just differently than MS-DOS :) unfortunately, this las sentence was just a joke. Why? Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] #pragma in UNSTABLE breaks compilation with OpenWatcom 1.2
#pragma aux default parm [ax dx cx] modify [ax dx es fs] Thanks, Eduardo - Jeremy already noted these errors on CPU < 386 this and today I fixed it in the CVS by applying it only for an 80386. The pragma was suggested by Bart. I don't understand how it works but it does decrease kernel size significantly. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Informer by Kondakov K.V.
Hi Lucho, My sound card is a Creative Labs Sound Blaster 16/AWE32 ISA. Interon - Original Message - From: "Luchezar Georgiev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 2:10 PM Subject: Re: [Freedos-kernel] Informer by Kondakov K.V. Hi Justin, A freeware DOS hardware detection program called Informer froze/locked up during sound card detection. Informer is my old friend. I've used it for UDMA. It works for me with the latest unstable kernel, despite that I have 3 (THREE) sound cards installed here, one of them embedded in the main board. What sound card do you have, and which kind of bus (PCI/ISA)? Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] NSSI Works!!!
Hello Luchezar, >> In FreeDOS 2035a, NSSI crashed. >> In the newest unstable kernel, NSSI works excellent! >> Get NSSI at http://www.navsoft.cz > Thanks for the information! Unfortunately if UDMA or CD-ROM driver is > loaded, it hangs at the "checking memory for viruses" stage under the > unstable CVS kernel. these were my results also - with boring, rock stable now DOES IT WORK ON UNSTABLE OR NOT ? WHICH UNSTABLE ? > Else it works, but hangs at the "Checking NLSFUNC" > stage when creating automatic report. Needless to say everything works > under MS-DOS 7.10. but scince NSSI is under active developement, the author can probably tell us what we are doing wrong. unfortunately, this las sentence was just a joke. tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
