September 2005 - Wine-Devel

Re: resubmit: implement hlink.dll
by Mike McCormack Sept. 19, 2005

Sept. 19, 2005

Aric Stewart wrote: > + if (r == S_OK); I don't think you want to put a semi colon there. > + { > + if (pwzLocation) > + IHlink_SetStringReference(*(IHlink**)ppvObj, HLINKSETF_LOCATION, > + NULL, pwzLocation); > + if (pwzFriendlyName) > + IHlink_SetFriendlyName(*(IHlink**)ppvObj, pwzFriendlyName); > + if (pihlsite) > + IHlink_SetHlinkSite(*(IHlink**)ppvObj, pihlsite, dwSiteData); > + if (pimkTrgt) > + IHlink_SetMonikerReference(*(IHlink**)ppvObj, 0, pimkTrgt, > + pwzLocation); Rather than continually casting ppvObj, why not make a temporary variable of type IHlink? > +static HRESULT WINAPI IHlink_fnGetMonikerReference(IHlink* iface, > + DWORD dwWhichRef, IMoniker **ppimkTarget, LPWSTR *ppwzLocation) > +{ > + IHlinkImpl *This = (IHlinkImpl*)iface; > + > + TRACE("(%p) -> (%li %p %p)\n",This, dwWhichRef, ppimkTarget, ppwzLocation); > + > + if(ppimkTarget) > + { > + if (This->Moniker) > + *ppimkTarget = This->Moniker; > + else if (This->Site) > + IHlinkSite_GetMoniker(This->Site, This->SiteData, > + OLEGETMONIKER_FORCEASSIGN, OLEWHICHMK_CONTAINER, > + (LPVOID)ppimkTarget); > + } > + > + return S_OK; > +} The above function doesn't look right. You don't use dwWhichRef or ppwzLocation, and you unconditionally return S_OK even when *ppimkTarget is uninitialized or IHlinkSite_GetMoniker fails. Mike

1 0

scared! freedce-win32 in a cvs repository near you
by Luke Kenneth Casson Leighton Sept. 19, 2005

Sept. 19, 2005

right. 48 hours later, i've got a first version of freedce-win32 to try out, which i'm actually a bit frightened of running. just in case it works :) thank goodness for pthreads-win32, otherwise i'd be up small creek. major things todo: in ipnaf.c (actually ipnaf_linux.c or even better ipnaf_win32.c) it's necessary to write an IP-interface-enumeration function. this function presumably will call GetIpAddrTable and go over all the addresses including netmasks and broadcast addresses returning information that the rpc runtime can then "listen" on - one by one. no, freedce doesn't go listening on 0.0.0.0 it binds to all "towers" whatever they're called. because i've commented this code out (stubbed) i am not expecting freedce-win32 to work straight off. once this is working, putting it in place of rpcrt4 should be relatively straightforward (and mostly very very mind numbingly boring) - a matter of "back-converting" and following the lead of dceport.h - microsoft's "wrapper" header file that allows application developers to port DCE/RPC applications to MSRPC. i say "lead" because it's woefully inadequate, representing about 10% of the functions and structs that actually need "converting", because dceport.h contains the "publicly accessible" functions. once _that's_ done, then there will be two remaining tasks: 1) check that pthreads-win32 works under wine (!) and if so, job done, otherwise it's _yet_ another emulation layer to write, but at least the source code of pthreads-win32 represents a damn good starting point 2) mash freedce's typelib output to be compatible with MSRPC binaries. this latter is no small task (but at least it could be considered). the data structures have been _totally_ mashed, by microsoft. gotta run. later. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Empire Earth continued
by Stefan Dösinger Sept. 19, 2005

Sept. 19, 2005

Hi, I think I've found the cause of the Empire Earth crash. This is not a reference counting problem at all, Empire Earth releases the DirectDraw and Surface objects on purpose. This is what happens: 1) EE creates a DDraw object 2) It attaches a Complex Surface 3) It sets up a D3D device for this Surface 4) EE performs a Flip(NULL, 0x20) on the surface 5) It Releases the DirectDraw object 6) It Releases the surface Wine releases the surface in 5), Windows doesn't. It appears to me, that Windows doesn't release Surfaces which have a D3D object attached when the DDraw instance they belong to is freed. I have written a small test app, which reproduces EEs behaviour. It crashes in Wine, but worksin Windows 2000. I'll do some more tests and submit a patch. Stefan

3 12

OLE file close problem in win32s mathcad 5.0
by paul Sept. 19, 2005

Sept. 19, 2005

