IPCWorkshop

[Dan Kegel]

There's a fun little test app (with source) called IPCWorkshop at
http://www.codeproject.com/threads/ipcworkshop.asp

I noticed it probably needs a Sleep(500) in its Mailslot
receive loop, and a lot of its stuff doesn't seem to work
on my Windows Me system, but its "filemapping" and "mailslots"
modes do seem to work on Windows Me.  (Oddly, "Clipboard"
doesn't work for me on Windows Me.  This app is fairly new,
maybe it's still a bit buggy.)

None of its modes seem to work on Wine.  Not sure why.
In server mode, it never redraws, so the GUI is messed
up somehow.  I'm sure this app triggers several Wine bugs.

Anyway, if anyone's looking for simple test apps that
exercise various IPC methods, this one might be worth checking out.
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

visual studio 6 not happy?

[Dan Kegel]

wine cvs doesn't run visual studio 6 especially happily.
Building a simple app fails with "Error executing rc.exe".

I wonder if this is another example of that named pipe failure...
it certainly is calling PeekNamedPipe to beat the band, and
http://www.microsoft.com/msj/0698/win320698.htm
says that vcspawn.exe (used to run external processes)
probably uses named pipes to communicate with msdev.

Guess it's back to the commandline for me.  Yep, exporting
a makefile and building with nmake works better.
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: SMATCH: add missing LeaveCriticalSection

[Dan Kegel]

Michael Stefaniuc wrote:

on some error path the critical section wasn't released.
Found with smatch's help.


I'm impressed.  Didn't know smatch could detect this kind of
thing in Wine code.

For those who haven't heard of smatch, see http://smatch.sf.net
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

smatch, something like the Stanford Checker

[Michael Stefaniuc]

Hello,

i always dreamed to have something like the Stanford Checker for Wine
and some days ago i've seen on freshmeat smatch
http://smatch.sourceforge.net/ . It's a project from KernelJanitors and
it seems usefull, at least it's worth an entry on Dimi's janitorial
page.
A short description:
Smatch is basicaly a patch to gcc-3.1.1 that makes the gcc dump out it's
internal represantation of the code and a set of perl modules/scripts to
ease the parsing of the dumped code. Most of the perl scripts are for
the Linux Kernel but writing new scripts seems to be easy. I wrote
(well, mostly adapted an existing script for the kernel) one script
http://people.redhat.com/mstefani/wine/smatch/enter_leave.pl
(if we decide to adopt smatch it should probably go to $wine/tools/smatch/)
to find code path with missing LeaveCriticalSection's. Scripts to find
some other usefull things like fd, DC, GDI obejects leaks should be easy
to write.

Comments?
bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
System Administration   Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart



msg17380/pgp0.pgp
Description: PGP signature

Re: Windows API (What I have so far)

[Shachar Shemesh]

In our continous effort to to avoid understanding what the other one is 
writing by sending our own stuff, here is a version of my parser that 
does the actual generation of a HTML table.

Also attached is this program's output when run against Dave's original 
HTML. The HTML is compressed with bzip, as when compressed with gzip it 
was over this list's quota (44Kb). Be warned that the file size after 
uncompress is 2.7MB(!!!), and it poses quite a problem for Mozilla to 
display (though it manages to, eventually).

Also not that the resulting display is as ugly as an airport. This was, 
in fact, on purpose. If you view the source of the HTML, you will find 
that it was meant to be styled with a CSS, and thus contain no formating 
directives, but do contain "class" directives. Unfortunetly, my web 
design skills are close to nada, and so I do not consider myself up to 
the task of creating such a style sheet. If anyone else present would 
like to generate CSS for this table, please keep in mind that Table Data 
cells of class "CyclicDepend" are cells that, if marked, indicate that 
the DLL has a cyclic dependancy. It is therefor probably a good idea to 
give them a different background.

Last, this program still has a bug, though I don't know how serious. 
When run it issues lots of warnings about use of uninitialized var. I 
believe this has the potential of indicating a real bug in the program, 
but the DLLs I have sample checked against the original input proved to 
be ok.

Share and enjoy.

   Shachar

Dave wrote:

Ok, here is new HTML.  I used c:\windows as the path so gdiplus would 
be included.

I'll add the newlines, but haven't yet.  So new HTML doesn't have them.

At 12:25 AM 2/10/2003 +0200, you wrote:

David Miller wrote:


I checked my system for gdiplus.dll.  It simply is not under 
c:\windows\system32, which is the path I gave when I made the sample 
HTML.  It is under c:\windows\winsxs.

The new program strips the path and dll extension in the HTML output.
Would it be better to reverse that change, and include the path and 
extension to be compatible with your parser?


I don't think that would be necessary. Just make sure that in the 
HTML you add a real NL after each  (or otherwise make the 
interesting parts at most one per line), and that SHOULD work.

My parser removed the path if it's there, and removes the extension 
if it's .dll. If the files have no path and no extension, that should 
still work fine (I would love to either have you check that, or give 
me an up to date HTML for me to check against).

   Shachar

--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/








--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/




parse.pl
Description: Perl program


winxp_dll_map.html.bz
Description: Binary data

Re: Windows API (What I have so far)

[Dave]

Ok, here is new HTML.  I used c:\windows as the path so gdiplus would be 
included.

I'll add the newlines, but haven't yet.  So new HTML doesn't have them.

At 12:25 AM 2/10/2003 +0200, you wrote:
David Miller wrote:


I checked my system for gdiplus.dll.  It simply is not under 
c:\windows\system32, which is the path I gave when I made the sample 
HTML.  It is under c:\windows\winsxs.

The new program strips the path and dll extension in the HTML output.
Would it be better to reverse that change, and include the path and 
extension to be compatible with your parser?

I don't think that would be necessary. Just make sure that in the HTML you 
add a real NL after each  (or otherwise make the interesting parts at 
most one per line), and that SHOULD work.

My parser removed the path if it's there, and removes the extension if 
it's .dll. If the files have no path and no extension, that should still 
work fine (I would love to either have you check that, or give me an up to 
date HTML for me to check against).

   Shachar

--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

Re: Windows API (What I have so far)

[Shachar Shemesh]

David Miller wrote:


I checked my system for gdiplus.dll.  It simply is not under 
c:\windows\system32, which is the path I gave when I made the sample 
HTML.  It is under c:\windows\winsxs.

The new program strips the path and dll extension in the HTML output.  
Would it be better to reverse that change, and include the path and 
extension to be compatible with your parser? 

I don't think that would be necessary. Just make sure that in the HTML 
you add a real NL after each  (or otherwise make the interesting 
parts at most one per line), and that SHOULD work.

My parser removed the path if it's there, and removes the extension if 
it's .dll. If the files have no path and no extension, that should still 
work fine (I would love to either have you check that, or give me an up 
to date HTML for me to check against).

   Shachar

--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

Re: Windows API (What I have so far)

[David Miller]

I checked my system for gdiplus.dll.  It simply is not under 
c:\windows\system32, which is the path I gave when I made the sample 
HTML.  It is under c:\windows\winsxs.

The new program strips the path and dll extension in the HTML 
output.  Would it be better to reverse that change, and include the path 
and extension to be compatible with your parser?

At 09:39 AM 2/9/2003 +0200, you wrote:
Dave wrote:


Thanks, I will look into merging the two together sometime soon, if no 
one beats me to it.  First I want to make the existing program a little 
more readable before it becomes unmanageable and even I don't know what 
it does.  :)

