March 2003 - Wine-Devel - list.winehq.org

Fwd: Re: Installshield.... no way!
by Davide Giannotti March 29, 2003

March 29, 2003

Oh yeah... i have the native std*tlb files... i unpacked them from my WinXP Pro cd. I'm currently running wine without windows installation. Don't know what to say... are you sure that latests installshield work with wine? I think this is a priority task... I recompiled wine from a clean tarballz... and as i said, some apps works fine. But nothing to do with installshield.... :-( Thanks Subject: Re: Installshield.... no way! Date: Saturday 29 March 2003 11:54 From: Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> To: Davide Giannotti <davide.giannotti(a)itsplanet.com> Cc: wine-devel(a)winehq.com >>>>> "Davide" == Davide Giannotti <davide.giannotti(a)itsplanet.com> writes: Davide> I give up, after 2 days of try.. Nothing to do with some Davide> setups. I'm using latest wine on redhat 8.1 with glibc 2.3.1 Davide> recompiled for my processor (athlon xp). Davide> Apps are launched with winelauncher and the Davide> LD_ASSUME_KERNEL=2.2.5 var. set. Wine has been compiled from Davide> source, everything went fine and some apps work fine and Davide> fast. (like ms office viewers) There's no original dll or config Davide> setting or suggestion in the mailing lists that brought me Davide> further. My $800 macromedia studio hangs after extracting files Davide> and preparing the setup. So do some other apps. I'm still Davide> hanging on Windozz... :-( You don't tell about the std*tlb files, so I guess you don't have them. To state it again: The native std*tlb Files from a windows installation are nescessary for InstallShield6 application. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- ------------------------------------------------------- -- Davide Giannotti ITS Planet s.n.c davide.giannotti(a)itsplanet.com www.itsplanet.com

1 0

Installshield.... no way!
by Davide Giannotti March 29, 2003

March 29, 2003

I give up, after 2 days of try.. Nothing to do with some setups. I'm using latest wine on redhat 8.1 with glibc 2.3.1 recompiled for my processor (athlon xp). Apps are launched with winelauncher and the LD_ASSUME_KERNEL=2.2.5 var. set. Wine has been compiled from source, everything went fine and some apps work fine and fast. (like ms office viewers) There's no original dll or config setting or suggestion in the mailing lists that brought me further. My $800 macromedia studio hangs after extracting files and preparing the setup. So do some other apps. I'm still hanging on Windozz... :-( If somebody has any idea.... thank you all guys. On Wednesday 26 March 2003 13:34, Davide Giannotti wrote: > > There's nothing i can do to make some installers work. > > I always get the > > "The installshield engine (ikernel.exe) could not be installed" message. > > > > I tried to install the dcom98, and it unpacked the files in the > > windows\system dir, and that's ok, but i don't think there was much more. > > > > When i try to install the microsoft installer (InstMsi.exe) it seems > > working, and it gives me the "succesfull installed" popup windows too... > > but i know it didn't cause it unpacks and doesn't even ask me if i want to > > proceed, it just jumps... to the end of process. > > > > And when i try to install some progs like Dreamweaver MX, i get the darn > > message above. > > > > Any suggestion? > > > > Thank you all guys > > > > P.s: The "export LD_ASSUME_KERNEL=2.2.5" command seems to work (at least > > partially). i added the line in my winelauncher script and konqueror uses > > winelauncher to start my win apps. > > Shouldn't you check for glibc version and add that line as default in the > > winelauncher script? > > -- > Davide Giannotti > ITS Planet s.n.c > davide.giannotti(a)itsplanet.com > www.itsplanet.com -- Davide Giannotti ITS Planet s.n.c davide.giannotti(a)itsplanet.com www.itsplanet.com

2 1

Re: Debugging winedbg
by Eric Pouech March 29, 2003

March 29, 2003

Ulrich Spoerlein wrote: > Can anyone please explain this to me? every module (in the Wine sense) is create with a .init section. the code in this section is executed as soon as the module is loader (by the ELF loader). But the code in this section expects a bit of Wine environment to be already present (basically the wine executable) with preloading the .exe.so file, this code gets executed with the wine executable being loaded > And what would be the easiest way to break into gdb on DEBUG_MainLoop? add a breakpoint instruction at the start of DEBUG_MainLoop code __asm__("int 3"); would do A+ -- Eric Pouech

1 0

Some shell32 questions and pictures
by Steven Edwards March 29, 2003

March 29, 2003

Hello, I was taking a look at the current shell32 sources from winehq and trying to see if we needed to merge in the reactos shell32 fork stuff. We have forked a small part of shell32 to be able to run the control panel application with our own dll. After doing some testing I wanted to see from you guys if our implementation was right and if it would be accepted to the winehq tree. I was wondering if this really needs to go in to the shell32 or in to the explorer clone. Thanks Steven Standard Win2k Control Panel http://mail.gleneagle.net/sedwards/control-with-win2k-shell32.jpg Now with the WINE shell32 from the current CVS you get this under Windows2000 http://mail.gleneagle.net/sedwards/control-with-wine-shell32.jpg And with the ReactOS shell32 you get this http://mail.gleneagle.net/sedwards/control-with-ros-shell32.jpg

2 1

Irc channel topic modification
by Sylvain Petreolle March 28, 2003

March 28, 2003

Could you remove the WineX from the freenode #winehq topic, as #winex exists too ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Is it as nontrivial as it appears
by Bill Medland March 28, 2003

March 28, 2003

I've now got to the stage where I have to look at whether it is possible for a linux process to call into windows dlls. (Don't bother telling me to use winelib to make the linux executable into a winelib one). I've never really thought too hard about it; it has always seemed to me that it ought to be quite trivial; just make sure you call the correct initialisaton functions and there you go. Indeed that has been my response on occasions on c.e.m.w and no-one had corrected me. I've just started looking at it and I get the distinct impression that due to the multiple processes and threads involved it may not be as trivial as I though. Anyone care to comment? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

