Hi, On Fri, Jul 12, 2013 at 10:00 AM, Bertho Grandpied <[email protected]> wrote: > Tom Ehlert <[email protected]> wrote : > >> I don't know know why this design decision was made, but >> this is one example of 'this not a bug, it's a feature' ;) > > = A /*mis*feature,/ maybe ! This time FreeDOS is not following MS, > MS DOS [7.1 for reference] does obey the operator's interactive choice > on SWITCHES.
BTW, a quick check of ke2041s.zip 's config.txt shows that SWITCHES supports these: /E /F /K /N (but /W is MS-DOS only). It's not something most people, including myself (admittedly not a kernel dev), are used to fiddling with. > Furthermore, the processing order of this directive > wrt config'ed DEVICES is different (not a bug per se). FreeDOS is already incompatible with its MENU setup. DR-DOS too. In fact, DR-DOS does a lot of little things differently (menus, even SWITCHES ... IIRC it doesn't support /F). Some stuff DR invented (HIDEVICE?), but MS chose to go an incompatible route with similar functionality (DEVICEHIGH), including order of devices loaded, drive letter assignment, etc. I'm just saying, in general, it gets a little confusing as there is no real official standard. MS-DOS may be the most widely known "DOS", but just following them (or not) doesn't guarantee 100% compatibility. AFAIK, FreeDOS does not try to 100% follow every minor MS-DOS detail. There may have been a patch, for instance, to support MS-style menus (a la MS-DOS 6), but AFAIK it was never officially integrated. > In sum, there is still a /bug/ around here: since the intent, and effect, of > the FreeDOS > code is that this and similar "pass 0" directives be executed > /inconditionally/ then Kernel /should'nt ask/ its Y/N question on them! I haven't bothered much lately to check, but it even differs across kernel versions. IIRC, kernel 2037 was vaguely different from 2036 in menus, perhaps starting at 0 in one and 1 in another. Well, my point is that nothing is fixed in stone. FreeDOS officially (IIRC) does not reject improvements as long as they don't break any functionality. > (4) The Kernel is confused and corrupts the MCB chain in > certain circumstances - rather than go on here, I think I'll > open a new thread for that apparently serious bug. I'm glad you're posting here. Feel free to discuss ad infinitum. :-) But I don't know how closely Tom is keeping track. Well, what I mean is that it's probably too much for one person alone to handle. Better to also post a bug report on SourceForge (though, yes, I know, there are some that have gone unanswered, but that's life, everyone is busy), just for clarity and completeness, to keep bugs together for easier reference. In particular, I don't know if Jeremy or Bart (or others) read this closely enough to be able to keep track and (potentially later) fix these issues. I would rather these "bugs" (or whatever you want to call them) didn't get forgotten about accidentally. (But I know it can be tedious to file a proper bug report for every little thing. I just think it may get a wider, more official audience, in theory.) ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
