Re: Windows stuff...
CoJaBo wrote:
>
> 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.
<snip>
I've seen some odd spellings of my name too, like:
CoJaCo (Typo in Win32Lib IDE docs(fixed now))
cOJaaBo(another site)
kohjaabooo(posted using MY account on another site by a
cracker who seems to be mad at me for some reason...)
>
> >
> > > 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
|
|