2 1

WineHQ: still TODO
by Dimitrie O. Paun March 28, 2003

March 28, 2003

Hi folks, Here is my personal TODO list for our very beautiful WineHQ site. Big Items --------- 1. Integrate Bugzilla into the site 2. Integrate AppDB into the site 3. Integrate the guids into the site Jer, silly question: Bugzilla and AppDB seem to already be written with the 'boxed' approach. I haven't looked at the code, but any fundamental reason we can't simply stick the main Bugzilla or AppDB main box into WineHQ? Medium Items ------------ 4. The Who's Who page is terribly out of date. Also, the organization with VIPs/Core/etc. sucks IMO. The page should include only the active developers, the rest should go into an Acknowledgements page. 5. Speaking of which, we're missing an Acknowledgements page. This should include significant contributors, significant corporate sponsors, funding sources. 6. The Download pages don't feel like. They should refer to the HowTo rather than duplicate the information. Also the Download/Sources is too skinny, needs more meat. 7. The HowTo needs improvements. There's a lot more stuff that we need to add to it. 8. We're missing a History page, that would put everything in context and a nice narative. Small Items ----------- 9. The Contributing page is too heavy, needs better integration with the new Fun Projects/Winelib/Janitorial pages. 10. The Sending Patches needs a bit more work. The .cvsrc link is wrong, maybe a bit more info on how to configure various email clients to not mangle patches, make it more clear that only uniffied diff is acceptable, show an example .cvsrc, how to email a patch (ChangeLog, one patch/per message, etc). Stuff we've been discussing for so long. Tony, I know you've been doing work in this area, maybe you can look into it? 11. TODO/Fun Projects/Janitorial/Winelib pages need constant updating from my site. I'll do that. 12. The Status/UI Status page still needs some work. Help wanted. 13. Get rid of the Miscellaneous section from Status/Core Status. 14. The Search box is too low, one needs to scroll to get to it, even in high resolutions. Any other requests? BTW, why aren't WineHQ CVS commits visible on wine-cvs anymore? -- Dimi.

2 1

Re: Fix incorrect documentation
by Andreas Mohr March 28, 2003

March 28, 2003

Hi, On Fri, Mar 28, 2003 at 04:35:36PM +0000, Mike Hearn wrote: > I'm surprised nobody caught this one in my previous (duff) patch... the > "uninstaller" app appears to have been forgotten about. Well, I'd caught this in my update, but your version is somewhat better. Applied it ;-) I'm *almost* done with that stuff... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

