Turns out the CRT unit in OS/2 -- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored.

Sterling

---------------------------------
Post your free ad now! Yahoo! Canada Personals

From: "Sterling Bates"
To:
Subject: [fpc-devel] Quick patch for bug 3762
Date: 30.3.2005 - 12:18:31

Hi Sterling

Turns out the CRT unit in OS/2 -- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored.

Thanks for your patch, it's correct and I'll apply it once I get to a machine with CVS access (unless somebody else applies it earlier ;-) ).

Unfortunately, the problem is wider - there are several other issues with the current OS/2 implementation (if you just quickly compare it with e.g. the GO32v2 implementation, you'd find some other problems too - e.g. handling of #8 is surely incorrect etc.). The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance?

Regards

Tomas

We can't give you a free computer if you do so, though :)

Jonas

In response to Tomas Hajny:

I'd certainly be willing to give it a try. Granted, I only have Windows XP, but if I'm careful it should be a smooth transition. No promises on a timeline :)

Another problem with Windows (not sure about other OSs) is in bug 2084. (Use the second example in the description.) I was able to narrow down what the problem is, and it's pretty daunting. Essentially, initmouse will call SetMouseEventHandler() in winevent.pp. This spawns a thread that runs EventHandleThread in a fairly tight loop, which captures all console input.

The problem comes when ReadKey then calls KeyPressed, which also attempts to read console input. No matter what, EventHandleThread will capture the input (since it places a call to WaitForSingleObject, waking up the instant something is in the queue), leaving KeyPressed with nothing to process.

My initial attempt to get around this is to tie KeyPressed to EventHandleThread as well. (If you can't beat 'em, join 'em, right?) I've attached the work I've done so far, but it's not quite right. With two ReadKey calls in a row, the first will read the key, the second will exit without even reading the queue. I think this is because the first ReadKey hasn't had a chance to clear the ScanCode variable before the second ReadKey call to KeyPressed (which exits when ScanCode #0). This results in the DOS window outputting a garbage character when the program finishes because there's still something in the queue.

It's possible to fix it by wrapping the contents of ReadKey in a critical section, but that, to me, is just more overhead. I think there's a more elegant solution waiting to be discovered :-)

Thanks,

Sterling

Your message below:
------------------
Unfortunately, the problem is wider - there are several other issues with the current OS/2 implementation (if you just quickly compare it with e.g. the GO32v2 implementation, you'd find some other problems too - e.g. handling of #8 is surely incorrect etc.).

The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance?

---------------------------------
Post your free ad now! Yahoo! Canada Personals

From: "Sterling Bates"
To:
Subject: RE: [fpc-devel] Quick patch for bug 3762
Date: 31.3.2005 - 8:26:06

I'd certainly be willing to give it a try. Granted, I only have Windows XP, but if I'm careful it should be a smooth transition. No promises on a timeline :)

Fine. I can perform testing for OS/2 and GO32v2, and testers for Unix targets shouldn't be difficult to find in FPC core team, I guess... ;-) In addition, you can do everything on one platform (successively replacing all Win32 API calls with the low-level functions from our "console" units) and then perform necessary testing on other platforms just before switching them to the common implementation, so this is rather easy to handle, IMHO. I'd just suggest to refer to the GO32v2 implementation while working on it, because this one is probably the most compatible one to TP/BP behaviour.

Another problem with Windows (not sure about other OSs) is in bug 2084. (Use the second example in the description.) I was

That's the point - there are quite a few different issues on different platforms. Instead of trying to address them in platform-specific implementations, it would be probably better to replace them with common implementation based on existing "console" units (Keyboard, Video, Mouse) which are already used in FVision and thus in our text-mode IDE (so there's quite some chance they might be working fairly well nowadays). I don't know whether this would eliminate all the problems (see below too), but if not, it would probably mean that the problem already exists in these console units and should be fixed there anyway. Especially the clash between Crt and "console" (former "FPC API" units) appearing in bug 2084 is exactly something which should get automatically resolved with this Crt unit rewrite.

I'm no Win32 person, so I wouldn't be probably able to help with details here. However - does unit Keyboard suffer from the same problem (GetKeyEvent versus PollKeyEvent)?

It's possible to fix it by wrapping the contents of ReadKey in a critical section, but that, to me, is just more overhead. I think there's a more elegant solution waiting to be discovered :-)

The fewer critical sections the better - I'd try to avoid that unless absolutely necessary.

Tomas

separating keyboard and mouse events. If I'm right here, then I'd suggest to separate platforms with separate mouse and keyboard events from platforms with common events for both devices. The platform independent implementation then should assume and use separate queues, as provided (separated if required) by the platform specific code.

DoDi

This is Windows specific.

Yes, a quick fix can be made by replacing the ReadConsoleInput() in winevent.pp by a PeekConsoleInput() call and crt works again.

Maybe this was even intended by the original developer since there is a "read, but don't remove the event" comment in front of the offending line (although it uses the ReadConsoleInput() call which actually removes the event).

Already sent this patch to a developer a two days ago (or so).

But may have undesirable side effects if no one else is eating the console events (not sure if this is actually possible, that means a problem, in console programs).
The IDE does not seem to mind though from a short try afair.

Seems like we are working on the same things atm =)

Regards,
Thomas

From: "Thomas Schatzl"
To: "FPC developers' list"
Subject: Re: [fpc-devel] Quick patch for bug 3762
Date: 31.3.2005 - 12:44:20

.
.

Seems like we are working on the same things atm =)

Which part do you concetrate on, Thomas? Is your work related to unit Crt (which could/should become cross-platform in its majority), or are you rather fixing implementation of console ("API") units (keyboard, mouse, video) for Windows (which includes winevent)? These two don't need to interfere, IMHO (so there definitely can be enough space for both of you ;-) ).

Tomas

Hello,

But may have undesirable side effects if no one else is eating the console events (not sure if this is actually possible, that means a problem, in console programs).

More testing showed that this is a problem after all. So don't apply it.

The IDE does not seem to mind though from a short try afair.

Regards,
Thomas

From: "DrDiettrich"
To: "FPC developers' list"
Subject: Re: [fpc-devel] Quick patch for bug 3762
Date: 31.3.2005 - 22:49:06

Implementation of the low-level units (Keyboard, Mouse and Video) for all supported platforms is different from each other (well, with the exception of Unix being handled as one common group), so no special separation is necessary there. OTOH, Crt (once rewritten to be built on top of these low-level units) should be (almost?) completely platform independent and thus no separation would exist there either.

Tomas