Board index » kylix » Re: What about a new IDE for dcc and bc++

Re: What about a new IDE for dcc and bc++


2003-11-27 08:21:26 PM
kylix1
Marco,
Quote
Somebody that could tell you more about the current state of the
database support (including TDataset part) of FPC is "michael at
freepascal dot org"
Thank you very much for the name.
Regards,
Oliver
 
 

Re:Re: What about a new IDE for dcc and bc++

Quote
Yes. *BSD is a bit of a problem though. Sys V threads do exist there, but
can (and are often, security) disabled in the kernelconfig.
If that really is a problem, it's not a big deal to create a propriety
message system using sempaphores ore other inert process communication
means. In Delphi you can do even do this using TThreadList and TEvent
(but the problem remains how to create a Delphi language event from a
TEvent in the main thread, or is this even solved in FP ?).
Quote
>But something like that needs to be present in FP anyway, if event driven
>programming (like in Delphi) is now possible in FP.

No. GTK works with blocking calls, not with messages afaik. It is a more
generic system.

By I "something like that" I meant a kind of event scheduler that
converts Mouse and Keyboards (and other) events into "Delkphi language
events". It should be quite easy to hook incoming (system V) messages in
here.
Quote
FPC/Lazarus effectively makes choice 2.
Sonds like a good choice.
Quote

Why? Because real 100% compability is really hard, and cannot be achieved in
the coming two years (that is with FPC/lazarus as start, if you start over
now on top of dcc, we are talking at least 5)
Understood.
Quote

And I've seen this discussion before, a fat 5-7 yaers ago. In practice most
people ditched their old codebases, or convert them to the next best thing
(.NET in this case), and only the ones that really
It's not only the personal code based, it's alto the huge count of free
and commercial components that are avvailable in source code for Delphi
and enhence our productivity greatly.
Quote

But maybe if it e.g. is like an ARM, of a ripoff of a different, supported
target, there might be a chance.
Nope, it's something completely new, that is why it's so interesting.
It's got a "memory to memory" architecture (operations usually are done
without using registers, which is not a tradoff, as it has a dual ported
internal ram and can do e.g. A:=A+B for non-register variables in a
single cycle (4 nSec). Moreover it has internal multithreadding with 0
cycle task switching overhead. So the FP port would be an "iuntersting"
task <g>.
Thanks, Michael
 

Re:Re: What about a new IDE for dcc and bc++

On 2003-11-27, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>Yes. *BSD is a bit of a problem though. Sys V threads do exist there, but
>can (and are often, security) disabled in the kernelconfig.

If that really is a problem, it's not a big deal to create a propriety
message system using sempaphores ore other inert process communication
means. In Delphi you can do even do this using TThreadList and TEvent
(but the problem remains how to create a Delphi language event from a
TEvent in the main thread, or is this even solved in FP ?).
Not that I know, but that doesn't say much.
What do you mean by "language" events btw? The message modifier for classes?
Quote
>No. GTK works with blocking calls, not with messages afaik. It is a more
>generic system.
>
By I "something like that" I meant a kind of event scheduler that
converts Mouse and Keyboards (and other) events into "Delkphi language
events". It should be quite easy to hook incoming (system V) messages in
here.
>And I've seen this discussion before, a fat 5-7 yaers ago. In practice most
>people ditched their old codebases, or convert them to the next best thing
>(.NET in this case), and only the ones that really

