Hi, On Wed, Aug 24, 2016 at 4:56 PM, Eric Auer <[email protected]> wrote: > > Hi everybody, it seems that tickets on sourceforge easily get > forgotten (to be honest, I also check only email, not websites).
SF.net nowadays can email you if someone files a ticket. > So here is a list of tickets for which I believe that they can > get updated, closed or whatever. Please comment and update :-) > > https://sourceforge.net/p/freedos/bugs/153/ crash at dir change > (may 2016) probably general emm386 versus disk fail, file there Again, I don't see the point of loading (J)EMM386 (by default) at all since many machines seem to have problems with it. N.B. This (2016!) bug report is regarding FD 1.0 (2006), so it's probably pointless. As much as I hate to say it, the resolution should be "don't use EMM386" and/or "upgrade to 1.2-pre". > 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!). > https://sourceforge.net/p/freedos/bugs/147/ interlnk failure > (feb 2016) tom lists a patch, where in the pipeline is the patch? Jeremy said, "Tom's workaround will be in svn kernel soon, but I need to do some more testing as I'm still getting crashes ...". Ulrich claimed at that time that the following (esp. "/LOW") worked around the issue entirely: DEVICE=C:\UTIL\INTERLNK.EXE /AUTO /NOPRINTER /LOW N.B. An old FD technote suggests using File Maven instead: http://www.freedos.org/technotes/technote/archive/108.html > https://sourceforge.net/p/freedos/bugs/143/ boot failure on 286 > totally lacks details, hangs at "freedos123", maybe 386 kernel? > the ticket is basically worthless in the current form There aren't a lot of testers, esp. not for 286. In fact, I had problems even weakly trying to use FDXMS286 (admittedly not on an actual 286), so even that may not be reliable. Dunno .... > https://sourceforge.net/p/freedos/bugs/142/ mode stop=2 failure > rugxulo commented on the ticket but fails to link the fixed mode There was no fixed "mode", or at least it wasn't sent to me. IIRC, you had asked what other minor changes should go in before you published it. All I got from you was a very very tiny patch (which I converted to an extremely tiny binary patch in case the OP had trouble rebuilding sources). https://sourceforge.net/p/freedos/mailman/message/34698796/ > https://sourceforge.net/p/freedos/bugs/106/ ludivmul.inc issue > vaguely remember the 2013 discussion, but what was the conclusion?? (shrug) Dunno, would need further testing. Honestly, with modern gigahertz machines, it shouldn't be impossible to brute force test all variations. > https://sourceforge.net/p/freedos/bugs/97/ boot sector crash instead > of message if kernel not found, c. masloch offers a patch here... I don't see any actual patches available here. So either he never did it or it was already integrated in SVN. Ask Jeremy (or C. Masloch). > https://sourceforge.net/p/freedos/bugs/96/ edit 0.9a right alt versus > alt gr issue, apparently forgotten since 2014, reported 2012? Ask Aitor (or just close the bug if he's unavailable again). > https://sourceforge.net/p/freedos/bugs/92/ welcome screen of distro > mis-spells pasquale villani as pasqualle... Trivial, should be closed. > 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". (As much as I hate to say it, there's probably better tools to do similar functionality. Ask Jerome or take a look at J. Hoffman's DOSUTILS.) > https://sourceforge.net/p/freedos/bugs/79/ something about kernel > and shell version names being confusing... Trivial, should be closed. > 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, it's just way too obscure. AMD allegedly has 20% of the x86 market, but VIA has almost none (esp. for end users). > https://sourceforge.net/p/freedos/bugs/60/ usb boot failure with way > too little details in 2010, i suggest to drop that ticket as invalid Not a great bug report, probably should point to this and close: https://wiki.debian.org/FlashBIOS > https://sourceforge.net/p/freedos/bugs/57/ some 2010 lbacache stack > nesting problem on t61 and x61 laptops, anonymous reporter so unlikely > to ever get investigated, drop ticket? Considering they couldn't find you (even with help), thus no further reports, it's probably irrelevant. Just close it. > https://sourceforge.net/p/freedos/bugs/55/ sys fails to update the > fat32 BACKUP boot sector, has that been fixed between 2010 and now? Dunno, ask Jeremy. > https://sourceforge.net/p/freedos/bugs/45/ confusion about whether > C: is your boot USB stick or your harddisk, very weak description! Sounds like a BIOS bug, but OEM is not named. Close it! > https://sourceforge.net/p/freedos/bugs/44/ kernel 2039 fat32 cross > linkage issue with discussion of a patch for 2040, any news here?? Says fixed, so close it! N.B. IIRC, this is the NSSI detection tool dude, so while you could email him, I think it's easier to just close it and assume everything is fine (since he never further tested or complained). > https://sourceforge.net/p/freedos/bugs/31/ kernel 2038 int 24 issue > with plenty of details, but unclear if kernel bug or just app bug? Sounds DOSEMU specific. Close it! > 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. (See /current/v2gnu/fil41br2.zip .) > https://sourceforge.net/p/freedos/bugs/3/ ctmouse in freedos 1.0 distro > fails with bochs or qemu but "believed to be fixed in 2.1 beta 4 of > july 2008", any current bochs or qemu comments about that?? I don't use Bochs, but it seemingly works fine under VBox or QEMU (under limited testing, e.g. FPC's samegame). > https://sourceforge.net/p/freedos/bugs/4/ int 21.5a, then 21.3c leads > to dead cluster chain while ms dos seems to handle this hack better?? > (yes this was from 2008 / 2009 but i have no idea what we did then!) IIRC, not sure if this is the same bug, but one workaround for it was using it in the root dir! (MS-DOS v5 and v6 tmpfile quirks??) But it's fairly obscure, so probably not worth worrying much about. > https://sourceforge.net/p/freedos/feature-requests/63/ WISH 2.88 mb > floppy image (answer: rugxulo has one and i probably have a copy!) I don't have a physical drive of that type, but I still have that old file that you made once (not recommended though, very kludgy on my part): https://sites.google.com/site/rugxulo/eric-rugxulo288.zip?attredirects=0 > https://sourceforge.net/p/freedos/feature-requests/62/ duplicate of #63 Indeed. Close it! > 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! > 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! > https://sourceforge.net/p/freedos/feature-requests/55/ WISH greek i18n > basically greek font/keyb are supported but most translations absent? I still have this as a FDCONFIG.SYS boot option since then! And I don't even speak Greek! And nobody ever cared, so I never did much with my old "i18ndos" demo floppy. (Yet another floppy .img that nobody needed, too tedious to pack up everything with sources.) It would indeed be cool (or interesting) to have such a demo system setup for all such i18n things, but I'm afraid it's too niche to attract much attention. So interested end users have to roll their own (again). > https://sourceforge.net/p/freedos/feature-requests/52/ WISH edit window > tiling... sounds like something that edit can probably already do now? Dunno but extremely trivial suggestion. Close it! > https://sourceforge.net/p/freedos/feature-requests/41/ WISH boot sector > should treat bad cluster same as last cluster - at least some of our > boot sectors already do this, check the sources and close the ticket? Ask Jeremy. > https://sourceforge.net/p/freedos/feature-requests/40/ WISH 64k (floppy) > DMA boundary wrap trap int13 handler inside the kernel, seems rejected? > Note that this ticket also features a workaround TSR "lowdmaplus" ;-) > (website gone but file also provided along with ticket on sourceforge) https://www.auersoft.eu/soft/mixed/lowdmaplus.zip Should this be mirrored to iBiblio?? I don't see any mention of license. > https://sourceforge.net/p/freedos/feature-requests/38/ WISH Euphoria > programming language support, 2007, totally forgotten after 2011?? Way too obscure. It's already mirrored on iBiblio (although DOS version is long dead). Close it! > https://sourceforge.net/p/freedos/feature-requests/15/ WISH network > printing or rather dosemu printing, discuss in dosemu group instead! There was a 2007 discussion about network printing (mostly by M. Viste about LPT2FILE and JetDirect). Would that clarify? https://sourceforge.net/p/freedos/mailman/freedos-user/thread/[email protected]/ > https://sourceforge.net/p/freedos/feature-requests/12/ WISH usb drive > support, 2003 to 2004, mention now existing usb drivers and bios usb > legacy support and close that ticket if you ask me. Ugh. Close this immediately. Way too ambitious. Send Bret J. a pizza (saying "Thanks anyway"), give up such ridiculous false hope, and "just use Linux" (25 years and counting although technically USB came in 2.2 or 2.4, I forget which). > https://sourceforge.net/p/freedos/feature-requests/7/ WISH usb printer > joystick serial device support, basically solved by Bret's drivers :-) Ridiculous. Close it! > Thanks for updating and closing all those tickets before they collect > even more virtual dust and make our sourceforge page too depressing ;-) What is depressing is that all of the "interesting" stuff in modern computing needs a PhD just to program / access. This will be the death of hobby OSes. ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
