February 2005 - Wine-devel - list.winehq.org

Useful RPC/DCOM document
by Mike Hearn 20 Feb '05

20 Feb '05

http://www-csag.ucsd.edu/individual/achien/cs491-f97/projects/dcom-writeup.… They apparently had access to the NT source code, and describe the process of writing a new transport for the RPC runtime. thanks -mike

1 0

Problems with rsaenh/advapi32 and 'Myst Uru Demo'
by Paul Vriens 20 Feb '05

20 Feb '05

Hi, I've download a bunch of demo-apps and this one (http://www.gamershell.com/news/10306.html) has some problems with the builtin rsaenh.dll/advapi32.dll. The trace (+crypt,+loaddll) shows: fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e39320): not verifying image trace:crypt:RSAENH_CPAcquireContext (phProv=0x77e3941c, pszContainer="{07EC3FFA-8373-11D9-C687-000CF1342294}", dwFlags=00000010, pVTable=0x77e394d0) trace:crypt:CryptReleaseContext (0x77e38c68, 00000000) trace:crypt:RSAENH_CPReleaseContext (hProv=00000001, dwFlags=00000000) trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\rsaenh.dll" : builtin trace:crypt:CryptDestroyHash (0x77e38c48) wine: Unhandled exception (thread 000d), starting debugger... Is this due to the 'lack' of reference counting in the advapi32 crypt stuff? It looks like RSAENH_CPReleaseContext released 'everything' where it shouldn't, hence the failure of CryptDestroyHash. Cheers, Paul.

2 1

wpp
by Ge van Geldorp 20 Feb '05

20 Feb '05

wpp will currently silently drop non-preprocessor stuff (typedefs, function prototypes etc.) when #including a .c or .h file. However, if you preprocess e.g. a .rc file externally and then feed it to wrc (which in turn will feed it through wpp) the non-preprocessor stuff isn't removed. The patch below changes that, by looking at the filename on the #line directive. If it ends in .c or .h, no output is generated (but the file is still parsed for preproc statements ofcourse). We need this for ReactOS, it doesn't hurt Wine (yes, I've tested it <g>) and including it in Wine would make my monthly job of merging Wine and ReactOS a tad easier. If there are no objections I'll submit to wine-patches in a few days. We also have another change in wpp, which adds support for #include_next (can't take credit for that, Filip Navara wrote it). Since you can't use that #include_next in Wine anyway (not every compiler supports it) I'm not going to bother creating and testing a Wine patch for it. If I misjudged and there is interest in this from the Wine side just let me know. Ge van Geldorp. Index: libs/wpp/ppl.l =================================================================== RCS file: /home/wine/wine/libs/wpp/ppl.l,v retrieving revision 1.4 diff -u -r1.4 ppl.l --- libs/wpp/ppl.l 21 Oct 2003 23:57:25 -0000 1.4 +++ libs/wpp/ppl.l 20 Feb 2005 15:12:10 -0000 @@ -232,6 +232,7 @@ static void newline(int); static int make_number(int radix, YYSTYPE *val, const char *str, int len); static void put_buffer(const char *s, int len); +static int is_c_h_include(char *fname, int quoted); /* Buffer management */ static void push_buffer(pp_entry_t *ppp, char *filename, char *incname, int pop); static bufferstackentry_t *pop_buffer(void); @@ -551,11 +552,15 @@ case pp_define: case pp_mbody: case pp_inc: - case pp_line: case RCINCL: if (yy_current_state()==RCINCL) yy_pop_state(); pplval.cptr = get_string(); return tDQSTRING; + case pp_line: + pplval.cptr = get_string(); + if (is_c_h_include(pplval.cptr, 1)) pass_data=0; + else pass_data=1; + return tDQSTRING; default: put_string(); } @@ -1404,12 +1409,12 @@ * Include management *------------------------------------------------------------------------- */ -static int is_c_h_include(char *fname) +static int is_c_h_include(char *fname, int quoted) { int sl=strlen(fname); - if (sl < 2) return 0; - if ((toupper(fname[sl-1])!='H') && (toupper(fname[sl-1])!='C')) return 0; - if (fname[sl-2]!='.') return 0; + if (sl < 2 + 2 * quoted) return 0; + if ((toupper(fname[sl-1-quoted])!='H') && (toupper(fname[sl-1-quoted])!='C')) return 0; + if (fname[sl-2-quoted]!='.') return 0; return 1; } @@ -1448,7 +1453,7 @@ pp_incl_state.seen_junk = 0; pp_incl_state.state = 0; pp_incl_state.ppp = NULL; - if (is_c_h_include(newpath)) pass_data=0; + if (is_c_h_include(newpath, 0)) pass_data=0; else pass_data=1; if(pp_status.debug)

1 0

press -- eweek, Microsoft Seeks to Bottle Up Open Source Wine
by Tom 20 Feb '05

20 Feb '05

Hello All, I just ran across this at eweek: http://www.eweek.com/article2/0,1759,1766843,00.asp Ivan you are now famous can I get your autograph ;) Tom

4 7

idea to spot regressions
by Jonathan Ernst 19 Feb '05

19 Feb '05

Hi everyone, I'd like to know what you people think about this idea for the application database: When an application version goes from gold to silver or silver to bronze for example, the AppDB asks the maintainer if he wants to inform wine developpers about this regression and if yes the maintainer has a field where he can enter some comments about the regression and the AppDB sends an e-mail to wine-devel with links to the AppDB entry and the maintainer's comments. This would ease the task for maintainer to report regressions and for developpers to know about them. Looking forward to reading your comments. Jonathan

1 0

Re: Microsoft genuine downloads looking for wine
by Sam Lauber 19 Feb '05

19 Feb '05

