Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
On Sat, 17 Jul 2004, Arkady V.Belousov wrote: Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks like Steffen fixes (at least, one) bug, related to environment, but up to now I don't know where to download fixed version. (May be, now you remind for Steffen to make fixed version available for download?) Arkady, FreeCOM _never_ had a problem with an _empty_ environment, but: + with a missing '.' in PATH, long fixed, and + with the MS-DOS-style of an empty environment, you've called broken yourself. That's also fixed in CVS. No other problems are aware to me. BTW: To add PATH or COMSPEC won't hurt any shell. I may ADD adding any variable (including PATH=.) to (empty) environment, but better, if Steffen at last makes fixed FreeCOM available for download. Steffen?! When? May be, now you see that fixed programs should be available to download? I do not have no service contract about FreeCOM with anyone, so I will handle my resources at own will. I WILL NEVER DISCUSS THIS ISSUE AGAIN. If this topic comes up again, simply search the archives for my side of the thread. Bye, -- Steffen Kaiser --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Big tour of 32bit stuff in kernel / optimization / bugs?
Hi! 19--2004 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: Hi, I think it is now clear that Turbo C 2 cannot optimize for 386. HOWEVER, the NASM parts can still be optimized for 386. ... but then save a few byte by using a different longDIVMODMUL implementation doesn't make much sense. EA This was not only about space, it is also about speed. 8086 code is EA slow with mul, div, shift of 32 bit numbers, because - at least in EA TC - it is implemented in bit-by-bit loops. This is true only for division, where divisor is more than 2^16-1. EA Not sure how often 32 bit EA numbers are used in speed-critical way, though. Not much. I not profile FD kernel, but I doubt that 32-bit division with big divisors there have noticeable impact (especially on 8086 with small disks). EA We have LDIVMODU and LMULU, and they do: This is only for Watcom. This is Bart's trying to completely replace standard Watcom's libraries (and currently no one module from Watcom is required). EA By the way, what is this? -- MATH_EXTRACT=*H_LDIV *H_LLSH *H_LURSH *F_LXMUL MATH_INSERT=+H_LDIV +H_LLSH +H_LURSH +F_LXMUL EA ...? This is instructions for librarian to extract and to add consequent modules from/to consequent libraries. EA It might sound stupid, but I cannot find any place in the sources EA where LDIVMODU is actually used? Calls to __U4M and __U4D generated by compiler itself. EA Neither for LMULU... probably it means that our Asm code replaces something EA which would be normally present in the compiler as library function? Yes. EA init_LBA_to_CHS ... - unsigned hsrem = (unsigned)(LBA_address % hs); EA So we explicitly disallowed LBA_address / hs being 64k! You could EA rewrite EA that as: chs-Cylinder = (LBA_address16 = hs) ? 0xu : (unsigned)(LBA_address/hs); Nice suggest. :) unsigned hs = driveparam-chs.Sector * driveparam-chs.Head; chs-Cylinder = hiword(LBA_address) = hs ? 0xu : (unsigned)(LBA_address / hs); hs = (unsigned)(LBA_address % hs); chs-Head = hs / driveparam-chs.Sector; chs-Sector = hs % driveparam-chs.Sector + 1; EA Similar code exists in LBA_to_CHS - this has different arguments and range EA checks, but the core problem is the same: An unneeded 32:16=32 division EA which can be replaced by a 32:16=16 one Unortunately, you can't replace 32/16=32 by 32/16=16. :( Because nature of C/C++ (type promotions), (most) compilers always use generic 32/32=32. EA (actually the code even complains EA already for results 1023, one could arguably add support for special EA high cylinder count extensions like: EA - int 13.ee / 13.ef (add N to cylinder value of next int 13.2/13.3) Why? Mentioned error message shouldn't happen in real life, because initdisk.c selects LBA mode for all partitions above 1023 cylinder. EA While looking for other 32bit variables, I found a problem in the dmatch EA structure: dm_dircluster should be of type CLUSTER, not of type if FAT32 EA then ULONG else You forget about UWORD reserved, for which #ifdef anyway should be used. Or union around CLUSTER should be added. EA Same for dpb_xrootclst and dpb_xcluster! Useful, but not neccessary. I, probably, replace ULONG by CLUSTER at some time, when (and if) will touch consequent headers. EA Not sure if you can change this: ULONG l_diroff; /* offset of the dir entry */ EA ^ if you use the slot number instead, 16 bit will be enough. EA As far as I know, FAT32 directories cannot have 64k entries each. ULONG used only in lfnapi.txt. Desynced description. Fixed - see patch in next letter. EA Another dmatch issue: dm_size is LONG but should be ULONG at least for EA FAT32. Potential bug cause for processing of files 2 GB. Officially, DOS doesn't allows to have files more than 2G. In any case, dm_size (currently) used only as acceptor for dir_size field, which _is_ unsigned long. EA The f_node f_offset is ULONG, too. Nice. Would it be okay to change EA f_count from UWORD to UBYTE? No. This makes misaligned structure, while space savings is low. EA time? How about f_mode and f_flags, both 16 bit...? Hm. Looks like they may be joined (of course, with shifting for f_flags by two bits higher). But I not yet study the Bart's fnode, so this is optimization for later. EA and both the f_cluster (current) and f_cluster_offset (relative cluster EA number within file), both of type CLUSTER. f_cluster_offset is a _relative cluster number_ in cluster chain (whereas f_cluster is a _physical number of current cluster_). See computations at lines 1315-1357 in fatfs.c. Probably, this field may be removed if fnode structure may be modified. EA Finally there is f_offset, which EA is ULONG, as told. Note that f_cluster_offset cannot be calculated from EA f_cluster - at most you could try to relate it to f_offset, not sure... It already: see line 1315 in
Re: [Freedos-kernel] Big tour of 32bit stuff in kernel / optimization / bugs?
Hi!
19--2004 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
[...]
EA The DosGetFree function (remember my bug report...) calls
EA flush_buffers if called from FatGetDrvData (int 21.1c?), maybe this is
EA where it crashed? Otherwise it also is int 21.36 ...
EA Plus, how do we know that this does not get a NULL pointer? --
EA if (*nc != 0x)
EA *navc = (COUNT) dos_free(dpbp);
In theory, *nc will never 0x (because it points to DX, and DL on
input is a drive number). Thus, you right, there is bug (which garbages
value of INT0 vector).
EA That fake for 64k cluster size looks evil, too.
EA while (ntotal FAT_MAGIC16 cluster_size 0x8000)
EA { SHL cluster size and spc, SHR ntotal and nfree }
EA ... seems to be a cluster size determination loop which should probably
No. As I understand, this loop is used to imitate FAT1x over FAT32. For
example - _known_ size of cluster is increased up to 32k to decrease ntotal
(total clusters on drive). Example: we have cluster 4k and total clusters
0x1 (long value). After increasing cluster size to 32k we get (16-bit!)
value 0x2000 for total clusters (and return 0x2000 instead 0x).
[...]
EA BOOL dos_setfsize(COUNT fd, LONG size)
EA should be ULONG, as it already is for dos_getfsize!
[...]
I wrote all these small fixes in my todos. When I will change these
files, I will fix also this.
EA void far *DynAlloc(char *what, unsigned num, unsigned size)
EA ...
EA if ((ULONG) total + Dynp-Allocated 0x)
EA ... should be possible to do that without having to use ULONG.
:) Yes. if (total ~Dynp-allocated).
EA STATIC int LBA_Get_Drive_Parameters(int drive, struct DriveParamS
EA *driveParam)
-- bug:
EA if (lba_bios_parameters.heads 0x ||
EA lba_bios_parameters.sectors 0x ||
EA lba_bios_parameters.totalSectHigh != 0)
EA {
EA printf(Drive is too large to handle, using only 1st 8 GB\n
EA ...
EA Explanation: totalSectHigh nonzero means either buggy BIOS (happens!) or
EA disk size above 2 TeraBytes! This does definitely NOT mean that you should:
EA ...
EA goto StandardBios;
This is not bug, this is, probably, misfeature.
EA ... not at all! Just use LBA and clip the useable disk size to 0xUL
EA sectors.
Nice idea, but Bart and Brian also should give their opinion.
EA Can somebody explain - in rwblock - what this does and why it uses UCOUNT?:
EA UCOUNT sectors_to_xfer, sectors_wanted;
What wonder you?
EA sectors_wanted /= secsize;
EA ... can this be optimized to use a shift instead? 16bitvalue - 16bit.
DPB doesn't contains value bits per sector_size value (similar to
dpb_shftcnt).
EA I saw the compile time option WRITEZEROS, could that be extended to
EA be supported by shrink_file (or maybe in rwblock itself?) ...?
?
EA Reading LBA_Transfer now, very interesting... play_dj (TODO: should call
EA the int 2f interface which allows to suppress the message!!),
?
EA int 1e stuff
EA and disk reset, track wrap avoidance for CHS, DMA wrap avoidance --
EA ** You should be allowed to disable DMA_max_transfer check for non-floppy!?
Why? DMA aligned access is useful in any case.
EA ** You should be allowed to disable track wrap protection for non-floppy!?
?
EA Wow. That was huge.
Yes, this letter _very_ huge. In future, please, split such long things
over more letters.
---
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_idG21alloc_id040op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Hi! 19--2004 08:29 [EMAIL PROTECTED] (Steffen Kaiser) wrote to [EMAIL PROTECTED] [EMAIL PROTECTED]: Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks ^^ like Steffen fixes (at least, one) bug, related to environment, but up to now I don't know where to download fixed version. (May be, now you remind for Steffen to make fixed version available for download?) SK Arkady, FreeCOM _never_ had a problem with an _empty_ environment, but: See underlined words above. With empty environment FreeCOM (whic is currently available for use) _is_ buggy. SK + with a missing '.' in PATH, long fixed, and SK + with the MS-DOS-style of an empty environment, you've called broken SK yourself. You mean Arkady called MS-DOS-style empty environment broken? Yes, I call this. But this is MS-DOS and all its bugs become standard and called feature. For example, INT25/26. There is bug, but you _should_ imitate and workaround this. SK That's also fixed in CVS. WHERE I MAY DOWNLOAD COMPILED FIXED VERSION OF FreeCOM? Very need. :( environment, but better, if Steffen at last makes fixed FreeCOM available for download. Steffen?! When? May be, now you see that fixed programs should be available to download? SK I do not have no service contract about FreeCOM with anyone, so I will SK handle my resources at own will. I WILL NEVER DISCUSS THIS ISSUE AGAIN. :( Of course, you have no contract, but hidding fixed version makes repeatable question why FreeDOS is wrong (for example, as reported by Alain: FreeCOM reports out of memory). [Note: not all may access CVS or recompile version from CVS, thus not prepare to download compiled version makes it equal to hiding.] BTW, is there ANYONE, who may recompile for me FreeCOM from CVS?! Then I will use it myself and redistribute when other users will ask. --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
On Mon, 19 Jul 2004, Arkady V.Belousov wrote: Hello, Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks ^^ like Steffen fixes (at least, one) bug, related to environment, but up to now I don't know where to download fixed version. (May be, now you remind for Steffen to make fixed version available for download?) SK Arkady, FreeCOM _never_ had a problem with an _empty_ environment, but: See underlined words above. With empty environment FreeCOM (whic is currently available for use) _is_ buggy. SK + with a missing '.' in PATH, long fixed, and SK + with the MS-DOS-style of an empty environment, you've called broken SK yourself. You mean Arkady called MS-DOS-style empty environment broken? Yes, I call this. But this is MS-DOS and all its bugs become standard and called So, you've fixed the FreeDOS kernel to issue the broken MS-DOS empty environment to programs, did I understood it correctly? Actually, it would be cleaner to never issue an empty environment. You will, for instance, find a reply in the archives from yourself, stating that the end of the environment is _not_ marked by '\0\0' (two bytes zero) as the poster stated, but by an empty string, hence, when the environment is completely empty, there is a single '\0'. To have a good and working work-around for any program and your own advices, it would be best to never pass on an empty environment. Bye, -- Steffen Kaiser --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
steffen) put MSDOS + current distributed FreeCOM on floppy. boot, and say F5 (skip everything) and you'll have a load complaining FreeCOM, although it definitively gets it's startup path. Arkady) it's a plain dull idiotic mathematicians braindead idea to 'improve' freedos kernel, but break all generations of distributed FreeCOM's just my 2 EUROS on that issue tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hi Eric, please be aware that some structs (such as fnodes) are free-style, but most are dictated by RBIL. It's best to use CLUSTER in internal parameters and fields etc. because this is either 16 or 32 bits. Just like those freedos specific open flags they are completely kernel-internal and have no meaning to the outside world. However, when mirroring an RBIL-dictated structure we should use ULONG (which is FD kernel speak for a 32 bit unsigned integer, I'm not terribly happy about the naming, but hey, we know what it means and what it does by now), it can never be 16-bits. Using CLUSTER there would just be obscuring things -- what if some weirdo makes CLUSTER 64 bits? It would completely break the mirroring. Also be careful with LSEEK. The offset you feed to it really is signed -- on the other hand with two-s complement it doesn't really matter. The Not Yet Implemented part about this 2GB files thingy is that normally opened files have to fail reads and writes if the current offset is beyond 2GB, perhaps also int21/ah=3d should refuse opening files 2GB. A special flag for int21/ah=6c is needed to enable 2Gb opens. Bart --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
On Tue, 20 Jul 2004, Bart Oldeman wrote: I'm still not sure if and when I really return, the archives aren't really encouraging... In any case, I appreciate that a bug was found in ludivmul.inc; the same bug was in fact present in the 64 bit version I adapted it from! Well I notified the original author. I should add that while serious it presently can never be triggered in the fd-kernel. All but 2 U4D's use 16bit divisors. The 2 places that use a 32bit divisor are in initdisk.c. But these two places aren't interested in the remainder. Bart --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's posts.
Eric, please please, if you discover that you made a mistake in a post then please edit the post while you still can. IMHO It's very annoying to read: Hmmm this must be the case. Oh no, sorry, what I said above was wrong, it is like this. This makes your already long post even longer than necessary, and adds unnecessary noise. You're not talking on the phone or IRC here. Of course this is true for everyone, it's just that Eric seems to make a habit out of it. Sorry, maybe you think it's cool to write that way but I'm afraid many people will ignore the rest of your post if you start rambling like this. Bart --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Bart Oldeman schreef: I'm sorry but I simply don't have the time to go through all the other patches. If they were reduced to just bug fixes I'll promise that I'll have another look though -- I still monitor the mailing list every now and then. Guys *any* project that wants to be close to a 1.0 release must be in deep freeze, a stabilation, that means that we should really freeze the mainline kernel for anything but bug fixes. No optimizations, no reformatting, no new fancy macros, no nothing but bug fixes with the minimal amount of lines changed. Of course feel free to have your own branch, but I don't think it's in the interest of the project to use that for a 1.0. So I can make a deal, you isolate your bug fixes and I'll return and be friendly, or you don't and I'll simply disappear. It's that easy. Hi Bart!, thanks for showing up a brief moment. Arkady is doing a nice job, but I think you kernel developers should give him some more time to work out his changes. At a given moment, he should probably issue a code-freeze and then make stuff more readable/review-able Anyway, Lucho is reviewing Arkady's code, Tom started a private (more or less personal) branch, and Jeremy, I think, was both creating a 2035a (2035 + very conservative patches) and a development branch (Arkady's code into CVS). perhaps the utter-most conservative and really required patches (bugfixes) should be provided for review before going into 2035a. Meanwhile Arkady's version might become 2036 in a later stadium? all IMHO, ofcourse. It's the kernel (co)developers' opinions which should count for you, not mine :) are you planning on improving MEM again in the near future? I *still* (sigh!) postponed releasing a new FreeDOS distro..blame it on the holidays Bernd --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hi Bart, In any case, I appreciate that a bug was found in ludivmul.inc so do I What I don't like is that the fix from Arkady (for the 1000th time...) does 3 things at the same time -- formatting, fixing, and optimizing. neither do I like that. This makes it impossible to see where things are really fixed. See the following is enough: --- ludivmul.inc.~1.2.~ Sun Jan 27 14:13:07 2002 +++ ludivmul.incTue Jul 20 00:35:31 2004 @@ -88,10 +88,12 @@ pop bx ; get dividend lo-word mov cx, ax ; save quotient mul di ; quotient * divisor hi-word (low only) + pushdi ; save divisor hi-word xchgax, di ; save in di mov ax, cx ; ax=quotient mul si ; quotient * divisor lo-word add dx, di ; dx:ax = quotient * divisor + pop di ; restore divisor hi-word sub bx, ax ; dividend-lo - (quot.*divisor)-lo mov ax, cx ; get quotient pop cx ; restore dividend hi-word thanks for that. I was going to analyse it was well to find the REAL difference to apply to my kernel branch, your effort saves me some time and it's again remarkable how little changes are needed wrt. the 200+ line diff's arkady sends. I'm sorry but I simply don't have the time to go through all the other patches. neither do I - specially if they are 90% completely useless formatting changes, 9% introcing LPVOID and Cstr data types, with (at most) 1% hidden gem inside. If they were reduced to just bug fixes I'll promise that I'll have another look though -- I still monitor the mailing list every now and then. Guys *any* project that wants to be close to a 1.0 release must be in deep freeze, a stabilation, that means that we should really freeze the mainline kernel for anything but bug fixes. No optimizations, no reformatting, no new fancy macros, no nothing but bug fixes with the minimal amount of lines changed. 110% agreed. Of course feel free to have your own branch, but I don't think it's in the interest of the project to use that for a 1.0. So I can make a deal, you isolate your bug fixes and I'll return and be friendly, or you don't and I'll simply disappear. It's that easy. well - I maintain such a kernel branch; however not sure if I catch every hidden gem... of course source is available on request. tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
At 12:55 AM 7/20/2004 +1200, Bart Oldeman wrote: I'm sorry but I simply don't have the time to go through all the other patches. If they were reduced to just bug fixes I'll promise that I'll have another look though -- I still monitor the mailing list every now and then. Guys *any* project that wants to be close to a 1.0 release must be in deep freeze, a stabilation, that means that we should really freeze the mainline kernel for anything but bug fixes. No optimizations, no reformatting, no new fancy macros, no nothing but bug fixes with the minimal amount of lines changed. Of course feel free to have your own branch, but I don't think it's in the interest of the project to use that for a 1.0. I am glad someone said this that nicely. I have been stunned that the vast number of relative last-minute pre-1.0 kernel changes which do not consist mostly of bugfixes or user-driven requests/needs has been considered a good idea by anyone. Items such as multiple stand-alone changes to source code comments which only change indentation levels or add a trailing tab are egregiously unnecessary when considered immediately prior to FD 1.0 release. On the other hand, this is exactly the sort of issue that kills so many open source developments. The talent butts heads over what needs to be done, no compromise can be achieved, and one group of talent splits away or quits in disgust. It would be very disheartening to see that happen (again) with FreeDOS, particularly given how close it is to 1.0. I don't work on kernel and have kept quiet until now because of that, but as this whole mess appears to be coming to a crisis, my modest addition to the discussion is this suggestion: perhaps self-tested optimizations can be included along with bugfixes and enhancements, since they actually affect code and give the programmer an opportunity to stamp the code with and demonstrate his talent? --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel status
There recently has been discussion of the kernel, of the upcoming FreeDOS 1.0 release, and of changes which should or should not be accepted. As acting kernel maintainer, this is how I am trying to ensure stability while making progress and trying not to 'upset the talent' as it were. As I said in my last message: The official FreeDOS kernel (well at least the one in sourceforge's cvs) _is_ branched. The official FreeDOS distribution should ONLY use released kernels. Right now this is still Bart's 2035 kernel. Unofficial freedos distributions, including those who include the FreeDOS kernel with their software may elect to use the release kernels, the stable cvs branch, or the development branch -- HOWEVER support (at least from me) will only be provided for release kernels and _latest_ cvs builds. The whole reason for the branch is so people can gain access to Arkady's and others improvements while still providing a stable platform for those who do not wish to deal with issues that may crop up (such as the current FreeCom failing to load one). My goal is to prevent any head-butting, unstabling changes for distributions, and continue improvements. I am trying to accomplish this by using a variation of the common stable/development cvs branches used by other projects. We have kernel developers who want minimal changes (only bugfixes and limited optimizations), they can use the stable series. We also have kernel developers who want to optimize, bugfix, and other changes, they should use the development kernel. As I am in neither (or perhaps its both) groups, this is my compromise. Anyone who feels they can do a better job, well the kernel maintainer position is still open. Please keep in mind, I am open to suggestions and changes -- in particular, with cvs, it is possible for multiple developers to work on the same source if they are willing to communicate. So let me end this with: Please keep the the discussion here related to bugs, bugfixes, optimizations, or other directly _kernel_ related issues. ALL arguing should be done via private emails or on other lists -- debates limited to concrete details, examples, etc. about the merits or harm of a [potential] patch are of course welcomed. Hopefully this clears any doubts or confusion to the future of the kernel. It is being maintained, and as best as possible, compromise between the developers is trying to be achieved. Thank you, Jeremy Davis interim kernel maintainer --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hi! 20--2004 01:09 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: Glad to hear you, Bart. Have some questions to you. BO please be aware that some structs (such as fnodes) are free-style, but BO most are dictated by RBIL. You develop the fnode structures, so should know the better. Thus, may you yourself fix the bugs in lfnapi.c (where used removed f_dmod field instead F_DMOD mask)? Also, I wish to know: may we remove f_cluster_offset field (and use in fatfs.c:map_cluster() stack variable)? BO However, when mirroring an RBIL-dictated structure we should use BO ULONG (which is FD kernel speak for a 32 bit unsigned integer, I'm not For 32-bit unsigned integers should be used UDWORD type. PS: Do you see the patch from tom, related to unfreed near fnodes at critical handler? --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Hi! 19--2004 21:56 Arkady V.Belousov wrote to [EMAIL PROTECTED]: SK the PATH=. variable? AVB MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH AVB VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu AVB or some SETs, then for INSTALL= MS-DOS passes empty environment into AVB program (in its style), for SHELL= it places zero into PSP[2C]. ...or vice versa, I not clearly remember. In any case, currently (available to download) FreeCOM doesn't runs under MS-DOS if there are no menu or SETs in config.sys. SK Because this introduces known incompatibly with existing implementations, AVB Blame existing implementations, which doesn't work under MS-DOS (and AVB why they should work in FreeDOS, if they written for MS-DOS?!). if they written for MS-DOS and don't work there?! --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Arkady V.Belousov wrote: Hello, 19--2004 13:59 [EMAIL PROTECTED] (Steffen Kaiser) wrote to [EMAIL PROTECTED] [EMAIL PROTECTED]: You mean Arkady called MS-DOS-style empty environment broken? Yes, I call this. But this is MS-DOS and all its bugs become standard and called SK So, you've fixed the FreeDOS kernel to issue the broken MS-DOS empty SK environment to programs, did I understood it correctly? No. I fix the task.c:ChildEnv(), which was wrongly scans empty environment with non-MS-DOS-style layout (only one empty ASCIIZ string). And yes, currently ChildEnv() for empty environment uses MS-DOS layout. SK Huh? So I did understood it correctly!? No. SK What does the kernel do now, when the originally correct empty SK environment layout arrives there? Originally correct - with one empty ASCIIZ string? Currently prepared MS-DOS-style empty environment. (DO WE SAY ABOUT BRAND NEW OS OR ABOUT MS-DOS CLONE?!) We talk about FreeDOS, usually. SK Does it care at all, well, it shouldn't? ? Task.c:ChildEnv(), which was wrongly scans empty environment with non-MS-DOS-style layout For me this phrase means ChildEnv() is analyzing an existing environment passed into the function and will now honor only the MS-DOS format of an empty environment. So I wondered why ChildEnv() cares about the second '\0' of the MS-DOS-style empty env at all. When the function needs to prepare such environment, there is a diffenerence, of course. What you have against? SK You've broke the compatibly with existing FreeDOS-near programs. Have you Please, name existing FreeDOS-near programs, which works under MS-DOS and not works under (patched by me) FreeDOS. SK What bugs me is: You've intentionally broke the compatibly with existing SK implementations for no good reason, WHICH COMPATABILITY I BROKE?! The compatibly between the FreeDOS kernel and the FreeDOS shell. And, because you've mentioned yourself that the knowledge of the MS-DOS style empty environment is damn brand-new, any other FreeDOS program probably used in INSTALL=. SK Actually, it would be cleaner to never issue an empty environment. You MS-DOS may. Also, not issue empty environment anyway mean don't make availabel startup path (what makes FreeCOM unhappy). SK To pass a non-empty environment to a programs means that it is not able to SK get argv[0]?? How you read?! Not pass empty environment mean putting zero valie into PSP[2C] word (as MS-DOS does, BTW). Or you mean, that someone should ADD into ChildEnv() adding of some garbage into environment to make it _look_ like non-empty?! For me an empty environment is an existing environment with no variable defined; and no environment when PSP[2C] contains zero. And yes, instead of rushing out and fix something you claim is a bug (because it is not so as in MS-DOS), have a work-around in place to let existing programs work. And, that way, instead of to bend other people to your willing, give them the freedom to decide themselves and, probably, have a remark about the issue. In this particular case: It would be as easy as to pass at least one env variable to the program. SK How can that be? How got programs, e.g. FreeCOM, aquire its SK start path from argv[0] during the time, the default environment included SK the PATH=. variable? MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu or some SETs, then for INSTALL= MS-DOS passes empty environment into program (in its style), for SHELL= it places zero into PSP[2C]. _My_ difference with MS-DOS in this respect is that I always pass (empty) environment (but with startup path), both for INSTALL= and SHELL=. I don't care about MS-DOS, and you as well. Why else would you pass non-zero to SHELL=? To gain a feature, to gain FreeDOS rather than another MS DOS. Utilities, unhappy). Also, MS-DOS _passes_ empty environment, why we shouldn't? SK Because this introduces known incompatibly with existing implementations, Blame existing implementations, which doesn't work under MS-DOS (and why they should work in FreeDOS, if they written for MS-DOS?!). Hmm, I thought we implement FreeDOS. SK and I expect that such stuff is discussed in advance among all affected SK people. I TRY TO DISCUSS, BUT SILENCE IS ANSWER. You mailed a bugreport, no word about to immediately release a kernel that breaks compatibly with FreeCOM. Here it is: FreeCOM incorrectly handles empty environment, _as this understanded by MS-DOS_. Trouble is that for empty environment MS-DOS places before 16-bit counter not _one_, but _two_ zero bytes. This is easy to see: make empty config.sys with line INSTALL=FREECOM.COM and FreeCOM will not detect presence of path after environment. SK For me this discussion looks like whether or not I have to emit another SK pre-compiled FreeCOM for each change of a line of code. Not for each change, but some changes are important
Re: [Freedos-kernel] ludivmul.inc
Arkady V.Belousov schreef: Hi! 19--2004 16:08 [EMAIL PROTECTED] (Bernd Blaauw) wrote to [EMAIL PROTECTED]: BB to work out his changes. At a given moment, he should probably issue a BB code-freeze and then make stuff more readable/review-able May you point, what in my code isn't readable (or, at least, less readable, than in original code)? :( replace readable by understandable for inexperienced C programmers the point is, the code should be as understandable as possible to as much people as possible, so everyone potentially can review the code, and contribute new code. I can't truely judge how understandable source code is. But, for example, I can see if I understand something like algorythms/code in config.c I'll have a look at FreeDOS again one of these days - I'm playing too much games anyway instead of releasing a new FreeDOS.. Bernd --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Hi! 19--2004 21:14 [EMAIL PROTECTED] (FreeCOM) wrote to [EMAIL PROTECTED]: SK What does the kernel do now, when the originally correct empty SK environment layout arrives there? Originally correct - with one empty ASCIIZ string? Currently prepared MS-DOS-style empty environment. (DO WE SAY ABOUT BRAND NEW OS OR ABOUT MS-DOS CLONE?!) F We talk about FreeDOS, usually. And what is FreeDOS? SK Does it care at all, well, it shouldn't? ? F Task.c:ChildEnv(), which was wrongly scans empty environment with F non-MS-DOS-style layout For me this phrase means ChildEnv() is F analyzing an existing environment passed into the function and will now F honor only the MS-DOS format of an empty environment. Was: when non-MS-DOS-style empty environment was arrive to original ChildEnv() it was generates garbage instead someting valid, because there was wrong process for such environment. On the other side, by itself, when no environment is defined (no variables in exec block or ps_environ contains zero), original ChildEnv() was create non-MS-DOS-style empty environment (with only one zero ASCIIZ string). My fix: ChildEnv() now accepts both environment styles, but itself for empty environment produces MS-DOS-style layout. WHICH COMPATABILITY I BROKE?! F The compatibly between the FreeDOS kernel and the FreeDOS shell. Compatability with bug? Isn't better to fix the bug, instead support buggy code in the kernel (which compatible with non-fixed bug), and which will not work with other, compatible programs? F And, because you've mentioned yourself that the knowledge of the MS-DOS F style empty environment is damn brand-new, Yes, this almost undocumented and not all peoples know this bug. F any other FreeDOS program probably used in INSTALL=. ? You can't use program in INSTALL= if (1) it searches for startup, but (2) expects non-MS-DOS-style empty environment, and (3) before INSTALL= no menu or SETs. But this is true for both MS-DOS and FreeDOS (as patched by me). Isn't this is goal of FreeDOS - reproduce MS-DOS behavior as much close, as possible? F And yes, instead of rushing out and fix something you claim is a bug F (because it is not so as in MS-DOS), If something doesn't work in MS-DOS, this _is_ bug, notwithstanding who claims this. (This statement slightly reduced ad absurdum, but goal of FreeDOS is a compatability with MS-DOS, including its bugs). F have a work-around in place to let existing programs work. But this not rejects fact of existing bug (not correctly runs under MS-DOS), which should be fixed in any case. F And, that way, instead of to bend other people F to your willing, give them the freedom to decide themselves and, F probably, have a remark about the issue. You _already_ fix the bug, so you already decide. Question is only: when fixed version will be available to use? MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu or some SETs, then for INSTALL= MS-DOS passes empty environment into program (in its style), for SHELL= it places zero into PSP[2C]. _My_ difference with MS-DOS in this respect is that I always pass (empty) environment (but with startup path), both for INSTALL= and SHELL=. F I don't care about MS-DOS, and you as well. _I_ care. F Why else would you pass non-zero to SHELL=? Non-zero=empty environment? Becuase beside CONFIG= and other SETs it may be useful to pass startup path (as you yourself mention in comments inside ChildEnv()). For example, this allows user to rename shell executable (as I do). F To gain a feature, to gain FreeDOS rather than another MS DOS. ? Blame existing implementations, which doesn't work under MS-DOS (and why they should work in FreeDOS, if they written for MS-DOS?!). F Hmm, I thought we implement FreeDOS. Hmm. I thought we implement MS-DOS compatible OS. I TRY TO DISCUSS, BUT SILENCE IS ANSWER. F You mailed a bugreport, no word about to immediately release a kernel F that breaks compatibly with FreeCOM. _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty environment), who wrong? Not for each change, but some changes are important and should be emited immediately. F Importance is a matter of taste. Of course. But requests to fixed version may (and do) indicate importance. --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
My dear Mr. Belousov, _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty environment), who wrong? do you really think a new kernel that breaks all installed FreeCOM's in the wild is an improvement ? Do you really want to force everyone to update to a new freecom? (people often update only one component) Do you really want to see all the 'updated to new kernel, now freecom doesn't work anymore' being a possibly talented programmer is one thing. but handling real world issues decently (and silently) seems not to be one of your virtues. tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Hi! 19--2004 22:11 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: te do you really think a new kernel that breaks all installed FreeCOM's te in the wild is an improvement ? Workaround for current bug in FreeCOM is easy, this is question of two lines in main.c before p_0(): if (empty environment) CmdSet(A=B);. But this works only when FreeCOM called through SHELL=, this not helps for INSTALL= - neither in orignal 2035, nor in my edition; also, if some application with empty environment tries to call FreeCOM, FreeCOM again wrong. And again, notwithstanding if this workaround is present (and eats extra memory in each following environment) or not, bug anyway should be fixed. te Do you really want to force everyone to update to a new freecom? te (people often update only one component) FreeCOM executable included into package with kernel executable. te Do you really want to see all the te 'updated to new kernel, now freecom doesn't work anymore' It work, unless config.sys defines no enivoronment (no menu and no SETs). --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel patch policy, branches, and FreeCOM
Hi all, Arkady: PLEASE do make FreeDOS 2035a behave as wrong as 2035, because people will want to compare 2035a to 2035, and if things happen like - you cannot format unformatted drives (disk access flag broken) - stable version of FreeCOM (0.82pl3, as opposed to 0.82pl3xyz testing) crashes if you try to use F5 at startup then it is very hard to get the motivation to do experiments with 2035a. If you insist on cloning MS behaviour for F5: You can add a SYS CONFIG variable temporarily, which has to default to FREEDOS behaviour. Then those people which NEED the MS behaviour (do they exist? Why is it needed?) can still enable that mode, whil other people will simply be able to use 2035a as a replacement for 2035 and check if things get better by that. I am sure 2035a fixes several bugs of 2035, but please tell us in great detail which of your many patches actually fix bugs, and which! Most of your patches contain improved comments and small optimizations. If one such patch also fixes a BUG, it is usually very hard to notice, especially if your patch is very LONG but your comment is very SHORT. Your patch announcement mails often contain at most 5 lines of explanation each, if at all. Another thing which would be really GOOD to have: Please let Lucho put all patches online, either separately or in one ZIP/RAR/TGZ/..., along with a SEPARATE text file which tells for every single patch file - when you sent it to freedos-kernel / what the file date is - whether and which bugs it fixes - whether it contains comment improvements - whether it contains optimizations and whether those have been tested to be 100% compatible with the old implementation Thanks a lot! That should allow Jeremy and Tom to use more of your patches for the STABLE branch of the kernel, and it should allow people who are interested in the DEVEL / cutting edge branch of the kernel to quickly find the corresponding patch if they find a bug. Example: I found that the changed dsk.c or something related to it no longer honours the disk access flag, so it is impossible to format disks which do not already have a valid boot sector now. Because it is too hard to find out which patches affected dsk.c in what way, I would probably simply replace the WHOLE dsk.c - or even the whole kernel if I would have been able to pinpoint the problem to probably dsk.c - by the classic 2035 version again, just to get FORMAT working again. If, however, it is documented which patch does what, and if the patches are somehow available for easier download than digging deep in my mail archives, then I can REVERSE APPLY single patches until I find the one patch which broke format for me. This will also make it easier for you and me to repair things, and will indirectly improve acceptance of your patches for the STABLE kernel. Eric --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hi! 19--2004 10:31 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: MD I am glad someone said this that nicely. I have been stunned that the vast MD number of relative last-minute pre-1.0 kernel changes I begun to (more deeply) work on kernel only when Bart quits his maintenance (before this I was hardly limited by his opinions; of course, now I also not completely free and I brake my tryings to fix all and at once). This is no my guilty that this event adjacent to awaited 1.0 release. MD as this whole mess appears to be coming to a crisis, my modest addition to MD the discussion is this suggestion: perhaps self-tested optimizations can MD be included along with bugfixes and enhancements, May you example what is self-tested optimizations? MD since they actually affect code and give the programmer an opportunity MD to stamp the code with and demonstrate his talent? _Me_ not need to demonstrate my talent (or its missing). I myself know what I may do and this is enough for me. --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
BB replace readable by understandable for inexperienced C programmers Unimportant. here I have to agree - kernel programming is nothing for inexperienced programmers, and will never be. Note: this is myth. well - my private email archives show that 'arkadifying code' is used as synonym for 'hardly understandable cryptic stuff' - both incoming and outgoing. SOMETIMES this may be useful - and we used it: the kernel's memory model is probably beyond most peoples understanding using it ALL the time is nonsense. However, the main kernel programming style was set forth ~10 years ago by Pat Villani in the kernel original sources. Both Bart and I didn't agree 100% with it (COUNT is discussable at least), but agreed to KEEP this style as much as reasonable. You often read tom's words about russian magician, which makes cryptic code and you trust these words. Yes, sometime I use not very common tricks, but I (always) try to comment all such places! If you see my code (and, especially compare it with original code), you find this. For example, compare original ludivmul.inc and my edition. I think, this is light example of what is my changes. Another example. Remeber, as you try to comment Umb_State in config.c, which was initialized by magic value 0, 1, 2? Compare _now_ with my edition, where used (commented) enumerations UMB_NONE, UMB_DONE and UMB_REQ. And, if sometime my comments not enough, I alway open and hear, and may comment more, if this will be asked. --- 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_idG21alloc_id040oplick ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Best regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886
Re: [Freedos-kernel] Kernel patch policy, branches, and FreeCOM
Hello Eric, I am sure 2035a fixes several bugs of 2035 found the ret_ah bug. if that has real world implications is unknown. found the Ulong 32%32 bug - impressive, but 100% irrelevant to the kernel as all real world use will work 100% ok. claims to have found a bug in umb_link code for a001: now it doesn't work either, and is again irrelevant as noone uses (for good reasons) /I=a000-afff possibly made the graphical MENU better - but certainly broke Eric's and mine non-graphical config.sys found a bug so now MS Smartdrv loads - unfortunately now FreeCOM doesn't work any longer (even if that's a bug) IMO that's less then impressive just as a OT sidenote, found somewhere on joelonsoftware.com: the old WIN developers took it *personally* if some old stuff wouldn't run any longer. this went as far as: they found that SIMCITY would run beutiful on DOS, but crash in windows. after some lengthy debugging they found that simcity frees some memory - and uses it afterwards. sure this works in DOS - and fails badly in a multitasking environment where this memory is reused by someone else. now there 2 solutions for that solution a) say this code is buggy, ask manufacturer solution b) implement 'is the current task simcity ?' if so, delay the *real* free for a couple of seconds. they (the MS developers) took b) and for me this ends the threat. tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hi!
19--2004 22:42 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov
[EMAIL PROTECTED]:
BB replace readable by understandable for inexperienced C programmers
Unimportant.
te here I have to agree - kernel programming is nothing for inexperienced
te programmers, and will never be.
I mean not this, I mean, that in given case is unimportant how to
understand readable - by experienced or not programmers.
Note: this is myth.
te well - my private email archives show that 'arkadifying code' is used as
te synonym for 'hardly understandable cryptic stuff' - both incoming and
te outgoing.
te SOMETIMES this may be useful - and we used it: the kernel's memory
te model is probably beyond most peoples understanding
te using it ALL the time is nonsense.
:( Say me, where below is 'hardly understandable cryptic stuff'?
__O\_/_\_/O__
enum { UMB_NONE, /* do nothing */
UMB_DONE, /* UMB initialized */
UMB_REQ,/* DOS=UMB detected */
};
static UBYTE HMAState BSS_INIT(HMA_NONE);
static UBYTE UmbState BSS_INIT(UMB_NONE);
[...]
/* fill HMA with buffers if BUFFERS count =0 and DOS in HMA */
if (wantedbuffers 0)
wantedbuffers = -wantedbuffers;
else if (HMAState == HMA_DONE)
buffers = (0xfff0 - HMAFree) / sizeof(struct buffer);
_
O/~\ /~\O
---
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_idG21alloc_id040op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
