- Wine-Devel - list.winehq.org

Re: FW: shell32.SHDefExtractIcon implementation take
by Uwe Bonnes Dec. 6, 2002

Dec. 6, 2002

>>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: +/**************************************************************************** + * SHDefExtractIconW [SHELL32.@] + */ +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) +{ + UINT ret; + HICON hIcons[2]; ^^^^^^^^ + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); + + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, nIconSize, h\ Icons, NULL, 2, LR_DEFAULTCOLOR); + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ + if (ret == 0xFFFFFFFF) + return E_FAIL; + if (ret > 0) { + *phiconLarge = hIcons[0]; ^^^^^^^^^^^^ Rolf, this doesn't look right to me: You allocate space on the function local stack, then hand out a pointer to that memory and return from the function. No the function local stack is undefined and the pointers are dangling. I think the heap should be used for allocating the needed storage. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Let --disable-debug actually do something
by Alexandre Julliard Dec. 6, 2002

Dec. 6, 2002

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 -0000 1.5 > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > @@ -23,6 +23,7 @@ > > #include <stdarg.h> > #include "windef.h" > +#include "config.h" You can't do that, installed includes shouldn't depend on config.h. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [RESENT] Batch support for CreateProcess (2 of 3)
by Alexandre Julliard Dec. 6, 2002

Dec. 6, 2002

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > --- wine/programs/wcmd/builtins.c 24 Jul 2002 19:00:25 -0000 1.15 > +++ wine/programs/wcmd/builtins.c 6 Dec 2002 14:04:02 -0000 > @@ -406,7 +406,7 @@ > return; > } > if (test != negate) { > - WCMD_parameter (p, 2+negate, &s); > + WCMD_parameter (p, 2+negate+test, &s); This doesn't look right. The number of parameters doesn't depend on the result of the test. -- Alexandre Julliard julliard(a)winehq.com

1 0

Janitorial Projects
by Dimitrie O. Paun Dec. 6, 2002

Dec. 6, 2002

Folks, I have updated the Janitorial section: http://www.dssd.ca/wine/Wine-Fun.html#janitorial with the list of cross calls from 32->16, and W->A. There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII. Any takers? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.

6 17

how to switch between threads
by Rajesh Akkineni Dec. 6, 2002

Dec. 6, 2002

Hi, I am debugging wine with MS Media Player. Some places the program is blocking with som 7 to 8 threads opened. They are all waiting for a some event(ConnectNamedPipe) But i think there should be another thread with will Create the file or NamedPipe. So How can i see where the other threads are when i set a break point in a perticular method. How dose debuggers handle MultiThreaded Applications? Can i Shit to different Thread to exmine where is it when the program Halted? Thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

RE: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com Dec. 6, 2002

Dec. 6, 2002

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. You're right in theory but you're partly wrong in practice. Some time back I changed a shared library which had been used by ten or so developers for about eight years. I changed all possible unspecified length string copies and concatenates to versions with length limits. The programs using the library crashed less and displayed bad output less. Nobody noticed any speed change there might have been. We all had access to all of the source code involved and none of it was deliberately hostile to the library. The changes caught things the application programmers had missed in their testing and odd or corrupt data which ended up in the databases and made them less harmful. It was then also easier to follow up and fix "the program displayed xyz trash here" than it was to fix "my PC crashed" or "your program died". As programmers we all try to follow the limits and take care with buffer sizes and lengths and validation. We all fail and we all fail to catch every time we fail. That's just the nature of bugs and what we do. Buffer length issues are particularly hard to find and no realistic testing for a project the size of wine will catch them all. Wine also needs to remember that hostile Windows program developers may deliberately try to break programs under wine by passing invalid parameters. Even if wine doesn't check all of those, it shouldn't die when it happens. At least one company has an interest in breaking wine when running its programs and coding defensively is a prudent thing. Performance is unknown and won't be known until any possible shared function is implemented. Just announce it with the length parameter and do it with a define. Let the person who implements it decide whether to use strcat, strlcat or whatever in the first implementation, a function or inline or whatever. Six months or a year from now someone can try different implementations to see whether there is a speed difference. Then they can do something about selecting the most efficient. It's an issue, so deal with it, but there's no way to know today which will be the best implementation because it depends on the data and it is obvious that nobody knows the data well enough to be certain which will work best. If you don't like the strlcat implementeation, then you can try it with strcat and tell everyone how much faster it is when the l is ignored. Or not. Even if the l is eventually ignored in production, having it around offers the opportunity to turn it on with a compile option and/or to use it for assert sanity checking in a debug build. Finally, hi.:) Just started monitoring this list because I'm helping to get a Windows application (OzWin) working under wine. James Day ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

3 2

Registering DLL's
by Jeff Smith Dec. 6, 2002

Dec. 6, 2002

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]" Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg. About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions. Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 4

Cabinet FDICreate()
by Mike Hearn Dec. 6, 2002

Dec. 6, 2002

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: wine/tools Makefile.in .cvsignore mingwrap.c
by Dimitrie O. Paun Dec. 6, 2002

Dec. 6, 2002

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

1 0

Re: Loading Autorun.inf on CD's
by Dustin Navea Dec. 6, 2002

Dec. 6, 2002

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

1 0