It's not only the personal code based, it's alto the huge count of free
and commercial components that are avvailable in source code for Delphi
and enhence our productivity greatly.
I know. However the situation was roughly the same with TP/BP. The mass of
code was immense, and doesn't disappear.
Some faction in the company that typically wants the newest stuff, or some
manager decides to conform to marketplace standards (read: what everybody is
using and has the biggest representation on bookshelfs) Totally independant
of real points in favour of against. This can happen quite fast, in only
a year.
Everything belonging to Delphi just gets {*word*221}stamped "legacy", because it
is considered a dead end, and then no money (employee time) is invested
anymore in anything Delphi related, components, tools and packages are not
updated, a few new Windows/IE/Office gadgets are not supported, and the
vicious circle starts.
FPC is formally independant of Borland (actually we get no cooperation what
so ever, not even some BP legacy code like Turbo Vision), however FPC's
userbase will be hit hard if the Delphi part of Borland stops (I don't
consider Delphi.NET to be Delphi, if most code must be rewritten from near
scratch).
Most of the FPC users own Delphi (specially the more serious ones, excluding
the usual people that do a one semester structured programming course), but
simply use FPC to go places where Delphi/Kylix can't go.
So if Borland Delphi colapses, it will hit FPC, but also e.g. Jedi within a
year, decreasing userbases, shorter involvement.
The Slashdot like "company dies, so all users will switch to the open source
equivalent" is pretty much nonsense, and only goes for exceptional cases.
FPC will loose the contributors that work with Delphi professionally over
time, and that will hurt. Badly. The few people still working with Delphi
will be effectively working on legacy codebases, and therefore won't spent
enough time on FPC enough to make a significant impact, only to solve their
direct problem at best.
The legacy users are only interested in full compability, and nothing more.
Most don't even expect to have to read manuals. Nothing will effectively
flow back into the project, while maintaining even 95% compability is
already a significant effort.
Only the people that _already_ have invested in creating clean and portable
code will be able to make a conversion.
The only beneficial effect of such a colapse would be the release of some
former shareware and freeware codebases into PD or under an Open Source
license.
Quote
>But maybe if it e.g. is like an ARM, of a ripoff of a different, supported
>target, there might be a chance.

Nope, it's something completely new, that is why it's so interesting.
It's got a "memory to memory" architecture (operations usually are done
without using registers, which is not a tradoff, as it has a dual ported
internal ram and can do e.g. A:=A+B for non-register variables in a
single cycle (4 nSec). Moreover it has internal multithreadding with 0
cycle task switching overhead. So the FP port would be an "iuntersting"
task <g>.
There are enough really worthwhile architectures to port to left :-) Ports
out of academic interest are not likely. It is simply too much work.
 

{smallsort}

Re:Re: What about a new IDE for dcc and bc++

Quote
Not that I know, but that doesn't say much.
What do you mean by "language" events btw? The message modifier for classes?
In Delphi language, an "event" is simply a callback. Of course you can
easily create your own "Events" in classes nicely by using a property
with a procedure type.
In Borland Delphi/Kylix, in the main thread of a GUI application, the
programmer usually creates nothing but events, hooking his code to
events that are provided by (standard) components. In Windows these
events are initially triggered by OS messages (Mouse, Keyboard, timer
etc.) The conversion Message->Callback seems to be done by Windows
itself. Linux does not offer this functionality, so it's done by QT (no
idea how). If FP really can do GUI applications in Delphi style (they
say you can compile some Delphi projects unchanged in FP and run them
ion Linux), this functionality seems to be implemented in the RTL. So
adding "some kind of message" ->event does not seem like a huge
problem.
Quote

I know. However the situation was roughly the same with TP/BP. The mass of
code was immense, and doesn't disappear.
But the third party code providers will not fork their products into a
Delphi and an FP branch. So FP needs to be as compatible as possible.
Quote

FPC is formally independant of Borland (actually we get no cooperation what
so ever, not even some BP legacy code like Turbo Vision), however FPC's
userbase will be hit hard if the Delphi part of Borland stops (I don't
consider Delphi.NET to be Delphi, if most code must be rewritten from near
scratch).

Did you read the borland.public.delphi.netpreview.nontechnical forum and
some papers provided by borland and others ? It seems that many delphi
applications can be ported easily (or nearly unchanged) to Delphi.Net.
The course being that .NET was designed by the main architect of Delphi
(C# being Delphi in disguise, it's inner principles much nearer to
Delphi than to C++) and, based on the same ideas, .NET can be seen like
the "bottom part" of Delphi.
Quote

There are enough really worthwhile architectures to port to left :-) Ports
out of academic interest are not likely. It is simply too much work.
Understood. The 3K is a really promising architecture for embedded
applications, but of course embedded is not the main issue for FP,
though it seems to be the best tool to do embedded stuff in Pascal.
-Michael
 

Re:Re: What about a new IDE for dcc and bc++

