Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
On Tue, Feb 7, 2012 at 9:51 AM, Tom Ehlert t...@drivesnapshot.de wrote: Dear PerditionC, UBYTE DiskTransferBuffer[MAX_SEC_SIZE]; wastes 3,5 KB low memory for *everybody*, not only when it's needed. regarding how much time we have spend until we had 64 byte free I think this is a bad idea please see my previous messages, I know exactly how much space is wasted and clearly stated this along with statement 512 will be default (and was already changed to such earlier) I also think that these experiments should NOT be in the stable branch. fork it, and make another 'unstable' branch if you want to experiment, but don't experiment with code that is supposed to be stable. Regards, Tom These are not experiments, this is me working to improve compatibility with MSDOS and existing though rare disks. I purposely left a default value larger than needed so I could track down a kernel issue with memory allocation during initialization. This issue still exists and I believe may be one of the reasons why there are occasional reports of invalid opcode/crash during boot. MSDOS sets the value based on known devices during startup, this is documented in books describing it. The FD kernel has been hardcoded for 512 bytes. My plan was first to ensure sizes 512 bytes work then make the changes to allow user to choose larger size than 512 so only those who need the different value are penalized with increased memory usage and can use FD kernel with their drive while everyone else only has minimally larger kernel but more like MSDOS. Part 1, the changes so sizes 512 can be used was committed and uncovered a memory allocation issue. I put part 2 on hold because this seemed important to find - instead I will leave the 512 hard coded which rarely triggers the bug. The experimental 4K build is based on my forked 0xdc (DOSC OEM id) kernel, and it is where I do most of my changes before merging/testing with the 0xfd kernel. Jeremy. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-devel] [PATCH] kernel - only print suspect partition warnings if FORCELBA is not in use
... 3. All the machines I have tried so far report the CHS vs LBA computed mismatch warnings. Considering that first time FreeDOS users might be put off because of these benign warnings, I would very much like to avoid them. There's a list of warnings indeed. A big one at that, especially when using syslinux's nopassany directive to hide physical disk drive units. Could this patch be considered for the mainline tree then? I can't answer this, as I'm no developer. It could be an interesting addition for kernel 2041 if any kernel maintainer is still active occasionally. Thank you, I will look at the patch this week. PS: is there a reason why one must have an AUTOEXEC.BAT present, even a blank one, to avoid the prompts for datetime in FreeCOM? What is the purpose of mandatory prompting for those? Remove your CMOS battery and you'll see. Basicly, ancient machines often had no battery and yet needed to have a time and date set. I guess FreeDOS follows MSDOS design in this aspect. Yes, it is the way MS/PC DOS command works due to not all computers having a real time clock so the time and date would need to be set on boot, or something like that - I could be recalling this incorrectly. :-) Jeremy -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
On Jul 20, 2011 1:37 PM, Bernd Blaauw bbla...@home.nl wrote: Op 20-7-2011 3:50, Bart Oldeman schreef: It's probably best to make things explicit (unless the goal is a true Win32-DOS cross-compile), using DOS16 utilities, by changing the last part of mkfiles\watcom.mak to: CFLAGS1 = -os-s-wx-bt=dos # *Implicit Rules* .obj.exe: $(BINPATH)\wlink sys dos f $ lib $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q .c.obj: $(CC) $ @$(CFG) But I haven't tested this! And now the fun part: compiling on Windows x64. No support for running 16bit programs at all. Thanks, worked like a charm (see below). It shouldn't be too difficult if someone actually wanted to (I use virtual machines with DOS and WinXP instead of my native Win7x64 so have no desire). The utilities all [except LOAD_ICD.exe] compile and seem to work properly with a simple wcl name.c after removing (or modifying) the #ifdef memory model to ensure far data pointers to build win32 versions (assuming Win32 version of Watcom used). I tested and committed Bart's suggestion above as it makes the build work much better and should have minimal impact on anyone else who might be building -- the big gotcha is that config.std (after copying to config.mak) needs to be modified to change ..\scripts\echoto $(CFG) $(INCLUDEPATH) to ECHO $(CFLAGS1) $(CFG) as echoto treats = as a separator character same as space i.e. the -bt=DOS into -bt DOS. Jeremy -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
And Bart is too quick, he already adjusted the watcom.mak so it just works. :-) Thank you, Jeremy -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
On Sat, Jun 25, 2011 at 4:40 PM, Bernd Blaauw bbla...@home.nl wrote: Op 25-6-2011 16:06, Kenneth J. Davis schreef: Hello all. ... Are there any verified/stable working compiled versions available of the following? * COMMAND (there's an openwatcom CVS/SVN version somewhere?) I finally managed to built the OW version (had issues with the utility programs being built as win16 executables, so modified the makefiles to build them as win32 [native], and have yet to build the installable command loading program - didn't even know it existed) so you can now find OW builds of command.com on fdos.org http://www.fdos.org/kernel/command/FreeCom/command.com Note: this has not been very well tested, especially given my changes to the build. * SHARE (thought there were 2 versions or so?) the most up to date version is with the kernel (no recent changes, just latest source floating around put into svn) (as soon as I upload a build, latest will also be found at http://www.fdos.org/kernel/share/ ) ... Jeremy -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
I am working on updating my site as I move files to my new host. www.fdos.org/kernel is updated. But I only have a little bit of time that I split among development website updates. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2040 released
Hello all. Kernel 2040 has been tagged and should be made available on Sourceforge file releases within next few days. Also available for download at fdos.org: installer compatible form - http://www.fdos.org/kernel/package/ same as sf releases - http://www.fdos.org/kernel/release/LATEST/ Note: these releases have not been compiled with the memdisk configuration checking as these are 8086 compatible builds. I will make available 386+ builds with it enabled within a 386 subdirectory. Thank you, Jeremy Davis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel changes
On Sat, Apr 9, 2011 at 6:56 PM, Eric Auer e.a...@jpberlin.de wrote: Hi Pat, kernel gurus Jeremy and Bart, You can release it [an updated kernel], but I want to put it together with other updates and finally generate v1.1. You mean a FreeDOS 1.1 BASE ISO image? That would be nice, but you can of course use many already pre-packaged updated packages from the fdupdate repository and also the updated installer from Jim for that... There is another problem, though: People why try to download a current kernel end up e.g. on fdos.org which is long dead, but used to contain an automated regular build of the kernel and a minimalistic boot floppy image containing that. Maybe the tradition of having daily builds somewhere could be resurrected, for those who cannot or do not want to compile kernels from the subversion repository manually. This would also be nice for tasks like binary search for when things in a regression bug broke and/or got fixed, etc :-) I do plan on restoring fdos.org, currently the [old] content is still available at fdos.info (e.g. wiki.fdos.info, help.fdos.info, and www.fdos.info). FYI: fdos.info is just a new domain name that is mapped to the same content fdos.org used to point to. fdos.org points to a new hosted virtual computer - early last November I had started migrating my data from the old site to the new one, but all my computers were stolen - hopefully in month I'll finally have a replacement. An SVN source tarball can be obtained at: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=tar An 8086/FAT32 OW1.9 compiled kernel.sys binary for testing at: http://dosemu.org/bart/kernel.sys ... * r1565 sys/sys.c: Change // to /* comments for Turbo C woops, sorry ... Thanks again for all those recent updates. Regards, Eric Yes, thank you guys for all the bug fixes and other improvements! Jeremy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Sys crashes when specifying file, kernel tree
On Fri, Nov 13, 2009 at 3:14 PM, ibid...@lavabit.com wrote: Hello everyone, First, I have a bug report against the 1497 fdos.org build of sys (OW386/FAT32/UPX)-- if I specify a file to write the bootsector to (sys c: large.bin, with or without /BOOTONLY or /BOTH), sys crashes with Invalid opcode at 00AB (etc.) A version that should fix it is available in http://www.fdos.org/kernel/ke386f32.zip Please let me know if it or any other errors still occur. Thank you, Jeremy -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
On Wed, Jul 29, 2009 at 5:06 PM, Eric Auere.a...@jpberlin.de wrote: Hi Bart, ... * New SYS, merged from unstable branch. I hope it still uses the much faster cached copying :-) Could you add a small but useful option to force either CHS or LBA mode boot sectors, in particular for FAT32? ... I did merge in the improved chunk copying method; however I kept the conceptually simpler copy as a single operation mode, which means there are a couple extra disk swaps needed as sys opens both input output file, reads in file, then writes file, then closes both input and output file; and it does this separately for the kernel file(s) and shell. I think I will change the order of the file closes, this should eliminate some disk swapping. Also I will add the option to force FAT32 lba/chs mode tonight. Jeremy -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Copyright owners for kernel license
On Mon, Jul 27, 2009 at 10:44 PM, ibid...@lavabit.com wrote: ... In the discussion I refer to, relicensing was mentioned. I am curious who should be contacted for such requests, or if relicensing would be allowed, etc. The kernel source says Portions copyright Patrick J. Villani. Would that mean that Pat should be contacted? ... It would be very difficult; at minimal one would have to find all the people listed in contrib.txt (within the docs directory in the kernel source) and each of them would have to agree or the corresponding contribution determined and replaced. Pat of course would be the starting point as the kernel as a whole is derived from his work; in recent years Bart and Tom have contributed the most. Assuming this was achievable, it would only get you a version of the kernel relicensed; the majority of FreeDOS [the associated shell utilities] would still be GPL licensed. Jeremy -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Fwd: FreeDOS kernel Build Fixed: Build 2009.07.18.001
I was just checking my email and about to work on an issue with the usb stack from Bret Johnson. Does this change effect/fix the issues with this (from the description it looks like it does - as the problem was described as FAT32 specific issue with the kernel and related to the buildbpb call) or is it just something you ran across? -- Forwarded message -- BUILD SUCCESSFUL Project: FreeDOS kernel Date of build: 2009-07-18 11:03:55 Running time: 00:03:23 Integration Request: continuous triggered a build (IfModificationExists) Last changed: 2009-07-18 10:05:26 Modifications since last build (1) Modifiedbartoldeman/kernel/trunk/kernel/fatfs.cCheck the BPB instead of the DPB for FAT32 after a BUILDBPB device call, as the DPB may still be uninitialized at this point. 2009-07-18 10:05:26 Thank you, Jeremy -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] prinf changes
On Sat, Jul 18, 2009 at 10:37 AM, Bart Oldemanbartolde...@users.sourceforge.net wrote: Jeremy, I was wondering what your reasoning is for changing It has to deal with debugging the kernel, especially during initialization. I choose this method as the kernel does not usually have many strings it prints except when built with DEBUG and the alternative is to determine exactly which portions of the C code and corresponding strings may possibly reside in different segments at different times (any time DS may not equal seg of string) and change just those prints - otherwise some strings print and some print garbage. I realize it changes printf prototype to only match compilers in large data mode, but the kernel does not use printf from the standard library of DOS compilers anyway. However, I will revert the changes if you prefer. Yes the CONST const issue is just trying to keep the code consistent since CONST is the preexisting usage. Jeremy -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2039-svn bugs
On Tue, Jun 30, 2009 at 10:52 PM, Bart Oldemanbartolde...@users.sourceforge.net wrote: 2009/6/30 ibid...@lavabit.com: I've been trying to patch 2039-svn with Christian's fix, while working under a TC 186/FAT32/Win kernel (built myself), and I have found the following: what does Win here mean? ... Win doesn't do anything. I would guess he is using the command line build.bat tc 186 fat32 win tc, 186, fat32 are obvious, they set appropriate options: compiler to use, target CPU, enable FAT32 support win does not do anything except set some defines which are not used by the kernel; in the future will be used to conditionally compile in the listen respond to windows broadcast hooks to see all options that can be set via cmd line instead of setting in config.bat use run build /? Jeremy -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
On Fri, Jun 5, 2009 at 2:05 PM, Eric Auere.a...@jpberlin.de wrote: Hi Bernd, Tom, Bart, others, ... WfW support will probably never come; WfW was tighly coupled to the kernel (at least according to Schulman et. al., WfW is MUCH more then just a flavour of Windows 3.11) What is Schulman et al? I wonder whether the experimental patch for the experimental 2037 branch was for making 3.1 enh mode or 3.0 enho mode or rather WfW work in FreeDOS, or maybe several of them, does anybody know? Note that it is hard to run old Windows on modern hardware with any DOS. The Windows specific patches are minor but add a small amount of code hence the extra work to enable (Windows is the only application for them). The kernel worked with windows 3.11 in enhanced mode except for an issue with keyboard input in DOS boxes not going to the proper VM instance, but I think this is related to VM instancing which took the shotgun approach and not the proper these are the parts of the kernel that need to be instanced. There are a couple settings in win.ini or system.ini that improve reliability, but really the hard part is getting a memory manager working reliably. For the kernel, load FreeDOS share so windows does not try to load the vshare.vxd. Windows actually goes a bit out of its way, if in a somewhat strange manner at times, to work with multiple DOS versions. The important parts for Win3x support I think was really the support added for country (the internal hooks to allow somewhat reentrant use of DOS). See http://wiki.fdos.org/Main/Windows for full details about using win3. ... Jeremy Davis created SYS 3.5 yes with support for several other ... PS: For those who want to use the can boot other OSes unstable variant of SYS, please consider porting six updates of stable to make a more stable version first: sys 3.6a is the current version, changes to older versions should be considered for maintenance purposes only. It is not unstable and it (or newer) will be in the 2039 kernel release. The support for other DOSes is compile time selectable so those dual booting need only 1 sys program and those who don't want it can compile sys without it. The FreeDOS sys was modified to work with DR-DOS and those changes were later folded back into the official version; now also as a compile time option to select FD sys or DR sys. Jeremy -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
On Mon, May 18, 2009 at 3:49 PM, Tom Ehlert t...@drivesnapshot.de wrote: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Tom It is not too difficult - I have a kernel without them lying around suffering from bit-rot, but it did not seem to bring anything useful to warrant the changes given the likely hood of bugs it also caused; I actually prefer the fnodes. Jeremy -- 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
On Mon, May 18, 2009 at 6:32 PM, Pat Villani p...@monmouth.com wrote: If half as much effort went into the code that has gone into this thread, we'd have rewritten the kernel several times over. Since I'm wrong about the kernel(?), let me put it to you this way. I wrong? want to put out a new release, FreeDOS v1.1 and get a plan in place. In 50 words or less, who is going to tell me which kernel is going with 1.1? Pat 2039 unless a later one is available - svn trunk tagged Jeremy -- 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] kernel 2038
Kernel 2038 tagged and available at http://www.fdos.org/kernel/latest/ Someone with access, please upload to ibiblio and release on SF. Please test and report any new issues to the mailing list. Depending on any reported issues, 2039 scheduled to be released in about a month. Comments about new or existing bugs to focus on for next release welcome. Thank you, Jeremy -- 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] Kernel build 2038rc1 testing
On Mon, May 4, 2009 at 9:35 PM, Eric Auer e.a...@jpberlin.de wrote: Hi ibid_ag at lavabit com, I tried 2038rc1svn out _briefly_. It works about the same as prior builds (runs edit, mem, command, gem; loads ctmouse, gcdrom, himemx,jemm386, shsucdx; still does not run GEM/XM). thanks, that sounds about right as I have not had a chance to install GEM (any version) yet on my test computer so I haven't tracked down the issue yet good to know the usual programs run If anyone else wants to test GEM compatibility, I would suggest downloading the OpenGEM SDK from Sourceforge and running GEM 2 (same internals as XM) or XM itself in a debugger (perhaps Japheth's 16bit DPMI one,to debug the kernel). Please give more exact instructions... Which files to download, from which URL, how to install, which commands to run... Best would be a minimal experiment, involving only few / small parts of GEM XM or GEM 2 to keep the amount of code to look at small. OpenGEM variant of FreeGEM (http://gem.shaneland.co.uk/) provides the GEM/XM (multitasking variant) http://gem.shaneland.co.uk/downloads/OpenGEMXM.zip and the OpenGEM SDK (link on main page, basically all the stuff needed to run and build programs for GEM including full source). From what I've read, GEM/XM was a branch of GEM v2, so both use FCBs. Other interesting debuggers: 386SWAT, Dosemu dosdebug, the Bochs built-in debugger. Note that with dosemu, you may get different results for redirected Linux directory drives as for normal FAT (diskimage) drives, which might be interesting in itself :-). problably should use a debugger, but printf is what I use :-) Eric PS: I suggest to do experiments only with himemx, without the other drivers you mention, again to keep the size of the context small. Other than using FCBs for volume label, does anyone know of other programs that use FCBs instead of file handles? for testing purposes Thanks, Jeremy -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel build 2038rc1 testing
On Tue, May 5, 2009 at 2:10 PM, Eric Auer e.a...@jpberlin.de wrote: Hi Jeremy, Bart, IBID, ... I could not find any LOAD*.* file in the zip, though... Maybe this whole experiment is something different than IBID meant? Eric See http://www.seasip.info/Gem/gemxm.html (I'm not sure if its the same/newer/older than the one from the OpenGEM site) This version of GEM/XM includes the changes to use handles instead of FCB, so its load.a86 source (the module that did use FCBs) probably doesn't help much. The original source to the load module was apparently lost prior to the GEM release as Open Source, so there is no original load.a86 but there are remarks from various messages via google to a commented dissassembled version of the original - not sure where it is though [would be really handy to see what is going on though]. From what I remember reading, GEM v2 and XM in the load module uses FCBs to access information from the assign.sys driver. GEM v3 this functionality is in loader.asm and uses handles which was partly incorporated into the above mentioned XM update. The next step is to figure out what FCB calls GEM v2/XM make and then determine what the FD kernel is doing with those requests. Jeremy -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] GEMXM incompatibilities FCB errors
On Mon, May 4, 2009 at 6:26 PM, ibid...@lavabit.com wrote: Hello, I've tried running GEM/XM under freedos kernels 2035b, 2036, 2037, and Christian experimental build (later renamed 2038pre). Official documentation says it will not work due to using FCBs to read the driver loading file, 'ASSIGN.SYS'. GEM/XM complains about assign.sys, then dies. So I conclude that 1. the GEM/XM documentation is correct and 2. there is a serious bug in the freedos kernel (fcbfns.c?) regarding how FCBs are handled. I have not seen any mentions of fixes for this in 2038. If it has been fixed in any kernel builds, please respond on the list. I _hope_ to see GEM/XM running in FreeDOS 1.1 Thanks. I saw the bug report (Sourceforge tracker, don't have # handy) and tried finding load.asm from GEM/XM so I could see what it was doing (which commands failed). I never did find it, but did download the GEM/XM so I can run try it. The fix may make it into the 2038 kernel, but if not depending on the actual issue should be in the 2039 release (which my goal is to release shortly after 2038 assuming there is a need and people actually report success or problems with 2038). I seem to recall something about an updated version that used handles instead of FCBs (win98 compatibility issue as well), have you tried the latest GEM/XM with these updates? Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: Re: state of kernel 2038
I am still reviewing and testing the pending patches... but progressing. :-) Does the non-UPX'ed kernel boot for anyone else? I spent most of this evening tracking down why my kernel didn't boot (that is testing my new setup so I wasn't sure if it was my host OS/compiler (I'm already using ms2wlink from OW1.7 since the 1.8 one is flaky for me)/kernel/etc, haven't tracked down beyond works with upx and not otherwise. For anyone who wants to test latest svn kernel I have put a compiled version online: binary (kernel.sys sys.com, need to add your own command.com) http://www.fdos.org/kernel/test/ke2038rc.zip source http://www.fdos.org/kernel/test/ke2038rc-src.7z Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
On Fri, May 1, 2009 at 4:01 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Bart, thanks for making the patch much shorter, very commitable now :-) Why did our old code do that complex put bp at [bp+2] thing? And don't know what does the cpm_error jump decision now inverted patch mean? skips the call to int21 if the value in cl is 24h, ie limits the call to int 21h functions 0-24h before it incorrectly limited the calls to functions 24h Eric This is a minimal fix for [entry.asm] ... ... cmp cl,024h - jbe cpm_error + ja cpm_error ... Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
On Thu, Apr 30, 2009 at 8:18 PM, Bart Oldeman bartolde...@users.sourceforge.net wrote: ... This is a minimal fix for the kernel: --- entry.asm (révision 1371) +++ entry.asm (copie de travail) ... This bug has been there since the DOS-C days by the way! Bart Thank you! Patch committed along with some comments to help explain what is going on. ... near call to psp:05h which in turn is a far call to 0:0Ch embedded in the psp with the value embedded at psp:06h also the size of the com file (more or less) for CP/M compatibility and 0:0Ch (overlapping where address for int 30h 31h would be) contains the code to do a far jmp to the code in entry.asm which is where the bug was and now correctly strips the bad return offset and rearranges the stack to match an int 21h call. Additionally limiting this whole tromp around memory to function codes 0 through 24h. Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
free time at last... On Wed, Apr 29, 2009 at 8:49 PM, Eric Auer e.a...@jpberlin.de wrote: Hi Bart, admins, others, Would you like to have access again? Should be no problem :-) Sure! Apparently only Aitor, Jim and Pat can give you SVN write access but I think that would be a *very* nice idea... ;-). I noticed Pat already uploaded your SYS OW 1.8 fix :-). :-) If you plan to patch things overlapping those things listed below, please announce so we can coordinate. You may also want Please consider the 2037 [dev] kernel for review only (not that I'm abandoning it, just moving my work outside of the scope of official FreeDOS kernel). to read the state of kernel 2037 and state of kernel 2038 threads on the freedos-user in Feb 2009. High on the wishlist will do, I have been trying to read through my archives, unfortunately my gmail account only goes back a year (search and access from multiple computers really is nice). for 2037 would be extending that SVN changelog wiki page and interesting read, but don't expect updates from me, for now at least a backport of country sys support to 2038 stable. Eduardo may be considering to work on that backport... =A0For SYS, I would suggest an option to enforce either LBA or CHS style boot, in I plan to work on porting the country (or ensuring Eduardo's patches are committed and tested) and win patches (the win specific parts are minimal) from dev to trunk after we get 2038 released (with the plan to release 2039 shortly after with these patches). sys work can wait for a little while questions though, are all the outstanding patches for country in the unstable branch or are there any emails/patches/whatever still floating out there? particular for FAT32, via the command line. The wishlist for the stable 2038 kernel is quite short: Insert patches listed below, update changelog file and make a SF file release :-). I'm working on the patches, been reading through and refamilarizing myself with the code, and think I can figure out the SF release process again, but those darn changelogs (ever so useful from the outside ...) Patches waiting here for review, comments, uploading: - *Bart*: SYS compileability with OpenWatcom C 1.8 and newer (in SVN) I need to check latest sys version and probably commit something similar as well, but that can wait until after 2038 is released - Eric: dosfns.c / fatfs.c / proto.h SHARE tuning (safe afair) - Christian: entry.asm revamp to fix the CP/M call (review!) http://sf.net/tracker/?func=3Ddetailaid=3D2421577group_id=3D5109atid= =3D105109 anyone know of any CP/M like programs or applications to test these with? - Any: (?) update changelog, update my email addr in the docs http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=3Dlo= g - RayeR: init-mod.h always say BSS_INIT(x)=3Dx (workaround OW bug?) I want to look into this one more, I know there is some interesting logic in startup because of the code relocation; need to verify what the entry code is doing - Tom: inthndlr.c bugfix for int 21.1c no-FAT case I don't remember seeing this one, will have to search for it - RayeR: initdisk.c CHS cyl off-by-one and total_sectors overflow =A0and DebugPrintf drive param format string fixes - Any: If DSSI points to partn (00 or 80) in FAT16/32 boot sector =A0then take partn offset from DSSI+x (I *had* a patch but where??) - Eric: re-enable drive access flag handling to make unformatted =A0drives more properly unformatted, disk tools should be fine now? - Christian: patch related to exit/resident if self-owned PSP =A0(he pasted the patch in a recent thread on the mailing list) - Any: (Eric?) support 4 GB file size by changing sft_size, sft_posit =A0to unsigned (dir_size, f_offset already are) and changing lseek =A0error reporting (no longer treat negative as fail) - seems you =A0can let SftSeek accept ANY dos_lseek retval as errors are already =A0checked by SftSeek itself before calling dos_lseek? DosSeek just =A0calls SftSeek, needs no changes. The sft_size / sft_posit change =A0might require adjustments to that at some places in the code. - Any: (?) support that extended open flag which allows sizes above =A02 GB: DosRWSft should throw error 5 access denied if you try to =A0write beyond that file offset if that flag is not set (shrug ;-)) all 2GB work should wait until 2038 and possibly 2039 are released, this should be done along with work towards FAT+ support (backword compatible with support for files 4GB, requires addition of one extended seek API function - see EDR for RBIL type spec and some internal changes to ensure sequential access works correctly) - Any: implement int 2f.1228?? Apparently exists but commented out?? will look into it, don't recall and too lazy while typing this email to see what this function does/is :-) Thanks for the explanation of OW 1.8 / 1280 get/setftime un- DOS-ification of headers to gain MS VC / DJGPP compat
Re: [Freedos-kernel] Freedos-kernel Digest, Vol 1, Issue 421
Abrahan Sanjuas wrote: ... I suppose that this kernel is not compiled with WIN31SUPPORT option because the debugging messages in the end of execution of a program does not shown on screen. And how i can view if kernel is compiled with WIN31SUPPORT or NOT??? The simplest way I can suggest is to get this program and run it. http://www.fdos.org/kernel/test/testwin.zip It will tell you if windows definitely will not work or if and only if the WIN31SUPPORT stuff is compiled in that windows may work. Note: this little program relies on the way the FD kernel handles the Windows startup broadcast, so running with any other version of DOS will give useless and probably wrong results. (For the curious it basically calls int2F with AX=0x1605 and passes in an arbitrary [0x0123] value for the Windows version. If the FD kernel is compiled with WIN31SUPPORT enabled then it will handle this call and return with the windows version field set to the same as passed in; ie to 0x0123 in this case or 3.X under normal usage.) Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] DOS interrupts
najmus saqib wrote: HELLO I want to ask something about DOS interrupts. Does freeDOS uses MSDOS interrrupts. How can i do the same. can any1 tell me about the Yes, it uses the same interrupts and parameter interface as MSDOS. More specifically, it attempts to implement nearly 100% compatible (possibly including advanced features, hence not 100% identical) interface including most hooked interrupts and their functionality. On the flip side, the FreeDOS kernel most likely calls the same set of interrupts as MS DOS, ie BIOS calls; but the exact order and which ones called [ie FreeDOS kernel may take advantage of newer functions such as LBA for disk access] may not be the same. files doing this in freeDOS kernel. the primary interrupt handler (for int21h) is in inthndlr.c, see also int2f.asm, intr.asm, and intwrap.asm for the C/Asm interface for the interrupt handling. main.c will show you all interrupts hooked. Of course the interrupt handlers call into the various other files; see Pat's book on the FreeDOS kernel or have a look through the source and the call tree should be pretty easy to follow. Jeremy --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] solution for problem with diskette-less systems
Eric Auer wrote: Hi, I looked at the issue kernel acts weird if there is no diskette drive... In short: ... Eric for testing, a very similar patch, please try http://www.fdos.org/kernel/test/kernel.boot.sys PS: As a bonus possible problem, I noticed that the cvs unstable SYS FAT1x CHS/LBA FreeDOS boot sector assumes that DL will be the drive number after int 13 (readdisk) when it passes on the boot drive number to the kernel (in BL)... However, RBIL tells about int 13.02 that: Apparently some BIOSes or intercepting resident software have bugs that may destroy DX on return or not properly set the Carry flag. ... Thanks for the above and note about the boot sector. Jeremy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Freedos-kernel digest, Vol 1 #409 - 1 msg
Charles Doty wrote: Is there a specific reason to compile out the check and not simply use the config option to disable the 2 second f5/f8 check? I missed that config option. Is it in config.b? No, perhaps I should have been more clear. It is a settable configuration option via sys config skipconfigseconds=# where # (see kconfig.h) represents: 0 : not possible to skip config.sys (no check), and no delay = 0 : only possible if already pressed before, no delay or message 0 : wait that many seconds for F5/F8 to be pressed Additionally ensure BootHarddiskSeconds (another sys config option) is the default of 0 (or a negative value) so when not booting from a hard drive it just continues the boot without waiting/prompting the user. A positive value here will cause a delay, with a default action of booting from the hard drive instead of the floppy or whatever (useful if you tend to leave a bootable floppy or CD in the drive but usually want it actually boot). Jeremy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel source modifications.
Charles Doty wrote: I modified the following files to allow the kernel to boot from a floppy without all of the delays: config.c (around line 693): ... Is there a specific reason to compile out the check and not simply use the config option to disable the 2 second f5/f8 check? I will check out the patch better this weekend. Thanks for the patch, Jeremy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] read issue in config processing
[dev kernel, will check stable shortly] It was brought to my attention by Eric that in config.sys read() returns an unsigned count or 0x on error but we were checking as though it returned a signed value (-1 or less than requested count). I committed the change that makes these tests check instead for != requested count (ie less than requested count or 0x; also greater than requested count is an error, but can only be seen if the kernel is already corrupted). I also committed some code lying around in my tree, it is very simple code that allows DebugPrintfs to be sent to a COM port (hard coded as to which one, so a recompile is needed if you want to use another one). Note really the most robust stuff, but works well for debugging apps that don't mess with the serial ports. All conditional, so won't show up unles explicitly requested, also I think its OW only. Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Can FreeDOS be installed on embedded system based on 80186/80188?
飘似沙鸥 飘 wrote: Hi, I'm a newer to FreeDOS and I want to know if FreeDOS can be installed on embedded system based on 80186/80188? If yes, is it The FreeDOS kernel and most programs are fully compatible with 8086* and higher computers, so if the embedded system is similar enough standard IBM compatibles (generally AT class or modern systems are used for development and testing, but older PC/XT systems should work) then yes FreeDOS can be installed* and used on an embedded system. * The kernel can be compiled with 8086, 80186, or 80386 specific optimizations (mostly just effect file size); same for FreeCom (our command.com replacement), though the latest FreeCom is usually compiled with 80186 optimizations due to size/features issues. * It might be easier to do a manual install for embedded systems than the CD [or diskettes] based install; that is download the latest kernel, FreeCOM, format, fdisk, and manually do the fdisk/format/sys sequence, then copy over any other programs (mode, keyb, diskcopy, ...) you need. possible that freeDOS work on an embedded system without BIOS? Not really. Currently the kernel and many of the utilities make extensive use of both BIOS interrupts and the BIOS data area (equipment flags, etc). It is possible to remove/alter the need for BIOS, but it would probably be a lot of work (but full source is there if you wish to look through and see for yourself and/or do the changes needed). I'm always open to accept patches that make FreeDOS more friendly for embedded use. Though most things would need to be compile time selected (#ifdef SOME_FEATURE #endif), such as FAT32 support and WIN3 support currently are. If you have any other questions feel free to ask. If you can provide more specific details about the operating environment others may be able to provide better information. Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] freecom/lib cd_dir.c,1.4,1.5 critrchk.c,1.1,1.2 err61.c,1.4,1.5 mk_rddir.c,1.2,1.3 optsb.c,1.3,1.4 where.c,1.5,1.6
Arkady V.Belousov wrote: ... BTW, bug! Function number should come in AH, not AL! So: ... I will try to fix in the morning, thanks. Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: UNSTABLE: Add int 2F 122B and 122D support
Eduardo Casino wrote: Hello All, This patch adds support for int 2F122B (Internal IOCTL) and int 2F122D (Internal Get Extended Error) to kernel. Those are necessary for the upcoming new version of NLSFUNC to work with DISPLAY 1.0. Regards, Eduardo. Thank you, committed. Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/sys sys.c,1.41.2.20,1.41.2.21 fdkrncfg.c,1.11.2.2,1.11.2.3
Arkady V.Belousov wrote: Hi! 30-Ноя-2005 21:59 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ sys.c 30 Nov 2005 21:59:18 - 1.41.2.21 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); +++ fdkrncfg.c30 Nov 2005 21:59:18 - 1.11.2.3 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); Isn't better to move prototypes to something like prf.h? -- Yes, and this is planned as they are repeated way too many times and a pain to keep in sync. :-) Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] comments in kernel and stuff
would anyone object if after merging current changes into stable I modified the comments in the dev branch so I could run a tool like naturaldocs on the kernel and get useful output (www.naturaldocs.org). Alternatively anyone know of any similar tool that would be better? Nothing urgent, nor necessarily something I plan to concentrate on, just something I figured I might do while reading through the files. Just wanted some input, as it would be big change to the comments, but not functional (so really only impact is some extra commits and a little harder to compare to stable, but could make some pretty docs) Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] notes about my recent commits (dev kernel only)
The reason for these -zu compatible fixes is that in cases where SS is not the same as DS (DGROUP) certain calls behave oddly, such as printf, since the compiler is passing an offset on the stack where it assumes DS==SS so the function receiving the parameters can use either segment interchangeably. The problem is in certain circumstances (such as this new interrupt handler) we are using the user's stack so the printfs only work if that happens to be the kernel else you get random values. There may be other cases where this occurs (I have experienced the printf issue before when doing some win3 work in the int 2f handler, but did not investigate at that time). I think Borland's compilers default to DS!=SS (given I only saw an option to set DS==SS) so should not be an issue for them. I may have introduced issues when building with Borland's compilers, I will fix them, but probably not until next week. The basic gist of these commits are to handle int13h calls more like MS/PC DOS does. In particular, MS-DOS hooks the int13h handler to both fix some BIOS issues (about the only ones we may fix currently is if the BIOS doesn't set carry on error, as we force it set and the BIOS must clear, but additional ones can be easily added if needed), improve dma boundary conditions (this is left in our int 25h/26h code), and allow it to notice disk change even when a user program causes the BIOS disk change status to be cleared. The latter is what this mostly fixes, if a user program invokes any of the lower 0x16 subfunctions of int 13h (the higher ones seemed not so important/BIOS disk specific/ and at least 0x16 must be watched) then the BIOS may report disk change and clear its internal flag. Now when the kernel goes to detect a disk change, the BIOS will report none and the kernel will most likely not notice. This can be a tricky data loss issue to track down (one must know that one of the programs they are running is calling an int13h function directly and causing the BIOS to reset its disk change flag, and even then on a change they would somehow have to force the kernel to recognize this). So now we hook int13h with our own handler and on BIOS returning disk change we go ahead and flag, so next query will see that a disk change did most likely occur. Note though these changes will probably cause a small (unnoticeable) slowdown on some Award BIOS based 386/486 (others?) computers as it seems only certain int13h calls (such as disk read) will clear the disk change flag causing the kernel to think the disk is changed until it reads the BPB causing the flag to be cleared. I also added (not fully tested) the int2Fh function 13h function that allows one to install their own int13h handler while still letting the kernel do its initial/post processing of int13h calls (failure to let the kernel in on the processing could result in failed disk change issues, unexpected DMA errors, all the other stuff the kernel normally corrects, etc). This makes the kernel more compatible, including for sneaky virus programs. Jeremy --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Arkady V.Belousov wrote: Hi! 20-Ноя-2005 16:57 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: --- NEW FILE: intwrap.asm --- reloc_call_int13_handler: cli ; disable other interrupts for now INT instruction already disables IFlag. stc ; force error unless BIOS clears ?! This is issue of caller to set or reset CFlag. push dx ; store BIOS drive # for error handling usage push ds ; get segment of kernel DATA mov ds, [cs:_DGROUP_] pushf ; simulate int call so returns back here (flags+cs:ip on stack) call far [ds:_UserInt13] Bug!!! Here DS register is garbaged, whereas it used by some functions (for example, INT13/42). good catch, I rewrote this section several times until I finally tracked down my problem was my usual init-time variables don't match run-time variables [address wise, though the compiler thinks they do, so the UserInt13 initialized wasn't the one used] unless special care is taken. Earlier versions had a different path for ah 17h versus ah 17h, which I need to re-add (as the error values returned do not make sense for most functions ah 17h, but even if not returned, still within same error code group for those less; that or just change it to check on int13/16h ) pop ds ; restore ds jc int13err ; test if error, if not return to caller int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. I'm not sure what is correct here, but I suppose it should simply leave the flag as the user had it (I think I added this after reading a note somewhere in RBIL about a bug in earlier BIOSes that failed to do this). int13wrap: %IF XCPU 186 push ax ; preserve registers, setup stack frame push bp mov bp, sp mov ax, 13h; want to push 0x13 onto stack xchg ax, [bp+2] ; so restore pushed ax value and put 0x13 on stack pop bp ; clean up stack frame (leaving just 0x13 pushed on stack) pushbp pushbp mov bp,sp mov word [bp+2],13h pop bp I like it, cleaner and removes the easy to overlook restoration of ax Thanks for reviewing these patches, Jeremy --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70.2.4,1.70.2.5 entry.asm,1.27.2.3,1.27.2.4 fatfs.c,1.70.2.5,1.70.2.6 int2f.asm,1.34.2.3,1.34.2.4 inthndlr.c,1.87.2.18,1.87.2.19 kernel.
Arkady V.Belousov wrote: ... +cmp word [_OemHook21], -1 +je no_oemhndlr +cmp word [_OemHook21+2], -1 +je no_oemhndlr This is if (FP_OFF (OemHook21) != -1 FP_SEG (OemHook21) != -1), which is not equal to if (OemHook21 != -1) _and_ prevents OemHook21 point to HMA. I suggest, check only for offset is enough. (And in this case you may restore DS right before JE.) sounds like a reasonble solution as I doubt anyone really would set this to : for a valid pointer. +pop dx +pop ds +jmp far [ds:_OemHook21] ; invoke OEM handler (no return) Looks like bug: if before ds=cs:_DGROUP_ DS doesn't contains segment of _OemHook21, then it willn't contain it after POP DS (and JMP then tries to get jump address from wrong point). Else, if DS contains segment of _OemHook21 before this code, then why MOV DS above? ... I agree there is a bug here, I originally coded this differently (copied address to a variable in code segment which I believe a comments still has remnants of) and then simplified it at some point (which introduced the bug). I have a fix locally (just need to compile and test). Jeremy --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] request for comments/ideas etc
For some projects I would like to work on I need to modify the kernel to not overwrite certain sections of memory at startup. My problem is that these items are put in memory before the kernel is loaded so I can not just allocate the memory using DOS calls (since no MCB chain exists yet). The specific items are boot time support for non-FAT filesystems (so I can boot the FD kernel on NTFS and LEAN filesystems), where although I could place the fs support in the kernel, I really think a TSR/driver based IFS is the way to go, and use a fd specific boot time API to reuse the boot sector read logic to load the IFS driver. Instead of a specific to this, I would prefer a more generic approach to not overwriting the memory in use (with the option to free/reuse once no longer needed). The other item I'd like to eventually get to (probably sometime after I fix ATAPICDD, so a year or two down the road) is a replacement for the BIOS int 13h. How does the ontrack and such software work so DOS doesn't overwrite them? My reason for this is that I have two computers that could use improved support, one an old laptop [though I may fry it when I replace its cmos battery] so BIOS does not have a user specified CHS setting (yeah its that old that only predefined types are available and it uses a full size standard 3.5inch hard drive)], the other is my trusty 486 (my primary kernel testing computer). I could put the card I bought and never used that is supposed to add LBA/modern for the time IDE support to my 486, but I don't think it will fix the fact that the BIOS only supports a single IDE channel, so although I have a functioning CD-ROM on a secondary controller, I am limited to the primary controller for hard drives. So any suggestions, are there existing DOS methods that software such as network stacks for remote booting or disk software to allow large hds to work with DOS use to notify DOS? if so any pointers to what to look for when searching. Or any suggestions for a FD specific solution? Should it just extend/create a extended BIOS data area and replace the code that DOS uses to detect its existence and size (is this feasible)? Thanks for you input, Jeremy --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
The main issue with FreeCom would be the location of its resources changing. As long as the comspec env variable still pointed to the same (or an identical) copy of the strings, it would probably be ok, but honestly I don't know if FreeCom closes/opens or keeps open the file with its resources. There may or may not be other issues. Jeremy --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: reload partition table and reassign drive letters
firstly, I never said FreeCom couldn't handle drive letter changes, I said if one did something, then they need to make sure it can; in particular the way it loads strings; although from my experience not being able to load its strings usually just results in FreeCom issuing useless messages (eg try to do dir get a bunch string #XX instead). I stand by my take the code from the kernel and make it an external program if you really want it. Its not overly difficult, just make sure all files are closed first, change the internal structures (hence the kernel version check), and as far as the kernel is concerned nothing happened, but now you may have different drive letters. Of course you would want to be sure to handle the case of LASTDRIVE too small and various details like that. And really if you wanted to be clever, maintain the needed information about open files and TSRs won't even notice the change, even if the file is now on a different drive (C:-D:) The point is, in a known boot state this could all work fine, but in a random user's setup, some program out there is going to get confused and cause data loss (some undelete, raw disk accessing, ... utility) and given the effort involved for such tool versus the man power we have, the best idea is just plan for a reboot. This has the advantage of almost always working, requires no kernel specific knowledge (so same boot disk can easy be changed to use FD/MS/PC/DR/EDR/ROM/??? DOS) and is not too difficult; for floppies simply require it to be writable and store the current state (this is what was done at my old job for repartiting/restoring/upgrading the PCs [of course they were all IBM machines so it was easy to detect the proper machine for driver/BIOS issues]) and for CDs there are methods. As for the int19h issue, MS DOS actually hooks several (I think this is one) and assuming it eventually gets called by whoever hooks it after, does several things to aid in rebooting; restoring a couple of the int vectors and if himem was loaded it clears the vdisk entry so it will reload on next boot (unlike with FD where you get the driver already loaded error). So to summarize, yes DOS could reload partition tables and reassign drive letters, to a certain extent some drivers such as CD or network drivers do this, current kernels do not do a complete scan and reassign drive letters though, doing so would require work from developers we don't have and if made into a resident DOS call would waste conventional memory for most people. Jeremy --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] reload partition table and reassign drive letters
I've considered this in the past, but the consensus seems to be that it is best just to reboot. It is possible to assuming no TSRs are loaded that would be confused by such action, but if done in the kernel it would involve leaving normally init time (hence transient so does not normally occupy the precious low memory) code in. If you really really really need to do this, then for a controlled setup only (no TSRs or ones you know, and I do mean know, will not be confused by such action -- note FreeCom may be confused by such action) I would suggest taking the source for the specific kernel you are booting and make an external program that does the required work. I don't have time at the moment as I'm trying to finish my MS/PC DOS 6 config menu support, have a few dozen bugs on the back burner, my SYS work, my FreeCom work, my AtapiCDD work, and half a dozen other things I've forgotten about. Jeremy (current kernel maintainer) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] about boot sector
cstarter wrote: %define bsOemName bp+0x03 ; OEM label %define bsBytesPerSec bp+0x0b ; bytes/sector %define bsSecPerClust bp+0x0d ; sectors/allocation unit %define bsResSectorsbp+0x0e ; # reserved sectors %define bsFATs bp+0x10 ; # of fats %define bsRootDirEnts bp+0x11 ; # of root dir entries %define bsSectors bp+0x13 ; # sectors total in image %define bsMedia bp+0x15 ; media descrip: fd=2side9sec, etc... %define sectPerFat bp+0x16 ; # sectors in a fat %define sectPerTrackbp+0x18 ; # sectors/track %define nHeads bp+0x1a ; # heads %define nHidden bp+0x1c ; # hidden sectors %define nSectorHuge bp+0x20 ; # sectors if 65536 %define xsectPerFat bp+0x24 ; Sectors/Fat %define xrootClst bp+0x2c ; Starting cluster of root directory %define drive bp+0x40 ; Drive number I read the boot code many times , the bp+xxx puzzled me . not value specified , how to calculate . I wonder the bsSectors's(nFATs ,...) value , and how to calculate . Thanks . I'm not really sure what you are asking. The number of FATs is stored in the BPB at offset 0x10 (bsFATs). The BP+0x10 is a trick to generate smaller code, it works because BIOS loads the 1st sector (which has the BPB and boot code) from the disk to 0:07C0h and the boot code sets SS to 0 and BP to 07C0h, so any positive reference from BP will access the BPB (or boot code). The value actually stored in the BPB for number of FATs is placed there when the disk is formated (almost always 2 unless a RAM disk or special tool used), sys takes care not to alter these when placing the boot code on the disk. Jeremy --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Eric Auer wrote:
...
struct dhdr FAR *IsDevice(const char FAR * fname)
has a problem here. But why does that only happen with DEVLOAD?
...
I hope there are still some readers on the kernel list and we
can move the further discussion to that list. A fix should be
quite straightforward: 1. . .. \ are all no device names and
2. dhp-dh_attr should be tested for ATTR_CHAR before comparing
the IsDevice input to dhp-dh_name.
struct dhdr { struct dhdr FAR *dh_next; UWORD dh_attr;
VOID(*dh_strategy) (void); VOID(*dh_interrupt) (void); UBYTE dh_name[8]; };
Eric, I have uploaded a test kernel [stable branch] for you to try.
http://www.fdos.org/kernel/test/kernel.eric.sys
It implements the two items you suggest, a check check for \,., and ..
before checking all device headers, and the device header is checked to
make sure it is a character device before testing its name.
Unfortunately I don't get the error you are experiencing with devload
and xmsdisk, it works fine for me without the fix so I can't verify it
will fix your problem (my guess is my computer's memory has 0s or values
that don't trigger the problem). I also fixed a bug in that function
where device names shorter than 8 characters could return as not a
device (on these i==FNAME_SIZE+1 due to inner for loop).
As soon as you test and get back to me, I will either change or commit.
By the way, init_device drops devices which either take no memory
(endaddr same as device header location) or are 0 drive block devices.
yes, this is correct.
Eric
Thanks for the detailed analysis,
Jeremy
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Eric Auer wrote: ... So your kernel is still not immune to the problem entirely - it still somehow uses names of block device drivers even though those names are optional and not even related to file name processing at all. I will have to check and see if there are other references in the kernel then, as the IsDevice proc should not be the issue any longer (it checks the device header for character bit, and if not set continues to next header in chain bypassing any block devices). ... I also fixed a bug in that function where device names shorter than 8 characters could return as not a device (on these i==FNAME_SIZE+1 due to inner for loop). Are you sure that there was a bug? Maybe you even introduced one ;-). you are correct, not a bug, just a mistake on my part, already undone ... Eric Jeremy --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel task.c,1.44.2.4,1.44.2.5
Arkady V.Belousov wrote: Hi! 17--2005 18:34 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: tc debug build fix +++ task.c17 Jan 2005 18:34:10 - 1.44.2.5 -#if DEBUG +#ifdef DEBUG __O\_/_\_/O__ #if TST # error 1 #endif _ O/~\ /~\O __O\_/_\_/O__ bcc -c -DTST tst.cpp Borland C++ Version 3.1 Copyright (c) 1992 Borland International Error t.cpp 1: Expression syntax Fatal t.cpp 2: Error directive: 1 *** 2 errors in Compile *** _ O/~\ /~\O Fix: #if TST+0 ---^^ PS: I don't understand, what the trouble was with debugging? Old code was includes conditional part when DEBUG is defined, new code includes code only when DEBUG is defined AND not zero. Ie. -DDEBUG now not enough to include those conditional part. I'm confused. How does #ifdef DEBUG (the new code) require DEBUG to be defined and not zero? The issue here is that when I converted an #if 1 to be debug only code I forgot to change the #if to #ifdef. On a tangential [only slightly related] note, for debug code I want in the source but almost never compiled (something that helped track down a specific issue, but generally not needed for a debug build), should I used #ifdef DDEBUG ... #endif or simply #if 0 ... #endif or #ifdef ?? suggestions ?? ... #endif Thanks, Jeremy --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.6,1.14.2.7 buildall.bat,1.6.2.2,1.6.2.3 config.b,1.12.2.3,1.12.2.4 defaults.bat,1.1.2.5,1.1.2.6
Arkady V.Belousov wrote: Hi! 31--2004 21:37 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: use NT OW binaries on NT, add access to more options from build cmd line +++ defaults.bat 31 Dec 2004 21:37:51 - 1.1.2.6 +set BINPATH=%BASE%\bin +if %COMPILER% == TC set BINPATH=%BASE% +if %COMPILER% == WATCOM set BINPATH=%BASE%\binw +if %COMPILER% == WATCOM if %OS% == Windows_NT set BINPATH=%BASE%\binnt + +echo Path to compiler programs (binaries) is %BINPATH% if not %BINPATH% == goto skip_binpath ^^ set binpath=%BASE%\bin if %COMPILER% == TC set BINPATH=%BASE% if %COMPILER% == WATCOM set BINPATH=%BASE%\binw if %COMPILER%%OS% == WATCOMWindows_NT set BINPATH=%BASE%\binnt -^^ ok echo Path to compiler programs (binaries) is %BINPATH% :skip_binpath +:- MSC searches libraries only through LIB variable. +if %COMPILER% == MSC set LIB=%MSC_BASE%\lib if %COMPILER%%LIB% == MSC set LIB=%MSC_BASE%\lib -^ I like +set XCPU_EX= +++ build.bat 31 Dec 2004 21:37:51 - 1.14.2.7 +echo :--- This ECHO shows line with quotes. and? its just there so I don't have to keep opening the batch file to see what its arguments are, they should be balanced though, making a bounding box (at least for me it does) if %1 == 386 set XCPU=386 +if %1 == x86 goto setCPU This option doesn't shown in help screen. its not really a useful option, that was me testing to see if setting the compiler to 386 made a difference (since I rarely test on anything less than a 486), but all OW's settings produced identical code (though its possible the setting somehow didn't propagate, for the curious, it basically sets XCPU=386 and later adds the %1 as a compiler switch (eg -4 instead of -3). cd ..\sys call %MAKE% all if errorlevel 1 goto abort-cd +if NOT %XUPX% == %XUPX% ..\bin\sys.com Isn't better to place XUPX call inside sys\makefile, like in kernel\makefile? yes, I would prefer it in the Makefile, but I do not know how to do in way that works with all our make.exe programs to only perform the upx if %XUPX% is set. If you (or someone) has a suggested patch, please send it to the list (or me at my fdos address). I'll see about updating this shortly. Thanks, Jeremy --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: GRUB for DOS and FreeDOS
While I can reproduce this bug with the indicated kernel revision, it does not appear to be a current problem. Can anyone reproduce with the current kernel? Did anyone already fix this or are we possibly still corrupting memory, just a different location now? Thanks, Jeremy ... version 1.1.35w (Build 2035w-UNSTABLE, Nov 28 2004) also saved a wrong BIOS interrupt vector table, so GRUB.EXE does not run. Details: FreeDOS build 2035w-UNSTABLE destroyed two hardware interrupt vectors. FreeDOS build 2035w-UNSTABLE tried to save the original BIOS int 0x08 - int 0x0F vectors at :0710, but the FreeDOS startup code overwrote the region. On my QEMU virtual machine, this destroyed region is dumped here: ... (53 FF 04 1A) corresponds to int 0x0B; (1C 9E 00 F0) corresponds to int 0x0C. ... Hope this bug in the FreeDOS Kernel will be fixed soon! Wengier --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] broken FreeDOS kernel.
Bernd Blaauw wrote: Jeremy, the -dev kernel is BROKEN. Try booting, and then SET FOO=BAR ... This is fixed in current cvs. The problem was that the DOS int21h function 4A, resize block, is called by FreeCom to resize its initial environment to size requested by the /E: option. For a brief moment of time we failed to return failures correctly, so FreeCom never attempted to allocate a new block properly assuming the resize succeeded. The inability to set the env var is a result of FreeCom using the env seg created during config.sys processing, which is only as big as necessary to hold the up to 128 bytes of env vars set (usually about 48 bytes). (Another error where I missed a len reduction by 2 and so reduced a copy by another 2 is also fixed. Lucho is a bit quicker than me. Thanks.) :-) Jeremy --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel Source Documentation
Karthigan Srinivasan wrote: ... am kind of lost. Is there any documentation of on the kernel source. I am new to OS programming and ... The only documentation that I am aware of is: The FreeDOS Kernel book by Pat Villani, the comments in the source, the Topica Sourceforge fd-kernel archives, and to some extent Ralf Brown's Interrupt list and similar DOS documented undocumented references. If you have specific questions, please ask and we will try to assist you (as best as our understanding and time available permit). Jeremy --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Broken VERSION= in 2035 etc. - too many kernels
Eric Auer wrote: Hi! If it is broke in stable and fixed in dev, then it should be fixed in head soon. Please people, the kernels are not Lucho/Arkady vs Tom/..., they are stable and development (unstable). Well I can only give people the Lucho or the SF homepage URL if they want a kernel BINARY. If I understand right, we NOW have the Tom and the CVS SF binaries online, too? Which SF binaries, Not sure about Tom, but yes there are binaries from unmodified [sourceforge kernel] cvs now. 2035 plus stable plus dev? Or is stable the same as 2035? SF only contains release binaries, which presently is 2035 and soon will add 2035a. On my site are the cvs binaries as they are meant only for testing. And if I understand right, The CVS dev branch contains most Lucho / Arkady patches? Are there patches which are rejected even in dev, or does that mean that CVS dev is - after some delay - the same as the kernel on Luchos homepage? And CVS stable is one kernel Lucho's homepage refers to cvs unstable branch last I checked. which collects all useful/stable updates since 2035, similar to Toms kernel but not the same? Any quick-to-describe differences yes between Tom and Jeremy-CVS-dev? I haven't reviewed Tom's kernel yet. See history.txt in the docs directory. Accesible through the CVS web viewer for the dev and stable branches? Should be, don't have the URL handy though. Also see http://www.fdos.org/kernel/head2unstable.diff if you are curious of the difference (minus new files) between stable dev. Nice idea, but that is 554394 lines (bzip2 compressed would be 115k) in ONE file, pretty tricky to fetch a collection of patches from that 16613 line (71622 words) file unless you know verrry well which patches you want. Well, its the diff file I use to apply patches to stable, so its hard for me to give you the mini patches you request -- I followed the discussions as they were posted to the list and that is still the archives are still the best place to pick and choose them from. I'm still reviewing the patches in the dev branch and merging into stable. Any that make it in that others strongly disagree with can always be reverted... Thanks a lot, that definitely takes a lot of your spare time. You could put up an online feedback system where people can download single patches and 'upload' comments (like a grade / degree of confidence in 'does not introduce bugs' / 'improves kernel' / 'does not change semantics' (or does change them, fixing a bug) terms). That would allow to split the work a bit. The catch is, from experience I've found people don't generally comment if things are liked, only if they are disliked. Eric ... Sorry for not replying better, but I'm late for work as it is. Jeremy --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Broken VERSION= in 2035 etc. - too many kernels
Eric Auer wrote: Hi, after a while we found that only the Lucho / Arkady kernel has working VERSION=, ... If it is broke in stable and fixed in dev, then it should be fixed in head soon. Please people, the kernels are not Lucho/Arkady vs Tom/..., they are stable and development (unstable). ... which reminds me that we have too many versions: There is exactly one (1) kernel; in cvs there are two (2) branches and many versions (from the original Pat release up to current cvs versions). There are are also forks I'm sure, Tom for one has one of these, but as he makes available his kernel, any bugfixes in his should show up in sourceforge one, time permitting. - outdated 2035 - Jeremy has added an unknown amount of patches to CVS HEAD 2035a, but I have no idea if / how well those patches got reviewed and which bugs they fix See history.txt in the docs directory. Also see http://www.fdos.org/kernel/head2unstable.diff if you are curious of the difference (minus new files) between stable dev. - Tom has added only the best few lines of the Lucho / Arkady patches, those which OBVIOUSLY fix bugs, but will have missed several bugfixes which were hidden between optimizations - Lucho / Arkady produced a big amount of patches which mainly contain optimizations (hopefully not too compiler specific), but also important bugfixes, as well as hard to justify variable renamings, indendation changes, macro changes, etc.!? Please note, you can easily ignore identation changes with a few diff options, that is largely why I don't care if they are made or not. So I suggest: Jeremy, please create a list of improvements / changes between 2035 and newest CVS kernel, and a way to download all patches separately (or in one big tgz/zip), along with short descriptions of them. As best I know (though haven't double checked through my email) all patches are integrated in dev branch, so its history.txt should tell you everything that has changed (recent additions are mostly organized by person then file), and a cvs diff can get you the patch. Tom, are you planning to publish your kernel variant? In either case, Tom has said on several occasions his kernel is available upon request. [Note: I see looking ahead he has provided a URL.] could you help us to discuss the feature / bugfix differences between your and Jeremies kernel? I think it should be possible to sort the recent patches into important useful patches vs. tuning / optimization / experimental patches, to create a combined Tom's and Jeremies best pick of all recent patches kernel on which all parties could settle for a stable 2035b official release for freedos.sourceforge.net ... what happened to 2035a? :-) Finally Lucho and Arkady can comment on that by describing the advantages of the patches which did not made it into 2035b, and by pointing out I'm still reviewing the patches in the dev branch and merging into stable. Any that make it in that others strongly disagree with can always be reverted (such as the recent thread started by Bart). I'm trying to be conservative in what goes into stable, but limiting the divergence at the same time. which bugfixes should be added before 2035b would be published officially on SF.net ... In either case a list of patches, in a file, not spread over dozens of mails, would greatly improve the overview over the available improvements, dependency between patches, give a guide which helps to find relevant 2035 / 2035b differences in processing bug reports for either (!) of the two, give information which patches are considered to be stable and which are more obscure and therefore not yet reviewed well, and so on. ... Eric. comments/reviews/discussions (not arguments) on patches/bugs/regressions are of course always welcome. Please be patient with me though, I have but a few hours a week (squashed between sleep and my jobs) to work on projects. Jeremy :-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel source zips Re:...
Arkady V.Belousov wrote: Third (or 5th?) times of asking (without answer): where and how download latest (unstable) kernel sources? And, as I understand, there is If sourceforge has cron working, tarballs are there still, additionally: http://www.fdos.org/kernel/kernel.HEAD.zip for stable sources http://www.fdos.org/kernel/kernel.UNSTABLE.zip for dev sources The fdos.org sources will be updated regularly and not change (for a good while anyway). I will be adding bilds to the kernel/ directory to, just haven't had a chance to set it up. now 4 alternate trees: 2035, 2035-tom, 2035-Lucho and 2035-Jeremy? No. There is the stable branch (which should be similar to Tom's, though yes he has his own as others may?), and then the unstable/dev branch, which is where Lucho changes and some stuff that I'm doing that I haven't tested enough to be considered stable. 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
Arkady V.Belousov wrote: Hi! Log Message: easier change of kernel load segment, remove need of keypress when linking +++ wlinker.bat 2 Sep 2004 20:22:05 - 1.3.2.2 -%BASE%\binw\ms2wlink %1 %2 %3 %4 %5 %6 %7 %8 %9kernel.lnk +%BASE%\binw\ms2wlink %1 %2 %3 %4 %5 %6 %7 %8 %9 kernel.lnk Please, explain this. It removes the anonying prompt for NULL.DEF I did not really investigate to see if all the commas are needed, just copied from the stable batch file. Without this, when it links, I have to press enter, and I can not enable my automatic builds if I have to be there to press enter. My assumption is that it works like other compilers I've used and simply indicates the optional file is not wanted/needed. If you have a better fix, I will gladly change it. [I have some updates to UNSTABLE's boot.asm if you look at bug 1820 and want to verify/improve before I commit it. This weekend I'm going to go through Lucho's kernel patch and commit parts of it, so if you have anything not in there (and not already mailed to the list) please send it to me so I can try and review it and commit it as well. ] 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
[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] Arkady Patches
James Tabor wrote: Hi, I see allot of patches from Arkady. If I had more time I could check them out and start committing to the CVS. But! So many patches! Yes there are! :-) Which is why I created a development branch, where I can more quickly apply patches that may (or may not) need more testing/review. End users should stay with release kernels, those using the kernel for other products should stay with the HEAD branch or release kernels (as they deem necessary), and developers are free to use either branch (but be clear about which is used in any discussions and keep in mind the dev branch may have a bug already fixed). Arkady! Do you have a working kernel so I can look at it for testing? you can get a source tarball from sourceforge (URL not yet permanent) /freedos.UNSTABLE.tgz or from cvs using -r UNSTABLE on checkout, or from fdos.org bootdisks page (which includes binaries). James 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/docs history.txt,1.78.2.1,1.78.2.2
Arkady V.Belousov wrote: Why? Also, I see, you miss my fix for previous records in history.txt (was published here). Because I have not had time to review the patches that the changes refer to, and I do not wish to make any adjustments to prior changelog until I am certain of what the change really was/did. As for the added batch line in your other email; it helped me track down why build.bat failed mysteriously for me the first time I ran it. (Also, thanks for the FreeCom note; saved me some time reviewing the mailing list / debugging). Jeremy --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
...
I may send you my edition of config.c (private, I suggest?), but it not
the last edition (I continue to work on it).
please do
...
and add own comments. For example:
KJD yes, I viewed yours, the original, RBIL, and the code and selected
KJD the one that seemed the most clear, being more verbose if necessary.
Hm, I look at RBIL. Looks, like there is another ambiguite (or even
wrong) description. :(
In the future I will be more careful and try to validate descriptions
with other resources.
PS: There are also other re-changes in compare to original and my edition.
For example, I describe `drive' parameter for all functions (as in dsk.c) as
UBYTE (this gets better code) and return type as `int' - in your edition
While the drive parameter is an unsigned byte, it is actually passed in
as a word, and the prototypes in dsk.c at present still indicate this.
So instead of using UBTYE in one place (floppy.asm) and WORD in another
(dsk.c), I maintained the use of WORD. No code is effected, as these
are strictly changes to comments. When I apply your dsk.c patch 10,
which does change the prototypes, I will change floppy.asm to match.
this is no so. Also, I think, explaining in comments for sbb al,al that
Al=-CF is not good. This is same, as write next:
int i = ...
i++; /* increment i */
My comment isn't AL=-CF it is AL=-CF={-1,0}, the comment is
saying that after the sbb call, AL is either -1 or 0. The -CF simply
clarifies that only carry determines the actual value.
(BTW, you preserve comment in mov ah,0 ; zero out ah). Also, you preserve
sure its an obvious comment, but how does it adversely effect anything?
wrong comment cylinder number (lo only if hard) - this is complete
cylinder number, not its lo part. Also, count to read/write is wrong
corrected
comment, because there is code for format and verify (same for
how about 'count of sectors to read/write/...'
fl_lba_readwrite()). Also, you remain (Zero transfer count) and force
into 255 count, whereas AL (AL only, AH cleared!) returns error code, not
transfer count.
ok, adjusted, I read this comment as extending al into ax without sign
extension.
PPS: Also, there are cosmetic remarks (from me :): in some places you
preserve my tabulations (though, before some comments you lost one - see,
for example, mov ah,18h), in other places you preserve trailing spaces
(even on empty lines)...
While I will commit some, I prefer to not make whitespace only changes.
it also depends on how I apply a given patch.
Jeremy
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] commit: floppy.asm
I have gone through Arkady's floppy patchset (is there a 5 of 5?). This weekend I intend to finish processing his dsk.c patchset (which includes Lucho's rewording patch), and once a patch is provided I will work on the config processing. I'll commit the history.txt update once I finish the dsk.c work. I have set the build version to 2035a to help prevent confusion with released kernels. As I commit updates, please refer to sourceforge for source, but I may provide binaries and diffs at http://www.fdos.org/kernel/ As this is my first commit, for exact patch committed see: http://www.fdos.org/kernel/2035a/p1.diff and for the binary compiled with OpenWatcom 1.2 + UPX'd see: http://www.fdos.org/kernel/2035a/KERNEL.SYS Please feel free to comment and thank you for the patches! Jeremy Davis [EMAIL PROTECTED] CVS: Modified Files: CVS:drivers/floppy.asm hdr/version.h -- based on floppy.asm patchset from Arkady, use ret instead of ret 8 appropriately; improve comments, including sync with prototypes in dsk.c; small code clean up --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit: floppy.asm
Arkady V.Belousov wrote: Hi! 18--2004 03:12 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: KJD I have gone through Arkady's floppy patchset (is there a 5 of 5?). There was 4 of 5. Last patch I omit, because it was cosmetic. Ot the other side, you may get complete floppy.asm patch (all in one) in previous letters. Ok. Thanks, just wanted to make sure I didn't somehow overlook it on sourceforge. KJD This weekend I intend to finish processing his dsk.c patchset KJD (which includes Lucho's rewording patch), and once a patch is KJD provided I will work on the config processing. I not send any patch here. Reason: there too many changes - so, I should send one _big_ patch or send _many_ smaller patches. I fear, this is not acceptable here. That's fine, it doesn't matter to me if its one big, several smaller, or even just the changed file. KJD As I commit updates, please refer to sourceforge for source, but Is kernel.tgz will be updated? Should be. KJD Please feel free to comment and thank you for the patches! KJD CVS: drivers/floppy.asm hdr/version.h I see, you miss some my changes (for example, fl_diskchanged epilog) please be more specific, for example I changed floppy.asm patch 3 to maintain the same size and return values as the original logic, as I did not see a reason to make the code longer and return 0x00FF instead of 0x (-1). see http://www.fdos.org/kernel/2035a/arkady/test.asm for the three variations (mine, yours, the original). and add own comments. For example: yes, I viewed yours, the original, RBIL, and the code and selected the one that seemed the most clear, being more verbose if necessary. + pop dx ; drive, (DL only, bit 7 set resets both floppy hd) ---^^... This is wrong addition: of course, BIOS enumerates hard disks as 80h-ffh (with bit 7 set), bit 7 not relates to reseting both floppy and hd, there will be reset disk, which number is in DL and only it. Ok, I will remove it. It was taken from RBIL, and I added as it looked like a really weird quirk to be aware of and research a bit further; along with determing if we actually called any of the floppy functions with a disk number corresponding to a hard drive, as RBIL indicated for several of the calls we use about problems with some buggy BIOSes if a value greater than 0x7Fh was use (ie if drive number refers to a hard drive). Jeremy --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Arkady V.Belousov escreveu: Hi! Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For example, my current todo contains at least 6 bugfixes for dsk.c, and 2 which I don't know how to handle. Beside this, there optimized out some hundreths of bytes. Until someone else steps up and has the time, if wanted, I can do my best to apply patches for bugfixes to the kernel cvs sources. I should already have the necessary access to commit to cvs, but do not do so as I do not wish to step on anyone elses toes. If there are no objections, then about once a week I will go through the kernel mailing list archives [I no longer assume I get all my emails, as my mail box fills up daily with spam and false bounce messages] and apply patches or initiate further discussion. I will send a message to the list to indicate what patches are applied, so if I miss any or whatever, we can can discuss them further. This will pretty much be apply patches only, as I doubt I will have the time for indepth bug solving. As soon as Bart, Tom, or whomever deemed appropriate wants to continue doing so, I'll go back into my lurk mode. Is this acceptable? or is there someone else already doing this? wanting to do it? etc. Thanks, Jeremy Davis [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] SYS issues
- /Odrive - use fixed drive number (in hex) in boot sector. MHT If this switch is intended for compatibility with DR-DOS, drive number MHT should be given in decimal. Support for hex with '0x' and/or '$' prefix MHT can be a nice extension, though :-) Inconsistent: address in /L option is hex-value. And I think, _here_ consistency inside one program interface is more important, than full compatability with (very rarely used/known) option of DR-DOS SYS. If the option is mimicking an existing option (in this case from DR-DOS sys), we should at least try to be compatible. So wouldn't the better change to require/support the 0x or $ or h notations for the /L option as well, and use base 10, at least for the /O option, if not used or complain/warn if a hex prefix/suffix is not used. So if in all the examples, options are used as /L 0xABCD and /O 0x123 we will be consistant within this one program and at the same time constistant for those familiar with the DR DOS sys /O option. Just my opinion, do as you feel best for our sys though. Has your work been committed to cvs or is there a patch/ source archive around that one can look at? Thanks, Jeremy --- 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] sys.c portability increase
Please change the two lines in sys.c that use (int *) to use (UWORD *) or similar. I overlooked this when compiling with MS VC 6 and causes the resulting floppy to not be able to boot as the wrong location is written to (as int == DWORD instead of WORD). And I'm likely to overlook it again if I update to a newer version of SYS later. ((int *)newboot)[0x3C] = load_seg; ... /* put 0 for A: or B: (force booting from A:), otherwise use DL */ bs-bsDriveNumber = drive 2 ? 0: 0xff; ((int *)newboot)[0x2E] = load_seg; I like the cleaned up command processing, though there is one or two spots that need fixing: printf(%s: drive %c must be A:..Z:\n, pgm, *argv[(argc == 3 ? 2 : 1)]); should probably be printf(%s: drive %c must be A:..Z:\n, pgm, argv[drivearg][0]); and some of the tests seem to have redundant !variable if tests (both and bootonly). Does this result in a size reduction or am I missing some aspect of the test? (Forgive me if these are already pointed out / fixed outside current nightly tarball, as I haven't been following fd-kernel too closely.) Thank you, Jeremy [See http://www.fdos.org/bootdisks/autogen/source.zip if you want the source to my MSVC6 port of sys 3.1 for NT (2000/XP tested). Because its all I need, it only properly supports floppies and requires NT, but should work more reliably under NT than the official DOS sys. Source.zip may be large, so I can pull out winsys.c from it if desired.] --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