The sample HTML I created was done from my laptop, which has all sorts of 
applications installed.  There might be a lot of irrelevant 
information.  It may become a much smaller table once it's run on a clean 
system.

Please keep the foreend/backend approach, as I have neither tools nor 
environment to run your original perl prog, and I would still like to get 
the HTML rendering. I think the best approach is for a backend to dump the 
raw data into a easy to parse format (and your original format was, as you 
can see, not too difficult once you add the newlines), and a frontend that 
formats these into HTML.

As for the unnecessaries - 238 columns is much better than I feered. More 
worriying than the sheer number is the warning my prog issues when run on 
your original input (like I said - I don't have any other):
DLL fsusd depends on DLL gdiplus, which does not exist
DLL photowiz depends on DLL gdiplus, which does not exist
DLL shmedia depends on DLL gdiplus, which does not exist
DLL webvw depends on DLL gdiplus, which does not exist
DLL wiadefui depends on DLL gdiplus, which does not exist
DLL wiavideo depends on DLL gdiplus, which does not exist
DLL wiavideo depends on DLL gdiplus, which does not exist
DLL wiavusd depends on DLL gdiplus, which does not exist
Manually checking that with your output reveals that to be a correct 
assesment (i.e. - not a bug). there are references to a DLL called 
"gdiplus", which does not itself show in the output. Care to check your 
system and find out how that came about?

   Shachar


At 01:11 AM 2/9/2003 +0200, you wrote:


Attached is a perl prog that taked David's original HTML output with a 
single necessary preprocessing (replacing each  with \n), and 
issues a list of the DLLs (no deps as of yet) in the order discussed 
before (i.e. - A depends on B -> A is higher, A has more dependants than 
B -> A is higher).

I will now work on displaying this in a table. Shouldn't be too 
difficult (the fact that the table will be 238 coloumns wide 
nonwithstanding). Could be worse. The table is 1141 lines long.

This does not work with David's new prog yet, but as the both of them 
are in perl I am sure it will not be too big a deal to merge the two 
progs into one. This will just simplify the process of getting the 
initial input (currently parsed from the HTML).

   Shachar

Shachar Shemesh wrote:

Havn't had a chance to look at your script yet, but I am two hours' 
work away from something that parses the original HTML you gave, and 
outputs the monster in the form Dimi and I suggested. I will attach it 
later today, and then you can merge the two, if you like.

   Shachar

Quoting David Miller <[EMAIL PROTECTED]>:



I thought a few of you might be interested in the current status of this
script, so here is an update.  I will attach a copy in case anyone wants
to
test it, or add functionality or fixes.  I'd be interested in the
results of
any tests, especially if you discover any parsing errors.

It is far from complete, but at this stage does the following:

- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of
paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results
in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:

   DLL nameimported DLLimported API

- parse exports.txt as follows, and save the results in
exported_api.txt:

   DLL nameexported API

Future plans:

- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine






--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/







--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

More on the Treeview

[Drew \"DanteAliegri\" Ogle]

also, when I replaced the comctl32 with a native,
it didn't fix the problem, so I'd think its safe to say
that the error is occuring outside comctl32..


-Dante

Re: Tried to install Red Alert - Yuri's Revenge

[Sylvain Petreolle]

 --- [EMAIL PROTECTED] a écrit : 
> and it failed.  The installer said that comctl32.dll was too old, did
> I want a new one, so I said no.  They it said that DirectX was a
level
> 0 (well actually a long list of 00.00s), and asked if I wanted to
> install what looked like version 4 (although the docs with the CD say
that it
> will install 8.0a).  When I said no to that the installer quit.
 
> This was a Debian unstable system, which is using the latest
> Wine.deb.
what is the version of this deb ?
check http://www.winehq.com/docs/wine-user/bugs.shtml
for proper bugreport.

=
Sylvain Petreolle
[EMAIL PROTECTED] 
Fight against Spam ! http://www.euro.cauce.org/en/index.html
ICQ #170597259

"Don't think you are. Know you are." Morpheus, in "Matrix".

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Treeview Regression

[Drew \"DanteAliegri\" Ogle]

There has been a treeview regression, since at least 20030115,
I assumed someone would take it up, but noone has.
I will try to fix it, but a rather simple testcase ( ~200 lines of C )
is at http://open-socket.dyndns.org/~dante/treeview-testcase.tar.bz2

What appears to be happening, is when the dialog recieves a message
that is WM_NOTIFY , it excpets the lparam to 1) be
LPNMHDR, and lparam->code to be TVN_SELCHANGED.
the lparam->code that wine appears to be returning is 0.


-Dante

Tried to install Red Alert - Yuri's Revenge

[David . Goodenough]

and it failed.  The installer said that comctl32.dll was too old, did I
want a new one, so I said no.  They it said that DirectX was a level 0
(well actually a long list of 00.00s), and asked if I wanted to install
what looked like version 4 (although the docs with the CD say that it will
install 8.0a).  When I said no to that the installer quit.

This was a Debian unstable system, which is using the latest Wine.deb.

So how is it detecting the age of comctl32, and how should I convince it
that the dll really is up to date, and do I need to install the front bits
of DirectX in order to use the support that Wine is now increasingly
providing, or should Wine be advertising its DirectX support differently.
This is the first time I have tried to install a DirectX program on the
machine, and I do not know quite how I should proceed.

Thanks in advance

David

Re: Crash in MSVCRT_type_info_name

[Marcus Meissner]

On Sun, Feb 09, 2003 at 06:29:14PM +0100, Uwe Bonnes wrote:
> Hallo,
> 
> Altera Quartus crashes soon after start when run with builtin msvcrt:
> 0009:Call msvcrt.?name@type_info@@QBEPBDXZ(0062) ret=407ec69a
> trace:msvcrt:MSVCRT_type_info_name trace:seh:EXC_RtlRaiseException
> code=c005 flags=0 addr=0x402a680b
> trace:seh:EXC_RtlRaiseException  info[0]=
> trace:seh:EXC_RtlRaiseException  info[1]=006a
> 
> I didn't see where the argument(0062) comes from.
> 
> Any ideas?

Well, however we implemented this function, we most likely did it wrong
I would guess.

Ciao, Marcus

Crash in MSVCRT_type_info_name

[Uwe Bonnes]

Hallo,

Altera Quartus crashes soon after start when run with builtin msvcrt:
0009:Call msvcrt.?name@type_info@@QBEPBDXZ(0062) ret=407ec69a
trace:msvcrt:MSVCRT_type_info_name trace:seh:EXC_RtlRaiseException
code=c005 flags=0 addr=0x402a680b
trace:seh:EXC_RtlRaiseException  info[0]=
trace:seh:EXC_RtlRaiseException  info[1]=006a

I didn't see where the argument(0062) comes from.

Any ideas?

Bye
-- 
Uwe Bonnes[EMAIL PROTECTED]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Re: IDA regression again :-)

[Eric Pouech]

Yeah, it works better now (I finally managed to get it to work before that :
I just had to click a long time for the console to register my clicks :-) ).

curses seem to behave strangely here...
btw, you'll get the same issues with the ESC key :-(


And 'Backspace' and 'Return' seems to be still broken :-)

well, I would agree for Return (it's now fixed), but Backspace works 
here (ie. it generates the same code than the USER backend, and my 
version of IDA recognizes it). Could you elaborate ?

Anyway, where can one find docs on how the console works (MSDN, ...) to be
able to help out debug 'simple' stuff ?

1/ Console API is documented on MSDN
2/ Console behavior is documented under Windows (even registry keys...), 
which normally we should mimic
3/ what's not documented is wine internal protocols (kernel32 <=> server 
<=> wineconsole)

A+
--
Eric Pouech

Re: Windows API (What I have so far)

[Shachar Shemesh]

Dave wrote:


Thanks, I will look into merging the two together sometime soon, if no 
one beats me to it.  First I want to make the existing program a 
little more readable before it becomes unmanageable and even I don't 
know what it does.  :)

The sample HTML I created was done from my laptop, which has all sorts 
of applications installed.  There might be a lot of irrelevant 
information.  It may become a much smaller table once it's run on a 
clean system.

Please keep the foreend/backend approach, as I have neither tools nor 
environment to run your original perl prog, and I would still like to 
get the HTML rendering. I think the best approach is for a backend to 
dump the raw data into a easy to parse format (and your original format 
was, as you can see, not too difficult once you add the newlines), and a 
frontend that formats these into HTML.

