freedos sourceforge ticket parade

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

freedos sourceforge ticket parade

Eric Auer-3

Hi everybody, it seems that tickets on sourceforge easily get
forgotten (to be honest, I also check only email, not websites).

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

https://sourceforge.net/p/freedos/bugs/151/ sys seems to fail to
update the boot sector or mbr (?) (may 2016)

https://sourceforge.net/p/freedos/bugs/147/ interlnk failure
(feb 2016) tom lists a patch, where in the pipeline is the patch?

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

https://sourceforge.net/p/freedos/bugs/142/ mode stop=2 failure
rugxulo commented on the ticket but fails to link the fixed mode

https://sourceforge.net/p/freedos/bugs/106/ ludivmul.inc issue
vaguely remember the 2013 discussion, but what was the conclusion??

https://sourceforge.net/p/freedos/bugs/97/ boot sector crash instead
of message if kernel not found, c. masloch offers a patch here...

https://sourceforge.net/p/freedos/bugs/96/ edit 0.9a right alt versus
alt gr issue, apparently forgotten since 2014, reported 2012?

https://sourceforge.net/p/freedos/bugs/92/ welcome screen of distro
mis-spells pasquale villani as pasqualle...

https://sourceforge.net/p/freedos/bugs/88/ set /p fails to close pipe,
leading to creative sources of problems :-p

https://sourceforge.net/p/freedos/bugs/79/ something about kernel
and shell version names being confusing...

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...

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

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?

https://sourceforge.net/p/freedos/bugs/55/ sys fails to update the
fat32 BACKUP boot sector, has that been fixed between 2010 and now?

https://sourceforge.net/p/freedos/bugs/45/ confusion about whether
C: is your boot USB stick or your harddisk, very weak description!

https://sourceforge.net/p/freedos/bugs/44/ kernel 2039 fat32 cross
linkage issue with discussion of a patch for 2040, any news here??

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?

https://sourceforge.net/p/freedos/bugs/29/ discussion whether xcopy
should copy timestamps while copying and under which conditions...

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??

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!)

https://sourceforge.net/p/freedos/feature-requests/63/ WISH 2.88 mb
floppy image (answer: rugxulo has one and i probably have a copy!)

https://sourceforge.net/p/freedos/feature-requests/62/ duplicate of #63

https://sourceforge.net/p/freedos/feature-requests/61/ WISH live CD
we probably made one since 2012, or not?

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!

https://sourceforge.net/p/freedos/feature-requests/55/ WISH greek i18n
basically greek font/keyb are supported but most translations absent?

https://sourceforge.net/p/freedos/feature-requests/52/ WISH edit window
tiling... sounds like something that edit can probably already do now?

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?

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://sourceforge.net/p/freedos/feature-requests/38/ WISH Euphoria
programming language support, 2007, totally forgotten after 2011??

https://sourceforge.net/p/freedos/feature-requests/15/ WISH network
printing or rather dosemu printing, discuss in dosemu group instead!

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.

https://sourceforge.net/p/freedos/feature-requests/7/ WISH usb printer
joystick serial device support, basically solved by Bret's drivers :-)

Thanks for updating and closing all those tickets before they collect
even more virtual dust and make our sourceforge page too depressing ;-)

Cheers, Eric


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: freedos sourceforge ticket parade

Rugxulo
Hi,

On Wed, Aug 24, 2016 at 4:56 PM, Eric Auer <[hidden email]> 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/7705c9030712260747i328f25d3y9c8cf9a590eeca70@.../

> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: freedos sourceforge ticket parade

tom ehlert
Hi,

>> 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".

EMM386 is useful because it provides upper memory. having more memory
below 1 MB is very useful for real mode operating systems.




>> 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



>> 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

this is about an operating system bug. having a workaround doesn't
solve the bug.

btw: best workaround is 'use a serious operating system'


> N.B. An old FD technote suggests using File Maven instead:

> http://www.freedos.org/technotes/technote/archive/108.html

this sucks. File Maven is in no way a replacement for interlnk; just
like FTP is not a replacement to a network drive.



