Re: [Freedos-devel] Test email (June 6, 1pm US/Central)

[Johnpaul Humphrey]

> Sending a test message to see if this works.
Works for me!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Johnpaul Humphrey]

I second the OpenGEM sentiment. One of the things that makes DOS special to
me, is the simplicity, both of the API, and the usage. Lack of multitasking
is a plus for me, not a minus. (IIRC GEM supports some multitasking
though.) GEM does seem to have that simple, RAW, feel, and that's a good
thing IMHO.

I would probably not be too interested in a Windows 3.x clone, and I am
told that a lot of DOS admins hated it in the day, but it seems to fit the
spirit of the project more than oZone and seal, IMHO.
It still won't beat GEM though. :)

On Sun, Dec 27, 2020 at 3:07 PM Ralf Quint  wrote:

> On 12/27/2020 11:10 AM, Jim Hall wrote:
>
>
> The challenge we've had is lots of developers have wanted to create a GUI
> for FreeDOS, but then they get halfway through building one before they
> realize it's a lot of work. And then the project gets dropped. That leaves
> us with things like SEAL and oZone that look cool - until you look more
> closely and find a bunch of features that don't work. Or it hogs memory. Or
> whatever. And that brings us to the conversation we started here some weeks
> ago about removing some stale packages, like SEAL and oZone. I don't want
> to get into another situation like that.
>
> Well, that is the problem with all of those GUI attempts. Some people have
> grand ideas and start to create some nice colored pictures but none of them
> is seriously thinking about (before they start coding!) on all the basics
> "behind the scenes", to make things really work and being useful.
> And when you point this out to them, they quickly get all defensive and
> pissy...
>
> IMHO, anyone who is REALLY interested to get  a working GUI for FreeDOS
> working, should much rather looking into participating in getting (Open)GEM
> a little bit more up to date.
>
> Ralf
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_6282456411182112900_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>


-- 
Johnpaul T. Humphrey
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] beep implementation

[Johnpaul Humphrey]

Sorry for the late reply!

The regular bell character starts to beep, stops beeping after a short
time, and then lets me continue.
The freecom beep starts to beep, beeps forever (I presume, I haven't
tested it that long) and doesn't let me do anything else.
I was able to fix my copy via the hex editor. Maybe I will try to
compile from source, so I can update beep().
I am a little afraid of "fixing" it in the source code, because I am
not sure y'all would like my "fix".

On Wed, May 13, 2020 at 9:16 AM tom ehlert  wrote:
>
>
> > Thanks, I will try the patch out when I get a little time.
> patches are not too helpful in an open source OS.
>
>
> > The regular bell character doesn't hang, so I wonder why freecom
> > implements its own version.
>
> you aren't entirely clear in your bug description:
>
> does it start to beep, and then beeps and hangs indefinitively
>
>
> OR it starts to beep, and then beeps forever, but continues to work?
>
>
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



-- 
Johnpaul T. Humphrey


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] beep implementation

[Johnpaul Humphrey]

Thanks, I will try the patch out when I get a little time.
The regular bell character doesn't hang, so I wonder why freecom
implements its own version.

On Wed, May 13, 2020 at 3:20 AM Eric Auer  wrote:
>
> Hi Rugxulo,
>
> Thank you for your binary patch but...
>
> > 1). 2016-May-6: "[Freedos-devel] Beep command can't stop sounding when
> > run in Intel Skylelake platorm."
> > * https://sourceforge.net/p/freedos/mailman/message/35068370/
> >
> > 2). 2017-Jun-9: "#189 Beep function freezes on recently intel platform
> > (skylake/kabylake)"
> > * https://sourceforge.net/p/freedos/bugs/189/
>
> (because delay and sound use port 0x61, missing there)
>
> The latter sounds as if Bart has fixed the bug in 2018?
> Then why are we still using the old FreeCOM binary? See:
>
> https://github.com/FDOS/freecom/blob/master/lib/delay.c
>
> Regards, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



-- 
Johnpaul T. Humphrey


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] beep implementation

[Johnpaul Humphrey]

FreeDOS does only hangs for a little bit on the message.
My version is "0.84-pre2" the version that ships with the standard USB install.
So the problem does not appear to be delay().
Maybe the problem is nosound()?
Maybe the keyboard has an error? or the computer itself?
I can write a test program if needs be, later on today.

On Fri, May 8, 2020 at 9:40 AM Eric Auer  wrote:
>
>
> Hi!
>
> In short, your FreeCOM beeps are infinitely long.
> As you saym beep_l.c and beep_n.c implements them
> as beep_low() and beep() as follows:
>
> void beep_low(void)
> {
>   sound(900);
>   delay(200); /* 400 */
>   nosound();
>   delay(100);
> }
>
> void beep(void)
> {
>   sound(900);
>   delay(200); /* 400 */
>   nosound();
>   delay(100);
> }
>
> However, FreeCOM also uses a delay in cgetchar_timed(int secs)
> and in hangForever(). The latter is only used as crash handler.
>
> The former has something to do with the F8 or /Y or CALL /Y mode
> and FreeDOS 2025 or newer:
>
> "Press F8 for trace mode, or F5 to bypass" (for example autoexec)
>
> is supposed to be shown for at most 3 seconds. Unless you press
> a key immediately, it does delay(100) between attempts to check
> whether you have yet pressed a key. So if delay() itself hangs
> on your computer, FreeCOM should also hang at that prompt, too?
> Which exact version of FreeCOM are you using? See "VER" :-)
>
> Regards, Eric
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



-- 
Johnpaul T. Humphrey


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] beep implementation

[Johnpaul Humphrey]

Hi Developers,

I noticed that when I tab complete in the default shell, (freecom, I
think) that it beeps, and is stuck beeping for a long time. I have not
been able to see how long till it stops, but if it stops at all, it is
much longer than it should be. The only way I have found to stop it is
to turn the computer off.

I am not the greatest programmer ever, but I am comfortable looking at
source code. I checked a couple files from freecom source. beep_l.c
and beep_n.c
The implementation looked reasonable, assuming that the argument to
delay is in milliseconds.
I also am assuming that the instructions are executed in series.

I am sending this to the developer mailing list, because I think it is a bug.
I also plan on mailing the user mailing list to discuss configuration options.

I can check the other files included to see about sound and nosound.
Though I am not an expert, and would be surprised if I was able to
find issues.

I am running FD12 on an HP Pavilion that is about three years old.
I used the USB install image from your official website, and there
were no errors while installing.

I think this is a problem with the shells implementation. 4dos beeps
for a tolerable period of time.

TL;DR: The beep in the default shell hangs longer than it should.

--
Johnpaul T. Humphrey


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel