Re: Windows stuff...
Derek Parnell wrote:
> Juergen Luethje wrote:
>>
>> Tommy Carlier wrote:
>>
>>> Patrick Barnes wrote:
>>>> To program in windows using only the standard libraries is very time
>>>> consuming and annoying.
>>>> Excellent work has been done in 3rd party projects like win32lib and
>>>> w32engine.
>>>> Some people find one or both of these restrictive, and so go off and
>>>> use a different system...
>>>>
>>>> This means that programmers are using different windows libraries to
>>>> write their own code, and to convert a library to use a different
>>>> windows library is difficult, if not impossible.
>>>>
>>>> What do you think about collaborating to produce a common core to
>>>> these windowing systems, that can be extended to produce a library
>>>> that caters to different needs?
>>>>
>>>> For a start, one include file should have every windows API constant,
>>>> and be compatible across the board. Perhaps it should be included in
>>>> the euphoria installer as a standard include.
>>>
>>> I agree that there is a need for a core library, but that library
>>> should be very limited. The API constants are necessary.
>>
>> Yes, the API constants are necessary, and I actually think that they
>> should ship with the official Euphoria distribution.
>
> Which API constants? Microsoft's Windows API? Linux KDE? Linix GNOME?
> wx? OpenGL? DirectX? All of them?
I can't say anything specific about Linux, because I don't know it.
I see, that there is much stuff on your list. "If we can't get
everything, then we shouldn't get anything." -- is this what you want
to say? I can't believe it.
As always, it's a good idea to start with the most basic things. For
MS Windows this will probably be API constants and wrappers for C-like
structures and function calls.
Actually RDS already had started doing so, just look at 'msgbox.e'. Is
this a bad thing because it doesn't support Linux? No, it's better than
nothing, and it's worth to be continued.
> Why is RDS responsible for distributing
> these and for keeping up to date with the likes of Microsoft and
> Linux publishers?
I didn't say that RDS is responsible for it. I said that it would be
useful if included in the standard distribution. And I believe that's
the reason why other companies such as Borland, PowerBASIC Inc. etc.
actually do so.
> Remember that Euphoria is both a programming langugage - a tool.
>
> RDS publishes one specific instance of a Euphoria interpreter. In future,
> there could be alternative publishers of Euphoria interpreters and compilers.
a) Noone knows, if and when this will happen. In 40 years, my ashes
probably won't care anyway. 
b) I don't see any problem regarding this point.
There are also many publishers of say BASIC interpreters and
compilers. Some of them include Windows API constants and wrappers in
their distribution.
> Would also expect that all Euphoria publishers have to supply
> all 3rd-party constants too?
>From the consumers point of view, this will be a nice situation, because
s/he has the choice, which Euphoria interpreter/compiler to buy.
Euphoria publishers of course will not *have to* supply all 3rd-party
constants (I never said "all" BTW), but if some publishers do so, while
others don't, this might influence the choice of the customers.
Including MS Windows API constants and wrappers for C-like structures
and function calls will certainly raise the value of a product.
>> This is normal for other languages such as C, Delphi, PowerBASIC
>> etc. for years now.
>
> If I recall correctly, Kernighan and Ritchie did not distrubute Windows
> API constants 
Sorry for not having expressed myself clearly enough. I wanted to say:
In the current century, Borland C comes with MS Windows API constants,
Open Watcom C comes with MS Windows API constants, Borland Delphi comes
with MS Windows API constants, MS Visual Basic comes with MS Windows API
constants, PowerBASIC comes with MS Windows API constants, ...
>>> But I think that it would be useful, if instead of a Euphoria-library,
>>> these definitions (constants, functions, structures) would be available
>>> as a database.
>>
>> I certainly don't have as much programming knowledge as you, but anyway,
>> I'd like to say here: KISS. I think it should be a plain include file.
>> It works fine e.g. for the languages mentioned above, why shouldn't it
>> be good for Euphoria?
>
> Also, C, Delphi, PowerBASIC, etc are all compilers. In these languages,
> using the constants is a compile-time effort and never at run-time.
> With Euphoria, every time you run a program, the 'constants' must be
> executed. Thus having ALL the constants run for every Windows program
> written in Euphoria might be a penalty for some.
This is currently the same with Win32Lib. If exw.exe runs the source
code of a program, that includes Win32Lib, it takes some time for the
'collection' and interpretation of all the source code at the beginning.
But if the same program is bound, it starts immediately, without that
delay.
> Thus it might be a better strategy to have related constants together
> in separate include files. That way, you execute the ones you are
> actually using.
I think you are completely right. I didn't say it should be one
monolithic file.
>>> Different libraries use different functions to define structures, and
>>> to load DLLs and functions.
>>
>> Yes, but that must not be accepted as a given prerequisite, because it's
>> part of the problem! And that's why it is highest time to create some
>> standards in this regard. When all libraries use these standards, then
>> this issue will dissapear.
>
> If only it was this simple. Why are there different approaches to these
> 'common' processes? One answer may be that they are trying to achieve
> different things. For example, in win32lib, we could have just used the
> 'native' methods for defining API functions: open_dll(), define_c_func().
> But I chose not to because I thought it would be faster to only define
> these if they were actually used in your program. Thus win32lib does not
> define any API routines if you are not using them. This makes the code
> in the library more complex, but has little impact for users of the
> library. Same with RAM structures. I could have just used simple offset
> values and then made users workout when to use poke(), poke4(), peek,
> peek4u(), peek4s(), etc.. as appropriate. David Cuny chose not to do it
> that way. He wanted to make it easy to use RAM structures and to reduce
> errors in defining such in the library. But this comes with a run-time
> cost. Other libraries have decided that the run-time cost is not worth it.
>
> There are different ways of achieving these things because there are
> different design goals. One size does not fit all.
Thanks for the comprehensive explanation, I see your point.
But how many users of say Delphi, Visual Basic, or PowerBASIC say:
"I don't like the built-in Windows API constants and function wrappers,
I'd rather write my own."? Zero, very probably.
>> In order to 'define' a standard, it's not
>> necessary to write large and complicated documents.
>
> No, the hard part is getting the agreed to.
That's what I think, too.
>> RDS just has to include the regarding code in the official Euphoria
>> distribution. This will automatically be a 'de-facto standard' like it's
>> already with the library routines, that currently ship with Euphoria.
>
> So are we happy to live with the "benevolent dictator" model?
This term is borrowed from politics, it doesn't suit for technical
problems. Or do you think ISO also is a kind of "dictator" when they say
we shall express distances in terms of meters and kilometers?
Maybe there was some democratic voting at Lockheed Martin in 1999 ...,
see <http://www.cnn.com/TECH/space/9909/30/mars.metric.02/>
>> For instance, if there would be built-in library routines for handling
>> C-like structures, all those different self-written routines would
>> become superfluous (provided, the built-in routines are good), and
>> sooner or later would disappear from the "market".
>
> Tell me again why C++, Delphi, D, PowerBASIC, Java, et al were invented?
>
> Because you can't please all the people all the time.
Don't compare apples to oranges, please. I was writing about
implementing support for C-like structures, not about the need for
different programming languages.
What do you think how many user-written routines for handling C-like
structures do exist in PowerBASIC? Zero, very probably. Because there is
already built-in support for it in the language. This means unification
and standardization.
> Which "pretty print" do you use?
It depends. Privately, I prefer 'ppp.e'. But when I want to share code
e.g. on this list, I prefer using Eu's built-in pretty_print(). I want
other people to be able to run my code, without the need to additionally
install any librarys (if possible). This again shows, how important
unification and standardization is. I suppose almost all people on this
list want to share code with each other.
I admit that the built-in pretty_print() is not completely accepted as a
standard. Please note that I wrote above
| (provided, the built-in routines are good)
IMHO output is one of Euphoria's Achilles' heels anyway, and also
pretty_print() could be better. Of course there is no guarantee, that
anything provided by RDS will be widely accepted as standard. The better
it works, the higher are the chances. And the chances are IMHO often
much higher, than for user contributions.
>> So the various different approaches, and different libraries are a
>> direct consequence of the lack of a standard in that regard. And (at
>> least currently, since OpenEU isn't available yet) no one else than RDS
>> can introduce an Euphoria standard, that will be accepted and used by
>> many people.
>
> RDS has given us EDS. It works as advertized. Yet people want SQL type
> databases.
I was not talking about databases, but about Windows API constants and
wrappers for the API routines. It's not necessary to convince me, that
live has many different aspects and colors. I'm also aware of the fact,
that I can't use my washing machine, in order to see my videos.
>> When there are suggestions for improvement to Euphoria, Rob often writes
>> something like: You can do it yourself. While it's true, this is not the
>> point. Of course, we can write this or that code snippet ourselfes, but
>> we can't define standards ourselfes. That's actually up to RDS.
>
> Anyone can write standards. But try getting people to follow them.
I was meaning of course standards, that will have a high probability to
be accepted by many people.
> Have you
> any idea how many RS-232 'standards' are out there in the real world?
>
> People will only follow an RDS published standard if they like it and if it
> suits them.
I agree. But we are talking about simple constants and function wrappers.
How many users of Delphi or PowerBASIC say, that the built-in Windows
API constants and function wrappers don't suit their needs? Zero, very
probably.
The more complex things are, the more likely it is that several people
have different needs, but we are talking about very basic stuff here.
>>> If the API definitions are available as a
>>> database, anyone could generate Euphoria-code from it.
>>
>> Sorry, but I actually can't hear this "Anyone can do it her/himself."
>> argument anymore. 'Standardization' is the name of the game.
>
> But why isn't what Tommy suggested a possible standard?
I do think it is a *possible* standard, and I wish Tommy all the best,
of course.
Anyway, I'm afraid that the chances for becoming a standard are not high.
I don't know the reason why, probably it is the same reason, why neither
EuWinGUI, nor w32engin, nor Win32Lib, nor Arwen, nor EuGTK, nor
wxEuphoria has become a standard ...
I get headache when I think of highly motivated and skilled programmers,
re-inventing the wheel over and over again.
Regards,
Juergen
|
Not Categorized, Please Help
|
|