On Fri, 28 Nov 2003 11:23:57 +0100, Michael Schnell wrote:
Quote
In Borland Delphi/Kylix, in the main thread of a GUI application, the
programmer usually creates nothing but events, hooking his code to events
that are provided by (standard) components. In Windows these events are
initially triggered by OS messages (Mouse, Keyboard, timer etc.) The
conversion Message->Callback seems to be done by Windows itself. Linux
does not offer this functionality, so it's done by QT (no idea how). If FP
really can do GUI applications in Delphi style (they say you can compile
some Delphi projects unchanged in FP and run them ion Linux), this
functionality seems to be implemented in the RTL. So adding "some kind of
message" ->event does not seem like a huge problem.
So you're referring to an event as just a method pointer?
But then the way GUI stuff works in FPC is just that you have a bunch of
method pointers and hidden away in TApplication.Run you have a loop that
checks for GUI "events" and then calls the appropriate method (via a
method pointer that was assigned somewhere).
How the "events" are initially triggered doesn't matter, as long as you
have method pointers (which of course FPC has). Windows doesn't do the
"Message->Callback" conversion, TApplication.Run internally just goes over
the windows message queue and checks who the message was for, and calls
the appropriate method (via a method pointer).
I think there's some confusion here as to the definition of "event". You
seem to apply that an event is something triggered by the OS, yet inside
the RTL its simply some mechanism of checking for GUI/OS/XYZ events and
calling the appropriate "event handler" (which is just a method on some
object).
You'll always need some kind of main application processing loop here, so
I don't quite understand your point about FPC /supporting/ events. Of
course it has method pointers. Yes, you can write GUI programs and
TApplication.Run provides a main application loop that gets GTK events and
calls the appropriate methods to handle them.
Windows doesn't do any event handling, it just sends messages out. Linux
doesn't do event handling either, but the toolkit is responsible for
providing some way to check for messages. In windows you do this via
PeekMessage and related calls, in gtk you do this via the gtk_main_* calls
(afaik), and I don't know about qt.
johannes
 

Re:Re: What about a new IDE for dcc and bc++

On 2003-11-28, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>Not that I know, but that doesn't say much.
>What do you mean by "language" events btw? The message modifier for classes?

In Delphi language, an "event" is simply a callback. Of course you can
easily create your own "Events" in classes nicely by using a property
with a procedure type.
Hmm. You mean that. Actually in OOP theory a simply method call is also an
event (for that object).
Of course this works in FPC, but this whole system is something of the GUI
libraries, not of the language or basic runtime.
But keep in mind that something like ICS is running, relatively unmodified.
For an idea of the required changes see www.stack.nl/~marcov/ics.html
Quote
In Borland Delphi/Kylix, in the main thread of a GUI application, the
programmer usually creates nothing but events, hooking his code to
events that are provided by (standard) components.
Yes, but this is a VCL thing. Lazarus does also do this btw.
Only the dependance on _real_ messaging is afaik slightly less inside
lazarus, this because most other widgetsets (gtk) use procedural callbacks,
not messaging.
Quote
The conversion Message->Callback seems to be done by
Windows itself.
No. It is done by the application object IIRC.
Quote
Linux does not offer this functionality
"linux" is only a kernel. It depends on the widget set api. Also the GUI
system doesn't depend on messaging. Don't forget that the X windowing system
is nearly entirely userland based (like Windows NT had before 4.0)
Just like you can access the Windows GUI system via different api's (3.x apis,
win32 api, NT native, .NET probably)
, so it's done by QT (no idea how).
Quote
If FP really can do GUI applications in Delphi style (they say you can
compile some Delphi projects unchanged in FP and run them ion Linux), this
functionality seems to be implemented in the RTL. So adding "some kind of
message" ->event does not seem like a huge problem.
But you have to translate message to the exact same format, in the exact
same order etc.
(FPC is probably capable of compiling the VCL, if we would spend some time
in it)
Quote
>I know. However the situation was roughly the same with TP/BP. The mass of
>code was immense, and doesn't disappear.