>> https://sourceforge.net/p/freedos/bugs/92/ welcome screen of distro
>> mis-spells pasquale villani as pasqualle...

> Trivial, should be closed.
should be CORRECTED, then 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.)

nothing of FreeCOM is exactly actively maintained. Are you suggesting
to no longer fix bugs?
or are you suggesting that *you* are not able/interested/... to fix
bugs.



>> 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).
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.'



>> 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 .)
BS. XCOPY should work like expected. read the manifest.


>> 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.


>> 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.


this project is in real bad shape.

Tom


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: freedos sourceforge ticket parade

Steve Nickolas-2
On Thu, 25 Aug 2016, Tom Ehlert wrote:

> this project is in real bad shape.

*nod*

I get the feeling that the core elements of FreeDOS are long rotted away.

Unfortunately, these days there's really not a lot I can do about it
because since the days I had my hands busy working on FreeDOS - which
wasn't much, to be fair - I've had my eyes in places, so even if I had the
knowledge with which to do something about it...I really can't. :/

-uso.

------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: freedos sourceforge ticket parade

tom ehlert
In reply to this post by tom ehlert
>>> 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.)

> nothing of FreeCOM is exactly actively maintained. Are you suggesting
> to no longer fix bugs?
> or are you suggesting that *you* are not able/interested/... to fix
> bugs.

also: with world.txt containing

world1
world2
01.12.2016

execute

set /p hello1=<world.txt
set /p hello2=<world.txt
date

echo %hello1%
echo %hello2%
echo %date%






should be fixed by maintainer; results from freely mixing

open()/dup() for file redirection, and fgets() for actual input
processing

fix: SHELL\COMMAND.C

 int oldinfd = -1;       /* original file descriptor #0 (stdin) */
 int oldoutfd = -1;        /* original file descriptor #1 (stdout) */
+long oldstdinpos;

...

  if (in || (num > 1))          /* Need to preserve stdin */
    {
    oldinfd = dup(0);
+   oldstdinpos = ftell(stdin);
    }
...


  if (oldinfd != -1)            /* Restore original STDIN */
  {
    close(0);
    dup2(oldinfd, 0);
+   fseek(stdin, oldstdinpos, SEEK_SET );

    close(oldinfd);
    oldinfd = -1;
  }





now I'm wondering how long it takes for

a) a new version of command.com on the website,

b) updateable by the famous FreeDOS 1.0 package management process,

c) updateable by the famous FreeDOS 1.1 package management process, which is different

d) updateable by the famous FreeDOS 1.2 package management process,
which is probably different, again




Tom







------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: freedos sourceforge ticket parade

Rugxulo
In reply to this post by tom ehlert
Hi,

On Thu, Aug 25, 2016 at 1:13 PM, Tom Ehlert <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Road to Perdition

tom ehlert
In reply to this post by tom ehlert

got today a mail relating to FREECOM (one of the things that are
better then MSDOS, according to http://wiki.freedos.org/wiki/index.php/Main_Page

'Der 0.84-pre2 Build Jul 17 2011 21:46:46 und der
aktuellste Jul 19 2014 14:14:47 unterstützen kein LOADHIGH, beim
Versuch TSRs zu laden brechen sie mit "MCB chain corrupt [...] ab.
Nur die historische Aug 28 2006 00:29:00-Release kann per LOADHIGH
hochladen, enthält aber viele andere Bugs.'

(google translate) --> The 0.84-pre2 Build July 17 2011 21:46:46 and
date July 19 2014 14:14:47 not support LOADHIGH, when
load test TSRs they break with "MCB chain corrupt [...].
Only the historic August 28 2006 00: 29: 00 release can be made by LOADHIGH
Upload, but includes many other bugs.'

ok. easy. locate freecom, try to reproduce, then fix.

goto freedos.org.
'software list'
'base'

shows 'command 0.84pre2'. great. found it.
on normal websites, there would be a 'download' link.

on this great website, klicking this leads
to   http://freedos.sourceforge.net/ which is a redirect link to
http://wiki.freedos.org/wiki/index.php/Main_Page, which has no
download whatsoever.

alternate site
  http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/
holds nothing younger then 2006.

with some patience (and a little ingenuity) I even located http://www.fdos.org/kernel/

with http://www.fdos.org/kernel/command/, and could reproduce the bug.
unfortunately, no source.

so much about GPLvanything.

where can I find the source for command 0.84pre2, and why is this not
reachable from Freedos.org ?

Tom


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

Jim Hall-2
This is unfortunate. The most recent release should always be available from:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/

I'm not able to run DOS programs where I'm at right now (work) so I
can't run this to check version number:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/base/command.zip

If that's the correct new version (it should be the version from the
latest FreeDOS 1.2 pre-release) then we can copy this into the
ibiblio.../dos/command/ download area.