RE: fix compiling of libs/wine/loader.c on NetBSD
by Patrik Stridvall March 28, 2003

March 28, 2003

> On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > > It seems the stdint. header file should be included for > > compiling on NetBSD. > > This reminds me: Into which deep hole did Patrik disappear? In the deep hole of having other things to do. :-) Don't worry, I will be back.

1 0

Re: Java in wine?
by Dan Kegel March 28, 2003

March 28, 2003

Mike wrote: > Perhaps a bit offtopic, but my company has asked me to try and get a > desktop java app we use/are developing here running under Linux. You'd > think, being written in Java, that it'd just be a case of installing the > JVM and running it. Unfortunately, because Java is rather poor at > desktop apps, they've used a load of windows extensions via JNI to try > and make it integrate better. > > That means, the only solution is probably to run a JVM under Wine (short > of rewriting all the native code, which they don't want to do). Now, I > tried the Sun JRE, and it wasn't happy. I expect HotSpot does some wierd > stuff under the covers. So I'm wondering if anybody has walked this road > before, and if there are any other JVMs that might work better under > Wine? What version of Java does the app require? I wonder if perhaps some older Sun JREs run better on Wine than hotspot does. I haven't tried any, but who knows, it might be worth trying. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 15

Contributing page needs fixing
by Mathew McBride March 28, 2003

March 28, 2003

Web Site matenence: "We are in the process of redoing the web site and we really could use some help. The current beta is located at http://lostwages.winehq.org Here is the current list of bugs that needs attention: 597, 598, 600, 601, 605, 607, 608.If you would like to offer assistance with web maintenace feel free to contact Wine-Develipmont <mailto:wine-devel(a)winehq.com>." 1) lostwages. 2) D-e-v-e-l-o-p-m-e-n-t Oh, add a link to the mailing lists in the menu if you can.

1 0

Re: I/O Completion Ports (1 of 2)
by Alexandre Julliard March 28, 2003

March 28, 2003

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > +static int io_completion_send_data( struct thread *thread, void *cookie, struct io_completion_data * data ) > +{ > + struct io_completion_send_data_reply reply; > + int ret; > + > + reply.cookie = cookie; > + reply.signaled = STATUS_SUCCESS; > + reply.bytes_transferred = data->bytes_transferred; > + reply.completion_key = data->completion_key; > + reply.overlapped = data->overlapped; > + if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) == sizeof(reply)) > + return 0; You cannot send different message sizes into the wait_fd pipe, this won't work since pipes don't preserve message boundaries. I'd suggest simply using the normal wait mechanism and then doing a separate call to retrieve the rest of the info. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Any DCOM experts?
by Bill Medland March 28, 2003

March 28, 2003

On March 27, 2003 12:48 pm, Gregory M. Turner wrote: > On Thursday 27 March 2003 01:08 pm, Bill Medland wrote: > > Hi guys > > > > For the next part of the work I am doing I am trying to figure out if > > there is any way that the DCOM part of one of our products is going to > > work under Wine at the server end. > > > > I am not having much success so far and I was wondering if anyone knows > > whether this is because I don't have things set up properly or if it is > > because of some inherent known lack of functionality. > > > > To start the ball rolling I was working with MSDN's DCOMTST test program > > pair. > > > > I managed to get that working using the local server (after adding the > > definition of IStream to the registry) but am having no luck getting the > > client under Wine to talk to the server under Win98. In fact the client > > side doesn't even seem to send out a single TCP/IP packet. > > There is no implementation of the TCP/IP transport at this time. Wine will > fail to make interprocess calls without any indication of this failure in > some cases. Frankly, I'm pleasantly surprised to hear that even DCOMTST > works. Ah, yes. But the local DCOMTST case is only going to use named pipes or something. And I am actually using the native dlls. And I know that I can use the native rpc across the net (using the "simple" sample program) > The RPC implementation in wine is not up to par yet. DCOM needs RPC to do > it's dirty work, so interprocess RPC is very shaky, and interprocess > between wine and real windows is non-existant. > > The good news is that there are people working on this, in particular, Ove > Kaaven and myself, although we are not exactly making headlines with our > earth-shaking progress at this moment. The bad news is that getting wine > to talk to windows via RPC is a pretty distant target right now; there are > lots of "lower hanging fruit" that will presumably be addressed first. > > > (Aside - Nice demonstration of lazy Microsoft code; in their error > > reporting they call FormatMessage, ignore the return code and somehow > > print the returned error message, even when one hasn't been allocated; I > > guess it only works under Windows because the print routine traps the > > access violation) > > or maybe the thing was supposed to be allocated and wine didn't do it > properly. Always presume wine is at fault, not Microsoft; you will usually > be correct, especially in DCOM territory! No. If a function has a return code that indicates failure then you should test for that failure and not blithely continue as if everything was OK. They call FormatMessage, asking for FormatMessage to allocate the returned string. If nothing else, it could fail to allocate memory in which case it would be stupid to use the "returned pointer" which is just whatever happened to be on the stack at the time. And I noted it failing on Windows too; the printf or whatever simply stopped processing half-way along the format string. > > I am currently running native ole32 and native rpcrt4. > > Then you are really using Microsoft's DCOM implementation, and not wine's. > Which may not be a bad choice if you want it to "just work" Yes please > as much as > possible. I have successfully used native ole32 and rpcrt4 to talk to SQL > server via the MMC interface, quite a bit of RPC involved. It didn't work > too well, but it was interesting to see it work at all. Hm. So something at least is possible (i.e. it is possible to get ole32 to put tcpip packets across the wire) > > The builtin rpcrt4 fails on a call to unimplemented > > RpcServerInqDefaultPrincName but I don't understand why it is even > > calling that; why does it think I have Netware only and why does it think > > this is a server process. > > This is another unimplemented chunk of DCOM: the RPC name services do not > exist. Samba and dce rpc have this feature so it's not unattainable... but > it ain't there yet. The name services and other networked DCOM services > require priveleged ports that wine can't even use without some kind of > medium-scale reconceptualization of the basic wine security model anyhow... > it's easy to imagine reasonable solutions to that too, but it will take > some thought... > > > Anyone an expert in any of this stuff? > > Yes, but unfortuantely, they all seem to work for Microsoft ;) Seriously, > some of it is undocumented, some of it is well documented. There are > probably only a handful of people in the world who could answer some of the > hard questions without reverse-engineering the answers, and they probably > do work for Microsoft. So for wine, we must read the specs and reverse > engineer the rest. It's not a pretty landscape and you will need to be > patient, but I believe there is a light at the end of the tunnel. Good to know. Unfortunately it isn't my patience we are talking about. Do you know of any decent low level documentation that I could read that would explain why the native OLE doesn't even appear to be trying to hit the network? BTW, on the subject of specs, create_marshalled_proxy includes a reference to a figure at MSDN. Unfortunately the link is out of date. Any idea what it is a reference to? I had a quick look through the 1999 MSJ articles but didn't see anything obvious. Also, if I get bored and can find a few hours I was going to correct the arrangement of CoCreateInstance and CoCreateInstanceEx and tighten up the CoGetClassObject order of testing; does that conflict with anyone? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

1 0

Re: fix compiling of libs/wine/loader.c on NetBSD
by Joerg Mayer March 27, 2003

March 27, 2003

On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > It seems the stdint. header file should be included for > compiling on NetBSD. This reminds me: Into which deep hole did Patrik disappear? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want ist just stuff that works. Some say that should read Microsoft instead of technology.

1 0

Re: PATCH: Make.rules.in
by Dimitrie O. Paun March 27, 2003

March 27, 2003

On Wed, 26 Mar 2003, Gerald Pfeifer wrote: > In the FreeBSD port of Wine I inherited the following and > /usr/include/features.h on my Debian systems states > > _THREAD_SAFE Same as _REENTRANT, often used by other systems. > > so I'd like to propose the following. On FreeBSD these two are not > exactly synonyms (yet?), and on Linux it doesn't hurt anybody. Well, it does make the compiler command line longer and uglier. In this case, a configure test would work a bit better I believe. -- Dimi.

1 0

Re: TreeView notifications fix (take 2)
by Mike Hearn March 27, 2003

March 27, 2003

