Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 02:36 PM 10/9/2005 +0400, Arkady V.Belousov wrote: And how this should be look? Drivers doesn't return errorlevels, whereas INSTALL= executed after DEVICE=. MD Perhaps you could have it conditional on a register return value from an MD application, Even if I introduce new interface, then it will be useful only for new drivers. It will be useless for all existing drivers. Wrong. It will be useful for _everything_: CONFIG.SYS: ; CHECK386 program returns AL nonzero if 386+ level chip found %IF CHECK386 DEVICE=C:\WHATEVER\PATH\HIMEM.EXE %IF CHECK386 DEVICE=EMM386 ; CHECK286 program returns nonzero if 286-level chip found %IF CHECK286 DEVICE=FDXMS286 ; ISFLASH program detects USB flash driver presence with nonzero return %IF ISFLASH DEVICE=USBASPI.SYS %IF ISFLASH DEVICE=DI1DI.SYS ; ISVIDECD program detects whether CD needs VIDE driver %IF ISVIDECD DEVICE=VIDE-CDD.SYS ; otherwise try another generic driver %IFNOT ISVIDECD DEVICE=OAKCDROM.SYS ; if known broken BIOS fails critical operations, load workaround driver %IF DETFAIL DEVICE=FIXBIOS.SYS The actual %IF and %IFNOT were arbitrarily chosen as the conditional commands, of course. If you want to get fancy, you allow stacking multiple conditionals per line, e.g. %IFNOT CHECK386 %IFNOT CHECK286 DEVICE=lame 8086 memory manager. As long as you're not spreading out conditionals along multiple lines with IF/ELSE/ENDIF -- a behavior which seems much more complicated and nasty to implement -- it could be a simple parse loop added to the original conditional. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Hi! 10-Окт-2005 13:35 [EMAIL PROTECTED] (Michael Devore) wrote to freedos-user@lists.sourceforge.net: Even if I introduce new interface, then it will be useful only for new drivers. It will be useless for all existing drivers. MD Wrong. It will be useful for _everything_: MD CONFIG.SYS: MD ; CHECK386 program returns AL nonzero if 386+ level chip found MD %IF CHECK386 DEVICE=C:\WHATEVER\PATH\HIMEM.EXE MD %IF CHECK386 DEVICE=EMM386 Why to duplicate checks, which already present in himem and emm386? MD ; CHECK286 program returns nonzero if 286-level chip found MD %IF CHECK286 DEVICE=FDXMS286 Isn't fdxms286 checks for 286? MD ; ISFLASH program detects USB flash driver presence with nonzero return MD %IF ISFLASH DEVICE=USBASPI.SYS Who will write isflash.sys driver? MD %IF ISFLASH DEVICE=DI1DI.SYS MD ; ISVIDECD program detects whether CD needs VIDE driver MD %IF ISVIDECD DEVICE=VIDE-CDD.SYS MD ; otherwise try another generic driver MD %IFNOT ISVIDECD DEVICE=OAKCDROM.SYS Both vide-cdd and oakcdrom are generic IDE drivers and there not need other drivers, if you already use one of them. MD ; if known broken BIOS fails critical operations, load workaround driver MD %IF DETFAIL DEVICE=FIXBIOS.SYS Why not built checks into fixbios, when you will write it? PS: No, I not see there useful examples. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 11:28 PM 10/10/2005 +0400, Arkady V.Belousov wrote: MD %IF CHECK386 DEVICE=EMM386 Why to duplicate checks, which already present in himem and emm386? Why depend on on drivers to unload cleanly if they fail, which they already do not always do in closed-source drivers, despite protestations to the contrary. Why not allow external load control based on any of a thousand conditions the driver was never and could never have been written to consider? Someday I may also show you a device driver which uses UMBs, disproving the claim that none do. MD ; CHECK286 program returns nonzero if 286-level chip found MD %IF CHECK286 DEVICE=FDXMS286 Isn't fdxms286 checks for 286? It isn't relevant, as it is overly specific for the example and ignores the real issue of conditional processing the example is used for. But if you want an overly specific reply, it won't help that fdxms286 checks for a 286+-level if a 386-level driver is already loaded. MD ; ISFLASH program detects USB flash driver presence with nonzero return MD %IF ISFLASH DEVICE=USBASPI.SYS Who will write isflash.sys driver? Well, let's see, it would be open-source or close-sourced as the author(s) choose. Who will write FreeDOS? Who will write EMM386? Who will write Linux? Nor need ISFLASH be a SYS driver; a COM or EXE would be fine. COM obviously would be easiest to support. Both vide-cdd and oakcdrom are generic IDE drivers and there not need other drivers, if you already use one of them. If they all worked I wouldn't need to use one instead of the other for reliable CD access. Which I do. In mathematical logic terms, that demonstrates a counterexample which falsifies the original statement. PS: No, I not see there useful examples. It is almost impossible that you would fail to see the power of open-source load control of closed-source drivers at boot time, however it is implemented, yet you act deliberately obtuse on the matter. Why, I don't know and don't care, the capability remains a powerful, flexible, and realistic goal. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Michael Devore schreef: It isn't relevant, as it is overly specific for the example and ignores the real issue of conditional processing the example is used for. But if you want an overly specific reply, it won't help that fdxms286 checks for a 286+-level if a 386-level driver is already loaded. Again a nice theoretic discussion :) Anyway, are FreeDOS related programs and drivers also ment to be used on MSDOS or not as partial replacement? If yes, then each driver will have to do the hard work itself, as we cannot change the MSDOS kernel (including config.sys parsing) even if we could change the FreeDOS kernel. By the way, are drivers able to hijack interfaces from each other? would first loading FDXMS286 and later HIMEM or FDXXMS.SYS gain access to XMS3.0 and 4GB (overriding FDXMS286 completely) or would these drivers *always* fail with a simple XMS driver already loaded ? If they all worked I wouldn't need to use one instead of the other for reliable CD access. Which I do. In mathematical logic terms, that demonstrates a counterexample which falsifies the original statement. Yes, it proves that both cdrom drivers are not universal enough. Each of them works for 99%. I have no idea what happens if you try to load different drivers with same arguments. DEVICE=VIDECDD.SYS /D:TEST2 DEVICE=MTMCDAI.SYS /D:TEST2 DEVICE=OAKCDROM.SYS /D:TEST2 It is almost impossible that you would fail to see the power of open-source load control of closed-source drivers at boot time, however it is implemented, yet you act deliberately obtuse on the matter. Why, I don't know and don't care, the capability remains a powerful, flexible, and realistic goal. There's many possibilities, and not only for CPU checks, but also XMS (and amount of it), presence of Memdisk arguments, etc. Without doubt some interested person someday will find time to implement conditional parsing :) Bernd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Hi! 8-Окт-2005 21:22 [EMAIL PROTECTED] (Michael Devore) wrote to freedos-user@lists.sourceforge.net: MD As the front line guy taking most of the tech support on EMM386 (and MD HIMEM), I herewith state that you are incorrect. HIMEM delayed loading I _not_ say about loading HIMEM from command line, I say about CPU detection and preventing load on too old CPUs. MD Your last message said that aborting EMM386 and HIMEM 80386-check would be MD much better and prevent a floodgate of errors. It wouldn't; It will: when instead silent crash user gets message 386 required, it will understands what happens. MD it has nothing to do with delayed loading of the memory managers.. Yes. This is another topic. But I say about correct CPU checking, I not require immediately implement command line loading. May you explain, where you see there wreck? Difference between loading of XMM (not neccessarilly HIMEM) at config.sys and at command line is that at config.sys, _when DOS=HIGH_ present, DOS reuses HMA after loading MD We were talking about EMM386. We talking both about himem and emm386. At least, this paragraph was answer to your paragraph, where you discuss himem. MD There is an explicit reference to EMM386 in MD Bernd's message, my reply, your reply, and my reply again. In skipped part: EMM386 (and HIMEM), HIMEM delayed loading (not EMM386). Which difference in forcing protected mode at config.sys stage of _DOS session_ and command line stage of DOS session? MD It's the difference between forcing virtual 8086 mode on all programs MD running under DOS, including already loaded device drivers/TSRs, and MD switching into protected mode for a single program to execute. Most (99.99%) of programs doesn't deal with extended memory or deal with it through XMS/EMS. Remained part of programs either conforms allocate memory from top (modern ramdisks, for example) or not conforms (vdisk). Of course, with non-conforming (ill-behaved) programs himem will hang. But why you think that I say himem may be loaded _at any time_, even after non-conforming programs? No! I say: XMM may be loaded at command line, even though non-conforming programs anyway should be loaded after it. Again, see the difference: I not say XMM may be loaded after any possible program, I say XMM may be loaded at command line (ie. _difference between config.sys and command line_ is only in dos=high). Same for emm386 - I _not_ say, that protected mode manager may/should be loaded after program, which directly deals with CPU descriptors (SB drivers?). I say, that EMM may be loaded at command line. Of course, unless there is loaded non-conforming program/driver. But last sentence is equal for alone config.sys also - you may load any driver before emm386, unless it non-conforming. MD Plus the rest of the differences I posted. MD directly accessing extended memory handles and configuring memory maps, DOS doesn't access extended memory. MD HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean MD after loading device drivers of varying allocations, the DOS shell, and MD various AUTOEXEC TSRs. Yes. But I say about difference between config.sys and command line, not about difference between loading himem/emm386 before or after other programs. Let example config.sys and autoexe.bat: __O\_/_\_/O__ device=himem.exe device=emm386.exe _ O/~\ /~\O __O\_/_\_/O__ @echo off prompt $p$g _ O/~\ /~\O Now, if you move XMS and EMM loading to autoexec: __O\_/_\_/O__ _ O/~\ /~\O __O\_/_\_/O__ @echo off prompt $p$g XMSload EMMload _ O/~\ /~\O - where you get here non-clean memory map? MD plus remapping blocks of memory after a bunch of drivers Isn't memory remapped only in UMA, which not used before EMM386? And what prevents to load drivers in config.sys before emm386? MD Device drivers don't use UMBs? Themselves? No. MD They don't allocate memory outside of the DOS memory map? Which memory allocates ansi.sys? Or, what wrong if some program allocates extended memory from top and traps INT15 functions, which reports size of free memory? MD TSRs neither? Sure, if they were all written for 8086 MD only. Otherwise, you damn betcha they do. Of course, with non-conforming programs XMM/EMM can't be
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Arkady V.Belousov schreef: MD HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean MD after loading device drivers of varying allocations, the DOS shell, and MD various AUTOEXEC TSRs. Yes. But I say about difference between config.sys and command line, not about difference between loading himem/emm386 before or after other programs. Let example config.sys and autoexe.bat: HIMEM and EMM386 blank (wipe out) the XMS contents? FDXMS also? in that case FreeCOM would probably crash quite soon, as it uses XMS to store quite a large part of its data. @echo off prompt $p$g XMSload EMMload _ O/~\ /~\O - where you get here non-clean memory map? There's no difference. Michael simply (and for good reason) doesn't want to look at earlier drivers. Normally that's a perfect possibility, as before these drivers only the kernel is loaded. Bootimages in RAM are about the only thing that these drivers would have to consider when loading (boot-from-network, and Syslinux's MEMDISK program). No. XMSMGR proves, that there are no barrier to load XMS at command line. I know limitation of XMSMMGR is like FDXMS286: 16MB or 64MB limit, probably only XMS2.0 API. If you ommit words stripped-down - then yes, this is what I mean. Stripped down indeed, but that seems to be MS policy. I could try loading FDXXMS.SYS instead commandline, but storing 3 memory managers (HIMEM most advanced and most compatible, FDXMS286 for 286systems, FDXXMS for 64+ MB systems) in a single bootdisk is too much. Of course! But this is possible! And I mean this, and only this. It is possible for several drivers, and should NOT be a requirement/argument for other drivers that have the same functionality. Nice theoretic/academic discussion though about commandline device driver loading :) Moral of the story: -theoretically possible to load memory drivers from the commandline -sometimes also technically supported (FDXMS, XMSMMGR) -know what you're doing and test if everything works OK. -don't complain to maintainers/authors of the memory drivers if you're not loading the drivers in config.sys Bernd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Hi! 9-Окт-2005 13:49 [EMAIL PROTECTED] (Bernd Blaauw) wrote to freedos-user@lists.sourceforge.net: Yes. But I say about difference between config.sys and command line, not about difference between loading himem/emm386 before or after other programs. Let example config.sys and autoexe.bat: BB HIMEM and EMM386 blank (wipe out) the XMS contents? Before himem, there are no XMS. EMM also (should) not clears XMS. @echo off XMSload EMMload - where you get here non-clean memory map? BB There's no difference. Michael simply (and for good reason) doesn't want BB to look at earlier drivers. And this is not need, as currently: __O\_/_\_/O__ device=ansi.sys device=himem.exe device=emm386.exe _ O/~\ /~\O Where here looking for previous drivers? BB Normally that's a perfect possibility, as BB before these drivers only the kernel is loaded. ...with some builtin drivers (like CON). BB Bootimages in RAM are BB about the only thing that these drivers would have to consider when BB loading (boot-from-network, and Syslinux's MEMDISK program). Is current fdhimem and fdemm386 do this? No. XMSMGR proves, that there are no barrier to load XMS at command line. BB I know limitation of XMSMMGR is like FDXMS286: 16MB or 64MB limit, BB probably only XMS2.0 API. This is practical limit (there was not need to implement full XMS), not theoretical. If you ommit words stripped-down - then yes, this is what I mean. BB Stripped down indeed, but that seems to be MS policy. I could try BB loading FDXXMS.SYS instead commandline, BB but storing 3 memory managers (HIMEM most advanced and most compatible, BB FDXMS286 for 286systems, BB FDXXMS for 64+ MB systems) in a single bootdisk is too much. Yes. And this is also another topic. BTW, what wrong with HIMEM instead FDXXMS? --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Bernd Blaauw escribió: Arkady V.Belousov schreef: MD HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean MD after loading device drivers of varying allocations, the DOS shell, and MD various AUTOEXEC TSRs. Yes. But I say about difference between config.sys and command line, not about difference between loading himem/emm386 before or after other programs. Let example config.sys and autoexe.bat: HIMEM and EMM386 blank (wipe out) the XMS contents? FDXMS also? in that case FreeCOM would probably crash quite soon, as it uses XMS to store quite a large part of its data. Well, I don't think it will allocate to XMS before there's a XMS driver installed ;-) Aitor --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Hi! 8-Окт-2005 16:37 [EMAIL PROTECTED] (Michael Devore) wrote to freedos-user@lists.sourceforge.net: MD We've discussed loading HIMEM at the DOS prompt after CONFIG.SYS processing MD before, too. It's a bad idea that could easily open the floodgates of bug MD reports for people wondering why their drivers aren't loading or working MD properly, and why XMS/EMS memory or HMA/UMBs are missing or MD misbehaving. If himem/emm386 will complain something like 80386 required to run (both at command line and, especially, in config.sys) instead hanging/aborting/misbehaving (as now), this will be much better and prevents floodgates. MD As the front line guy taking most of the tech support on EMM386 (and MD HIMEM), I herewith state that you are incorrect. HIMEM delayed loading I _not_ say about loading HIMEM from command line, I say about CPU detection and preventing load on too old CPUs. Though, I myself think, there is nothing wrong in loading XMS after DOS load - this will be similar to loading DOS without DOS=HIGH. Ie. XMS will be available to applications, whereas DOS itself doesn't uses it. MD (not EMM386) might have limited utility for a narrow set of circumstances, MD but not as a general feature. But until someone else takes over and makes MD the mistake of thinking that normal delayed loading of low-level memory MD managers post-DOS shell is a good thing -- I think, this is _not wrong_ thing. Ie., this feature may have limited usefulness, but there nothing wrong. MD and subsequently pays the price MD for their misunderstanding -- it's not going to happen. If and when it MD does, I hope I'm not around to see that particular train wreck. May you explain, where you see there wreck? Difference between loading of XMM (not neccessarilly HIMEM) at config.sys and at command line is that at config.sys, _when DOS=HIGH_ present, DOS reuses HMA after loading XMM (and starts to control A20). When DOS=HIGH is missing, there are no differences (ie. loading XMM at command line adds another function to extended memory beside INT15). MD As far as EMM386, I am not sure one could ever reliably load EMM386 at the MD command prompt post CONFIG.SYS drivers and COMMAND shell, plus a scattering MD of AUTOEXEC TSRs. I am sure I don't want to try. Why not? This will be same, as loading in config.sys without dos=umb. MD Dynamically under a DOS session forcing a machine from real to V86 mode, Which difference in forcing protected mode at config.sys stage of _DOS session_ and command line stage of DOS session? BTW, DOS extenders runs protected mode at command line and there are no prevents for this from DOS side. MD directly accessing extended memory handles and configuring memory maps, DOS doesn't access extended memory. MD plus remapping blocks of memory after a bunch of drivers Isn't memory remapped only in UMA, which not used before EMM386? And what prevents to load drivers in config.sys before emm386? MD and the kernel has loaded, and probably other issues I forgot, is MD the same as loading CONFIG.SYS with no dos=umb? Yes. If dos=umb is missing, then DOS doesn't checks (includes into MCB chain) UMBs, if they appear after loading some driver (emm386, umbpci, etc). Other differences between DOS stages (config.sys or command line) doesn't exist. MD A number of device drivers and TSR's might not MD agree with this assertion, Which this assertion? Programs (applications) just use INT67 - and where difference if this interface appear at config.sys or command line stage? MD even assuming COMMAND.COM does. And that's not MD counting the significant number of code rewrites need to make the delayed MD load process as stable as possible. Probably, current fdemm386 2.06 checks at which stage it loaded (config.sys or devload at command line), but there is no reasons for this. MD Did you think that perhaps it's not so simple since nothing at all in the MD DOS world normally manages memory this way? Don't understand this sentence, but if you mean why ms-himem and ms-emm386 are .sys, not .exe. then answer is simple - because loading himem and emm386 at command line is less useful (DOS process dos=high and dos=umb only at config.sys). There are no other reasons - and xmsmgr.exe, which loads XMM at command line, proves this. But again: I not require immediate implement loading XMS and EMS at command line, I just say, that there no preventations for this. And I agree with Eric - checks for 386 (which already present in fdhimem and fdemm386) should be fixed. MD Alternatively, you, Arkady V.Belousov, could add basic configurability to MD the kernel code for conditional parsing of CONFIG.SYS. And how this should be look? Drivers doesn't return errorlevels, whereas INSTALL= executed after DEVICE=. MD It is an idea which MD passes the test of rational behavior with an overall increase in OS power MD for everyone. Plus, it shouldn't be a
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 03:01 AM 10/9/2005 +0400, Arkady V.Belousov wrote: MD As the front line guy taking most of the tech support on EMM386 (and MD HIMEM), I herewith state that you are incorrect. HIMEM delayed loading I _not_ say about loading HIMEM from command line, I say about CPU detection and preventing load on too old CPUs. Your last message said that aborting EMM386 and HIMEM 80386-check would be much better and prevent a floodgate of errors. It wouldn't; it has nothing to do with delayed loading of the memory managers.. May you explain, where you see there wreck? Difference between loading of XMM (not neccessarilly HIMEM) at config.sys and at command line is that at config.sys, _when DOS=HIGH_ present, DOS reuses HMA after loading We were talking about EMM386. There is an explicit reference to EMM386 in Bernd's message, my reply, your reply, and my reply again. Which difference in forcing protected mode at config.sys stage of _DOS session_ and command line stage of DOS session? It's the difference between forcing virtual 8086 mode on all programs running under DOS, including already loaded device drivers/TSRs, and switching into protected mode for a single program to execute. Plus the rest of the differences I posted. MD directly accessing extended memory handles and configuring memory maps, DOS doesn't access extended memory. HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean after loading device drivers of varying allocations, the DOS shell, and various AUTOEXEC TSRs. MD plus remapping blocks of memory after a bunch of drivers Isn't memory remapped only in UMA, which not used before EMM386? And what prevents to load drivers in config.sys before emm386? Device drivers don't use UMBs? They don't allocate memory outside of the DOS memory map? TSRs neither? Sure, if they were all written for 8086 only. Otherwise, you damn betcha they do. Yes. If dos=umb is missing, then DOS doesn't checks (includes into MCB chain) UMBs, if they appear after loading some driver (emm386, umbpci, etc). Other differences between DOS stages (config.sys or command line) doesn't exist. What do you think just loaded all over real and extended memory with CONFIG.SYS and COMMAND.COM[.EXE] and AUTOEXEC.BAT? Don't understand this sentence, but if you mean why ms-himem and ms-emm386 are .sys, not .exe. then answer is simple - because loading himem and emm386 at command line is less useful (DOS process dos=high and dos=umb only at config.sys). There are no other reasons - and xmsmgr.exe, which loads XMM at command line, proves this. Nonsense. You say XMSMMGR proves that HIMEM and EMM386 are only loaded first for DOS=HIGH and DOS=UMB purposes? There is no logical rigor to that assertion whatsoever. What it proves is that, under some circumstances where you don't have conflicting drivers and applications, you can load a stripped-down extended memory manager at the DOS prompt. That's not a terribly useful capability for most people. And how this should be look? Drivers doesn't return errorlevels, whereas INSTALL= executed after DEVICE=. Perhaps you could have it conditional on a register return value from an application, or on device driver name existence. Why does conditional processing have to depend on errorlevels from existing device drivers which are written to MS-DOS-only level of awareness? For my part, I am done arguing whether HIMEM and EMM386 only are needed in CONFIG.SYS instead of DOS prompt to facilitate DOS=HIGH,UMB handling. I consider the presence of other major differences self-evident given any serious attention to the details. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Many thanks, Blair. Just one word on the list: I know what some people may be thinking of some of the items there. I would like to suggest that the list be used to track the features that are not available in FreeDOS and are not to be implemented in FreeDOS in a short time or even never (e.g. DISKCOPY /1). Aitor -- Original Message - Subject: [Freedos-user] FreeDOS Post-1.0 todo list Date: Mon, 3 Oct 2005 23:19:53 -0700 From: Blair Campbell [EMAIL PROTECTED] To: FreeDOS User Freedos-user@lists.sourceforge.net Hi. Just wanted to let everyone know that I've copied the Post-1.0 todo list to the FreeDOS wiki so that everyone can view and edit the list of items. It is available at: http://wiki.fdos.org/Main/Post_1_0_Todo --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 11:19 PM 10/3/2005 -0700, Blair Campbell wrote: Hi. Just wanted to let everyone know that I've copied the Post-1.0 todo list to the FreeDOS wiki so that everyone can view and edit the list of items. It is available at: http://wiki.fdos.org/Main/Post_1_0_Todo No way I can see to discuss a page so that I can record a comment, for example, that notes most of the remaining EMM386 option to-do list is unnecessary, superseded, or no longer applicable. Not appropriate to just yank them out of there unilaterally. And pretty much the same with HIMEM. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
Michael Devore schreef: No way I can see to discuss a page so that I can record a comment, for example, that notes most of the remaining EMM386 option to-do list is unnecessary, superseded, or no longer applicable. Not appropriate to just yank them out of there unilaterally. And pretty much the same with HIMEM. The page should have a text Improvement ideas for external contributors (developers don't care for this specific feature, or have no time) No maintainer/contributor is expected to do everything by himself, that would be ridiculous. You've already implemented 98% or so of XMS and UMB/EMS drivers. Nonetheless, commandline compatibility would be nice, just let developers do what Jason Hood did: implement the switches, without any logic behind them. + ignore unsupported MSCDEX options (/E/K/S/M) it's important to see the difference between a ToDo and a Wish list, and that's not 100% clear from these lists yet. I'm also messing a bit around with the Wiki, it's quite fun but time consuming. Bernd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