Jim



On Thu, Sep 29, 2016 at 7:54 AM, Tom Ehlert <[hidden email]> wrote:

>
> got today a mail relating to FREECOM (one of the things that are
> better then MSDOS, according to http://wiki.freedos.org/wiki/index.php/Main_Page
>
> 'Der 0.84-pre2 Build Jul 17 2011 21:46:46 und der
> aktuellste Jul 19 2014 14:14:47 unterstützen kein LOADHIGH, beim
> Versuch TSRs zu laden brechen sie mit "MCB chain corrupt [...] ab.
> Nur die historische Aug 28 2006 00:29:00-Release kann per LOADHIGH
> hochladen, enthält aber viele andere Bugs.'
>
> (google translate) --> The 0.84-pre2 Build July 17 2011 21:46:46 and
> date July 19 2014 14:14:47 not support LOADHIGH, when
> load test TSRs they break with "MCB chain corrupt [...].
> Only the historic August 28 2006 00: 29: 00 release can be made by LOADHIGH
> Upload, but includes many other bugs.'
>
> ok. easy. locate freecom, try to reproduce, then fix.
>
> goto freedos.org.
> 'software list'
> 'base'
>
> shows 'command 0.84pre2'. great. found it.
> on normal websites, there would be a 'download' link.
>
> on this great website, klicking this leads
> to   http://freedos.sourceforge.net/ which is a redirect link to
> http://wiki.freedos.org/wiki/index.php/Main_Page, which has no
> download whatsoever.
>
> alternate site
>   http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/
> holds nothing younger then 2006.
>
> with some patience (and a little ingenuity) I even located http://www.fdos.org/kernel/
>
> with http://www.fdos.org/kernel/command/, and could reproduce the bug.
> unfortunately, no source.
>
> so much about GPLvanything.
>
> where can I find the source for command 0.84pre2, and why is this not
> reachable from Freedos.org ?
>
> Tom
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freedos-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

tom ehlert

> This is unfortunate. The most recent release should always be available from:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/
it's not

> I'm not able to run DOS programs where I'm at right now (work) so I
> can't run this to check version number:

no need to run dos programs.

there is a 'last modification date' for files.

nothing in
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command is
more recent then 2006.

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/base/command.zip

> If that's the correct new version (it should be the version from the
> latest FreeDOS 1.2 pre-release) then we can copy this into the
> ibiblio.../dos/command/ download area.

the binaries are  2006.

the source file modification dates were trashed on 17 august 2006.


Tom




> Jim