As for the unnecessaries - 238 columns is much better than I feered. 
More worriying than the sheer number is the warning my prog issues when 
run on your original input (like I said - I don't have any other):
DLL fsusd depends on DLL gdiplus, which does not exist
DLL photowiz depends on DLL gdiplus, which does not exist
DLL shmedia depends on DLL gdiplus, which does not exist
DLL webvw depends on DLL gdiplus, which does not exist
DLL wiadefui depends on DLL gdiplus, which does not exist
DLL wiavideo depends on DLL gdiplus, which does not exist
DLL wiavideo depends on DLL gdiplus, which does not exist
DLL wiavusd depends on DLL gdiplus, which does not exist

Manually checking that with your output reveals that to be a correct 
assesment (i.e. - not a bug). there are references to a DLL called 
"gdiplus", which does not itself show in the output. Care to check your 
system and find out how that came about?

   Shachar


At 01:11 AM 2/9/2003 +0200, you wrote:


Attached is a perl prog that taked David's original HTML output with 
a single necessary preprocessing (replacing each  with \n), 
and issues a list of the DLLs (no deps as of yet) in the order 
discussed before (i.e. - A depends on B -> A is higher, A has more 
dependants than B -> A is higher).

I will now work on displaying this in a table. Shouldn't be too 
difficult (the fact that the table will be 238 coloumns wide 
nonwithstanding). Could be worse. The table is 1141 lines long.

This does not work with David's new prog yet, but as the both of them 
are in perl I am sure it will not be too big a deal to merge the two 
progs into one. This will just simplify the process of getting the 
initial input (currently parsed from the HTML).

   Shachar

Shachar Shemesh wrote:

Havn't had a chance to look at your script yet, but I am two hours' 
work away from something that parses the original HTML you gave, and 
outputs the monster in the form Dimi and I suggested. I will attach 
it later today, and then you can merge the two, if you like.

   Shachar

Quoting David Miller <[EMAIL PROTECTED]>:



I thought a few of you might be interested in the current status of 
this
script, so here is an update.  I will attach a copy in case anyone 
wants
to
test it, or add functionality or fixes.  I'd be interested in the
results of
any tests, especially if you discover any parsing errors.

It is far from complete, but at this stage does the following:

- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, 
stripped
of
paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results
in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:

   DLL nameimported DLLimported API

- parse exports.txt as follows, and save the results in
exported_api.txt:

   DLL nameexported API

Future plans:

- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine







--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/









--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

Re: Windows API (What I have so far)

[Dave]

Thanks, I will look into merging the two together sometime soon, if no one 
beats me to it.  First I want to make the existing program a little more 
readable before it becomes unmanageable and even I don't know what it does.  :)

The sample HTML I created was done from my laptop, which has all sorts of 
applications installed.  There might be a lot of irrelevant 
information.  It may become a much smaller table once it's run on a clean 
system.

At 01:11 AM 2/9/2003 +0200, you wrote:
Attached is a perl prog that taked David's original HTML output with a 
single necessary preprocessing (replacing each  with \n), and 
issues a list of the DLLs (no deps as of yet) in the order discussed 
before (i.e. - A depends on B -> A is higher, A has more dependants than B 
-> A is higher).

I will now work on displaying this in a table. Shouldn't be too difficult 
(the fact that the table will be 238 coloumns wide nonwithstanding). Could 
be worse. The table is 1141 lines long.

This does not work with David's new prog yet, but as the both of them are 
in perl I am sure it will not be too big a deal to merge the two progs 
into one. This will just simplify the process of getting the initial input 
(currently parsed from the HTML).

   Shachar

Shachar Shemesh wrote:

Havn't had a chance to look at your script yet, but I am two hours' work 
away from something that parses the original HTML you gave, and outputs 
the monster in the form Dimi and I suggested. I will attach it later 
today, and then you can merge the two, if you like.

   Shachar

Quoting David Miller <[EMAIL PROTECTED]>:



I thought a few of you might be interested in the current status of this
script, so here is an update.  I will attach a copy in case anyone wants
to
test it, or add functionality or fixes.  I'd be interested in the
results of
any tests, especially if you discover any parsing errors.

It is far from complete, but at this stage does the following:

- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of
paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results
in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:

   DLL nameimported DLLimported API

- parse exports.txt as follows, and save the results in
exported_api.txt:

   DLL nameexported API

Future plans:

- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine








--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

Re: AppDB updated

[Z_God]

Is there any way to get the percentage of perfectly working apps?
That would be really interesting.

Op zondag 9 februari 2003 05:01, schreef Sylvain Petreolle:
> there is some problem I think.
> I looked at utilities/filesystem.
> almost every app is set to level 0.
>
> example : ddrcrypt.exe, reported as "Works really well!!" in desc, is
> set to level 0 !
> http://appdb.winehq.org/appview.php?appId=876
>
>  --- Andreas Mohr <[EMAIL PROTECTED]> a écrit : > Hi all,
>
> > I just (well, not "just": more like a matter of a whole week or so)
> > committed about 170 or so new entries to the AppDB, thus reaching
> > a count of 1523 distinct applications.
> >
> > I guess I'm feeling really exhausted now...
> >
> > Anyway, have fun browsing the site at http://appdb.winehq.org !
> >
> > Andreas Mohr
>
> =
> Sylvain Petreolle
> [EMAIL PROTECTED]
> Fight against Spam ! http://www.euro.cauce.org/en/index.html
> ICQ #170597259
>
> "Don't think you are. Know you are." Morpheus, in "Matrix".
>
> ___
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> Yahoo! Mail : http://fr.mail.yahoo.com

Re: IDA regression again :-)

[Lionel Ulmer]

> does the first patch help ?

Yeah, it works better now (I finally managed to get it to work before that :
I just had to click a long time for the console to register my clicks :-) ).

And 'Backspace' and 'Return' seems to be still broken :-)

Anyway, where can one find docs on how the console works (MSDN, ...) to be
able to help out debug 'simple' stuff ?

> as a dirty work around, apply the second patch, and define WC_USER (to 
> 1) in your env when you want USER backend (instead of CURSES)

Did not test it as IDA now works 'almost' fine with patch 1.

Thanks,
  Lionel (still IDAing Tribes :-/ )

-- 
 Lionel Ulmer - http://www.bbrox.org/

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

[Gregory M. Turner]

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.

This version avoids ({ }) entirely, in favor of Ove's original thought,
which was to use __LINE__; therefore, putting multiple __(finally|except)
clauses in the same line probably breaks.

Otherwise, these are better macros.  They are slightly more easily
understood (although still pretty darn confusing, especially in 
the debugger), probably more resiliant against compiler optimizations,
and have much less awful performance.  Best of all, they ought to 
properly re-raise exceptions after executing finally clauses.

There is some cruft in there, btw, which will be fixed before I
submit anything to patches.

They still break break/continue, of course, since they still rely on 
__TRY / __EXCEPT blocks to do the dirty-work.

