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] 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] 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
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
#include fcntl.h
#include io.h
#include dos.h
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] 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] 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] 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] 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] 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] 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: 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] 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
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 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] 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] 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] 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] 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
[Freedos-kernel] PRF.C test fails for [far] pointers
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... --- 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!!!
Hi again, Justin! 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. Else it works, but hangs at the Checking NLSFUNC stage when creating automatic report. Needless to say everything works under MS-DOS 7.10. 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: int 2f.122f...
If I right remember, Lucho's patch affect os_major and os_minor. No, it affects os_setver_m??or. --- 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] Kernel no longer removes or renames the current directory
Bom dia, Alain! Now the kernel no longer removes or renames the current directory of the drive for which this is requested. This says that it does not do what is requested... Could you please rewrite or explain it? MS-DOS never removes or renames the current directory of the drive for which this is requested but always fails with attempted to remove current directory error instead. Now FreeDOS does the same --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Exact URLs for the kernel and SYS binaries
CVS already updated. Binary at And question again: how to download this lates image? http://linux.tu-varna.acad.bg/~lig/freedos/kernel/KERNEL.SYS http://linux.tu-varna.acad.bg/~lig/freedos/kernel/SYS.COM The boot code in SYS now has the DMA 64K boundary cross bug fix (thanks, Jeremy! :) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils wlinker.bat,1.3.2.1,1.3.2.2
+%BASE%\binw\ms2wlink %1 %2 %3 %4 %5 %6 %7 %8 %9 kernel.lnk If you have a better fix, I will gladly change it. Microsoft LINK accepts a trailing colon (;) after the last meaningful argument instead of commas. Perhaps this would work for MS2WLINK too? Like this: +%BASE%\binw\ms2wlink %1 %2 %3 %4 %5 %6 %7 %8 %9; kernel.lnk --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils wlinker.bat,1.3.2.1,1.3.2.2
Microsoft LINK accepts a trailing colon (;) after the last meaningful argument instead of commas Sorry about my bad English. The dictionary says that the ; sign is called semicolon, not colon! --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Zurenava DOS extender hangs on exit
Michael, the KAVDOS32 problem is in its Zurenava DOS extender (Russian, of course ;-) Bind any 32-bit DOS executable with it and it'll hang on exit under FreeDOS and cleanly exit under MS-DOS. Zurenava source and binary code are available in a ZIP archive at http://dx.zr.spb.ru/zrdx047.zip --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] COMDRIVE compatibility problem and analysis
Eric, why don't you fill in a Bugzilla entry with this problem? Lucho Tue, 31 Aug 2004 18:53:29 +0200 (MEST), Eric Auer [EMAIL PROTECTED]: Hi all, please check: http://www.coli.uni-sb.de/~eric/comdrive-analysis.txt.gz ... and tell me how to make (either by fixing FreeDOS or comdrive or both) this potentially very useful tool work with FreeDOS. Thanks! Download URL for the program itself (10k download) is in the txt, too. COMDRIVE 1.1 (Shareware by EnterTec - does that still exist?) is a device driver which can fetch bpb and sectors from remote drives, to make the remote drive visible locally (read-only). It can also send sectors from arbitrary FAT1x local drives to a remote computer. You connect 2 PCs, both with COMDRIVE loaded, over a null modem cabel on com1 or com2. The included SEL tool allows you to select the remote drive letter to be used. Problem: This only seems to work with floppy drives and a bit with ramdisks (Tyler knows more - I could only analyze, not test). Maybe something is broken with out BPB refresh logics? Or int 28 is sometimes called while DOS stacks are busy? Or the function 0x13 (generic IOCTL) implementation of the driver is too bad? Or the driver calls the get-bpb function (int 21.440d.0860) with not properly specified parameters? More details about possible problems can be found in my analysis text. Happy bug-hunting and thanks in advance! --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Updated unstable kernel patches and binary
it doesn't compile. Sorry - it turned out that my patches were against a mixture of stable and unstable branch! Now I got the real unstable CVS sources, cleaned up mine, and the resulting patch became larger, because it contains some Arkady changes not in unstable CVS yet. Just uploaded it on the same place, http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Updated unstable kernel patches and binary
the TU-Varna FTP server has currently some [space?] problems and I can't upload the files there Problems got fixed so I uploaded both the patches and the binary there. You probably know the URL: http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ One more note: PLEASE don't link to it from pages visited very often. This may increase traffic so the administrators there may DELETE my files. This is an educational server NOT for mass download. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Mon, 23 Aug 2004 00:00:30 +1200 (NZST), Bart Oldeman [EMAIL PROTECTED]: 63978 bytes!!! HOORAY!!! ;-) ;-) ;-) Still strange. I get 64266, doesn't matter whether it's OW 1.2 or 1.3. Strange indeed. #if !defined(FORSYS) #pragma aux default parm [ax dx cx] modify [ax dx es fs] #endif in portab.h works only if you use the 386 options that may explain why it didn't work for you. What do you mean by the 386 options? I do use the -3 option as well as -zff -zgf options. The pragma reduces it to 63850 (from 64266, ie. 416 bytes). Wow! I'd like to try this. To reduce compressed size you can try #pragma aux default parm [ax dx] modify [ax bx cx dx es fs] which adds ~200 bytes uncompressed but reduces 300 compressed. Very interesting! Does it also require the 386 options you mention, and what are these options? Also shuffling the link order helps a bit. . ~100 bytes off compressed kernel. Indeed! It helps the Borland kernel too - 86 packed bytes less. -zm gets it further but that's broken (segments messed up), but if that can be fixed you just need to get it below 40960 (80 sectors). That's the threshold I'd like to reach with Watcom in order to replace Borland by it. Anyway the code generator hasn't improved from our point of view. That's the only weak point indeed. They didn't seem to fix the bug I reported (bug 407) either. I suspect there are other bugs introduced in 11.0 but not present in 10.6 that remain in 13.0 (1.3). The compiler is significantly faster for certain code (not sure if that affects FD-kernel). In case you're interested I've put the changes below. Thanks! I read it and saved for my reference. Quite impressive list of changes! I especially like the support of all the instruction sets into the assembler (we use some of them here). Now we have not only the best universal x86 compiler, but also the best MASM-compatible x86 assembler! Shame on Borland who introduced 3DNow! in their inline assmbler but not in their stand-alone TASM! :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Announce: COUNTRY.SYS
Ciao, Eduardo, We strive for MS-DOS compatibility, and MS-DOS, PC-DOS, PTS-DOS, OS/2, Windows 9x and Windows NT all use the same format that is so well described in the RBIL tables 2619-2622. So I chose that. IMHO, the COUNTRY.SYS format does not affect compatibility, as the information is accessed through DOS interrupts. But not everybody installs FreeDOS from the installer and uses all its external commands / files. I've always strived to make the kernel a drop-in replacement of the MS-DOS kernel (apart from Windows support). So, it now works with HIMEM.SYS, SMARTDRV.EXE *and* COUNTRY.SYS of MS-DOS! ;-) It doesn't yet work with the menu stuff of MS-DOS, but who knows, perhaps this will be changed... Actually, one of the reasons I chose that format is that I needed to test my COUNTRY= code with a COUNTRY.SYS file that is *really* correct, and what more correct than the Windows 98 COUNTRY.SYS? Only *after* ensuring that the code works right, I composed our COUNTRY.ASM and fixed its bugs to make it compatible with the *already* correct code. Could I do it otherwise? If we had an already existing COUNTRY.SYS - yes, but debugging *both* code *and* data is far beyond my abilities... ;-) Besides, the RBIL describes the COUNTRY.SYS format of MS-DOS/PC-DOS/PTS-DOS/OS2/Win9x/WinNT rather well, and we always try to follow the RBIL in our kernel work (which is even written in our docs). DR-DOS, for instance, uses a different one. DR-DOS has never been 100% MS-DOS compatible, which is one of our goals, albeit we'll never reach it, of course, but... the only true goal is the unreachable one ;-) I think that FreeDOS is already much more MS-DOS compatible than DR-DOS. (This is not to say that DR-DOS is bad, no! ;-) I won't hide that I prefer Steffen's format, as I've already implemented NLSFUNC using that but, if we finally go for the MS format, we should consider to expand it to include a Yes/No table (for int 21.65.23), which is a nice addition in Steffen's version. It is pretty straightforward, but it will invalidate the use of COUNTRY.SYS files from those OSes in FreeDOS (apart from legal and/or ethical issues). As far as I can understand (and I don't understand it very much), Steffen's format is similar to that of DR-DOS, which isn't well described in the RBIL. I think that the Yes/No character can be used only in *fully* translated, complete versions of FreeDOS. Besides, there are other responses like Abort, Retry, Ignore, Fail? that are not covered there. Therefore, such characters are much better translated along with the strings. So, until we have *fully* translated version of FreeDOS (like German or Italian MS-DOS, for example), those configurable Yes/No characters are unusable. As for ethical and/or legal obstacles, I don't see any. The Russians of PhysTechSoft use it in their PTS-DOS and nobody has sued them yet. Do you think that if Microsoft had even the slightest chance to win, they wouldn't sue them? Remember how Adobe Systems (the little Microsoft ;-) sued Dmitry Sklyarov of ElComSoft, Russia. At the time of the announce of PTS-DOS, MS-DOS wasn't yet killed by Microsoft, so it was a direct competitor. FreeDOS can't be a competitor of something that Microsoft killed by their own hands. FreeDOS *cannot* be compared with Linux in this context, as Linux *is* a direct competitor of the Windows NT family, which Microsoft won't kill soon ;-) A presto, Lucio --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Yes that's what I meant. What are the errors dsk.c gives you? None! :-O Don't know why, but now when I edited the UTILS\MAKEFILE to define EXEFLAT for EXEFLAT.C so that the pragma doesn't affect it, OpenWatcom 1.3 *successfully* built the kernel and the size is... guess what - exactly 63850 bytes, as you wrote! But this is... after adding Eduardo's Int 2F-12 functions! Apack packs that to 42200 bytes. If I pack the exeflatted kernel by it as a .COM file, I get 41967 bytes. UPX gives me 41460 bytes. The other #pragma aux default you suggested gives me 64042 bytes uncompressed, and 41183 bytes compressed by UPX as a .COM file. I suspect I could never reach the sacred size of 40960 bytes :-( For comparison, the aPacked Borland 4.0 kernel is now only 40832 bytes. No, Watcom is just too smart to produce well-compressible code! :) Groet, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] The justice finally caught the criminal!
Lucho, whatever you do. Please leave that copyright message in. You made a proposal to change it. Then just removed it. Which is worse. The justice finally caught the criminal! I didn't remove it, I had just *moved* it to AUTOEXEC.BAT where it can be enjoyed in its full glory for as long as you wish instead of only for 3 seconds, and I announced that in my COUNTRY.SYS announcement, stating that I anticipate a stormy reaction to that. And here it is! OK, I added it back to main.c but the kernel became 40 KB. So I must find a way to optimise it further. When I do this (hopefully tomorrow), I'll upload the new files. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Bom dia, Alain! I believe that being hated as much as a certain man is a matter of behaviour. I always use this analogy: Oracle's product are very expensive, but their custumers are content and Oracle is not hated at all. M$ make we feel bad, not because they charge, but because they force us in ways that we want not, or something like that... (I believe that this would happen even if their product was not so bad) I agree. William Henry Gates the Third is not a human. And he has not been such even 25 years ago. Currently I improve (cure) my nose, so I again delay my answer around a week. Can someone translate that from Russian :) (It could be some code that the CIA should not see) He wanted to say that his nose was running because he suffered from cold and he was curing himself Be healthy, Arkady! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Free space count not updated
Now I discovered this using DISKEDIT. It's a double word at offset 488 (1E8h) of the second sector of the FAT32 boot record (which consists of three sectors, not one as for FAT12 and FAT16). But actually this is described in http://www.microsoft.com/hwdev/download/hardware/fatgen103.pdf It's declared in hdr/xstructs.h as xdpbforformat.setdpbcounts.nfreeclst but I don't see it updated anywhere! I suppose that this should be done at the end of kernel/fattab.c:link_fat() along with the update of the dpbp-dpb_xnfreeclst, but how to do it? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Free space count not updated?!
It's declared in hdr/xstructs.h as xdpbforformat.setdpbcounts.nfreeclst but I don't see it updated anywhere! I suppose that this should be done at the end of kernel/fattab.c:link_fat() along with the update of the dpbp-dpb_xnfreeclst, but how to do it? I was wrong. It's fsinfo.fi_nfreeclst and is updated in the following line in fattab.c:write_fsinfo(): fip-fi_nfreeclst = dpbp-dpb_xnfreeclst; --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Microsoft C is Lattice C
(some) big corporations _do_ thefting. For example, Sony theft Walkman idea (AFAIR, from Bulgarian inventor), Logitech was reject co-operation with Russian developers, but then (quietly) reuse their ideas in own mice. :( I didn't know those things, and they only support my anti-corporate attitude :-( Lattice C - Microsoft C, Do you sure, that MSC is a LC? Yes. Here is a quote from the book IBM's Personal Computer by Chris DeVoney, Que Corporation, Indianalopopis, 1983, page 214: C [...] Digital Research developed its own version of C, whereas Microsoft licensed its compiler for MS-DOS from Lattice Associates of New York. Microsoft has enhanced this version of C with several additional functions and programming tools. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Getting COUNTRY.SYS done right
About country sys: Do NOT copy it from another DOS. It's NOT copied! See COUNTRY.ASM in http://linux.tu-varna.acad.bg/~lig/freedos/kernel/CVSPATCH.TXT --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, resolve rejects in exeflat.c :( Sorry, my fault. Just fixed that and uploaded a new CVSPATCH.TXT, including a SYS fix - OpenWatcom 1.3 now complains about missing return type of fat32readwrite so I addeed an int at both places. I've uploaded it to http://freedos.sf.net/kernel/kwc38632.txt so you can compare the map file. Thanks! Silly me, I had forgotten to rename the FAT and CPU variables to XFAT and XCPU, so what I was getting was a 8086 kernel! Now, with OpenWatcom 1.3, the uncompressed 80386/FAT32 kernel is... 63978 bytes!!! HOORAY!!! ;-) ;-) ;-) Congratulations, Bart! Now we can make some experiments with first exeflatting the kernel, then packing it. But first, please write about your #pragma aux default - why doesn't it work for me? Thank you very much - now I'm looking forward to say Goodbye, Borland! Welcome, Watcom! ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
63978 bytes!!! HOORAY!!! ;-) ;-) ;-) I'm looking forward to say Goodbye, Borland! Welcome, Watcom! ;-) Sadly, I can't do this yet - UPX compressed it to 41604 bytes as COM and 41614 bytes as EXE. aPack - to 42071 bytes as COM. In contrast, the cowardly Borland 4.0 FAT32/80386 aPacked kernel is just 40718 bytes, almost a kilobyte smaller. So, unfortunately I have to remain a coward :-( Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
UPX compressed it to 41604 bytes as COM and 41614 bytes as EXE. I mean as SYS, not as EXE. I just changed the first 4 bytes to FF to fake it. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hello, I had forgotten to rename the FAT and CPU variables to XFAT and XCPU, so what I was getting was a 8086 kernel! Hm. How you miss kbc8632 instead kbc38632? No, the Borland configuration file was correct, the problem was with my other configuration files! OpenWatcom 1.3, the uncompressed 80386/FAT32 kernel is... OW 1.3? Do you mean, 1.3 is ready?! They had moved the 1.3 from the devel/beta subdirectory onto a new one: http://downloads.openwatcom.org/ftp/zips-1.3/ I think it's a good sign that they're ready to announce it soon. But Bart probably knows more ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Announce: COUNTRY.SYS
Hello, All that MS does - enclose _public_ information into own file format. What is permitted for Zeus, is not permitted for mortals! :-( That's exactly what I meant when I wrote that Microsoft are the biggest thefts. Even their first Basic interpreter was from public domain sources. Not speaking about QDOS - MS-DOS, Lattice C - Microsoft C, VMS - NT, and so on. Thus, I don't think that this is beyond fair use to reuse this public information. Violation (probably!) if we use original MS files and/or their format, but layouts are not property of MS. Their COUNTRY.SYS format is safe to use, because PTS-DOS and OS/2 also use it and nobody has sued PhysTechSoft or IBM yet ;-) I've never understood copyright well (and even think that copyright is anti-natural!) but I don't think that a file format or data structures can be copyrighted at all. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] dpb_xnfreeclst not updated when allocating new clusters?
Hello, I noticed that I often get CHKDSK/SCANDISK errors that my FAT32 freespace count is incorrect. This happens when I write new files onto my disk, e.g. free space decreases. I see that dpb_xnfreeclust is incremented / decremented in fattab.c:link_fat() but is this the only place where it must be adusted? Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Announce: COUNTRY.SYS
Hello, At http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ are a kernel patch collection (CVSPATCH.TXT) and binaries (KERNEL.SYS and COUNTRY.SYS) that add COUNTRY.SYS file support to the kernel and move the hard-coded country data from the kernel where it belongs - to a separate COUNTRY.SYS file, as in all other DOSes. The COUNTRY.SYS file format is the same used in MS-DOS, PC-DOS, PTS-DOS, OS/2, Windows 9x and Windows NT, and is described in the Ralf Brown Interrupts List (tables 2619-2622). The so modified kernel has also been successfully tested with the CONFIG.SYS file of Windows 98 (MS-DOS 7.10). Some more countries were added. Note that COUNTRY.SYS is still under 2 KB versus 30 KB for MS-DOS 7.10 because it consists of only CTYINFO data and doesn't have any uppercase and filename tables. Of course, if (when) such information is added to COUNTRY.SYS later, the kernel code to read it can easily be added too. The aforementioned patch also moves the copyright message from the kernel to the AUTOEXEC.BAT file where it can be enjoyed for as long as needed, instead of appearing for only 3 seconds during bootstrap. (This may not be accepted but I'll never understand why. You know I'm a copyright illiterate or at least ignorant.) The patch also modifies EXEFLAT.C so it can process kernels without any relocations and make the kernel independent from the loading segment in this case. (Of course the kernel still needs to be loaded at segment 60h. Those 3 bytes the patch adds to the stub allow for future kernels, independent from the loading segment. I think 3 bytes aren't a high price to pay for that.) CVSPATCH.TXT contains other small optimisations too. Enjoy! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Well if I claim I can get it under 64K I'm not lying. Did I say you're lying? OW compiles *plain 2035* as 66318 bytes uncompressed for me for FAT32/386. Why your kernel is bigger after all these optimizations is a puzzle. I've read that on low memory machines its optimizer may be limited I have 256 MB RAM and 60 MB free XMS (the rest is for a XMSDSK) - surely enough for it. but I can't think of anything else. What version of OpenWatcom are you using? I use 1.2. I can't otherwise explain the size difference For the unstable branch it's 64700 or so. Even after reducing kernel size with my latest patches I still get 65830 bytes. That's more than a kilobyte bigger! How can we explain that? Changing the calling convention to #pragma aux default parm [ax dx cx] modify [ax dx es fs] in portab.h (careful, don't do that for SYS EXEFLAT) Unfortunately this causes compile errors as early as in dsk.c for me, so I can't use it. and making LoL (init-mod.h, main.c) extern struct lol FAR * const LoL; (see the const) chops of another couple 100s of bytes. Adding const shortens it by 16 bytes for me, so I added it. Borland kernel size doesn't change. The smiley implies that it can't be freely downloaded from Vietnam. Maybe you can but I can't. Why are we so different? I'm much older than you but we both sound like it was the opposite! ;-) Everything can be physically downloaded. ...if you know the right URL at the right time ;-) But that's a silly argument and by publically encouraging it you're not doing this project a favour. Oh, sorry, did I trod the kitten again (as we say here)? I'm scared of myself but not ashamed :) Why? Because I'm a complete copyright illiterate, or at least ignorant. And I'm too old to change. Right, checking again I see it compresses a SYS file like a COM file. Well with some hand holding (load at 50:100) you could treat kernel.sys like a COM file too. Haven't tried that though. Let me first achieve your uncompressed kernel sizes with OpenWatcom. I hope you help me with this. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Hallo Bart and Tom, In this case, instead of pursuing a technical solution (Open Watcom is open source so can be changed) to reach a certain goal, you suggest I go for an illegal black-box solution, the cowards' way out. All right, I was a fly, now I'm a coward. Very well. Perhaps I'm something like a flying coward :) By ignoring Borland's copyright you indirectly hurt the OW project because the other means to reach your goal would be to modify it. All right, Bart, I feel like an elephant in a glass store here - whatever I do breaks something. I don't understand why I hurt OpenWatcom?! I like this compiler very much and if you help me achieve smaller compressed kernel size with it, I'll gladly drop Borland, because I don't like it at all! Otherwise I find your comments very interesting and must agree with most of them. Not only Bulgarians. 3/4 of the world thinks so. And many Americans and Germans too, by the way. there is a german saying 'hey guys - eat shit! Billions of flies can't be wrong' So we're just billions of flies to you. Very well :) Otherwise it's a great anti-fashion proverb. information is as much a product as a car or a house, and it costs similar effort. I disagree. Building 1000 houses costs one almost 1000 times more than a single house. Making 1000 copies of a program costs one much less than developing the program itself. It's a false analogy. Aren't 10 copies of Windows enough to cover its development costs? But no, they sell 1, with an 10% profit! What's this if not a huge exploitation of the whole world by a single corporation? That's why I'll be so happy when Microsoft die, as Joe Cosentino signs in his FreeDOS song ;-) and the people who made this product must be paid - some way or the other. I agree, but by buying a second-hand BC copy Bart wouldn't pay the Borland programmers in any way. just because you can technically copy it (whithout causing me any direct harm) does NOT imply you MAY do that. Legally wise - yes, but my conscience is 100% clear. You know that I'm not really such a coward :) please accept the fact, that there is FREE information, and for some other information you have to pay, or you will kill the producer in the long run (because he will starve to death) Oh, if I could starve Microsoft to death! Alas, as Bart suggest, it seems I even help them grow :( it's simple as that: they want your money IF you use their software. they offer you a deal, which you can accept - or deny. stop using their software, and you don't have to pay them a dime. If I stop using it, what will they gain? Nothing! There is no logic here. I assume your company produces some sort of (hardware) gadget, that it sells - which in the end ends up as salary in your pockets. I wonder what happens if I rip off your gadgets design and internal software, 'reengineer' the gadget, produce it myself (at much lower cost as I don't have to pay the engineers), and sell it at a price below your gadget. probably neither your employer nor you what be very glad in the end. This cowardly deed has nothing to do with mine. I don't use BC as a competitor of Borland. I'm not a threat to them. Whereas you (in the role you describe) would kill our product with what you do. But we know that the world we live in is so nasty, so we've taken measures against such actions :) I'd like to add that we must consider standards of living too. When I say 3/4 of the world thinks so, I also mean that 3/4 of the world is so poor they can't pay even a modest price for a piece of software. The majority where I belong, whereas you probably belong to the minority. Imagine you're asked to pay not $70 but $700 for a copy of 4DOS. Would you do it? Hardly, however lawful you are. OK, Tom, neither of us can convince the other one. So, let's not argue anymore, OK? It's always nice to hear your opinion on a topic I understand much worse than you do. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: Allow seeing ZIP disk serial number
Did you run guest to load the drivers for the parallel port Zip Drive? Yes, and it worked for me. I tried it three months ago and I could not get it to work. Kernel version is 2.1.34. I had composed a simple batch file (LOADZIP.BAT) to replace GUEST and consume less memory. It's dated 2 May 2004 so it had worked with build 2034, as GUEST did. Here it is @dynaload c:\iomega\aspippm1.sys file=byte.ilm speed=1 info @c:\iomega\scsicfg.exe /v @dynaload c:\iomega\scsidrvr.sys --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. ;-) I could never use an uncompressed kernel that is below 64 KB. OpenWatcom makes the FAT32/80386 unstable kernel 66330 bytes long. The maximum size that UPX accepts is 65350 bytes. The difference is almost a kilobyte. How could we reduce the kernel further without crippling it? It's difficult! I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? It's not worth a penny because it can be freely downloaded from Vietnam (I posted the URL here ;-) How about Digital Mars for instance? A very good compiler in my opinion, backed by Walter Bright's C++ great compiler know-how, but Tom once wrote that he gave up porting the kernel to it as he didn't see advantages. I experimented a bit -- as it turns out once the uncompressed size goes to 64K you can stick on a SYS header to kernel.sys, UPX the already exeflatted SYS file and use that. For some reason in this case UPX is better than APACK by the way. Well I got it down to ~41300 bytes vs. your 40957. Now you're just lucky that 40957 is just below the 80 sector boundary but the difference is gone at 40961 bytes. Does that 64K kernel support FAT32? Hardly. The 40K one at my site does. So that's an incorrect comparison. Besides, aPack doesn't compress .SYS files at all. An incorrect comparison again. Did I say it was bad? I just claim it's not the best tool for our job and has several other disadvantages. You're right, but I have to put up with its disadvantages for one big advantage - KING SIZE! ;-) Do Datalight really use it because the entropy is lower so the compressed size goes down? Their DOS is not compressed at all, although I offered them some stubs to compress a 64K kernel. Of course they lost the race (MSVC, Intel, GCC) when Sybase took over and eventually stopped development. And from what I gather 11.x however introduced various obscure linker bugs, and loop optimization bugs (most are fixed in OW now). And OW still has years to catch up in terms of C++ standards (slowly getting there). The information about loop optimisation bugs is very important. So, not all of them are fixed yet? For example a colleague of mine discovered such a bug which I reported to them. It's present in all Watcoms since 11.0 but wasn't there in 10.6! Unfortunately, there are no bug-free compilers :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Hallo Tom, It's not worth a penny because it can be freely downloaded from Vietnam (I posted the URL here ;-) I know bulgarians think that way. Not only Bulgarians. 3/4 of the world thinks so. And many Americans and Germans too, by the way. It's still theft. It would be a theft if I *move* the files. If I copy them, I don't deprive anybody form anything. The whole nature of information allows copying, so it cannot be private property of anyone. All information but some reasonably secret and personal data must be free for everyone. Quite the contrary, corporations steal our money when they ask us to buy their software. Microsoft stole everything they released. The criminals are they, not we. There is no fair (honest) way to become a millionnaire or a billionaire. And because we're not millionaires or billionaires, we're not criminals. Good programmers who really deserve money, like you or Joergen Ibsen, get it even from people like me. I registered my copy of aPack! Would I register it if it it was made by a corporation like Borland? Never! They're too rich anyway! Copyright is dying, long life copyleft! ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: Allow seeing ZIP disk serial number
interesting loading option, I have SCSI internal zip100 iomega drive. Does DEVLOAD 3.13 also work for you instead of DYNALOAD? (no idea if we have put it online somewhere, though :( ) I haven't tried it, but there is no reason why it shouldn't work. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Patch: Allow seeing ZIP disk serial number
Hello,
First, I'd like to express my gratitude to Alain Mouette for his generous
donation of an external 100 MB parallel ZIP drive + disks to me which
allowed me to catch the bug below. Thank you, Alain!
Attached is the file CVSPATCH.TXT - a cumulative patch for the unstable
branch that contains a fix for a bug in IOCTL.C which prevented the ZIP
drive serial number to be seen. The problem was that the r_unit field was
incorrectly set to unit number, whereas it must be set to subunit number.
And while I was at it, I also added assignments of the SI and DI fields
for IOCTL 13h/19h, because the IBM PC DOS Techical Update explicitly
states that these fields contain SI/DI on pages 104 and 105.
Needless to say that I also updated CVSPATCH.TXT and KERNEL.SYS at
http://linux.tu-varna.acad.bg/~lig/freedos/kernel/
Sorry for the relatively big attachment that contains patches that were
already known, but Opera screws up copied-and-pasted chunks of code so
attaching the patch file is the only cure for this.
Regards,
Luchodiff -Naur cvs/kernel/hdr/device.h src/kernel/hdr/device.h
--- cvs/kernel/hdr/device.h 2004-07-24 19:02:42.0 +0200
+++ src/kernel/hdr/device.h 2004-08-16 10:30:12.0 +0200
@@ -374,7 +374,8 @@
struct {
UBYTE _r_cat; /* Category code */
UBYTE _r_fun; /* Function code */
- UBYTE unused[4]; /* SI or DI contents or DS:reqhdr */
+ UWORD _r_si; /* Contents of SI and DI */
+ UWORD _r_di; /* (PC DOS 7 Technical Update, pp 104,105) */
union
{
struct gblkio FAR *_r_io;
@@ -424,6 +425,8 @@
/* generic IOCTL and IOCTL query macros */
#define r_cat _r_x._r_gen._r_cat
#define r_fun _r_x._r_gen._r_fun
+#define r_si_r_x._r_gen._r_si
+#define r_di_r_x._r_gen._r_di
#define r_rw_r_x._r_gen._r_par._r_rw
#define r_io_r_x._r_gen._r_par._r_io
#define r_fv_r_x._r_gen._r_par._r_fv
diff -Naur cvs/kernel/kernel/inthndlr.c src/kernel/kernel/inthndlr.c
--- cvs/kernel/kernel/inthndlr.c2004-07-25 20:12:50.0 +0200
+++ src/kernel/kernel/inthndlr.c2004-08-13 12:05:56.0 +0200
@@ -698,10 +698,8 @@
case 0x30:
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
- 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 stack! */
if (ReturnAnyDosVersionExpected)
{
diff -Naur cvs/kernel/kernel/ioctl.c src/kernel/kernel/ioctl.c
--- cvs/kernel/kernel/ioctl.c 2004-07-24 19:02:42.0 +0200
+++ src/kernel/kernel/ioctl.c 2004-08-16 12:39:48.0 +0200
@@ -92,8 +92,9 @@
sft FAR *s;
struct dhdr FAR *dev;
+ struct dpb FAR *dpbp;
unsigned attr, flags;
- UBYTE cmd;
+ UBYTE cmd, unit;
switch (r-AL)
{
@@ -141,8 +142,6 @@
case 0x0e:
case 0x0f:
case 0x11:
-{
- struct dpb FAR *dpbp;
/*
Line below previously returned the deviceheader at r-bl. But,
DOS numbers its drives starting at 1, not 0. A=1, B=2, and so
@@ -154,25 +153,23 @@
#define NDN_HACK
#ifdef NDN_HACK
/* NDN feeds the actual ASCII drive letter to this function */
- UBYTE unit = (r-BL 0x1f) - 1;
+unit = (r-BL 0x1f) - 1;
#else
- UBYTE unit = r-BL - 1;
+unit = r-BL - 1;
#endif
- if (unit == 0xff)
- unit = default_drive;
- CharReqHdr.r_unit = unit;
-
- if ((dpbp = get_dpb(unit)) == NULL)
- {
-if (r-AL != 0x09)
- return DE_INVLDDRV;
-attr = ATTR_REMOTE;
- }
- else
- {
-dev = dpbp-dpb_device;
-attr = dev-dh_attr;
- }
+if (unit == 0xff)
+ unit = default_drive;
+
+if ((dpbp = get_dpb(unit)) == NULL)
+{
+ if (r-AL != 0x09)
+return DE_INVLDDRV;
+ attr = ATTR_REMOTE;
+}
+else
+{
+ dev = dpbp-dpb_device;
+ attr = dev-dh_attr;
}
} /* switch */
@@ -186,6 +183,8 @@
{
CharReqHdr.r_cat = r-CH;/* category (major) code */
CharReqHdr.r_fun = r-CL;/* function (minor) code */
+CharReqHdr.r_si = r-SI; /* contents of SI and DI */
+CharReqHdr.r_di = r-DI;
CharReqHdr.r_io = MK_FP(r-DS, r-DX);/* parameter block */
}
else
@@ -194,6 +193,7 @@
CharReqHdr.r_trans = MK_FP(r-DS, r-DX);
}
CharReqHdr.r_length = sizeof(request);
+ CharReqHdr.r_unit = dpbp-dpb_subunit;
CharReqHdr.r_status = 0;
switch (r-AL)
@@ -256,7 +256,7 @@
case 0x09:
{
- const struct cds FAR *cdsp = get_cds(CharReqHdr.r_unit);
+ const struct cds FAR *cdsp = get_cds(unit);
if (cdsp == NULL)
return DE_INVLDDRV;
if (cdsp-cdsFlags CDSSUBST)
diff -Naur cvs/kernel/kernel/nls.c
Re: [Freedos-kernel] HiNTOS vs HX - Japheth about to win :)
4 days ago, I wrote: I see! OK, when I copied it from W98 to C:\HX, PESTUB patched MASM 6.15 successfully, so I can now run it in FreeDOS, this time perfectly, also when building real projects with NMAKE and assembling multiple files at once. Congratulations! However, when I apply PESTUB to Digital Mars 8.38 (SC.EXE and SCPPN.EXE), it still crashes with a register dump (general protection fault) when I try to build real projects with SMAKE, but works when converted by HiNTOS, albeit *not* in FreeDOS :-( But on the next day, Japeth fixed an incompatibility in DKRNL32.DLL, and now I can run both ML and SC in FreeDOS too! So, the only tool that I ran in MS-DOS but can't run in FreeDOS is the Windows version of RAR (currently HX's DUSER32.DLL doesn't have the ExitWindowsEx call that RAR needs). But *if* Eugene Roshal fixes the long standing Not enough memory archive update bug in the DOS version of RAR, RAR32, I would be able to run RAR32 as I run RAR in FreeDOS too, so then HX will really be the winner because it works in FreeDOS too, without the SFT magic that HiNTOS does! ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hallo Bart, whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version numbers ;) ...and 2035, 2035a (why not rename them to STABLE?) and 2035a-UNSTABLE releases ;) Just have to send Ralf Brown another email as my previous mod to interrupt.f will be obsolete. ...in the hope that the probability of releasing the next version of the RBIL is greater than the probability of releasing the next version of the GPL (and neither of them is zero ;-) Anyway most references other than RBIL tell that the serial number isn't used as such. True. Moreover, the IBM PC-DOS 7 technical reference update (http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf) says: = start quote = 30H Get DOS Version Number Purpose Returns the DOS version number. Examples PUSHCX ; CX destroyed in call PUSHBX MOV AH,30H ; Function Call Get PC DOS 7 ; Version INT 21H ; Issue request to DOS MOV MajorVersion,AL ; Save Version MOV MinorVersion,AH MOV DOS_Running_From,BH ; POP BX POP CX - MajorVersionDB ?; X of X.YY MinorVersionDB ?; YY of X.YY DOS_Running_FromDB ?; 0 = DOS not running in ROM DOS_Running_FromDB ?; 8 = DOS running in ROM Comments On entry, AH contains 30H. On return, CX is set to 0. AL contains the major version number. AH contains the minor version number. BH contains 8 or 0 for DOS running or not running in ROM. If AL returns a major version number of 0, you can assume that the DOS version is pre-DOS 2.00. Use function call 33H AL=6 (Get or Set System Value) to get the true version number. = end quote = Not that it says On return, CX is set to 0. So, the RBIL is just one of the references - not to be absolutised. www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm That URL doesn't work. The correct URL (without the extra space) is: www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte2zlc.htm tells us that - the OEM serial number is a rarity, though some older OEM DOS versions implemented this feature. Most likely 32RTM wouldn't run on those older OEM DOS versions either then. Yes. This patch won't apply without manual tweaks Lucho, please fix your email client. I can't fix Opera - it's closed source ;-) Lines were wrapped and indentation also messed up (hard tabs?). Sorry. From now on, I'll enclose my eventual patches as plain text attachments. They'll work then. There's also a pointless optimization, that the compiler can do for us as well. Will Watcom (the only compiler you recognise) do this? Borland won't, I'm sure. So my optimisation is NOT pointless. By the way, Bart, as an OpenWatcom contributor, would you please post news here and on fd-devel when version 1.3 is officially released? Thanks. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) And this means - never, and you know it! ;-) I do recognize other compilers but... Glad to hear that! ;-) BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) True, but my optimisation isn't BC-specific. It's beneficial for all compilers but Watcom! ;-) Besides, you know that Borland C++ 4.0 produces the smallest possible packed kernel binary file. Sometimes kernel file size is what matters (for floppy and ROM disks) and sometimes - the resident size in RAM (where Watcom is the king), if the DOS is in low RAM or if there is no cache. Depends. This is not to say that I like Borland. They added 3DNow! to their inline assembler in C++Builder 6, but NOT in their TASM, which makes me extremely angry at them! But on the other hand, Datalight still use Borland as their one and only compiler for ROM-DOS. If it was so bad, would they use it? This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using _seg * pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. I agree that this was a right decision. Bart, some programmers claim that the only true Watcom is 10.6-, and 11.0+ is NO LONGER WATCOM as it was RUINED by Sybase. I have compared the code generated by both, and the difference is not so big, plus the code by 11.0+ is more optimal. What you can say on these Watcom version differences? Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
Hello Michael, I don't want to suggest basic things you've probably already thought of, but want to point out that the actual exception due to REP MOVSW in protected mode is significant. It's not a crash within FreeDOS or failure within the real mode INT 21h handler. Looks like a bad pointer to me. I tried int 0x21 ah=0x34 in both MS-DOS 7.10 and FreeDOS. In both, the returned offset in BX is 321h although the segment in ES is slightly lower in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory location pointed to by ES:BX was 0. So, that pointer seems valid to me. I also tried to catch the real pointer value when called by 32RTM with STEPDOS. It didn't came to calling DOS function 34h at all! The latest DOS function I saw before it showed the Unhandled exception message was 2Fh (get DTA). The returned value by function 2Fh in ES:BX was 1376:80h. Of course, that bad pointer could have come about due to stack corruption real or pmode, stack overflow back into Borland's data storage, memory corruption, or changing an unexpected register, but RTM lives long enough to get back to the RTM code itself, presumably in the DPMI dispatch/return area. I don't think the actual ES:BX return value is the problem, because it's not had a chance to be used at the exception point. You may be right that it's a bad pointer in the context of the real call. Could you catch what pointer it returns when called by 32RTM? The returned value in ES:BX when I test it by int is D2:321h. I tried manually shoehorning my own GDT entry in the RTM GDTand overwriting RTM's IDT for exception 0DH so I could catch the exception without any luck other than a change in exception message, but I could try again if nobody has any idea why it's failing. Alas, this seems so, indeed... If you can see the pointer DOS function 34h returns (or even the byte pointed to by it) when called by 32RTM, this may help. Thanks, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Thank you very much, Michael, for your discovery of the 32RTM bug!
There you have it folks. A dumb bug in a Borland product that by purest
happenstance fails under FreeDOS and not MS-DOS. I don't have any idea
how to gracefully fix the problem other than to have FreeDOS change its
serial number. And it shouldn't have to do that.
Sure. But since it's easier to make the kernel return a serial mumber of 0
as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
our function 30h to return 0 in CX. I tested this change and now 32RTM
works without -X as Michael wrote indeed! So I uploaded a new unstable
kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
of the Eduardo's NLS patch and the following patch. Thus, regrettably
we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
I guess 32RTM now stands for 32 times Read The Manual! ;-)
Do you see now what I meant when I wrote that MS-DOS has a better bug
compatibility? ;-)
Regards,
Lucho
--- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
+++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
@@ -698,10 +698,8 @@
case 0x30:
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
- 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
stack! */
if (ReturnAnyDosVersionExpected)
{
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Initial copyleft / licensing message
FreeDOS kernel build 2035a-WHATEVER. Copyright... This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. I'd prefer this: FreeDOS kernel build 2035a-UNSTABLE Copyleft 1995-2004 Pasquale J. Villani and the FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public License Nice idea and very easy to implement. :) I think, this is even _should_ be implemented, as startup screen should be cleaned. Please don't put the licensing conditions into the kernel! We strive for small size, don't we? Besides, that GNOMOVISION example is in the 12 year olg GPL2 only. The Alfero license, which is said to be the example for the future (mythical?) GPL3, doesn't have this example. If you ask me, the smaller startup message the better, and no license games at DOS bootstrap! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM Bug Found, copyleft message
Hallo Eric, Even 2035z would still mean a sufficiently small CX value and 32RTM would work. If CX is nonzero, 32RTM will *not* work. And CX *is* zero in *all* DOS version I've tested (MS-DOS, PC-DOS, ROM-DOS and DR-DOS). Michael, Tom and Alain are right. There's nothing else we could do but clear CX. What's more important after all - that FreeCOM shows 1.1.35 instead of 0.0.35, or that 32RTM works? I think that the answer is obvious for everybody. Yes we DO want to mention the license! MENTION. Not display the whole 18k file, obviously. That's exactly what I meant with my proposal (it fits on 2 lines despite the wraparound that my mail client will probably do): FreeDOS kernel build 2035a-UNSTABLE Copyleft 1985-2004 Pasquale J. Villani and The FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public License This increases the size in RAM by ZERO bytes and the size on disk by some really small number of bytes - and our kernel is very small on disk already anyway. So leave the banner message as is, thank you. The current message does more than simply MENTIONING the GPL. That's why I think it's too long. Just MENTIONING the GPL is enough - most people nowadays already know it. It's not like it was back in 1991! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS vs HX
Hello Japheth, and thanks for your reply! I downloaded all the 10 ZIPs there but none contained CRTDLL.DLL Yes. That is because CRTDLL.DLL is copyright MS and is included in every windows OS. I see! OK, when I copied it from W98 to C:\HX, PESTUB patched MASM 6.15 successfully, so I can now run it in FreeDOS, this time perfectly, also when building real projects with NMAKE and assembling multiple files at once. Congratulations! However, when I apply PESTUB to Digital Mars 8.38 (SC.EXE and SCPPN.EXE), it still crashes with a register dump (general protection fault) when I try to build real projects with SMAKE, but works when converted by HiNTOS, albeit *not* in FreeDOS :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(InDOS); lr.BX = FP_SEG(InDOS); break; What could be wrong here? The InDOS flag value itself? Stack usage during the call? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
Hello Michael, Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. This is either a really obscure extender or else also known under a different name, as even Google Usenet search doesn't pick up a hint of it. But it doesn't sound like it's a current issue for anyone. HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). It's available at http://www.alex-hint.narod.ru/hintos-e.html and I think it's becoming more and more important now when everybody releases Windows console programs without DOS counterparts. I converted successfully with it: Digital Mars C/C++ 8.38, MASM 6.15 and RAR 3.30 (its DOS version fails to modify existing archives but its Windows console version can do it). HiNTOS works under MS-DOS, PC-DOS and ROM-DOS, but not under DR-DOS and FreeDOS. To make it run under FreeDOS, the kernel will have to be rewritten not only to show SFT data to the outside world but also to work with this data internally as MS-DOS does. This won't happen soon, if at all :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret I don't understand the comments here. Who wrote this code? Does re-enrty sake before disk stack mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all call dos_crit_sects in entry.asm. Just tried what you suggested, Bart, but unfortunately the result is the same :-( Any other ideas? Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: 32RTM BitMixer feature incompatibility
Hello Michael, More specifically, I would need download access to an application which fails when running under these (or any) extenders, rather than the bare extender itself. The whole Borland C++ 5.02 is in Vietnam at http://www.saigontech.net/users/htliem/BC502/ The only files you need from there are UNPAQ.EXE (48 KB) and DPMI32.PAK (110 KB) containing 32RTM.EXE, because if you make 32RTM.EXE successfully load by itself without the -X (disable BitMixer) switch, the problem is solved. In short, the problem is getting its BitMixer feature work under FreeDOS. This is explained below. Without the context of the CPU instruction or data being patched and what the patch is meant to do, an offset and byte punch value is of no use for externally tracking down and correcting the underlying problem. As I wrote in a later post, I finaly remembered that the problem was in the so-called BitMixer. If you load 32RTM -X disabling it, it loads successfully. If load it without -X, it fails saying Unhandled exception 000D at 0020 034B ErrCode 000. My patch just changes the flag at offset 284h of 32RTM.EXE which controls if BitMixer is enabled by default from 0 (enabled) to 1 (disabled). Good luck! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Bart, if the partition table loops (recursive problem), MSDOS just hangs but FreeDOS checks for it and happily uses the partitions that are fine. Of course, there are bugs in MS-DOS that are not present in FreeDOS. But I think that the main problem of the FreeDOS kernel are not bugs, but incompatibilities, e.g. with DOSLFN 0.33. Some of them will never be solved, e.g. the code patterns which Windows 3.1 looks for that Eric mentions will NEVER be there, nor should they be there, of course. Not to mention the fact that the FreeDOS kernel's disk and memory footprints (40K vs. 50K in HMA) are smaller than those of MSDOS 7.10. The HMA footprint doesn't count much if a disk cache is used, because the number of buffers that HMA is filled in doesn't matter then. Microsoft even recommends that an explicitly low number of buffers is used in this case (e.g. 8). The disk footprint counts much more, but not always. For example, if someone wants to embed the kernel into the BIOS (which turned out much more difficult than I thought, as modern BIOSes won't allow ISA option ROMs!) it counts a lot. It counts for boot diskettes too, but not for hard disks. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Re: Will FreeDOS work from a primary slave partition?
Hello! Isn't the real bootable partition always assigned to C:? BTW, I think this (slightly) misleading, when (boot) partition from secondary disk becomes C:. Again, I suggest, probably, better to _not_ make it C:, but in main.c:FreeDOSmain() make it default (to allow process (fd)config.sys from it). Not a bad idea. Let's concentrate on bgfixing before the imminent FD1 release. I not object, but this question may be studied _for future releases_. Isn't? :) Sure. All suggestions here are for a post-FD1.0 release. EA the config file can contain a (processed in 0th pass) EA BOOTDRIVE=X line which makes FreeDOS select drive X: and EA load the config file from there for the other passes. Or it can even implement the ROM-DOS's NEWFILE= CONFIG.SYS command. Below is the relevant for NEWFILE excerpt from http://www.rtdusa.com/NEW_manuals/software/cpumodules/ROMDOS_manual.pdf Lucho __ NEWFILE CONFIG.SYS Command The NEWFILE command allows you to continue CONFIG.SYS file processing from a new file. The file can be located in another directory or even on a different drive. Syntax NEWFILE=filename[,device] Remarks The NEWFILE command is especially useful when the CONFIG.SYS file is located on an inaccessible drive or in ROM. Additional device drivers or instructions can be added easily to the new file and is processed along with the main CONFIG.SYS file upon starting the system. When the NEWFILE= instruction is processed, control passes from the present file (the one containing the NEWFILE instruction) to the file specified in the command. Any commands placed after the NEWFILE instruction in the original file are not processed. If the specified filename cannot be located, CONFIG.SYS processing returns to the original CONFIG.SYS file and the next instruction is processed. The next instruction can even be a second NEWFILE= statement, allowing flexibility for systems which may have a variety of drives installed or not installed at boot time. The first successful NEWFILE statement is processed, transferring control to the specified filename. The remaining instructions in the original CONFIG.SYS file, including NEWFILE= statements, are not processed. When NEWFILE is used, it is also created as an environment variable, retaining the value assigned by the NEWFILE= statement. This can be used in an AUTOEXEC.BAT file for further boot-up decision-making. The presence of [,device] on the NEWFILE command line will tell the ROM-DOS kernel to load this device driver before trying to process this NEWFILE statement. The format of this parameter is exactly the same as the parameter for a DEVICE= statement. Examples NEWFILE=C:\BIN\NEWCFG.SYS Causes instructions in the file NEWCFG.SYS, located in the C:\BIN directory, to be executed as part of the CONFIG.SYS file. NEWFILE=C:\BIN\NEWCFG.SYS,ROMDRIVE.SYS C000 Causes the device driver, ROMDRIVE.SYS, to be executed prior to processing the instructions in the file NEWCFG.SYS as part of the CONFIG.SYS file. Also, the environment will contain the following entry: NEWFILE=C:\BIN\NEWCFG.SYS Verify this by running the SET command with no parameters. NEWFILE commands can be nested. That is, your original CONFIG.SYS can call a second set of instructions via the NEWFILE command. The second file can, in turn, call a third file by using the NEWFILE command, and so on. Be sure that each filename in the successive steps has a unique name, otherwise, you will create an infinite loop as control is passed back to the same file repeatedly. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom, I have an idea - why not call the UNSTABLE branch DANGEROUS (but still moving!) and STABLE branch - ROCK-SOLID (like a stone, but also static and even almost dead as stone ;-) Joking of course... that you use it doesn't mean there are no news bugs. e.q. the complete ioctl was 100% mixed/changed/... how many ioctl's are you using - not every day, but at least once per month? I use IOCTL every day and that's how I found that the XMSDSK lock bug that prevented SCANDISK from checking the XMSDSK drive had come back as Arkady moved the lock check too low. Without anger, I wrote a patch for this, he accepted it with some minor changes, and - voila! Problem solved :) do you use MS-LANMAN networking (at least once per month)? etc... I don't even know what MS-LANMAN is, and I guess I don't use it ;-) just because YOU don't find bugs (old or new) doesn't mean there are no (old or new) bugs. Sure, but this can be said for the stable version too. In fact, Arkady hasn't touched the file system processing part of the kernel at all. So the two kenels don't differ very much internally. in particular (by your own finding) the new SYS is buggy (if loadseg != 60), but you only found out after using SYS (at least once). True. this shall not imply the arkady introduces new bugs every other day (although I've seem a couple of OOPS's); it's simply that I can't verify (perr review) what he changed simply because his stupid 'change everything' attitude. and so I won't touch the arkady branch with a 3 meter long stick. You already wrote this, but (1) I'd prefer the innocent presumption, to the guilty presumption towards him, and (2) I think that accusing him when he's absent to defend himself is not ethical. if you are using (and distributing) SMARTDRV, you can also distribute msdos xx. I don't distribute SMARTDRV - Microsoft did this for many years in their SOFTLIB FTP directory, and now when they no longer offer it, there are mirrors from which I can still be downloaded. smartdrv is an entirely different beast, that knows a lot about the underlying DOS; expecting compatibility with SMARTDRV is probably beyond the requitrements of this project (wouldn't hurt for sure, but not *required* ) I agree, but as I use it every day with FreeDOS, I think that besides the obscure incompatibility with its delayed write feature on FAT32 that I reported (which may well be a bug in SMARTDRV itself that doesn't reveal in MS-DOS!) I haven't noticed any other problems with it under FreeDOS. you didn't report, if the same problem happens with LBACACHE. Because since I found out that SmartDrive is compatible with FreeDOS, I don't use LBACACHE anymore *very* easy to fix if you have softice loaded. boot normal. softicebpint 13 ah=2 softicebpr 0:0 a000:0 t softiceboot (which reboots the machine, but leaves s-ice softiceactive, and you can step booting !!) Yes, the great SoftICE! Sweating on the scene is good, but now I'd prefer to be among the public and see if anyone else can sweat instead of me ;-) Let's give a chance to the young generation ;-) not 'complex tasks'. for tasks involving LFNDOS and creating new files; creating a lot of them just makes it more probable to happen. OK, perhaps I generalised unnecessarily. As Alexandre Dumas (father) put it, every generalisation is dangerous, even this one (one of my favourite recursive thoughts ;-) It's been a pleasure for me to work with Bart, you and the nearly forgotten victor who gave us FAT32 in a very ompressive way. Victor Vlasenko? Can you write more about this remarkable achievement of his? I'm sure that such people may not be, can not be, and are not forgotten! For me, it's THE dos today - and I can affort to distribute a junk DOS even less then Steve Gibson. OK, this is a good attestation, but perhaps if there wasn't the current absurd that using MS-DOS in any way is illegal (unless you've bought a legal second hand copy or bought it long ago - hey, I even have a Certificate for Authenticity for MS-DOS 6 - just in case the cops intrude here! ;-) everybody would use MS-DOS 7.10 which guarantees 100% compatibility (and even BUG compatibility :) It's good enough for what I do, and I take care that it remains that way. So this is your role since you stopped active kernel development - to act as a kind of Kerberos, and thus prevent the only person who still actively works on the kernel from having impact on it! Which means that the kernel development has virtually stopped now. How sad... Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom,
I certainly didn't wait to say this until he's absent
Sure. The eternal dispute continues forever! ;-)
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
What isn't routed through it?
I wouldn't hold my breath if I'd like to see this bug fixed.
OK. We'll see. Who knows, perhaps some day I'll try it myself.
a) he implemented FAT32
b) he implemented FAT32 virtually bugfree on first try
without 25 'please everybody test this' alpha releases.
he probably tested it himself before publishing.
c) he implemented FAT32 - and virtually every single line he changed
was necessary to do the job. no additional noise at all.
he probably optimized for smallest diff.
Great. So Victor's work can be an excellent example of how the job should
be done, indeed.
Speaking about Arkady, however, there are some circumstances which can
hinder his testing. He has only a 80386 PC with a small hard disk and
Windows 3.1. And he has no Internet connection at all!
and while I see no purpose in what he's doing in general, I look at his
changes, and what makes sense (to me), goes into my branch as well.
I see. That's good.
bug fixing will probably never stop, but squeezing single byte out of it
is IMO a complete waste of time.
When there are important bugs to fix - yes. But Arkady notices bugs
exactly while optimising! ;-)
you may have seen that while I stopped to work regularily on the kernel,
I probably made Stev Gibson happy with FreeDOS (stacks=9,256), made
FreeDOS load DD1000XX.SYS, made freedos kernel load Intel Pro1000
network driver, and found one reason for panic('too many fnodes in use')
4 serious real world bugs; so I wouldn't call my branch dead.
You're right. It's not dead. Good job, Tom! Still, there's no progress in
anything but bug fixing - the call of the day. By the way, will all your
changes go into the stable branch? It's good that the unstable branch
benefits from your work too and has all your bug fixes integrated too.
Regards,
Lucho
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom, the kernel talks directly to int13 and never uses int25 internally. SmartDrive 4/5 doesn't hook Int 25h as SmartDrive 3 hooks Int 13h. Here's a detailed description of the working principles of SmartDrive 4 and 5 - http://support.microsoft.com/?id=83325 I don't see any new features in keDANGEROUS either. Completely new no, but for example CONFIG.SYS menu processing has been improved (menu, prompts for each INSTALL command at the time of actual loading and not beforehand like in ROCK-SOLID-STONED ;) Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello! Jeremy: as for patch starting this discussion, I'll look at it when I get home from work tommorrow afternoon; anyway I've got to get ready Thanks for your commitment to maintain the kernel now when it's branched and thus hard to maintain Aitor: Could you please fill bugzilla entries with these please? Done. See bugs 1817 to 1821. A pitty to hear you go, or am I misinterpretating your words? They were misty enough to be understood. I don't leave FreeDOS but won't likely work on it anymore Michael: I'd like to know of any DOS extender compatibility problems as I have looked carefully for them. All the big name extenders and several 2nd or 3rd tier ones, work fine for all the applications tested. Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. I've patched it to make it work by modifying the byte at offset 284h from 0 to 1. The X32 DOS extender used in Digital Mars SMAKE had caused problems, so I've patched its offset 4707 from 23h to Bh, but right now when I test it, it works! (So somehow the bug got fixed during the last year ;-) Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. Alas, I did my patches more than an year ago and I don't remember how I found out these offsets :( Bart: Of course this is since the DOSLFN author apparently isn't interested in running it on FreeDOS and most FreeDOS developers aren't interested enough in DOSLFN (it's useless on networked drives for instance, which makes it almost useless in DOSEMU!). As Tom suggests, it's best to integrate LFN services into the kernel. The it can be distributed in two versions: LFN-enabled and non-LFN-enabled. But the task is rather complex as you know :-( Same for SMARTDRV, anyway why SMARTDRV if we have LBACACHE? Because it works better for me. They're very different beasts, using entirely different principles In any case these China DOS Union guys seem to think they can freely redistribute MSDOS 7.10 so if they think that's all fine and it works for what they want then I wish them good luck. Actually, the kernel they distribute is almost twice as small as the original kernel, because they managed to remove the embedded logo bitmap and other Windows-only code/data. If you have a chance to find Wengier's boot disk, take a look at it. Very good job! It's the best boot disk I've seen. PC-DOS 7.1 never seems to have been officially released but just appears to be what's used on Norton Ghost's boot disks. It can be freely downloaded with the trial Symantec Ghost version from the Symantec site. However, to get a DOS kernel consisting of only the IBMBIO and IBMDOS files and two boot sectors without even a SYS utility, one must download the whole 90 MB :( Latest build: 1.29 dated 9 November 2003. Remember that Steve Gibson went round trip back to FreeDOS after evaluating several other DOSes so this means that FreeDOS can't be that bad :) I just hope that if I ever need spinrite myself Steve can pay back by giving me a free copy ;) ;-) ;-) ;-) You're right. It's not bad at all. You know I like it, but I'm afraid the remaining bugs (I don't mean just my bugs of course) may play bad jokes on us in the future if not fixed. Besides, Steve can't afford to use any DOS illegally. So if I were him, I'd choose FreeDOS too. Sorry for this rather long message of mine. Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Copyright message, SFT vs F-node
Hallo Bart, Honestly I believe you're right here -- the issue is that changing copyright messages without agreement of the original author is a bit shaky IMHO. If you just get Pat's go ahead for the change then I'm all for it. OK. If Pat reads this list, perhaps he can write here if he approves the removal of this phrase? FreeDOS kernel build 2035a-WHATEVER. Copyright... FreeDOS kernel build 2035a-DEADLY_DANGEROUS! Copyleft Pasquale J. Villani the FreeDOS Project ;-) This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. I'd prefer This kernel has ABSOLUTELY NO WARRANTY and is licensed under the GNU Public License. No need to play copyleft license games at so solemn moments like FreeDOS startup! ;-) Well those can be dealt with, a bit awkward though. IIRC Win98 stores these clusters in the various SHARE related fields. You mean, fields at offsets 2B (BYTE FAR *sft_bshare), 2F (WORD sft_mach), and 37 (BYTE FAR *sft_ifsptr)? Not sure how many DOS programs (if any) depend on these on FAT32 though. Maybe SMARTDRV and DOSLFN or LFNDOS? I don't know. IMHO easiest to copy those fields across that matter, and then then delete them from the persistent fnodes. i.e. the far fnodes would be able to become different from the near ones, and xlt_fd() and save_far_fnode() would no longer use fmemcpy but copy individual fields. A possible solution, indeed. But it won't allow programs like HiNTOS which modify the SFT to work. Another difference is the way that directory entries are addressed: SFT's use (sector number, entry in sector), where fnodes use (starting cluster number of dir, entry in directory). And if you don't keep the whole directory entry in memory then dir_write would have to become read/modify/write instead of simply write. We can leave the directory entry structure in the F-node. It helps a lot indeed. Takes a fair bit of time of course, it just depends how motivated one is. Exactly. Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: 32RTM bug
Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. Forgot the message: Unhandled exception 000D at 0020 034B ErrCode . This happens without EMM386. I haven't tried it with EMM386 in FreeDOS. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM BitMixer incompatibility
Hallo Eric, could you file the list of problems which are mentioned in this thread as Bugzilla entries? I already filled in all the 5 bugs (3 kernel and 2 SYS bugs) I reported but the DOS extender bugs. I believe some RTM did work - and Lucho found a very small binary patch to fix 32RTM - so Lucho, please try to remember what you patched and why, thanks. Just remembered! :) If 32RTM is loaded without the so-called BitMixer, it works (e.g. load 32RTM -X and run TLIB - it works now, then unload RTM -U). So I had changed the byte at offset 284h that controls whether BixMixer is enabled from 0 (enabled) to 1 (disabled). Now when I run a Borland program that uses 32RTM, 32RTM gets loaded without BitMixer, even though the Borland program doesn't explicitly use -X. Unfortunately I don't have the slightest idea what BitMixer is... :( Hope this helps. Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] exeflat (2035a) start segment must be variable
exeflat.c of build 2035a (not 2035) has a problem. The start segment is an argument so it's a variable and its value - 2 must be loaded into DI instead of the constant 0x5E. Here's a fix: --- cvs\kernel\utils\exeflat.c 2004-07-09 04:16:30.0 +0200 +++ src\kernel\utils\exeflat.c 2004-08-07 13:16:38.0 +0200 @@ -303,6 +303,7 @@ 0x33,0xFF, /* 27 xor di,di */ 0xFF,0xE7, /* 29 jmp di; jmp 0 */ }; +*(short *)trailer[3] = start_seg - 2; *(short *)trailer[15] = (short)size + 0x20; *(short *)trailer[20] = start_seg + header.exInitSS; *(short *)trailer[25] = header.exInitSP; --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hallo Bart, This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hallo Bart, #define BUILD 2035 #define SUB_BUILD a #define KERNEL_VERSION_STRING 1.1.35 /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a /*#BUILD SUB_BUILD */ #define BUILD 2035a #define SUB_BUILD -UNSTABLE #define KERNEL_VERSION_STRING 1.1.35a /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a-UNSTABLE /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type -UNSTABLE. But it reports that on the screen right? Sure. It reports quite a lot of things. But if BUILD is defined as 2035 (Bart) and 2035a (Arkady),it may be used for identification too. I hate the build version dualism (e. g. version should be 2.0.35), but I know that neither this, nor removal of phrases like All Rights Reserved. that are useless now, nor removal of the f-nodes that prevent programs which modify SFTs from working, will ever happen. OK, long live the holy conservatism that saves the FreeDOS world from the Arkadifying hell ;-G By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Bart, Actually a couple of years ago it was build 1937 for version 1.0.2 ;) Wow! Well, I hope that it can be 2.0.60 for build 2060 in just a couple of years ;-) nor removal of phrases like All Rights Reserved. that are useless now Pat sent an email to this list -- here's your chance if you really care about this! The Buenos Aires Convention (1911) that required this was superseded by the Universal Copyright and Berne conventions. More on this at http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html It's more difficult than a simple removal. If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are FAR). Also fnodes are used in situations where SFTs can't do the job (dir operations). You're right - there are for example cluster fields that must be 32 bit and not 16 bit for FAT32. However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. I see. What about including the SFT in the F-node structure and removing all duplicating fields? As all SFTs are pointed to by a linked list, I think that this is possible. What do you think? An altogether different subject, and you know very well why. You've made plenty of patches yourself and most of them went in. For which I thank you, and I hope that in time, more Arkady's patches will be accepted too. No idea. A bit silent here indeed. Arkady, please respond if you read this. How are you? Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Tom et al, or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. 100% agreed. Since I use unstable kernel every day in practice, I think it has no more bugs than the stable one. But during the last few weeks I noticed several more bugs and incompatibilities present in both stable and unstable branches, most of them extremely difficult to fix, namely: 1. While copying a directory tree containing many LFNs *without* DOSLFN loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many invalid directory entries are created, which consist of parts of the contents of the copied files. Turning delayed write off makes the bug vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS, there is no bug. 2. The same test above, but *with* DOSLFN loaded, if done with the COPY /S command of 4DOS, which supports LFNs, causes only lost clusters and all the target files are in zero length. If done by another program which supports LFNs, for example FM, there is no bug. (FM is a Bulgarian all-in-one file manager / file editor / disk editor / CD player / calculator / Tetris / etc.etc.). Again, if FreeDOS is replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS - no bug. 3. If load segment (/L option) was different than 60h, bootstrap causes a read error during the loading of the kernel if it's longer than about 62 KB. The exact value of the load segment doesn't matter, and the bug reveals for *any* value other than 60h. 4. SYS hangs up or causes an invalid opcode at the time of reading the boot sector of my ATA flash cards, if compiled by anything than Watcom. Non-Watcom versions of SYS work on all other drives. 5. DOSLFN 0.33, run off a XMSDSK RAM-disk, doesn't show the files there with dir in FreeDOS, but works in MS-DOS 7.10. DOSLFN 0.32 works everywhere. DOSLFN 0.33 works on any other disk in FreeDOS Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). Thank you for your attention. It's time for me to concentrate on other tasks. It's been a pleasure for me to work with you guys. I hope that FreeDOS will be THE DOS one day. But hardly real soon now... Regards, Lucho () --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Unofficial CVS FAT32/386/BC4.52/aPack kernel binary
On Mon, 05 Apr 2004 20:11:05 +0200, Erwin Veermans wrote: As always, a patched CVS kernel binary (FAT32, 80386, BC 4.52, aPack) is available in my ROMDSK binary package that can be downloaded at http://linux.tu-varna.acad.bg/~lig/romdsk/romd-bin.rar I get: Forbidden You don't have permission to access /~lig/romdsk/romd-bin.rar on this server. What am I doing wrong? Nothing. It's my fault, sorry. I had set incorrect permissions for the file (0600 instead of 0644). Fixed now. Try again. or should I send some cigars first ? ;-) ;-) Thanks, but I don't smoke ;-) Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] handle 4 defaulting to PRN???
On Mon, 5 Apr 2004 23:13:16 +0100 (BST), Bart Oldeman wrote:
Hi, in the FAQ, somebody claims that file handle 4 should default to
PRN:
http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/224
Any idea why this would work at all? And why it works in MS but not in
FreeDOS? Used language is C.
Look at the definitions in stdio.h - stdaux is _iob[3], and stdprn is
_iob[4] (Borland uses _streams instead of __iob). The order of these
devices in different in MS-DOS and FreeDOS:
MS-DOS: CON, AUX, PRN, CLOCK$, A:-D:, COM1, LPT1, LPT2, LPT3, CONFIG$,
COM2, COM3, COM4
FreeDOS: CON, PRN, AUX, LPT1, LPT2, COM1, COM2, COM3, COM4, CLOCK$,
A:-D:
Fortunately, fixing this is very easy. It's enough to swap the
corresponding entries in io.asm. Do I need to provide a patch for this?
Aren't you looking at the wrong place here? It's about the high level
handles as far as I know.
The PSP has for the handles:
0 1 2 3 4 5 6 ...
01 01 01 00 02 FF FF
01 = CON
00 = AUX
02 = PRN
which means that also in FreeDOS, (high level) handle 4 corresponds to
PRN.
So the problem must be somewhere else.
I don't understand you (I usually need a bit more explanation ;-) but
you're right! The follwing simple test program
#include stdio.h
void main()
{
fputc('\f', stdprn);
}
works on MS-DOS, FreeDOS before my patch, and FreeDOS after my patch!
So my patch is not needed then. And I have no idea what the bug reporter
means :-(
But today I encountered an application (a X-modem file transfer program
called TRANSFER.EXE by Datalight) that hangs up FreeDOS after returning to
DOS prompt when all my drivers and TSRs are loaded (and not in bare DOS).
This doesn't happen in MS-DOS (with the same TSRs and drivers). I need to
investigate where exactly the incompatibility is and then what exactly
causes the hang.
Lucho
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] handle 4 defaulting to PRN???
Hi, in the FAQ, somebody claims that file handle 4 should default to PRN: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/224 Any idea why this would work at all? And why it works in MS but not in FreeDOS? Used language is C. Look at the definitions in stdio.h - stdaux is _iob[3], and stdprn is _iob[4] (Borland uses _streams instead of __iob). The order of these devices in different in MS-DOS and FreeDOS: MS-DOS: CON, AUX, PRN, CLOCK$, A:-D:, COM1, LPT1, LPT2, LPT3, CONFIG$, COM2, COM3, COM4 FreeDOS: CON, PRN, AUX, LPT1, LPT2, COM1, COM2, COM3, COM4, CLOCK$, A:-D: Fortunately, fixing this is very easy. It's enough to swap the corresponding entries in io.asm. Do I need to provide a patch for this? Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] handle 4 defaulting to PRN???
MS-DOS: CON, AUX, PRN, CLOCK$, A:-D:, COM1, LPT1, LPT2, LPT3, CONFIG$, COM2, COM3, COM4 FreeDOS: CON, PRN, AUX, LPT1, LPT2, COM1, COM2, COM3, COM4, CLOCK$, A:-D: Fortunately, fixing this is very easy. It's enough to swap the corresponding entries in io.asm. Do I need to provide a patch for this? Here it is, below. Now stdaux and stdprn should work as in MS-DOS. Lucho --- io.asm 2003-06-15 16:21:26.0 +0200 +++ io.asm 2004-04-05 20:08:32.0 +0200 @@ -81,33 +81,33 @@ ; global _con_dev _con_devequ $ -dw _prn_dev,LGROUP +dw _aux_dev,LGROUP dw 8013h ; con device (stdin stdout) dw GenStrategy dw ConIntr db 'CON ' ; -; Generic prn device that can be redirected via mode -; -global _prn_dev -_prn_devdw _aux_dev,LGROUP -dw 0A040h -dw GenStrategy -dw PrnIntr -db 'PRN ' - -; ; Generic aux device that can be redirected via mode ; global _aux_dev -_aux_devdw _Lpt1Dev,LGROUP +_aux_devdw _prn_dev,LGROUP dw 8000h dw GenStrategy dw AuxIntr db 'AUX ' ; +; Generic prn device that can be redirected via mode +; +global _prn_dev +_prn_devdw _Lpt1Dev,LGROUP +dw 0A040h +dw GenStrategy +dw PrnIntr +db 'PRN ' + +; ; Printer device drivers ; _Lpt1Devdw _Lpt2Dev,LGROUP --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] handle 4 defaulting to PRN???
Fortunately, fixing this is very easy. It's enough to swap the corresponding entries in io.asm. Do I need to provide a patch for this? Here it is, below. Now stdaux and stdprn should work as in MS-DOS. As always, a patched CVS kernel binary (FAT32, 80386, BC 4.52, aPack) is available in my ROMDSK binary package that can be downloaded at http://linux.tu-varna.acad.bg/~lig/romdsk/romd-bin.rar Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeDOS idle HLT
On Mon, 29 Mar 2004 18:55:44 -0300, Alain wrote: New Power supplies are very cheap. For that they have simplified many important circuits. They don't handle current fluctuations vary well. Well, again from bad to worse... They must come with a BIG red sign HLT forbidden! then :-( Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new conv mem highs.
On Mon, 29 Mar 2004 19:00:54 -0300, Alain wrote: INHO and considering that FreeDOS is in C versus all other DOSes being in ASM ROM-DOS, our greatest living competitor (not speaking of the venerable DR-DOS that is still in coma and PC-DOS that must have finally died in 2002) is also written 90% in C but uses much more conventional RAM. But what we talk about is *data*, not code, so language doesn't matter. I believe that we should just _CELEBRATE_ :) FreeDOS 7.1: 10688 MS-DOS 7.1: 9680 PC-DOS 7.1: 9456 Where's the Champaigne? ;-) Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new conv mem highs.
On Fri, 26 Mar 2004 22:22:20 + (GMT), Bart Oldeman wrote: Can you check again? I think I solved at least Lucho's problem during the init phase -- when fnodes could overlap disk buffers! Weird things could happen indeed. Congratulations, Bart! Bug fixed indeed - just tried. But I keep thinking that the right place for the far fnodes is the HMA (I haven't checked yet your latest CVS changes though - you work lightning fast! ;-) By the way, you're a good detective (but in time you'll see that I'm also not a bad one ;-) Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patches
On Sat, 27 Mar 2004 03:22:59 +0300 (MSK), Arkady V.Belousov wrote: PS: Just checked TechHelp: it says nothing about AL, only AH=6C. Definitely bug in RBIL. :( MS-DOS technical reference defines AL=0 as reserved (http://www.clipx.net/ng/dos5/ng1ff99.php). We already discussed this issue last year and I wouldn't like to comment on it further. Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.40,1.41 etc
if (new_diroff == 65535) Borland C++ complains here. Change the constant to 65535UL (see patch below). Although Borland says constant is long, it's enough to change it to 65535U, not UL. Lucho diff -ruN cvs/kernel/kernel/fatdir.c src/kernel/kernel/fatdir.c --- cvs/kernel/kernel/fatdir.c 2004-03-22 14:45:54.0 +0200 +++ src/kernel/kernel/fatdir.c 2004-03-22 14:49:00.0 +0200 @@ -213,7 +213,7 @@ unsigned new_diroff = fnp-f_diroff; /* can't have more than 65535 directory entries */ - if (new_diroff == 65535) + if (new_diroff == 65535U) return DE_SEEK; /* Directories need to point to their current offset, not for */ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Last change introduced an unknown unit delete bug
Bart, unfortunately your very last change (scaling and shortening the directory entry pointer) introduced a bug! When I start my elvis editor (a vi clone) and exit it, it can't delete its temporary file ELV_3E5.1 from my XMSDSK RAM disk where is my temporary directory. 4DOS fails to delete it saying 4DOS: (Sys) Bad disk unit :\elv_3e5.1. When I test this with rm in STEPDOS I see that the UNLINK (delete file) DOS function (41h) fails with return code of 14h (unknown unit) which isn't even allowed for it and is an Int 24h error! What's going on here? A slight detailisation. This error is returned on attempt to rename the file or delete it. But all reads on it succeed. So, it must be happening only on directory writes. Besides, I may be wrong that this bug was introduced by your very last changes, because I haven't checked the contents of my drive I: for a while (probably a couple of days). So it may be a result of a slightly earlier change, but in all cases it's a very recent change. Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] LF written to the file being read?
But what if it was the first entry in the root directory? Then the new_diroff++ in dir_read() will make it -1! remove_lfn_entries() checks for fnp-f_diroff == 0. The first entry can't have any LFN entries connected to it. Of course! I should have seen that. This is so for lfn_dir_read() too. I wanted to ask you one more question: chario.c:read_line_handle() calls echo_char(LF, sft_idx) - doesn't this write the LF to the file being read? Thanks for the 240 more low memory bytes, by the way! ;-) Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Extra CRs after input in output file
On Thu, 18 Mar 2004 11:14:39 +0200, I wrote: the redirected output contains two consequtive carriage returns though. I mean that the output file contains extra CRs only after the r and q input commands, not where DEBUG does its own output. Good news - I now saw that this is exactly the same under MS-DOS 7.1! So let it be this way ;-) Lucho http://linux.tu-varna.acad.bg/~lig/freedos/CVSPATCH.TXT http://linux.tu-varna.acad.bg/~lig/romdsk/romd-bin.rar --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: editing command line
I mean: is this mean, that editing code is/should duplicated in kernel and command.com? As far as I know, no. FreeCOM has its own command line editor with history and auto-competion. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: editing command line
I mean: is this mean, that editing code is/should duplicated in kernel and command.com? As far as I know, no. FreeCOM has its own command line editor with history and auto-completion. But: 1. In kernel present editing code. 2. If code presented in command.com, how this affects other programs (say, DEBUG)? I already wrote that it's in the kernel, not in the shell. Any function 0Ah (3Fh) call does it. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: editing command line
The F3-style command line editing is in the kernel because function 0Ah (3Fh when reading from standard input) in MS-DOS does it. Period. As to FreeCOM, it has a better (4DOS-style) command line editing and I don't see a reason for a separate DOSEDIT. Period. I'll not answer anymore. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] chario.c, dsk.c, floppy.asm patches
On Sun, 21 Mar 2004 23:42:26 + (GMT), Bart Oldeman wrote: It appears that ^C has to be echoed to stdout. This is easy to test, I'm using a simple test0a program, see below. If you (in MSDOS) run test0a foo and press ^C then the ^C ends up in foo. Or if I run DEBUG BOZA then type ^C and Q then BOZA contains the ^C, so you're right indeed! Boza (millet-ale) is a very specific thick light-brown Bulgarian drink that I don't like and is our rough equivalent to FOO.BAR (there is also a virus with this name, Bulgarian, of course ;-) Which is not stderr. I thought that stderr is more logical, but as I see, Microsoft didn't think so :( Let it be! :) Also about LF. Press ctrl-j and you'll see it is echo'ed as cr-lf, except when you're still at the beginning of a line and it's the first key you press. ctrl-j ctrl-j or ctrl-f ctrl-j already does the trick. Most likely the first time trick is to deal with cr-lf from redirected input, indeed. OK. Most important is that your changes fix the DEBUG redirectioj bug, too! So I accept them. I'm leaving your floppy changes out of the kernel for the time being as you are still dry swimming as far as I understood, and RBIL specifically says about int13/ah=16 B-1316--- INT 13 - FLOPPY DISK - DETECT DISK CHANGE (XT 1986/1/10 or later,XT286,AT,PS) AH = 16h DL = drive number (00h-7Fh) that the TSR lets this function be valid for DL=80 I still find hard to believe Wow! I didn't notice that this call is only for floppy disks (0-7F)! So you're right again, as usual! ;-) Well, Bart, congratulations and thanks for your changes that fix those bugs! As to my dry swimming, it's because I don't have a ZIP drive [yet] to test its disk change... So, this bug will have to wait until I buy one just to see what's going on :-( Don't you just hate IOMEGA? ;-G Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Extra CRs after input in output file
the redirected output contains two consequtive carriage returns though. I mean that the output file contains extra CRs only after the r and q input commands, not where DEBUG does its own output. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] DEBUG redirection bug fixed, 2 new remain
On Wed, 17 Mar 2004 13:37:07 + (GMT), Bart Oldeman wrote: It looks like a bug in both DEBUG and the kernel. What happens is the reference count in the SFT gets too high. 1. open: 1 2. int21/ax=4b: 2 3. int21/ax=55: 3 (this function called by debug) then: 4. int20: 2 5. int21/ah= 3e: 1 ... and the file still isn't really closed If you do the redirection again then it will use new sft entries. Just do the above a couple of times and you'll see that opening a file gives an sft idx entry in the PSP that is higher and higher... in other words, leaked file handles... Wow! What a nightmare! :-( It doesn't hurt to commit (sync) the file though so with the patch below the problem is solved. And this is so for both MS-DOS DEBUG and FreeDOS DEBUG, as it seems from your and my tests... That's strange. Then MS-DOS DEBUG would also leak handles... Seems so, because applying your patch FIXED the problem with MS-DEBUG too! Congratulations! :-) So far so good. But when the input debug SCRIPT contains just these lines: r q doing DEBUG SCRIPT starts to output NULs and BEEPs! Pressing Ctrl-C stops it, but then the SCRIPT file has that ^C appended! This is like a similar bug we had - do you remember? :-( But when SCRIPT has only CARRIAGE RETURNs as line terminators (without line feeds), it's OK! So we have yet another TWO bugs to fix :-( Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] redirection BUG
On Mon, 15 Mar 2004 22:27:45 +0300 (MSK), Arkady V.Belousov wrote: a int 3 g=100 q Run DEBUGT.DRESULT (where DEBUG is by Paul Vojta, MS-DEBUG doesn't work under FreeDOS). This is wrong. MS-DOS 7.10 DEBUG *does* work under FreeDOS 7.10! I've used it many many times. Under MS-DOS result file is fine, under FreeDOS redirected file is zero size. Noted by Bernd Blaauw I don't understand anything. What redirected file? The above script just sets a break-point. Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