Since some work is occurring in OLE I will mention this bug. http://bugs.winehq.org/show_bug.cgi?id=3154 When you start mathcad one New blank file is opened. Trying to close any file does not work and my guess some Ole stub return value is preventing it. This application has had this problem of not closing for several years. What other traces do I need to generate? Open file splash.mcd then close it and it does not close. bash-3.00$ WINEDEBUG=+ole wine mcad Loading required GL library /usr/X11R6/lib/libGL.so.1.2 trace:ole:DllMain 0x7b7c0000 0x1 0x1 fixme:ole:OleRegisterServer (Mathcad,0x7bc9f330,0x7bc9f334,0x400000,1): stub! fixme:psdrv:PSDRV_ExtEscape QUERYESCSUPPORT(24) - not supported. fixme:ole:OleRegisterClientDoc (Mathcad document,\Untitled:1,...): stub fixme:ole:OleRegisterServerDoc (1,\Untitled:1): stub fixme:ole:OleRegisterClientDoc (Mathcad document,C:\WINMCAD\handbook\deskref\splash.mcd,...): stub fixme:ole:OleRegisterServerDoc (1,C:\WINMCAD\handbook\deskref\splash.mcd): stub fixme:ole:OleRevokeClientDoc (2): stub fixme:ole:OleRevokeServerDoc (3): stub

1 0

Re: server: Try2: add case-sensitivity comparison flag to find_object & co
by Alexandre Julliard Sept. 19, 2005

Sept. 19, 2005

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > I guess this one got lost. Resend it. > Or is there anything wrong with it? Well, you didn't change create_named_object, which looks suspicious. Also I'd really like to see some regression tests for the behavior of the various objects. -- Alexandre Julliard julliard(a)winehq.org

3 3

Take 2: DDRAW: Fix reference counting
by Stefan Dösinger Sept. 19, 2005

Sept. 19, 2005

Hello, This patch increases the reference count of a DirectDraw object when a Surface is created, like Windows does. It also adds a test which tests this functionality. This time with the !FAILED() -> SUCCEEDED() suggestion from Robert Shearman. I kept adding a secound refcount in case of DDSCAPS_TEXTURE surfaces to achieve more compatiblity with Windows. Stefan

1 0

Re: msvcrt spec changes
by Dmitry Timoshkov Sept. 19, 2005

Sept. 19, 2005

Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > added reference to kernel32.GetLocalTime to _getsystime stub function > (support.microsoft.com/default.aspx?scid=kb;en-us;99456) > -@ stub _getsystime #(ptr) > +@ cdecl _getsystime(ptr) kernel32.GetLocalTime You can't just forward _getsystime to GetLocalTime, they accept different arguments: struct tm * vs. SYSTEMTIME *. Have a look at your MSVC docs. -- Dmitry.

2 2

Re: Fwd: amblksize definition
by Saulius Krasuckas Sept. 19, 2005

Sept. 19, 2005

* On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: > > amblksize definition in msvcrt. Wouldn't it be nice to establish a real variable somewhere in the msvcrt code?

2 2

Re: hhctrl: Correctly draw the navigation pane
by Robert Shearman Sept. 19, 2005

Sept. 19, 2005

James Hawkins wrote: >Hi, > >Changelog >* Correctly draw the navigation pane. > > > Hi James, I'm impressed with the work that has been done to get hhctrl this complete. But... >@@ -149,7 +144,7 @@ static void HH_RegisterChildWndClass(HHI > wcex.hInstance = pHHInfo->hInstance; > wcex.hIcon = LoadIconW(NULL, (LPCWSTR)IDI_APPLICATION); > wcex.hCursor = LoadCursorW(NULL, (LPCWSTR)IDC_ARROW); >- wcex.hbrBackground = (HBRUSH)(COLOR_3DFACE); >+ wcex.hbrBackground = (HBRUSH)(COLOR_MENU); > > This doesn't seem right. You're not registering a menu-like class. > wcex.lpszMenuName = NULL; > wcex.lpszClassName = szChildClass; > wcex.hIconSm = LoadIconW(NULL, (LPCWSTR)IDI_APPLICATION); > > -- Rob Shearman

2 1

Picasa working pretty well...
by Dan Kegel Sept. 18, 2005

Sept. 18, 2005

I had a free couple of hours this morning, so I amused myself by trying out Picasa on the most recent snapshot of wine on my el-cheapo x86_64 Compaq laptop running 32 bit FC3. I was really impressed with how well things worked in general - much of the interface worked very smoothly. Hats off to the Wine developers! Still, there were some real glitches, so I filed six bug reports. You can see them in the AppDB at http://appdb.winehq.org/appview.php?versionId=2786 I'll post individual messages about a couple of them. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0