For your consideration, here's a preview of some new seh_try_macros-type stuff...

[Gregory M. Turner]

On Wednesday 12 February 2003 08:25 pm, Ove Kaaven wrote:
> ons, 2003-02-12 kl. 23:41 skrev Gregory M. Turner:
> > On Wednesday 12 February 2003 01:44 pm, Alexandre Julliard wrote:
> > > "Gregory M. Turner" <gmturner007 at ameritech.net> writes:
> > > > Let me know what you think of these.  So far, I like them better
> > > > than the original versions, although in solving some limitations of
> > > > the old macros, I've created some new ones.
> > >
> > > Of course the main limitation is that this requires gcc, which means
> > > the macros can't be used in Wine itself. They might be useful for
> > > Winelib apps though.
> >
> > actually, since I got rid of "({ })" in this revision, I'm not sure it's
> > gcc-specfic at all... or did I miss something?
>
> I was under the impression that you were still using nested functions,

yup. forgot about those. 

> which is kind of a gcc-ism. So getting rid of ({ }) doesn't seem to buy
> anything, unless you *know* of a different compiler that has one but not
> the other. So you may as well keep ({ }) if it makes the macros more
> manageable or flexible.

makes sense.

> > > IMO you shouldn't use a variable at all, you should do everything on
> > > the stack. Otherwise it won't work when an exception happens in the
> > > middle of the exception code.
> >
> > Yup.  I'd prefer this myself... but unfortunately, I haven't found a way
> > to achieve it.  The problem is that the finally clause provided by the
> > user needs to be outside any lexical scope I can create (this is simply
> > because I have no way to put some close-brackets after the finally clause
> > like __ENDTRY).  So, if I'm going to use the approach of turning the
> > user's finally clause into a function, there's no way to get at it
> > without inheriting it from the "global" (relative to the place the macros
> > are invoked) lexical scope...
>
> Nested functions in gcc can access any of the parent function's local
> variables, would that work? (Or would this exception stuff break gcc's
> mechanism for this? not sure what it does)

They work.  And given ({ }), perhaps they can even be used effectively
(otherwise I am stuck because the block starts with __try, and ends with
__finally, where __LINE__ is neccesarily different... although maybe there's
a work-around in moving more logic into __try... )

The holy grail would be to achieve all this without any gcc'isms.  Ultimately, we
know we just need some "syntactic sugar" (what a lame term, sorry to use it)
around the basic algo used by __TRY & family...  Anyways, where there's a will...
I'll go back to the drawing board for these one last time I guess.

BTW, does wine really have non-gcc users?  Or is it just a general policy to
not be gcc-specific within the wine platform core since it might get recycled by other
projects, etc...?

> By the way, it seems to me that the particular installer I'm working on
> doesn't need NdrClientCall2 after all. Which installer was it that
> needed it?

I think it was something along the lines of "a standard Installshield 6 program"... 
maybe it was something proprietary.

-- 
gmt

"Of all the tyrannies, a tyranny sincerly exercised for the good of its victims may be
the most opressive. It may be better to live under robber barons than under omnipotent
moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at
some point be satiated; but those who torment us for our own good will torment us
without end, for they do so with the approval of their own conscience." - C. S. Lewis