1. Window API Coding
----- Original Message -----
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: What we really need...
>
> >Win32Lib does a superb job of hiding
>
> superb???
Agreed, it is not a superb hiding job. It could definitely be improved, and
hopefully will be.
> > the details of what is going on behind the scenes. API programming is
> > not for the faint of heart.
>
> Yeah atleast its your code and you can fix it to work like you want it to.
Your perspective is from a lone coder. Most programming in the world is done
in teams and is maintained by people other than the original coders. We
simply do not have the luxury of disregarding the needs of other
programmers. "Cowboys" need not apply.
> >There are more constants, data types, and
> > structures than you can shake a stick at. I have one file at home
> > *one*, which is about 55k full of nothing but constants. Nothing else.
>
> AGREED.
>
> > Point? It is easier for me to code API in just about any other language
> > than Euphoria because of structure support. Heck, the top three
> > assembly languages I use all have structures. I find it unfortunate
> > that Windows is so reliant on these things. I find it even more so that
> > Euphoria does not directly support them.
> >
> > Trying to program API structures with Euphoria is like pulling teeth.
> > If done directly via peeks and pokes, its nice and fast. Its also hard
> > to read and maintain.
That is why David Cuny created the allot()/fetch()/store() routines that are
used in win32lib. These are a trade-off between maintainability and
execution speed. I think he did a good job.
> Don,
>
> Ive been writting in C and using Masm32 myself and this Euphoria snippet
> is what I use to make code smaller and faster. Just a very small snipp..
>
> constant
> sizeof_trm = 32 -- Size of trm structure
>
> atom trm
> trm = allocate(sizeof_trm)
> mem_set(trm,0,32)
(shouldn't this be "mem_set(trm,0,sizeof_trm)" 
)
> constant
> trm_Op = trm + 0, -- Tsunami operation number
> trm_File = trm + 4, -- Tsunami file handle
> trm_DataPtr = trm + 8, -- Address of data buffer
> trm_DataLen = trm + 12, -- Length of data buffer
> trm_KeyPtr = trm + 16, -- Address of key buffer
> trm_KeyLen = trm + 24, -- Length of key buffer
> trm_KeyNo = trm + 28 -- Key number
>
> ->>>> is definatly better than
>
> trm_Op = allocate(4)
> trm_File = allocate(4)
> trm_DataPtr = allocate(4)
> trm_DataLen = allocate(4)
> trm_KeyPtr = allocate(4)
> trm_KeyLen = allocate(4)
> trm_KeyNo = allocate(4)
>
> and then peek4( ) each time you need access to a particular part of the
> struct sucks.
>
> Also, when you peek or poke a value you eliminate the extra "addition" (+)
> required
> e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start of
> your proggy.
>
> Maybe this is hard for some to understand but for me this seems easier and
> besides
> is obviously faster with less messy code.
You have actually code like this? If so, the coder would probably benefit
from learning a bit more about coding in general. This has nothing to do
with API coding. Of course, better support for structured memory areas would
be nice to have in Euphoria; at least we would have a unified way of doing
these necessary chores.
----------------
cheers,
Derek Parnell
2. Re: Window API Coding
- Posted by euman at bellsouth.net
Nov 12, 2002
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
> > >Win32Lib does a superb job of hiding
> >
> > superb???
>
> Agreed, it is not a superb hiding job. It could definitely be improved,
and
> hopefully will be.
>
> > > the details of what is going on behind the scenes. API programming is
> > > not for the faint of heart.
> >
> > Yeah atleast its your code and you can fix it to work like you want it
to.
>
> Your perspective is from a lone coder. Most programming in the world is
done
> in teams and is maintained by people other than the original coders. We
> simply do not have the luxury of disregarding the needs of other
> programmers. "Cowboys" need not apply.
yeah-haw!
>
> > >There are more constants, data types, and
> > > structures than you can shake a stick at. I have one file at home
> > > *one*, which is about 55k full of nothing but constants. Nothing
else.
> >
> > AGREED.
> >
> > > Point? It is easier for me to code API in just about any other
language
> > > than Euphoria because of structure support. Heck, the top three
> > > assembly languages I use all have structures. I find it unfortunate
> > > that Windows is so reliant on these things. I find it even more so
that
> > > Euphoria does not directly support them.
> > >
> > > Trying to program API structures with Euphoria is like pulling teeth.
> > > If done directly via peeks and pokes, its nice and fast. Its also
hard
> > > to read and maintain.
>
> That is why David Cuny created the allot()/fetch()/store() routines that
are
> used in win32lib. These are a trade-off between maintainability and
> execution speed. I think he did a good job.
SLOW!
> > Don,
> >
> > Ive been writting in C and using Masm32 myself and this Euphoria snippet
> > is what I use to make code smaller and faster. Just a very small snipp..
> >
> > constant
> > sizeof_trm = 32 -- Size of trm structure
> >
> > atom trm
> > trm = allocate(sizeof_trm)
> > mem_set(trm,0,32)
>
> (shouldn't this be "mem_set(trm,0,sizeof_trm)" )
>
> > constant
> > trm_Op = trm + 0, -- Tsunami operation number
> > trm_File = trm + 4, -- Tsunami file handle
> > trm_DataPtr = trm + 8, -- Address of data buffer
> > trm_DataLen = trm + 12, -- Length of data buffer
> > trm_KeyPtr = trm + 16, -- Address of key buffer
> > trm_KeyLen = trm + 24, -- Length of key buffer
> > trm_KeyNo = trm + 28 -- Key number
> >
> > ->>>> is definatly better than
> >
> > trm_Op = allocate(4)
> > trm_File = allocate(4)
> > trm_DataPtr = allocate(4)
> > trm_DataLen = allocate(4)
> > trm_KeyPtr = allocate(4)
> > trm_KeyLen = allocate(4)
> > trm_KeyNo = allocate(4)
> >
> > and then peek4( ) each time you need access to a particular part of the
> > struct sucks.
> >
> > Also, when you peek or poke a value you eliminate the extra "addition"
(+)
> > required
> > e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start
of
> > your proggy.
> >
> > Maybe this is hard for some to understand but for me this seems easier
and
> > besides
> > is obviously faster with less messy code.
>
> You have actually code like this?
Sure do, let me know of a better way in Euphoria Derek.
>If so, the coder would probably benefit
> from learning a bit more about coding in general.
I have learned all I know from Euphoria and Euphorians itself.
Who says code has to be a 1000 lines of complex arithmatic to beat
my few lines I presented.?
>This has nothing to do
> with API coding. Of course, better support for structured memory areas
would
> be nice to have in Euphoria; at least we would have a unified way of doing
> these necessary chores.
If you want C, then perhaps C suits you better....
You convert Win32lib over to C and I'll follow.
> ----------------
> cheers,
> Derek Parnell
Euman
3. Re: Window API Coding
13/11/2002 11:56:34 AM, euman at bellsouth.net wrote:
>>
>> That is why David Cuny created the allot()/fetch()/store() routines that
>are
>> used in win32lib. These are a trade-off between maintainability and
>> execution speed. I think he did a good job.
>
>SLOW!
Depending on the machine you are using, of course. On the two machines I have
access to, I cannot
notice any significant speed degradation. And this is acknowledging that your
hard-coded peek/poke
method is 5 times faster than the routines used in win32lib. But I can live with
800,000 fetch()
calls per second.
>
>> > Don,
>> >
>> > Ive been writting in C and using Masm32 myself and this Euphoria snippet
>> > is what I use to make code smaller and faster. Just a very small snipp..
>> >
>> > constant
>> > sizeof_trm = 32 -- Size of trm structure
>> >
>> > atom trm
>> > trm = allocate(sizeof_trm)
>> > mem_set(trm,0,32)
>>
>> (shouldn't this be "mem_set(trm,0,sizeof_trm)" )
>>
>> > constant
>> > trm_Op = trm + 0, -- Tsunami operation number
>> > trm_File = trm + 4, -- Tsunami file handle
>> > trm_DataPtr = trm + 8, -- Address of data buffer
>> > trm_DataLen = trm + 12, -- Length of data buffer
>> > trm_KeyPtr = trm + 16, -- Address of key buffer
>> > trm_KeyLen = trm + 24, -- Length of key buffer
>> > trm_KeyNo = trm + 28 -- Key number
>> >
>> > ->>>> is definatly better than
>> >
>> > trm_Op = allocate(4)
>> > trm_File = allocate(4)
>> > trm_DataPtr = allocate(4)
>> > trm_DataLen = allocate(4)
>> > trm_KeyPtr = allocate(4)
>> > trm_KeyLen = allocate(4)
>> > trm_KeyNo = allocate(4)
>> >
>> > and then peek4( ) each time you need access to a particular part of the
>> > struct sucks.
>> >
>> > Also, when you peek or poke a value you eliminate the extra "addition"
>(+)
>> > required
>> > e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start
>of
>> > your proggy.
>> >
>> > Maybe this is hard for some to understand but for me this seems easier
>and
>> > besides
>> > is obviously faster with less messy code.
>>
>> You have actually code like this?
>
>Sure do, let me know of a better way in Euphoria Derek.
Sorry for not making myself clear. I was not, and am not, attacking you or your
code. What I was
trying to say was -- have you really seen this style of code ...
trm_Op = allocate(4)
trm_File = allocate(4)
trm_DataPtr = allocate(4)
trm_DataLen = allocate(4)
trm_KeyPtr = allocate(4)
trm_KeyLen = allocate(4)
trm_KeyNo = allocate(4)
. . .
a = peek4u(trm_Op)
b = peek4u(trm_File)
. . .
It is THIS style of code that suggests that the author doesn't understand how to
use RAM
effectively. I was not refering to the method you tend to use; namely...
constant
sizeof_trm = 32 -- Size of trm structure
atom trm
trm = allocate(sizeof_trm)
mem_set(trm,0,32)
constant
trm_Op = trm + 0, -- Tsunami operation number
trm_File = trm + 4, -- Tsunami file handle
trm_DataPtr = trm + 8, -- Address of data buffer
trm_DataLen = trm + 12, -- Length of data buffer
trm_KeyPtr = trm + 16, -- Address of key buffer
trm_KeyLen = trm + 24, -- Length of key buffer
trm_KeyNo = trm + 28 -- Key number
. . .
a = peek4u(trm_Op)
b = peek4u(trm_File)
. . .
However, since you have invited me to suggest improvements...
Your solution is fine so long as you don't need to refer to two or more
different RAM locations
that contain the same structure. The code you have shown has fixed the location
of the trm structure
and the identifiers used to access its components. These identifiers can ONLY be
used to access your
specific single manifestation of the trm structure. They cannot be used to
access other trm
structures, such as ones passed to your code from other routines.
The style of coding you prefer encourages high maintenace costs. If that is fine
for you then you
don't have a problem.
>>If so, the coder would probably benefit
>> from learning a bit more about coding in general.
>
>I have learned all I know from Euphoria and Euphorians itself.
Maybe you you should get out a bit more often 
>Who says code has to be a 1000 lines of complex arithmatic to beat
>my few lines I presented.?
>
No one. Have they?
>>This has nothing to do
>> with API coding. Of course, better support for structured memory areas
>would
>> be nice to have in Euphoria; at least we would have a unified way of doing
>> these necessary chores.
>
>If you want C, then perhaps C suits you better....
>You convert Win32lib over to C and I'll follow.
I do not want C more than a better Euphoria, even though C is a great language
for low-level coding
(device drivers, operating systems, etc...)
I'd love to make win32lib a DLL one day, but first we have to get over the
routine_id passing issue
that presents.
---------
Cheers,
Derek Parnell
4. Re: Window API Coding
Thanks for your thoughts Matt. This is a really really low priority item on
my list, but I'll keep a copy of your note just in case somebody ever gets
around to the DLL idea on day.
----------------
cheers,
Derek Parnell
----- Original Message -----
From: "Matthew Lewis" <matthewwalkerlewis at YAHOO.COM>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Window API Coding
>
>
> > From: Derek Parnell [mailto:ddparnell at bigpond.com]
>
> > I'd love to make win32lib a DLL one day, but first we have to
> > get over the routine_id passing issue
> > that presents.
>
> I've never really bought into the win32lib as dll idea, for a couple of
> reasons--these are mainly doubts that could quite likely be proven wrong.
> We would still need some wrapper, unless you want to subject people to
> c_func, et. al. all over the place. Given that, I'm not sure how much of
a
> speedup you'd be likely to see, at least in general. There are perhaps a
> few routines that would see significant enough increases in speed to
> overcome the additional layer of overhead. Besides, part of the appeal of
> win32lib (to me, at least) is that its native code, no dll required (yeah,
> yeah, but everyone needs to use the windows dlls to function, so they
don't
> count).
>
> Assuming that it is worth it to move to a compiled win32lib, it should be
> fairly straightforward to pass routine_id's. I'll assume that in the
> wrapper for the win32lib dll, you've used the same names, so that we can
> 'seamlessly' go from an interpreted to compiled win32lib. In other words,
I
> can use setHandler() in the same manner. Now, in your wrapper, you need
to
> set up a couple of call back functions (or one, with an added parameter to
> specify func/proc distinctions) to call_func/proc the routine_id's of your
> app. The tricky part is passing sequences back and forth, since a
call_back
> has to pass a 32-bit integer:
>
>
> -- win32libdll.ew
>
> constant
> win32libdll = open_dll("win32lib.dll"),
> xGetSequence = define_c_func( win32libdll, "getSequence", {},
E_SEQUENCE ),
> xPassSequence = define_c_proc( win32libdll, "passSequence", {E_SEQUENCE} )
>
> procedure passSequence( sequence seq)
> c_proc( xPassSequence, { seq } )
> end procedure
>
> function getSequence()
> return c_func( xGetSequence, {} )
> end function
>
> global procedure setHandler(...)
> c_proc( xSetHandler, {...})
> end function
>
> -- call back used by the dll
> function w32CallFunc( integer rid )
> object result
> result = call_func( rid, getSequence() )
> if sequence(result) then
> passSequence( result )
> result = 0
> end if
> return result
> end function
>
> -- call back used by the dll
> function w32CallProc( integer rid )
> call_proc( rid, getSequence() )
> return 0
> end function
>
> -- end
>
>
>
>
