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? Why is RDS responsible for distributing
> these and for keeping up to date with the likes of Microsoft and
> Linux publishers?
>
> 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.
> Would also expect that all Euphoria publishers have to supply
> all 3rd-party constants too?
>
> > 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 
>
> >
> > > 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.
>
> 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.
>
> > > 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.
>
> > 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.
>
> > RDS just has to include the regarding code in the official Euphoria
<snip>
I use my own database system. It stores data more effeciantly, but
isn't as flexible since the types of data used must be declared
in advance. This ensures that the data is always in the correct
format, which works best for most of my programs, but is completely
useless in ones that need to store dynamic data.
The same thing applies to other libraries; what works for one program
might not work for another. As Dereck said "One size does not fit all."
>
> > 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. 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.
>
> > > 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?
>
> --
> Derek Parnell
> Melbourne, Australia
>
|
Not Categorized, Please Help
|
|