Agreed. Can't we just delete HKEY_CLASSES_ROOT/Software/Wine or move it to another name? > >> In any case, at least from a technical point of view, going > >> around such test ought to be fairly simple > If the mere existence of this key makes the validation fail, what's > to stop a virus from simply adding this key as a way to stop > legitimate users from downloading the security fix for that same > virus? If MS is really doing what we think they may be doing here, > I don't think they are going to be enjoying it for long. They are > (what else is new?) shooting themselves in the foot (again?). They're probably famous for that already ;-). > > I don't think we want to go there. I demonstrated a way of checking for > > Wine to Rob last night that we really cannot fix or workaround, and if I > > can think of it they certainly can too. > I think I know what way you are thinking of. Not sure someone less > versed in the way Wine works (it's an emulator, right?) would > figure that one out, but I guess you are right. I'll try to catch > you on IRC and see if we are, indeed, talking about the same thing. > > > Basically if we start integrating workarounds into Wine, it'll lead to an > > arms race we cannot possibly win. > > > Technically, it will probably cost them more than it will cost us. > Then again, they also have more resources. I'll just point out that > I don't think there is anything inherently wrong with MS wishing to > keep the parts that truly are core Windows for Windows legal > license users only. The main problem with MS is that what they call > "core OS" can get quite absurd. > > > Better to ensure our users don't need > > anything from that website. > Amen to that. So, opengl, dcom, what else do we need? :-) Write our own replacement. Try OpenGL first. We might have to clean-room reverse-engineer DCOM. IMO, the `core' operating system (besides the CD!) is the main installation disks and service packs. Anything else is what I call a `program'. Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

Re: Making builtin OLE32 work right
by Mike Hearn 19 Feb '05

19 Feb '05

Here is a brain dump of what I already know we need to fix for the CW supported apps: 1) InstallShield: RPC call re-entrancy 2) Lotus Notes: OLE drag/drop leaves an image of the window behind when it closes. Native does this functionality very differently to us. 3) VB apps: As Holly Bostick discovered to her cost, we can't load all OLEPicture resources correctly. Our OLEFont code also has misc bugs in, but we don't have any tests and code which uses these objects is rare so the full extent of the work here is an unknown 4) OLE Storage: IIRC misc things break in Office when this is pulled 5) Office embedding: We need marshallers for IOleObject for this, I think ... possibly a lot more. I do not know the details. 6) iTunes/iPod: Not fully investigated yet but I think we need to drop the typelib marshaller hack (this stands a good chance of breaking InstallShield for a short time as well) And one thing we probably don't care about: 7) Microsoft Transaction Server needs the typelib marshaller to generate RPC marshal-ops (format strings) instead of using custom marshalling like we do right now. But who cares about MTS while InstallShield and Office still aren't there? :) thanks -mike On Sat, 19 Feb 2005 10:58:27 +0900, Mike McCormack wrote: > Hi All, > > I'd like to compile a list of all applications that don't work correctly > without native ole32 (aka dcom95), then go through and try fix them. > > I think bugzilla is probably the right place to save the list, and that > alot of the information we're looking for is already in the appdb. > > How can we extract if easily? Maybe the appdb guys can provide a check > box that app maintainers can click on to indicate that builtin ole32 > works fine? > > any ideas? > > Mike

1 0

modem
by Hartmut Haase 19 Feb '05

19 Feb '05

I'm not sure if this is the right address, but you can certainly forward it to the right person(s): I'm using an analog modem, and as it is not easy to select the appropriate cal-by-call provider, I tried to use web.de's SmartSurfer which works fine with windows. But wine gives me only the choice to select some 'WINE virtmodem' which is certainly not the right one. Yast tells me that my modem is device ppp0. What can I do? -- Viele Grüße, Hartmut Haase Hungerhilfe: http://www.thehungersite.com Das heutige Motto: The most exhausting thing in life is being insincere

2 1

Re: Making builtin OLE32 work right
by Tony Lambregts 19 Feb '05

19 Feb '05

Mike McCormack wrote: > > Hi All, > > I'd like to compile a list of all applications that don't work correctly > without native ole32 (aka dcom95), then go through and try fix them. > > I think bugzilla is probably the right place to save the list, and that > alot of the information we're looking for is already in the appdb. > > How can we extract if easily? Maybe the appdb guys can provide a check > box that app maintainers can click on to indicate that builtin ole32 > works fine? > Well If I can get around to submitting my "new bugzilla integration" patch this could work right. The idea is to be able to attach multiple apps (versions) to the same bug. Right now we use "url" in Bugzilla to attach a bug to an app and that limits us to on app per bug. The feature you want is to be able to click on a link in a bug and see all the applications that that bug affects. I know exactly what I want it to do. I even have a bit rotted (almost) working version on my old machine. The problem I currently have is trying to keep up with the changes that Jon has been doing ( I don't work nearly as fast as him) so I have been waiting for the database to stablize a bit ... -- Tony Lambregts

3 3

Re: Add LPDWORD typedef to wtypes.idl
by Dmitry Timoshkov 19 Feb '05

19 Feb '05

"Vincent Béron" <vberon(a)mecano.gme.usherb.ca> wrote: > There are probably more pointer types missing from our wtypes.idl. > > Changelog: > Add LPDWORD definition to wtypes.idl. > --- include/wtypes.idl 8 Dec 2004 13:59:52 -0000 1.22 > +++ include/wtypes.idl 19 Feb 2005 00:41:55 -0000 > @@ -48,6 +48,8 @@ typedef float FLOAT; > > typedef void *PVOID, *LPVOID; > > +typedef unsigned long *LPDWORD; This introduces a potential miscompilation on 64-bit platforms. I'd suggest to use a base type instead of unsigned long: typedef DWORD *LPDWORD; -- Dmitry.

1 0