But the third party code providers will not fork their products into a
Delphi and an FP branch.
FPC mainly targets the open source world. The problem is that for nearly
all people not really interested in FPC, but only for a cheap way out,
only full 100% compability will do, which is near impossible, and even
undesirable, since both delphi and kylix are OS and processor specific.
We want to keep the 95% good stuff, and don't waste time on providing
compability.
Quote
So FP needs to be as compatible as possible.
If you put in the time, I'm sure something can be arranged :-)
But the main point is that FPC is not just about Delphi legacy code. People
create new programs with FPC, and near all contributors of the project are
of this kind.
You can't simply say that developers should work on maintaining Delphi
legacy compability because:
- Legacy and compability work is not popular with developers, people expect
to get paid for it.
- legacy crowds are not the most thankful crowds. Sure, it will attract a lot
of users, but not the kind that donates or improves something. They'll only
come when the compability is 100%, and do a single recompile, and be gone.
Quote
>FPC is formally independant of Borland (actually we get no cooperation what
>so ever, not even some BP legacy code like Turbo Vision), however FPC's
>userbase will be hit hard if the Delphi part of Borland stops (I don't
>consider Delphi.NET to be Delphi, if most code must be rewritten from near
>scratch).
>
Did you read the borland.public.delphi.netpreview.nontechnical forum and
some papers provided by borland and others ? It seems that many delphi
applications can be ported easily (or nearly unchanged) to Delphi.Net.
Borland wants to sell, and others (like dr Bob) are essentially sockpuppets,
they earn from Delphi training, and then specially training in _new_
features.
If I see Borland's own changelist, and I see the avg delphi app, this is
nonsense. Oh, and btw, recompiled with Delphi.NET is IMHO fully managed
code.
Quote
The course being that .NET was designed by the main architect of Delphi
(C# being Delphi in disguise, it's inner principles much nearer to
Delphi than to C++) and, based on the same ideas, .NET can be seen like
the "bottom part" of Delphi.
That is IMHO also propaganda. The technology is wildly different. That the
same person made it, and used the same set of filosophies doesn't guarantee
any compability at all, spescially when the architectures are so far apart.
Sure, it might make it easier for people that want to create refactoring
tools, but it doesn't eliminate pointers, win32 behaviour, database drivers,
3rd party components, string<->pchar conversions etc etc.
It's like saying a spaceshuttle is a plane because they both have wings.
Delphi.NET is not evil, it might be a nice productive environment, and a
good entry into the .NET platform, if you need to. (I don't before 2006),
and you might be able to take reasonable portable code with you, if you have
it.
It might also be a vehicle to slowly migrate to .NET, by not directly go
full .NET but slowly replacing unmanaged code by managed code. (I don't
know how well this works)
But a compatible platform like the series D2->D7? Not even close.
Quote
>There are enough really worthwhile architectures to port to left :-) Ports
>out of academic interest are not likely. It is simply too much work.

Understood. The 3K is a really promising architecture for embedded
applications, but of course embedded is not the main issue for FP,
though it seems to be the best tool to do embedded stuff in Pascal.
Ports are done on a "I want it, so I'll do the port" basis, there is no
internal priority list or so.
But developers
tend to make ports to archs they own, and they are more likely to own
popular archs.
If somebody submits a nonstandard port, wants to maintain it, and it is
suitable for inclusion, it would be included I think.
 

Re:Re: What about a new IDE for dcc and bc++

Quote
So you're referring to an event as just a method pointer?
Is this not the standard "Delphi speak" ?
Quote
But then the way GUI stuff works in FPC is just that you have a bunch of
method pointers and hidden away in TApplication.Run you have a loop that
checks for GUI "events" and then calls the appropriate method (via a
method pointer that was assigned somewhere).
Hmm. IMHO you are not (should not be) allowed to do infinite polling
loops in a user application eating up 100 % CPU time. Of course you can
do "nice" calls, but this will slow down the application (not usable for
embedded stuff).
Quote
How the "events" are initially triggered doesn't matter, as long as you
have method pointers (which of course FPC has). Windows doesn't do the
"Message->Callback" conversion, TApplication.Run internally just goes over
the windows message queue and checks who the message was for, and calls
the appropriate method (via a method pointer).
Ah, I see. Here the advantage is that you don't need to do any polling
but you can wait for the next message to arrive in the main thread. If
all messages are served by the appropriate events you can _wait_ (by a
system call) until the next message does arrive. No CPU time is wasted.
Quote