You can run the original seh_macros.c test against these successfully,
except for the "absurdly nested" ones which use macros and presumably
would fail quite dramatically due to __LINE__ duplications.

FWIW, compared to the degree of "pressing need" for these macros,
I have already spent way too much time on them...  But the old ones
kind of sucked, and, frankly, it's a fun semantic puzzle that requires
pusing the limits of good old cpp just a _bit_ further than may have been
intended ... so, here it is.

Note that I'm declaring a variable in the header file here.  I guess,
I should fix this by creating an internal API in ntdll?  I never quite
figured out whether global non-static variables in a dll are thread-local,
or what...  (same for lexically scoped static ones -- real clueless here, and
building a new system so I don't have much doco's at my fingertips ATM)

Sooo Anyone want to help me decide what's the best way to get a thread-local
global variable instantiated?  Probably, my previous attempt with TlsAlloc was 
semantically correct, but that was /way/ too fat a solution, I'd like something
much quicker if its at all possible.

Otherwise this won't be threadsafe, which seems like a bad call, esp. since
such code will probably end up being used to guard against unacceptable resource 
leakage..

warning, cut-and-pasted this patch in chunks so it might be bugged... should
be clear enough how to duplicate, however, if it fails...

--- ../wine.vanilla/include/wine/exception.h2003-01-29 21:50:14.0 -0600
+++ ./include/wine/exception.h  2003-02-09 01:33:45.0 -0600
@@ -21,8 +21,12 @@
 #ifndef __WINE_WINE_EXCEPTION_H
 #define __WINE_WINE_EXCEPTION_H
 
