Hi, On Thu, Aug 25, 2016 at 1:13 PM, Tom Ehlert <t...@drivesnapshot.de> wrote: > >> Again, I don't see the point of loading (J)EMM386 (by default) at all >> since many machines seem to have problems with it. > > EMM386 is useful because it provides upper memory. having more memory > below 1 MB is very useful for real mode operating systems.
I know that, but so many end users seem to think they need it loaded 100% of the time, which is false. It just has too many problems (on some machines) to load "by default". I'm not opposed to including it, just maybe we shouldn't be insanely overzealous and recommend it if we don't direly need to save a few extra kb. >>> https://sourceforge.net/p/freedos/bugs/151/ sys seems to fail to >>> update the boot sector or mbr (?) (may 2016) > >> Same dude as previously, using old (unsupported) FD 1.0. Probably >> should give same resolution (and close!). > > FreeDOS system installer AUG 10 2011. certainly not FD 1.0 Okay, mea culpa, but why is he reporting both 1.0 (2006) and 1.1?? These bugs were both reported a day apart. Is it reasonable for anyone to still be actively reporting bugs on FD 1.0?? (I'm not really violently opposed, but it's hard not to be a bit pessimistic.) EDIT: This same person also opened #154 "Create FreeDos bootfloppy fake success", which I never heard of, which apparently has me as "Owner" (there's a first time for everything!). I'm surprised but not surprised. Of course I know where to find "extract" online, I've pointed to it before, but that's not much real help. >>> https://sourceforge.net/p/freedos/bugs/147/ interlnk failure >>> (feb 2016) tom lists a patch, where in the pipeline is the patch? > >> DEVICE=C:\UTIL\INTERLNK.EXE /AUTO /NOPRINTER /LOW > > this is about an operating system bug. having a workaround doesn't > solve the bug. So you're waiting for Jeremy to fix this and release a newer kernel? > btw: best workaround is 'use a serious operating system' Which one? And does it support EMM386? /s :-P >>> https://sourceforge.net/p/freedos/bugs/88/ set /p fails to close pipe, >>> leading to creative sources of problems :-p > >> "set /p" is non-standard, and FreeCOM is not exactly actively >> maintained, so probably close as "wontfix". > > nothing of FreeCOM is exactly actively maintained. Are you suggesting > to no longer fix bugs? Go ahead. Fix and recompile and upload it yourself. I'll wait! (Yes, I see you posted a very minor patch for "set /p". Do you need our help??) > or are you suggesting that *you* are not able/interested/... to fix bugs. I have Turbo C++ locally, but no, I don't feel comfortable to rebuild such a horrible behemoth. And I'm not volunteering to be maintainer either (and apparently no one else is either). It could definitely use some minor cleanups and fixes, but honestly it's just too brittle and there's too many files. Ugh. Even the OpenWatcom port was (more) buggy, IIRC. >>> https://sourceforge.net/p/freedos/bugs/63/ some interesting but totally >>> forgotten xms related lbacache failure on via c7 cpu, unlikely to be >>> ever looked at unless somebody has a via c7 to test... > >> Just close it, we can't confirm it or test it anyways > > should be closed. not because of market share, but because the bug report > ends with > 'I got mail again, problem solved, and I still can't answer. > Please CLOSE this BUG.' If no one has a VIA C7 to test, then there's not much we can do anyways. It's fairly hard to find in the wild. >>> https://sourceforge.net/p/freedos/bugs/29/ discussion whether xcopy >>> should copy timestamps while copying and under which conditions... > >> Probably should just use DJGPP Coreutils "cp -p" instead. > > BS. XCOPY should work like expected. read the manifest. Patches welcome. >>> https://sourceforge.net/p/freedos/feature-requests/61/ WISH live CD >>> we probably made one since 2012, or not? > >> With RUFUS (as mentioned), you can do live USB, which is similar >> functionality (and less cramped than floppy). Close this bug! > > there should be a live CD or a way to make a useful USB stick with > FreeDOS, without the need to install it. there is *no* excuse for the > having a live boot medium. Patches welcome. Anyways, from what storage medium (and host OS) do you wish to create this live USB? I don't think it's actively supported with DOS creator / host. If you intend to fix that, then great. Otherwise, why are you complaining? Would it be nice to have native support for everything? Of course, but I feel like this is not constructive criticism. As much as I truly hate to mention it, at least my silly MetaDOS floppy .img can be (indirectly) used in various ways (MKBISO or RUFUS) for a "live" setup (via RAM drive, albeit minimal tools by default) atop bootable CD or USB. I don't really have much hope for "better" than RUFUS (or UNetBootIn or that one guy's Linux blog [Joe Linoff]) regarding bootable USB. >>> https://sourceforge.net/p/freedos/feature-requests/56/ WISH boot USB >>> the current distro edition is offered as USB image as far as i know! > >> There are several (third-party) ways to do this already, and they are >> (semi-)well known. Close! > exactly. several, semi known. So what exactly needs to be "live"? CD? So we need a premade .iso? Although I agree (barely), it's not that hard to roll your own. (I know that's a horrible solution, but hey it's true.) What about Mateusz's .iso? Was it "live" (can't remember)? Jerome probably knows more about this (I admit to not understanding all the options there!). You do realize that it's very hard to please everyone, have total compatibility and testing. Just complying with licenses is a pain (mostly because of developer sloppiness and the inertia against constantly rebuilding). It's cheap to make excuses, but it's just too much work for us few. > this project is in real bad shape. No, not really. We've been underwhelmed for years, and there still aren't enough volunteers or programmers. But Jim Hall has done more than enough to keep it afloat. Whether you acknowledge or understand it or not, he really has put a lot of effort into maintaining the overall ecosystem, much more than most other people. So let's not complain too hard. Sure, we only get a few scraps here and there, but most stuff still "mostly" works, so we don't (necessarily) need to rewrite everything from scratch. It could be much, much worse. ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