Hi Alexandre, Any reason this wasn't applied, or is it still in the queue? On Wed, 2003-03-19 at 14:08, Mike Hearn wrote: > As per Dimis suggestion, here is a more streamlined version of the > patch. > > ChangeLog: > > - Make IsWindowUnicode check dialog wndprocs -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

5 11

2 things with the new library system
by Steven Edwards March 27, 2003

March 27, 2003

1. I'm getting this error in the current cvs - patch is at the end of the message isolation(a)PH33R /g/src/wine-dev/wine/libs/wine $ make dllwrap --def ./wine.def -o libwine.dll config.o debug.o errno.o ldt.o loader.o -L../../libs/port -lwine_port -lmsvcrt libwine.exp(.edata+0xa4):fake: undefined reference to `wine_errno_location' libwine.exp(.edata+0xcc):fake: undefined reference to `wine_h_errno_location' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [libwine.dll] Error 1 2. I can build wrc, winebuild, widl and etc but when I go to run these programs they are bitching about not being able to fund NULL. It seems that dllwrap and gcc dont like having our dlls not have a library name in the .def file. If I add LIBRARY libwine_unicode.dll or LIBRARY libwine.dll to the proper file then all is great. My question is will this break Unix? with a .so or will LD just not care about this? cvs diff -u wine.def Index: wine.def =================================================================== RCS file: /home/wine/wine/libs/wine/wine.def,v retrieving revision 1.1 diff -u -r1.1 wine.def --- wine.def 23 Mar 2003 00:28:53 -0000 1.1 +++ wine.def 27 Mar 2003 20:09:55 -0000 @@ -27,7 +27,6 @@ wine_dll_unload wine_dlopen wine_dlsym - wine_errno_location wine_get_config_dir wine_get_cs wine_get_ds @@ -37,7 +36,6 @@ wine_get_server_dir wine_get_ss wine_get_user_name - wine_h_errno_location wine_ldt_alloc_entries wine_ldt_alloc_fs wine_ldt_copy __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

1 0

Re: building a windows API database
by David Miller March 27, 2003

March 27, 2003

Hi, I have attached the script I am working on for this project. It is not finished. Currently it will ignore APIs with no name or ordinal ### simply because I haven't figured out how to handle them yet. There seems to be a general consensus on wine-devel we don't need a MySQL database so I am working toward a text file solution instead. I do think MySQL could be useful though if someone made a nice interface to query the database. Any help, comments, and suggestions are always welcome. :) Currently this script will: locate dlls and dump import and/or export information with dumpbin cross reference imports in an HTML map parse the dumped exports and try to determine the status of each API based on entries in the wine .spec files. If you do not have access to perl on a windows system and dumpbin (from visual C++) I can provide sample output. At 11:35 AM 3/25/2003 -0800, you wrote: >Hi, I am interested in your project of >having an API database. > >I am building it, storing the information >in a server (MySQL), in order to retreive >from it any information about apis >and their relationship with other apis >and constants. > >I don't know if you have something yet, >and would like to share with you >the project. > >Greetings... > >__________________________________________________ >Do you Yahoo!? >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! >http://platinum.yahoo.com

2 1

new site nit
by Dan Kegel March 27, 2003

March 27, 2003

It would be nice if the site recognized normal URLs without the ?page= prefix. That ought to be easy to hack up. The extra verbiage makes links posted in news articles look ugly. Where's the code so I can fix it? I can't see it at http://cvs.winehq.com/cvsweb/ for some reason... I thought the site's code was in cvs... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 8

Wine, win4lin, vmware, bochs, plex86 can we build an alternative Windows yet ?
by Jacobus Erasmus March 27, 2003

March 27, 2003

Hi, I've been following the Wine development for years now. I was surprized when I learned of vmware and win4lin being able to run Windows. After some investigation it seems that they have consentrated on a simpler task that of building a virtual machine that can run Windows on top of linux. Wine on the other hand is concentrating on replacing Windows a much harder task. My question to the Wine comminuty is this ? Whithout stopping the current development would it be possible to build a striped down wine version that can run most Windows apps if you have windows available and are willing to install it in our Wine Virtual Environment. Given that Wine already contains most of the code to read and use DLL's. Most of the drivers is already available what would it take to setup such a wine version. (Interim solution ) -- Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> Kewlconcepts

3 2

Transient registry entries?
by Mike Hearn March 27, 2003

March 27, 2003

Hi, My app reads the registry to figure out network information, in particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards\] key to discover network cards, then [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the IP address of each one (this program can bind to multiple adaptors). These entries don't exist in Wine, and clearly they should be generated from the system configuration. There are three places that could be done: a) In initial setup, ie when you install Wine b) At Wine startup c) On demand, ie by writing special cases into the registry access code. Which of these is the one that should be used? Some stuff, like the IP address, can presumably be retrieved from other API calls, but other things, like the adaptors in the system might require new code to query the kernel. Has anybody got any tips? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: treeview click notification
by Alexandre Julliard March 27, 2003

March 27, 2003

Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > Alexandre - I noticed my last treeview patch wasn't applied, I have been > diffing against old copies rather than CVS.... is it that my patches are > no longer applying cleanly? If so, then I'll resubmit when I have CVS > access again. If there was a problem with the patch, could you please > say what it was so I can fix it now, while I have time? It's still in the queue. I can't apply all patches on the day I receive them; sometimes I simply don't have time for another compile/test/commit round that day, sometimes I wait a bit to leave other people a chance to comment, etc. If one of your patches is dropped by all means ask me about it, but please give me at least a few days before assuming it was dropped. Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

server/signal.c portability issue
by Gerald Pfeifer March 27, 2003

March 27, 2003

Unfortunately, the new server/signal.c doesn't seem to be portable: wine/server% make /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -D__WINESRC__ -D_REENTRANT -o signal.o signal.c signal.c: In function `do_sigio': signal.c:201: structure has no member named `si_fd' I'd love to provide a patch, but I have now idea what it should looke like. :-( If that helps, here is siginfo_t on FreeBSD 4.8: : typedef struct __siginfo { int si_signo; /* signal number */ int si_errno; /* errno association */ /* * Cause of signal, one of the SI_ macros or signal-specific * values, i.e. one of the FPE_... values for SIGFPE. This * value is equivalent to the second argument to an old-style * FreeBSD signal handler. */ int si_code; /* signal code */ int si_pid; /* sending process */ unsigned int si_uid; /* sender's ruid */ int si_status; /* exit value */ void *si_addr; /* faulting instruction */ union sigval si_value; /* signal value */ long si_band; /* band event for SIGPOLL */ int __spare__[7]; /* gimme some slack */ } siginfo_t; #endif /* _P1003_1B_VISIBLE */ Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