> On Thu, Sep 29, 2016 at 7:54 AM, Tom Ehlert <[hidden email]> wrote:
>>
>> got today a mail relating to FREECOM (one of the things that are
>> better then MSDOS, according to http://wiki.freedos.org/wiki/index.php/Main_Page
>>
>> 'Der 0.84-pre2 Build Jul 17 2011 21:46:46 und der
>> aktuellste Jul 19 2014 14:14:47 unterstützen kein LOADHIGH, beim
>> Versuch TSRs zu laden brechen sie mit "MCB chain corrupt [...] ab.
>> Nur die historische Aug 28 2006 00:29:00-Release kann per LOADHIGH
>> hochladen, enthält aber viele andere Bugs.'
>>
>> (google translate) --> The 0.84-pre2 Build July 17 2011 21:46:46 and
>> date July 19 2014 14:14:47 not support LOADHIGH, when
>> load test TSRs they break with "MCB chain corrupt [...].
>> Only the historic August 28 2006 00: 29: 00 release can be made by LOADHIGH
>> Upload, but includes many other bugs.'
>>
>> ok. easy. locate freecom, try to reproduce, then fix.
>>
>> goto freedos.org.
>> 'software list'
>> 'base'
>>
>> shows 'command 0.84pre2'. great. found it.
>> on normal websites, there would be a 'download' link.
>>
>> on this great website, klicking this leads
>> to   http://freedos.sourceforge.net/ which is a redirect link to
>> http://wiki.freedos.org/wiki/index.php/Main_Page, which has no
>> download whatsoever.
>>
>> alternate site
>>   http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/
>> holds nothing younger then 2006.
>>
>> with some patience (and a little ingenuity) I even located http://www.fdos.org/kernel/
>>
>> with http://www.fdos.org/kernel/command/, and could reproduce the bug.
>> unfortunately, no source.
>>
>> so much about GPLvanything.
>>
>> where can I find the source for command 0.84pre2, and why is this not
>> reachable from Freedos.org ?
>>
>> Tom
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freedos-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel

> ------------------------------------------------------------------------------
> _______________________________________________
> Freedos-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

Jerome Shidel
Hello Tom, 


On Sep 29, 2016, at 1:07 PM, Tom Ehlert <[hidden email]> wrote:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/base/command.zip

If that's the correct new version (it should be the version from the
latest FreeDOS 1.2 pre-release) then we can copy this into the
ibiblio.../dos/command/ download area.

the binaries are  2006.

the source file modification dates were trashed on 17 august 2006.


That appears to be correct. This version reports:

FreeCOM version 0.84-pre2 XMS-Swap [Aug 28 2006 00:29:00]

0.84pre2 is from 2006. So, if there is a version from 2011, is it possible it is a
later version (something like 0.84pre2b)? Or, possible a custom fork of the
original 0.84pre2?

Jerome

------------------------------------------------------------------------------

_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

perditionc
In reply to this post by tom ehlert
On Thu, Sep 29, 2016 at 8:54 AM, Tom Ehlert <[hidden email]> wrote:
>
...
> with some patience (and a little ingenuity) I even located http://www.fdos.org/kernel/
>
> with http://www.fdos.org/kernel/command/, and could reproduce the bug.
> unfortunately, no source.
>

This is an unmodified build from svn  (downloaded based on compile
date July 2011).  The source is available in several zips (all the
same source) e.g.
http://www.fdos.org/bootdisks/autogen/FDOEM_src.zip
http://www.fdos.org/bootdisks/autogen/FDSTD_src.zip

And source is always available by sending a request to me.  I try to
ensure the source is available next the binary builds, but in the case
I uploaded the command.com files as a convenience for me and never got
around to putting the source right next to it.  You are the first
person in 5 years to ask for the source from this particular download
location.

> so much about GPLvanything.
>
> where can I find the source for command 0.84pre2, and why is this not

this is just the SVN sources

> reachable from Freedos.org ?

The sourceforge svn source site used to be available linked from
FreeDOS.org, though I haven't checked in a while if this is still
true.

>
> Tom
>

Jeremy

------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

Matej Horvat
In reply to this post by tom ehlert
On Thu, 29 Sep 2016 14:54:49 +0200, Tom Ehlert <[hidden email]> wrote:

> (google translate) --> The 0.84-pre2 Build July 17 2011 21:46:46 and
> date July 19 2014 14:14:47 not support LOADHIGH, when
> load test TSRs they break with "MCB chain corrupt [...].
> Only the historic August 28 2006 00: 29: 00 release can be made by
> LOADHIGH
> Upload, but includes many other bugs.'

This is one of several bugs that occurs if FreeCOM is compiled with Open  
Watcom. Is that the case here?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Road to Perdition

perditionc

On Oct 1, 2016 2:59 PM, "Matej Horvat" <[hidden email]> wrote:
>
> >
...
>
> This is one of several bugs that occurs if FreeCOM is compiled with Open
> Watcom. Is that the case here?
>

Yes, I usually compile with Open Watcom; whether it's the cause of issues or not, I haven't looked into it.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Loading...