+/* WRC can't find setjmp.h.  Does it not check /usr/include? */
+#if (!(defined(__WRC__)))
+
 #include 
 #include "windef.h"
+#include "excpt.h"
 
 /* The following definitions allow using exceptions in Wine and Winelib code
  *
@@ -59,6 +63,16 @@
  *  You can use them to leave a __EXCEPT block though.
  *
  * -- AJ
+ *
+ * Now we can implement the __try/__except/__finally magic of VC++ as standard (?) 
+macros.
+ * this is a "good enough" implementation, it's incomplete, but should suffice for 
+most uses.
+ * 
+ * The macros require some symbols to be found in ntdll.dll.so, so link with that DLL 
+if you
+ * use them.
+ *
+ * If you are using VC++ and this header, #define USE_COMPILER_EXCEPTIONS before you 
+include it.
+ *
+ * -gmt
  */
 
 /* Define this if you want to use your compiler built-in __try/__except support.
@@ -146,8 +160,90 @@
 extern DWORD __wine_finally_handler( PEXCEPTION_RECORD record, EXCEPTION_FRAME *frame,
  CONTEXT *context, LPVOID pdispatcher );
 
+
+#if (!defined(NO_VC_SEH_MACROS))
+
+#ifndef _WINE_ALREADY_DEFINED_SEH_MACROS__
+#define _WINE_ALREADY_DEFINED_SEH_MACROS__
+
+/* fixme: should be renamed since these are used for except too */
+typedef void (*__p_seh_finally_executer) ();
+typedef void (*__p_seh_dotry_executer) (__p_seh_finally_executer);
+__p_seh_finally_executer __thread_outermost_handler_ptr;
+
+#define __SEH_LINEUNIQ_CAT2(x,y) __SEH_LINEUNIQ_ ## y ## x
+#define __SEH_LINEUNIQ_CAT1(x,y) __SEH_LINEUNIQ_CAT2(x,y)
+
+#define __SEH_LINEUNIQ_NULLMACRO(x) x
+#define __SEH_LINEUNIQ_MAGIC_LINE __SEH_LINEUNIQ_NULLMACRO( __LINE__ )
+
+#define __SEH_LINEUNIQ_ID(x) __SEH_LINEUNIQ_CAT1( __SEH_LINEUNIQ_MAGIC_LINE , x )
+
+#define __try \
+do { \
+void dotry(__p_seh_finally_executer fin) { \
+   __label__ __seh_macro_exit_spot; \
+auto WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler); \
+__TRY { \
+ { \
+
+#define __finally  \
+  } \
+ __seh_macro_exit_spot: \
+ if (0) goto __seh_macro_exit_spot; \
+   } __EXCEPT( __wine_seh_macro_exception_handler ) { \
+   } __ENDTRY \
+   (*fin)(); \
+   WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler) { \
+   (*fin)(); \
+   return EXCEPTION_CONTINUE_SEARCH; \
+   } \