I think there's some confusion here as to the definition of "event". You
seem to apply that an event is something triggered by the OS, yet inside
the RTL its simply some mechanism of checking for GUI/OS/XYZ events and
calling the appropriate "event handler" (which is just a method on some
object).
Of course you are right. But in any case a _decent_ RTL-implementation
of the "event driven" way of programming, Delphi imposes on the
programmer in the main thread, would neither waist CPU time by speedy
polling for "outside" events which "fire" Delphi callback "events", nor
slow down the application by not being able to react at once on an
outside event that occurs. In Windows this seems to be easy using the
message interface of the OS. I have no idea, how GUI "events" (e.g.
mouse click) can be handled in that way in Linux, but events that are to
be "fired" because a worker thread wants to notify the main thread, can
be done e.g. using Linux messages. If the GUI events (and Timers) can
only be handled by polling, maybe it might be a good idea to do this
(relatively slowly) in a worker thread and notify the main thread by
some kind of "message". A message mechanism could use Linux messages or
do this simply by using a single semaphore, the main thread waits for if
it has done all (event) work and which is released by any worker thread
that wrote a message in some kind of FIFO (e.g. a TThreadlist).
Quote
You'll always need some kind of main application processing loop here, so
I don't quite understand your point about FPC /supporting/ events.
See above. Of course you need a loop. But same should stop looping if
nothing is to do, and restart _at_once_ if something is to be done.
Quote
Yes, you can write GUI programs and
TApplication.Run provides a main application loop that gets GTK events and
calls the appropriate methods to handle them.
Fine. What exactly are "GTK-events" (If they are not a kind of
messages.) ?
Quote
In windows you do this via
PeekMessage and related calls, in gtk you do this via the gtk_main_* calls
(afaik), and I don't know about qt.
I'm quit sure that in Delhi/Windows the main thread _waits_ for the next
message with some API call and thus does not waste CPU time and can
react instantly on an Windows "event" occurring (e.g. Mouse click,
timer event or message from a worker thread.)
-Michael
 

Re:Re: What about a new IDE for dcc and bc++

Michael Schnell < XXXX@XXXXX.COM >wrote in
Quote
>Yes, you can write GUI programs and
>TApplication.Run provides a main application loop that gets GTK
>events and calls the appropriate methods to handle them.

Fine. What exactly are "GTK-events" (If they are not a kind of
messages.) ?
I'd suggest downloading the Lazarus source and look at the gtk and windows
interface units, and LCL messages. It's been a while since I looked at
them or worked on them myself, so the underlying structure may have changed
some, but I doubt it has changed more than this brief overview...
Windows "events" (mouse click etc.) are signaled by a message with a
certain WM_* message type and optionally some data in wparam and lparam.
You set up a message loop that registers which messages you are interested
in based on window handles, and call ReadMessage, which blocks until there
is an actual message. Thus you don't eat CPU time polling. The message
loop is the single "callback" for the windows system.
GTK "events" don't work that way. For them, each "event" is a callback.
Instead of setting the callback to the message handler, you set the
callback directly to the "event" handler. So to make this compatible to
the way Windows works, and thus Delphi, a method had to be found to emulate
the Windows message loop.
(Here's where my memory gets fuzzy, so check the source). What was done
was to define LM_* message constants to emulate the windows WM_* constants.
The message loop, to register messages based on LM_* constants, called
helper routines that in turn registered a GTK helper callback. Enough info
was stored so that the helper GTK callback could determine the source
component, thus the the "window handler loop", and then call back the
"window handler", which then calls the component's event handler (such as
OnClick). The important thing to note is that the GTK "window handler"
isn't a loop like in Windows. It is a callback to the callback to the GTK
object. Therefore it too does not eat CPU cycles. When you add an event,
the "handler" is called long enough to set up the callback sequence, and
when a GTK event occurs, the callback sequence generates the correct LM_*
message to the top callback "handler" that dispatches it to the component.
Mapping GTK events to Windows events, and thus to what Delphi programmers
expect and what component code expects, is hideously complicated. So these
intermediate callbacks are doing a lot of work. Even things like the
window bounds are different, as one includes borders and title bars and the
other doesn't. A whole lot of work has gone into making the GTK calls look
similar to Windows calls so that Windows components can be ported easily.
Jeff.
P.S. This is at least two years ago that I last got into the code, likely a
lot has changed, maybe even the fundamentals, so I suggest you download the
code and check it out.
 

Re:Re: What about a new IDE for dcc and bc++

Jeff,
Thanks a lot for all your comments !
I think this is encouraging enough to plan to d/l the Lazarus stuff.
If GTK just does callbacks, that means that such a callback can
"interrupt" an already running callback from some other event. That is
why a loop is necessary to serialize this.
Is it possible to include inter-thread communication in the "event loop"
scheme ? I suppose a worker thread could raise a signal to inform the
main thread about an event it wants to be handled and put additional
information in a TThreadlist or something like that. Is this already
implemented in FP/Lazarus ? Can this be implemented "on top" of the
normal version ? Could it be done (with reasonable effort) by modifying
the source code ?
What I'm interested in is a platform independent way of inter-thread
signaling. Some kind of "Messages" (a TMessage object or such) seems
like a good candidate. IMHO the "best" (most
Delphi-language-appropriate) solution would be a "remote event"
implementation (meaning that in any thread you can define an event that
is to be run as part of another thread, but this would imply that _each_
thread has an "event scheduler" to serialize these beasts, which is not
implemented in Delphi and maybe would need to be a language extension).
By that event driven programming would be enabled for worker threads,
too.
Thanks - Michael
 

