1. Windows stuff...
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.
>From that, common procedures could be agreed upon. Some things are
common across all flavours of windows library - opening a dialog box
and getting a result, the concept of an event handler, low-level
routines like timers etc....
The internals of the procedures and functions as implemented by
windows library designers do not have to be the same, but their
abstract behaviour should be the same, or similar enough to make
compatibility much easier.
Comments?
--
MrTrick
2. Re: Windows stuff...
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. 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. Different libraries use different
functions to define structures, and to load DLLs and functions. If the API
definitions are available as a database, anyone could generate Euphoria-code from
it.
> From that, common procedures could be agreed upon. Some things are
> common across all flavours of windows library - opening a dialog box
> and getting a result, the concept of an event handler, low-level
> routines like timers etc....
I don't totally agree with this statement: if you force such common procedures,
people will be limited to write libraries that all look the same. What if one
wants to write a library that doesn't use an event-system, or if it uses an
event-system that looks totally different than the common event-system? If such a
common event-system would exist, how would it look? I have to say: the Win32Lib
event-system is easy to use and pretty advanced, but what's the point of writing
a (revolutionary?) new library if you're going to stick with old habits.
> The internals of the procedures and functions as implemented by
> windows library designers do not have to be the same, but their
> abstract behaviour should be the same, or similar enough to make
> compatibility much easier.
I disagree: the abstract behaviour of a Windows library should not be the same
as any other Windows library. That's why I'm starting the new library: to make a
library that doesn't suffer from backward compatibility (yet), and that
implements some new features and ideas that haven't been implemented before.
Compatibility can be a good thing, but is also very limiting.
--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
Euphoria Message Board: http://uboard.proboards32.com
3. Re: Windows stuff...
Tommy Carlier wrote:
> Patrick Barnes wrote:
>
> I agree that there is a need for a core library, but that library should be
> very limited.
> The API constants are necessary. 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. Different libraries use different functions to define
> structures, and
> to load DLLs and functions. If the API definitions are available as a
> database, anyone
> could generate Euphoria-code from it.
It's not too difficult to do this, but it's only moderately useful. Only
a handful of people develop GUI libararies (compared with the number of
people who use them). Where I think it's really useful is for cross
platform development, and also for modularizing things. Take a look at
the developer's package for wxEuphoria:
http://wxeuphoria.sourceforge.net/download.htm
> > From that, common procedures could be agreed upon. Some things are
> > common across all flavours of windows library - opening a dialog box
> > and getting a result, the concept of an event handler, low-level
> > routines like timers etc....
>
> I don't totally agree with this statement: if you force such common
> procedures, people
> will be limited to write libraries that all look the same. What if one wants
> to write
> a library that doesn't use an event-system, or if it uses an event-system that
> looks
> totally different than the common event-system? If such a common event-system
> would
> exist, how would it look? I have to say: the Win32Lib event-system is easy to
> use and
> pretty advanced, but what's the point of writing a (revolutionary?) new
> library if
> you're going to stick with old habits.
The problem you'll run into is that you're building on top of the same
base (the Win32 API) as everyone else. There's only so much you can do
to make it work differently, before you're adding huge amounts of
complexity and overhead to your library. Then you've got something that
is probably a lot slower, and is definitely more difficult to develop and
maintain, because you not only have to deal with the idiosyncracies of
MS, but of your own code.
> > The internals of the procedures and functions as implemented by
> > windows library designers do not have to be the same, but their
> > abstract behaviour should be the same, or similar enough to make
> > compatibility much easier.
>
> I disagree: the abstract behaviour of a Windows library should not be the same
> as any
> other Windows library. That's why I'm starting the new library: to make a
> library that
> doesn't suffer from backward compatibility (yet), and that implements some new
> features
> and ideas that haven't been implemented before.
> Compatibility can be a good thing, but is also very limiting.
As far as re-engineering the way the library hangs together, I agree.
There were some choices made in the earlier days of Win32Lib that have
made extensibility more difficult than it could have been. Admittedly,
some of this can be traced to me (I think I've learned a bit on the
subject, and tend to make better choices these days).
Matt Lewis
4. Re: Windows stuff...
Hi, Patrick!
You wrote:
----------
> From: Patrick Barnes <mrtrick at gmail.com>
> To: Euphoria Mailing List <EUforum at topica.com>
> Subject: Windows stuff...
> Sent: 13 sep 2004 y. 10:37
>
> 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.
If you need such the lib with the Win API constants
for your work, try please the constant.ew file from:
http://www.RapidEuphoria.com/w32engir.zip
and add new constants.
If you need such the lib with the Win API functions
for your work, try please the c_routin.ew file from:
http://www.RapidEuphoria.com/w32engir.zip
and add new functions.
Both these libs are extracted from the very powerful
Bernie Ryan's w32engin.ew library.
All MicroBucks - to Bernie, please, just now 
[snipped]
Regards,
Igor Kachan
kinz at peterlink.ru
5. Re: Windows stuff...
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. This is normal for
other languages such as C, Delphi, PowerBASIC etc. for years now.
> 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?
> 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. In order to 'define' a standard, it's not
necessary to write large and complicated documents.
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.
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".
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.
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.
> 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.
<snip>
Regards,
Juergen
6. Re: Windows stuff...
Juergen Luethje wrote:
> Yes, the API constants are necessary, and I actually think that they
> should ship with the official Euphoria distribution. This is normal for
> other languages such as C, Delphi, PowerBASIC etc. for years now.
>
> > 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?
>
> > 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. In order to 'define' a standard, it's not
> necessary to write large and complicated documents.
> 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.
>
> 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".
>
> 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.
>
> 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.
>
> > 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.
I've read your post, and you've convinced me that this should indeed be
standardized.
--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
Euphoria Message Board: http://uboard.proboards32.com
7. Re: Windows stuff...
If such a standard API-library would be made, the constants should have a
prefix, to reduce the chance of possible naming conflicts.
Win32Lib uses x as a prefix (xSetVisible, ...) for functions, but no prefix for
constants and structures. Perhaps it would be good to prefix all definitions.
I suggest 'api' as prefix, unless someone can find a better prefix (or multiple
prefixes).
Examples: apiSetVisible, apiWM_PAINT, ...
--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
Euphoria Message Board: http://uboard.proboards32.com
8. Re: Windows stuff...
- Posted by "Wolf" <wolfritz at king.igs.net>
Sep 13, 2004
-
Last edited Sep 14, 2004
> If such a standard API-library would be made, the constants should have a
> prefix, to reduce the chance of possible
naming conflicts.
> Win32Lib uses x as a prefix (xSetVisible, ...) for functions, but no prefix
> for constants and structures. Perhaps it
would be good to prefix all definitions.
> I suggest 'api' as prefix, unless someone can find a better prefix (or
> multiple prefixes).
> Examples: apiSetVisible, apiWM_PAINT, ...
Oh yes, that's what we all want, ...more typing,typing,typing !
Bad enough that win32lib already has w32 in front of everything just because
one, ( yes 1... if I recall ! ), person
didn't want to change his little 'wrapper'.
Since old code wouldn't 'include' your new API-library anyways, where would the
conflict be?
Haven't seen watcomWM_PAINT, or borlandWM_PAINT anywhere....
9. Re: Windows stuff...
- Posted by "Igor Kachan" <kinz at peterlink.ru>
Sep 13, 2004
-
Last edited Sep 14, 2004
Hi, Tommy, again!
You wrote:
----------
> From: Tommy Carlier <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: Windows stuff...
> Sent: 13 sep 2004 y. 23:03
>
> posted by: Tommy Carlier <tommy.carlier at telenet.be>
>
> If such a standard API-library would be made, the constants
> should have a prefix, to reduce the chance of possible naming
> conflicts.
I think, that a standard API-library must to have the
original Windows API names for constants and for routines.
Then you can just take the original API docs and to be sure
that your constant or routine's parameters are right.
I do not like any intermediate docs and any intermediate
names because of they are unreliable and duobtful anyway.
> Win32Lib uses x as a prefix (xSetVisible, ...) for functions,
It is one of Win32Lib drawbacks, I think.
> but no prefix for constants and structures.
It is a good side, I think.
> Perhaps it would be good to prefix all definitions.
No, I think. Too many extra job without any sense.
> I suggest 'api' as prefix, unless someone can find
> a better prefix (or multiple prefixes).
> Examples: apiSetVisible, apiWM_PAINT, ...
Then you must to know both: apiSetVisible and SetVisible,
apiWM_PAINT and WM_PAINT.
Same as to know two different languages.
Euphoria interface to .dll's is very simple and
it doesn't need any wrapping, I think.
If we use the original constants names and the original
functions names, we all use the same language, so to say.
Bernie's approach is this one - only the original names
for the API stuff. I like it.
Euphoria is very simple tool, all these more
complicated things are from Windows and C.
And if you want to program for Windows, the better
way is to learn Windows itself, not any wrapper,
I think. Euphoria gives us the interface, not wrapper.
But *creating* of a wrapper is a very good way to learn
Windows. Then yours wrapper is just yours synopsis, precis,
abstract on Windows API.
Just some thoughts. Just IMHO.
I'm not a professional programmer.
Regards,
Igor Kachan
kinz at peterlink.ru
10. Re: Windows stuff...
- Posted by Derek Parnell <ddparnell at bigpond.com>
Sep 13, 2004
-
Last edited Sep 14, 2004
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
> 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?
> 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. Which "pretty print"
do you use?
> 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.
> 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
11. Re: Windows stuff...
- Posted by Derek Parnell <ddparnell at bigpond.com>
Sep 13, 2004
-
Last edited Sep 14, 2004
Tommy Carlier wrote:
>
> If such a standard API-library would be made, the constants should have a
> prefix, to
> reduce the chance of possible naming conflicts.
This is really a precedence issue. Maybe such commonly used names should
be regarded as if they were reserved words and thus no-one can use
them for other things. Its a pity that Microsoft chose commonly
used words, such as "Normal", "Bold",...
> Win32Lib uses x as a prefix (xSetVisible, ...) for functions, but no prefix
> for constants
> and structures. Perhaps it would be good to prefix all definitions.
The 'x' prefix is a mistake. There should not have been any prefix. But hey,
its a "standard"!
Some constants have prefixes, some don't. Another mistake. The API ones
don't (and that's a good thing), and the ones created by the library do.
> I suggest 'api' as prefix, unless someone can find a better prefix (or
> multiple prefixes).
> Examples: apiSetVisible, apiWM_PAINT, ...
Don't make that mistake again. The prefixes are not needed if we regard
the Microsoft names as reserved words.
However, if you are writing a platform independant library, then you are
free to invent new names
--
Derek Parnell
Melbourne, Australia
12. Re: Windows stuff...
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Sep 13, 2004
-
Last edited Sep 14, 2004
On Mon, 13 Sep 2004 12:03:46 -0700, Tommy Carlier
<guest at RapidEuphoria.com> wrote:
>I suggest 'api' as prefix,
anti.
Just avoid any name which has a hit on EUForum search.
Regards,
Pete
13. Re: Windows stuff...
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Sep 13, 2004
-
Last edited Sep 14, 2004
On Mon, 13 Sep 2004 16:50:58 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
<snip & some>
>the API constants should ship with the official Euphoria distribution.
>This is normal for other languages such as <snip>
>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?
I think it would be great for Euphoria, but RC is of a mind not to:
1) support *any* os-biased stuff (over any other)
2) do *anything* that *two* users could not do better.
3) label "user contributions" as "substandard"
>RDS just has to include <whatever> in the official Euphoria
>distribution.
It hardly matters if it is available on "recent user contributions".
Make it and he might. Ask him to do what you cannot and he won't.
>since OpenEU isn't available yet
did I hear anyone volunteer to help me out recently? ;-((
>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.
Bollocks. Define your own standards. Discuss this amongst youselves
and ride roughshod over RDS. What are you, man or mouse? Sure, maybe
at the moment you can't do this with the language, but a library?!?!!
Oh, all the above is tongue in cheek, of course... )
Pete
14. Re: Windows stuff...
Regarding constant declarations, standardisation, and what should and
should not be included in Euphoria standard distribution
> Tommy Carlier wrote:
> > If such a standard API-library would be made, the constants should have a
> > prefix, to
> > reduce the chance of possible naming conflicts.
As many have said, this is a bad idea.. I have enough trouble
remembering constant names as it is!
Derek wrote:
> Don't make that mistake again. The prefixes are not needed if we regard
> the Microsoft names as reserved words.
Maybe that's going too far in the other direction. At the moment,
Euphoria has about 30(?) reserved words. It doesn't need several
thousand.
It seems to me, that as part of the Euphoria standard distribution,
Rob should add an include file containing, simply, all of the windows
API constants. Want access to them? Just include the file.
Given all the problems with namespacing, this could make things
difficult. Library A uses the constants in the standard include file.
Library B defines their own... = problems!
Rob, I think you need to make a change to the interpreter:
If a constant is defined multiple times, to the same value ...
e.g.
<<win32lib.ew>>
global constant True = 1, False = 0
...
<<vectorlib.e>>
global constant True = 1
global constant False = 0
...
And a program includes both of them... It should just ignore it, or
put up a warning.
If a constant is assigned to a function return, or an offset of an
earlier constant, that should be counted as well.
If someone's sadistic enough to define True as 0 and False as 1, then
it should report errors... constants are constants - they should have
the same values.
--
MrTrick
15. Re: Windows stuff...
In regards to the comments about the constants, If you hold a copy of
windows then you are licienced to use those names in any way in your
libraries and programs.
In regards to EU 2.5 suggestions. STOP YOUR BICKERING! I can think of many
suggestions like new operators etc... eg >> >>= & (bitwise and) | etc...
or mabee the type sequence being defined when initialized as
"" meaning string and only allocating 1-byte per element and flattening any
embedded strings that get appended etc... but when initialized as {}
normal memory alloc and behaviour is used.
We dont really want to pack or little U-bute interpretor with such things
that dont get used on a general day to day basis. So I have to agree with
Rob. If you need it just code it in!
16. 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
17. Re: Windows stuff...
Juergen Luethje wrote:
>
> Derek Parnell wrote:
<snip>
> 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.
For all the reasons Derek mentioned, I don't think that C-like structures
are going to come bundled as a standard include. The only way this will
come with Eu is if it's built in.
<snip>
> 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.
I'm not convinced that distributing such things is such a great idea.
As I say below, having constants isn't all that valuable. The Eu docs
currently point the new user to the most popular source of constants,
etc. The new programmer (Euphoria seems to be the first language for
many people) probably shouldn't be mucking about with that sort of
thing, and the more experienced will probably be comfortable with
downloading an additional package or thirty. These things are very
unstable compared with Eu (several to many updates per year for the
libraries, vs less than one per year for Eu), that anything that was
bundled would likely be out of date when many get the language.
<snip>
> 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, ...
<snip>
> ...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.
<snip>
> 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.
But making wheels is fun. :)
Frankly, the list of constants is the most trivial part of writing a
wrapper. Sure, there's a bit of work to get them in there, but it's
basically mindless copy and paste work. The tough part is providing the
layer above the raw API. It's possible to simply wrap the c_func() calls,
but this isn't a very useful library.
Matt Lewis
18. Re: Windows stuff...
Matt Lewis wrote:
>
> Juergen Luethje wrote:
> >
> > Derek Parnell wrote:
>
> <snip>
>
> > 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.
>
> For all the reasons Derek mentioned, I don't think that C-like structures
> are going to come bundled as a standard include. The only way this will
> come with Eu is if it's built in.
>
> <snip>
>
> > 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.
>
> I'm not convinced that distributing such things is such a great idea.
> As I say below, having constants isn't all that valuable. The Eu docs
> currently point the new user to the most popular source of constants,
> etc. The new programmer (Euphoria seems to be the first language for
> many people) probably shouldn't be mucking about with that sort of
> thing, and the more experienced will probably be comfortable with
> downloading an additional package or thirty. These things are very
> unstable compared with Eu (several to many updates per year for the
> libraries, vs less than one per year for Eu), that anything that was
> bundled would likely be out of date when many get the language.
>
> <snip>
>
> > 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, ...
>
> <snip>
>
> > ...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.
>
> <snip>
>
> > 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.
It depends on how people like to program.
Arwen is similar to Win32Lib, but has some different features.
W32engine is also very similar to Win32Lib, but is a bit simpler.
EuWinGUI is simpler and seems similar to DOS, which could be useful
for translating DOS programs to windows,
or for people used to DOS programming.
EUGTK is cross-platform, but harder to set up.
> > 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.
It would be nice to see somthing completly new and not just
the same as Win32Lib or any other library.
>
> But making wheels is fun. :)
>
> Frankly, the list of constants is the most trivial part of writing a
> wrapper. Sure, there's a bit of work to get them in there, but it's
> basically mindless copy and paste work. The tough part is providing the
> layer above the raw API. It's possible to simply wrap the c_func() calls,
> but this isn't a very useful library.
>
> Matt Lewis
>
19. 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
>
20. 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
> >
>
21. Re: Windows stuff...
Matt Lewis wrote:
> Juergen Luethje wrote:
>>
>> Derek Parnell wrote:
>
> <snip>
>
>> 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.
>
> For all the reasons Derek mentioned, I don't think that C-like structures
> are going to come bundled as a standard include. The only way this will
> come with Eu is if it's built in.
I would appreciate this even more.
> <snip>
>
>> 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.
>
> I'm not convinced that distributing such things is such a great idea.
> As I say below, having constants isn't all that valuable. The Eu docs
> currently point the new user to the most popular source of constants,
> etc. The new programmer (Euphoria seems to be the first language for
> many people) probably shouldn't be mucking about with that sort of
> thing, and the more experienced will probably be comfortable with
> downloading an additional package or thirty. These things are very
> unstable compared with Eu (several to many updates per year for the
> libraries, vs less than one per year for Eu), that anything that was
> bundled would likely be out of date when many get the language.
Agreed. AFAIK PowerBASIC for instance offers a file containing Windows
API constants and function wrappers for free download on their website,
so that it can easily be updated.
I don't think it's important that such a file (or several small files)
is actually bundled with the Euphoria interpreter. But it should follow
a standard. And this standard should take "the big picture" into account.
It could also be a user contribution, when this user(s) will follow the
standard, and will promise not to start a 12 month lasting trip around
the world next week. See what I mean?
I think some "big plan" is needed for what I'd like to see in Euphoria,
and developing such a plan as well as realizing it requires a certain
level of organization. In contrast to a company like RDS, we, the
Euphoria users, are only organized very loosely, so this is probably the
reason why we probably can't do it.
I just recalled what happened to me, when I learned to know Euphoria.
After reading almost all the docs, and running and reading many of the
demo programs, I wanted to translate some programs from Charles
Petzild's book "Programming Windows" to Euphoria. In order not to write
*anything* myself, I needed some Windows API constants, function
wrappers, and support for C-like structures. The most helpful thing that
I found in this regard was w32engin.
Then later, I wanted to write a windows program by my own, as simple as
possible. As far as I could see, EuWinGUI was the best choice. For
writing more complex programs, EuWinGUI didn't seem to be good, so I
used Win32Lib ...
What I mean is this: Win32Lib didn't simply provide the plain constants
and function wrappers when I needed them, w32engin didn't allow me to
write programs in a manner as comfortable as I wanted. EuWinGUI was
somewhere in the middle ...
(Disclaimer: Maybe what I write here is not true, but it is the way
things looked to me at that time.)
Of course just having constants isn't very valuable. But sometimes I
just need them. Sometimes I need more, and I would like it very much,
when all the different pieces fit together nicely.
That's what users of e.g. PowerBASIC or Delphi actually get AFAIK.
[snipped in agreement]
Regards,
Juergen
--
I didn't have time to write a short letter,
so I wrote a long one instead.
[Mark Twain]
22. Re: Windows stuff...
Juergen Luethje wrote:
<snip>
> I think some "big plan" is needed for what I'd like to see in Euphoria,
> and developing such a plan as well as realizing it requires a certain
> level of organization. In contrast to a company like RDS, we, the
> Euphoria users, are only organized very loosely, so this is probably the
> reason why we probably can't do it.
I don't quite agree here: I think we CAN do it. Maybe I'm naive, but I believe
that the Euphoria-community is tight enough to realize a standard. I think the
necessary organizational tools already exist: the mailing list, UBoard, the
chatroom, etc...
With people like [insert names here], I think we have enough experience and
wisdom
to achieve this.
--
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
Euphoria Message Board: http://uboard.proboards32.com
23. Re: Windows stuff...
- Posted by Derek Parnell <ddparnell at bigpond.com>
Sep 15, 2004
-
Last edited Sep 16, 2004
Juergen,
if its just the constants and structs you need, why don't
you write a program that takes the approved MS C header
files and convert them into Euphoria format?
You can get the header files by downloading the Windows SDK.
--
Derek Parnell
Melbourne, Australia
24. Re: Windows stuff...
- Posted by "Unkmar" <L3Euphoria at bellsouth.net>
Sep 15, 2004
-
Last edited Sep 16, 2004
----- Original Message -----
From: "Derek Parnell"
Sent: Wednesday, September 15, 2004 4:34 PM
Subject: Re: Windows stuff...
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Juergen,
> if its just the constants and structs you need, why don't
> you write a program that takes the approved MS C header
> files and convert them into Euphoria format?
>
> You can get the header files by downloading the Windows SDK.
>
> --
> Derek Parnell
> Melbourne, Australia
>
As if that hasn't been unsuccessfully been attempted in a batch matter
more than once.
Yeah, I guess you can manually convert them one at time for each
thing you want to work in Euphoria.
unkmar
25. Re: Windows stuff...
- Posted by Patrick Barnes <mrtrick at gmail.com>
Sep 15, 2004
-
Last edited Sep 16, 2004
That would be a useful tool, especially as it would keep up with
changes to the header files...
On Wed, 15 Sep 2004 13:34:35 -0700, Derek Parnell
<guest at rapideuphoria.com> wrote:
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Juergen,
> if its just the constants and structs you need, why don't
> you write a program that takes the approved MS C header
> files and convert them into Euphoria format?
>
> You can get the header files by downloading the Windows SDK.
>
> --
> Derek Parnell
> Melbourne, Australia
>
>
>
>
>
--
MrTrick
26. Re: Windows stuff...
Tommy Carlier wrote:
<snip>
> I don't quite agree here: I think we CAN do it. Maybe I'm naive, but I believe
> that the Euphoria-community is tight enough to realize a standard. I think the
> necessary organizational tools already exist: the mailing list, UBoard, the
> chatroom, etc...
> With people like [insert names here], I think we have enough experience and
> wisdom
> to achieve this.
I actually hope that I'm wrong, and you are right here, for the benefit
of the whole Eu community. Good luck with your new projekt!
Regards,
Juergen
27. Re: Windows stuff...
Attn: Rob Craig
I know you don't like getting involved with the various holy wars that
rise and fall on this mailing list, but... Would you consider a
euphoria include file containing ONLY windows API constants to the
standard distribution?
I would think that would help both users and creators of windows
libraries if they do not have to create their own lists. And a list of
constants doesn't restrict any user from using the windows library of
their choice. I imagine it would have the same kind of facility as
msgbox.e.
While on the subject of msgbox.e, has someone written a
library-agnostic msgbox library that allows dialogs to be created that
ask for user input (like "Enter a number between 1 and 100") ? That
kind of tool could be well-worth adding to the standard distribution
as well.
--
MrTrick
On Thu, 16 Sep 2004 07:08:05 +0200, Juergen Luethje <j.lue at gmx.de> wrote:
>
> Tommy Carlier wrote:
>
> <snip>
>
> > I don't quite agree here: I think we CAN do it. Maybe I'm naive, but I
> > believe
> > that the Euphoria-community is tight enough to realize a standard. I think
> > the
> > necessary organizational tools already exist: the mailing list, UBoard, the
> > chatroom, etc...
> > With people like [insert names here], I think we have enough experience and
> > wisdom
> > to achieve this.
>
> I actually hope that I'm wrong, and you are right here, for the benefit
> of the whole Eu community. Good luck with your new projekt!
>
> Regards,
> Juergen
28. Re: Windows stuff...
On 16 Sep 2004, at 15:18, Patrick Barnes wrote:
>
>
> Attn: Rob Craig
>
> I know you don't like getting involved with the various holy wars that
> rise and fall on this mailing list, but... Would you consider a
> euphoria include file containing ONLY windows API constants to the
> standard distribution?
>
> I would think that would help both users and creators of windows
> libraries if they do not have to create their own lists. And a list of
> constants doesn't restrict any user from using the windows library of
> their choice. I imagine it would have the same kind of facility as
> msgbox.e.
>
> While on the subject of msgbox.e, has someone written a
> library-agnostic msgbox library that allows dialogs to be created that
> ask for user input (like "Enter a number between 1 and 100") ? That
> kind of tool could be well-worth adding to the standard distribution
> as well.
Bach has it.
Kat
29. Re: Windows stuff...
Derek Parnell wrote:
> Juergen,
> if its just the constants and structs you need, why don't
> you write a program that takes the approved MS C header
> files and convert them into Euphoria format?
>
> You can get the header files by downloading the Windows SDK.
I needed them years ago, when I started with Euphoria. At that time I
didn't have enough experience to write such a program. In the meantime,
I got that stuff, because Chris Bensler sent it to me privately, two
years or so ago (Thanks again, Chris!). He wrote such a program: DAWG
(DLL Automatic Wrapper Generator).
In my previous posts in this thread, I wasn't writing about something
that I want to have privately on my harddisk, but about enhancements to
Euphoria in general. Something that is a kind of standard, so that my
programs can use it as well as the programs of all other Euphorians.
Something that is part of a _well planned framework_, where all pieces
fit together nicely, rather than a _patchwork_. The constants, structs
and function wrappers are only a small part of all this, I know. But I
thought it could be a beginning.
Thanks for the suggestion anyway.
Regards,
Juergen
--
A: Because it considerably reduces the readability of the text.
Q: Why?
A: Top posting.
Q: What is annoying in e-mail and news?
