Re: [Freedos-kernel] Which kernel
Hi Pat, This sounds liuke a good strategy. I would say 2038 as default, 2037 (including winkrnl) as option--unless 2039 shows up first (doesn't look likely). If 2039 gets something worthwhile, 1.11 is an option. I agree - same as in 1.0, the stable kernel is the default and the unstable branch is available as an option for those who want to have extra features at the expense of less stability :-). Of course it would be nice if some patches from the stable branch could be added to unstable first, to make the pain for users of unstable smaller... ;-). Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork No. Because first, I don't develope DOS-C, and second, forking is bad and makes merging changes back in harder. Since your opinion seems to be that filesystem extensions can never be added to the stable or official release, this is of course what you want to happen to them: Implement it into unstable and it will never find it's way to stable. The problem here isn't just that you don't want to release new features in official builds, it's that you support forking another single build (which, by now, is already years behind in improvements of stable - see below why) instead of adding the feature to (unofficial) builds directly derived from the latest stable. Of course that's just my opinion and I'm not even a FreeDOS developer, so feel free to ignore it. At least I didn't yet see anything changed in stable which was derived from unstable Actually not much apart from COUNTRY SYS support in unstable has very favorable risk/complexity versus gain in features ratio at the moment, unfortunately... So why write a risky feature at first, if there's apparently no chance it will be merged to stable? Additionally, this raises the problem that people that want to write new features into unstable first will have to cope with a kernel already full of other unstable features. So I won't recommend re-using the outdated unstable anymore. , and improvements of stable aren't added to unstable either. This is because more or less the only developers were Jeremy, Lucho and Arkady - the latter is kind of missing and Jeremy just returned a few weeks ago from being so busy with the real world real life that he simply had no time to continue working on the unstable branch. Lucho now has other big things as 4DOS. I'm of course not blaming these people. However, as I mentioned previously, if all developers of stable had merged their changes (as applicable) to unstable as well, this would make life easier for people that want to test new features for stable on unstable. (And please don't argue that the developers of stable would have to know unstable then, too, because they of course should do if it's more than a fork.) If they were IFDEFed then you would have no chance understanding either ;-). I doubt I would have a problem with it if the source was divided that way. What do you mean by either? The stable / unstable diff is maybe 1000s of lines. Could it be smaller if the changes in stable were added to unstable? [...] because I prefer to write such programs in Assembler. In a way, I want to change everything compared to DOS-C (The FreeDOS Kernel) which is written in a high-level language, and that's the reason I choose not to develop it. Tastes differ. One of the original goals with DOS-C was using more C :-) I know. and that's the reason I choose not to develop it. If you repeat answering that DOS-C tries to use C as much as possible I can repeat to write my answer again ;-) Still you are welcome to point out tech details of bugs if you find them, as we often have only vague it somehow does not work type bug reports and no time or hardware/software to reproduce/debug them. Of course ;-) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Indeed JAM only works on non-FAT32 kernels because of different data structures... Any other different structures besides the SFT? JAM apparently needs the start cluster of the compressed disk file so it can use lowlevel (int 25/26...?) calls to access that file without causing reentrancy while the kernel accesses files on the compressed disk :-). Ignoring the fact that it apparently broke SHARE.EXE, too Our version of share? Does it work less well on FAT32 aware kernels? Nope, here I talked about the MS-DOS SHARE.EXE only problems of MS-DOS 7.10+ only. That'll make jmount incompatible with MSDOS4, DRDOS 56, but compatible with newer versions, because the word at 35h is the last accessed cluster, and after reading one sector (as Eric showed) that will still be the starting cluster. patching JMOUNT [...] is not elegant, but that is a typical problem with closed source software :-p Anyone tried to contact the JAM developers before patching the binaries? Does JAM read anything from the archive file (I presume it wants the first cluster of that file) before looking into the SFT? It does the following: Drive reset, network flush buffers, check if drive is remote, check for DJ mechanism state, for dblspace, for JAM drive properties, truename, more JAM drive properties. Then it checks the DPB of the drive with the JAM compressed disk file on it, OPENs that. Then dosdebug/dosemu logged that a first disk sector read happens, not sure why. Next JMOUNT seeks to: current +0, end +0, start +0. Now JMOUNT reads the first sector of the compressed disk file. Then it checks the JFT and SFT to, indeed, get the start cluster of the compressed disk file :-). Does it parse the JFT and SFT chain directly or does it use DOS services such as 2F.1220 and 2F.1216 ? I am not sure whether DOS would already read the next cluster when you read the first (size of cluster) bytes of a file, I would guess it will not... It *could* read the value of the next cluster from the FAT (value inside the FAT entry of just-read cluster) but that could also result in an EOF marker so I guess you're right. FreeDOS already does exactly that - as soon as any int 21 call is done, the SFT is updated with information from the fnodes where necessary. Only if an outside software would WRITE to the SFT you could cause problems because this might get the SFT out of sync with the fnodes: FreeDOS might have information stored in the fnodes which the outside software which manipulated the SFT will fail to update if it does not know about fnodes. But is the fnode re-used for the next DOS call, or is it populated from all values found in the SFT again? Because, if the former is true, then the cluster reference would be lost as soon as another call used the fnode for another file. And if the fnode was repopulated from the SFT on each DOS call, then if whatever program changed the cluster references in the SFT would also change the fnode indirectly (if it accessed the SFT when the InDOS and CritErr word was zero). Maybe extremely lowlevel software such as task swappers or such unimaginable things as online defragmenting software ;-) could cause problems here, but JMOUNT should be safe :-). Ack. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Cross compilation from Linux
Hi, Jim reinstated SVN write access so I committed a patch that I have used internally in a not so clean fashion for a long time: cross-compiling from Linux using Open Watcom. The reason why: well it is more convenient and quicker (less than 2 vs. 20+ seconds here) to cross-compile than fire up DOSEMU or another VM and do the compilation there. I hope it is useful to some others and also clean enough: mostly DOS understands / fine but some commands in makefiles need to use $(DIRSEP) to get either \ or /. The batch files obviously can't be used but the top level makefile can do the trick using make all, make clean, and make clobber. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