1 0

Re: wrc: -a -C -w
by Alexandre Julliard March 27, 2003

March 27, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > The -w options wanted to be merged into the -O option. > It makes sense: we want to control the input and output > format independently, and what better way than through > already existing -J and -O option? I don't mind removing -w, but it would be nice if you could also fix the makefiles so that things compile <g> -- Alexandre Julliard julliard(a)winehq.com

2 1

[RFC] wrc: remaining TODOs
by Dimitrie O. Paun March 27, 2003

March 27, 2003

Folks, Few things remain before I'm satisfied with the state of wrc. Here is a list of them: -- the -B option: I think this is a the wrong interface. The Win32 API has been ported to Big Endian machines IIRC, and there is no point allowing people to mock with alignment like so: it opens up a BIG can of worms for future support and maintenance. And I don't see how it can be useful -- the Wine code assumes a certain endianess, and that's exactly what wrc should output. NOTE: Of course, I just realized that the argument holds as long as the .res format has a fixed endianess on all platform. I hope it does. Anyone cares to enlighten me? -- we may need a -r option for compatibility with rc. rc used to have a -r option, it is now ignored for backwards compatibility. Anyone know if this is old enough that we can safely ignore? Up to what version was the option required? It is curretly used in the Mozilla source, so we were wondering if we could remove it from there as well. -- the -m option. rc doesn't have it, why do we need it? We are using it in the Wine tree, do we really need it? Personally, I'd be happier if we could get rid of it, so we don't depend on Wine-only extensions. -- I would like to add a -U option (undefine), for compatibility with rc. In fact, wpp should support it as well, for compatibility with cpp. That's it. Any more ideas? I would like to get this out of the way soon, any comments or suggestions are most welcome. -- Dimi.

3 4