Re:Re: What about a new IDE for dcc and bc++

Michael Schnell < XXXX@XXXXX.COM >wrote in
Quote
Is it possible to include inter-thread communication in the "event loop"
scheme ?
I have no idea on this. It's been a couple of years, and I didn't get into
that portion of it. Plus, from what I've seen on the mailing lists, the
whole threading units in FPC have been majorly overhauled, so some of that
may have carried into the Lazarus implementation.
Jeff.
 

Re:Re: What about a new IDE for dcc and bc++

On 2003-12-02, Jeffrey A. Wormsley < XXXX@XXXXX.COM >wrote:
Quote
Michael Schnell < XXXX@XXXXX.COM >wrote in
news: XXXX@XXXXX.COM :

>Is it possible to include inter-thread communication in the "event loop"
>scheme ?

I have no idea on this. It's been a couple of years, and I didn't get into
that portion of it. Plus, from what I've seen on the mailing lists, the
whole threading units in FPC have been majorly overhauled, so some of that
may have carried into the Lazarus implementation.
I don't think they already have. Lazarus is still in transition between the
1.0.x and 1.9.x branch (the one that used to be 1.1.x before it went into
beta), and still works with 1.0.x
 

Re:Re: What about a new IDE for dcc and bc++

On Tue, 02 Dec 2003 10:35:08 +0100, Michael Schnell wrote:
Quote
Is it possible to include inter-thread communication in the "event loop"
scheme ? I suppose a worker thread could raise a signal to inform the
main thread about an event it wants to be handled and put additional
information in a TThreadlist or something like that. Is this already
implemented in FP/Lazarus ? Can this be implemented "on top" of the
normal version ? Could it be done (with reasonable effort) by modifying
the source code ?
Yes, it surely is possible, you just have to call CheckSynchronize()
somewhere. Unfortunately gtk doesn't give you an fd to select() on,
because then I could also use an fd() to do Synchronize signalisation and
thus select() on both at the same time.
Quote
What I'm interested in is a platform independent way of inter-thread
signaling. Some kind of "Messages" (a TMessage object or such) seems
like a good candidate. IMHO the "best" (most
Delphi-language-appropriate) solution would be a "remote event"
implementation (meaning that in any thread you can define an event that
is to be run as part of another thread, but this would imply that _each_
thread has an "event scheduler" to serialize these beasts, which is not
implemented in Delphi and maybe would need to be a language extension).
By that event driven programming would be enabled for worker threads,
too.
Well, the thread would have to check for things in any case, wouldn't it?
So a thread would:
instead of
while not Terminated do begin ... end
do
while not Terminated do begin CheckEvents; ... end
and call CheckEvents appropriately at other points too
instead of doing Sleep(xyz) it would need some sleep that would select()
on the event fd (lets take a fd for given), and then do those events. But
then the timing becomes inaccurate, so maybe not what you want either.
The application main loop would have to do this as well, again with the
limitation that it needs to be polling two event sources somehow, because
gtk doesn't give you something to select() on. Maybe it does internally, I
don't know. If it does, it may be possible to wait for gui events and
internal events at the same time.
Basically, I think what you want can be implemented without any special
support from the language.
johannes
 

Re:Re: What about a new IDE for dcc and bc++

I can describe a very simple example:
A GUI program has a text field on a form.
A worker thread is spawned that waits for some hardware event (e.g. a
character from a serial device in a blocking read operation).
If a character comes in, the main thread should display it (at once) in
the
text field.
In Windows/Delphi I would use a message object in the main thread and
send a
message from the worker thread to the main thread when a character comes
in.
(The character can be a parameter of the message.)
The message fires a Delphi event (callback) in the main thread, when no
more
previous messages are in the queue to be serviced.
How would I do this in FP (Windows and Linux) ?
Thanks for caring.
-Michael
 

Re:Re: What about a new IDE for dcc and bc++

Quote
Basically, I think what you want can be implemented without any special
support from the language.

Thanks for ally your comments. I think I should take a plunge on FP some
day and try out what it can get me.
-Michael