January 2004 - Wine-Devel - list.winehq.org

Re: Variable in Visual Basic

by Nyef

On Fri, Jan 23, 2004 at 04:36:58PM -0200, Savio Ramos wrote: > Hi, > > I am using wine with fake_windows. A Program don't works and return the message below. > > fixme:ole:VarCat Failed to convert right side from vt 8 to VT_BSTR? The code for this fixme is slightly broken, it really failed to convert the left side, and doesn't tell us which vt it is trying to convert from. If you built from source could you apply the attached patch to dlls/oleaut32/variant.c, re-build, re-run your program and post the updated output? Thanks. --Alastair Bridgewater

Jan. 23, 2004

Dungeon Keeper thread(s) recently

by Jason Edmeades

Just a thank you for the people who followed up on this recently, including the recent patch. (I have been offline due to a failing modem, so couldnt participate towards the end.) Jason

Jan. 23, 2004

Re: Systray integration patch

by Mike Hearn

On Fri, 23 Jan 2004 10:44:54 +0000, Martin Garton wrote: > The systray.c problem is just in comments. > The others are not (don't appear to be from my inexperienced perspective) > trivial. Sounds like it collided with the atom interning code. > Maybe I'm using an old version of the patch. Is there somewhere where the > latest version lives? Yes, that's likely, search the archives of wine-patches for the latest one, I submitted it back in December I think. thanks -mike

Jan. 23, 2004

Re: warning to "wine on cygwin" experimenters

by Steven Edwards

--- Anonymous <name(a)domain.com> wrote: > > I got cygwin to compile wine to the point where wine-install tried to > run regedit on winedefault.reg. > > I should have been paying closer attention. > > The good news is that the wine regedit.exe works like a charm. The > bad news is that it overwrote my actual windows registry with the > bunk values in winedefault.reg. we need to add some checking to the configure and wineinstall system so that if the host or target platform is Mingw/Cygwin then we can skip winedefault.reg Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/

Jan. 23, 2004

segmentation fault when using kernel32.dll.so and oleaut32.dll.so

by Anil Akurathi

Hi, I need functions like 'MultiByteToWideChar', 'SysAllocStringLen', etc which are in kernel32.dll.so and oleaut32.dll.so libraries. I have some of questions regarding using them. - How can I link these libraries with my program. Using option -lkernel32.dll looks for libkernel32.dll.so file. - I tried renaming the files and also creating soft links using libkernel32.dll.so to kernel32.dll.so. - If I link like that, my program is giving a 'segmentation fault' error. - I tried using libraries produced by compiling on my uptodate RH8.0 machine and also the libraries from the RH8.0 rpm available on sourceforge.net. - I implement an XPCOM class using these libraries and when I try to create an object, it gives the 'Segmentation Fault'. - I tried using libwine.so but it doesn't contain the above functions I need. If anybody knows how to use these libraries, please mail back. Thanks in advance. Regards, Anil

Jan. 23, 2004

Variable in Visual Basic

by Savio Ramos

Hi, I am using wine with fake_windows. A Program don't works and return the message below. Any help? []'s Run time error '458' Variable uses an Automation type not supported in Visual Basic Invoking /usr/bin/wine.bin SISUPFOR.exe ... fixme:ole:CoRegisterMessageFilter stub fixme:ole:OleLoadPictureEx (0x4140292c,47552,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OleLoadPictureEx (0x4140292c,1086,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OleLoadPictureEx (0x4140292c,334,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958), partially implemented. fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf86c): stub fixme:ole:OLEPictureImpl_SaveAsFile (0x403b9d58)->(0x403c4168, 0, (nil)), hacked stub. fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf0a0): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf1dc): stub fixme:ole:VarCat Failed to convert right side from vt 8 to VT_BSTR? fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)->(0x406bf214): stub fixme:ole:CoRegisterMessageFilter stub Wine exited with a successful status -- Savio Martins Ramos Arquiteto Rio de Janeiro ICQ 174972645 Pirataria não! Use GNU/Linux Debian-br #705 Unstable http://www.debian.org

Jan. 23, 2004

RE: LockResource16 in ole32.dll

by Ge van Geldorp

> From: Dmitry Timoshkov > > Then it's better to fix LoadAcceleratorsA/W to use a proper allocator > and use the same aproach in both Wine and ReactOS. > > But in that case you have to write a test case which works at least > on NT/2000 and Wine. Another idea just popped up: the basic problem we're having is translating the handle passed in to a table containing the accelerator entries. How about using CopyAcceleratorTableA/W to do that? This function is designed to do that job and is located in user32. That dll is not shared between Wine and ReactOS anyway, so we can mess around in it anyway we like without disturbing Wine. Ge van Geldorp.

Jan. 23, 2004

Re: LockResource16 in ole32.dll

by Dmitry Timoshkov

"Ge van Geldorp" <ge(a)gse.nl> wrote: > > That will not work. 32-bit LockResource can't be used on a > > memory block allocated by GlobalAlloc16, as I explained before. > > No, not in Wine. But Wine will still use LockResource16, so there's no > problem. I can assure you that the memory block won't be allocated by > GlobalAlloc16 in ReactOS, simply because there is no GlobalAlloc16 in > ReactOS. Since there is also no LockResource16 in ReactOS it would take > the other code path. I'm just trying to find a solution which allows > umodified source code to be used by both Wine and ReactOS. Then it's better to fix LoadAcceleratorsA/W to use a proper allocator and use the same aproach in both Wine and ReactOS. But in that case you have to write a test case which works at least on NT/2000 and Wine. -- Dmitry.

Jan. 23, 2004

RE: LockResource16 in ole32.dll

by Ge van Geldorp

> From: Dmitry Timoshkov [mailto:dmitry(a)baikal.ru] > > "Ge van Geldorp" <ge(a)gse.nl> wrote: > > > Would the attached patch be an acceptable solution? > > Basically it does a GetProcAddress on LockResource16 > > and uses it if found (Wine case). If it's not found, > > it uses LockResource(). > > That will not work. 32-bit LockResource can't be used on a > memory block allocated by GlobalAlloc16, as I explained before. No, not in Wine. But Wine will still use LockResource16, so there's no problem. I can assure you that the memory block won't be allocated by GlobalAlloc16 in ReactOS, simply because there is no GlobalAlloc16 in ReactOS. Since there is also no LockResource16 in ReactOS it would take the other code path. I'm just trying to find a solution which allows umodified source code to be used by both Wine and ReactOS. Ge van Geldorp.

Jan. 23, 2004

Re: LockResource16 in ole32.dll

by Dmitry Timoshkov

"Ge van Geldorp" <ge(a)gse.nl> wrote: > Would the attached patch be an acceptable solution? Basically it does a > GetProcAddress on LockResource16 and uses it if found (Wine case). If it's > not found, it uses LockResource(). That will not work. 32-bit LockResource can't be used on a memory block allocated by GlobalAlloc16, as I explained before. -- Dmitry.

Jan. 23, 2004

Re: WWN#206

by Rein Klazes

Hi, > Mike wondered why the end of 1998 seemed so productive. > Rein felt two factors might have had a hand it: in October > CVS mistakenly reported the same commit more than once, > however at time Corel was actively working on Wine and > there geniunely were a lot of commits. > > Note - this graph does not reflect the size of the Wine > source code. It's only the commits. Anyone want to produce > a graph of how much has been added? I think it would be > interesting to see the trend. You can find it here: http://home.wanadoo.nl/~wijn/wine/cvssize.png Notes: - All files in the cvs wine tree are included, not just the sources. - I excluded the (libs/)unicode directory. That is almost 5 MByte of mostly generated source files creating an ugly step in an otherwise smooth curve. - The trend quite accurately represents the growth in the first 3 years. The last 2 years the rate of growth is clearly increasing. - The number of cvs commits in October '98 was corrected to 258 commits. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 23, 2004

RE: shlwapi prototype fixes

by Ge van Geldorp

> From: Robert Shearman > > > MLLoadLibrary was recently documented by Microsoft. > > My changes makes it conform to the now-documented prototype > > so I don't see what's wrong with it? > > Either it is different on Windows XP (my system is Windows > 2000 SP4 with IE6 SP1), or they just got it wrong. The fact > remains that I have seen an application working perfectly > well on Wine whilst using this function as it stands. Yes, you're right. Ordinals 377 and 378 (MLLoadLibraryA/MLLoadLibraryW) in both the Win2k and WinXP shlwapi.dll pop 12 bytes from the stack on return. I'll resubmit my patch for the other prototypes. Gé van Geldorp.

Jan. 23, 2004

Re: WINMM problem with Half-Life

by Mike McCormack

Here you go. wine --debugmsg +mciavi,+winmm,+seh hl.exe >& hl-winmm.log Pressed ^C after it hung. Mike Eric Pouech wrote: > yup. can you post a -debugmsg +mciavi trace > A+ >

Jan. 23, 2004

Re: LockResource16 in ole32.dll

by Ge van Geldorp

> From: Dmitry Timoshkov > > "Casper Hornstrup" <chorns(a)users.sourceforge.net> wrote: > > > I would like to have the call to the Win16 API LockResource16 removed > > from ole32.dll. I guess there is a reason for it being LockResource16 > > and not LockResource. What is the reason? > > Because LoadAcceleratorsA/W returns a value allocated by GlobalAlloc16. > > > How can the call be removed? > > Only if you or someone else can prove that under real windows > LoadAcceleratorsA/W behaves differently (taking into account Win9x > weirdness). Would the attached patch be an acceptable solution? Basically it does a GetProcAddress on LockResource16 and uses it if found (Wine case). If it's not found, it uses LockResource(). Ge van Geldorp. Index: dlls/ole32/ole2.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/ole2.c,v retrieving revision 1.48 diff -u -r1.48 ole2.c --- dlls/ole32/ole2.c 8 Dec 2003 22:46:08 -0000 1.48 +++ dlls/ole32/ole2.c 23 Jan 2004 14:17:06 -0000 @@ -1422,9 +1422,34 @@ /* YES, Accel16! */ LPACCEL16 lpAccelTbl; int i; + HMODULE Kernel32; + LPVOID (WINAPI *LockResource16Ptr)(HGLOBAL16 ResData); if(!lpMsg) return FALSE; - if (!hAccel || !(lpAccelTbl = (LPACCEL16)LockResource16(HACCEL_16(hAccel)))) + if (!hAccel) + { + WARN_(accel)("NULL accel handle\n"); + return FALSE; + } + Kernel32 = GetModuleHandleA("kernel32.dll"); + if (NULL != Kernel32) + { + LockResource16Ptr = (LPVOID (WINAPI *)(HGLOBAL16)) + GetProcAddress(Kernel32, "LockResource16"); + } + else + { + LockResource16Ptr = NULL; + } + if (NULL != LockResource16Ptr) + { + lpAccelTbl = (LPACCEL16) LockResource16Ptr(HACCEL_16(hAccel)); + } + else + { + lpAccelTbl = (LPACCEL16) LockResource(hAccel); + } + if (NULL == lpAccelTbl) { WARN_(accel)("invalid accel handle=%p\n", hAccel); return FALSE;

Jan. 23, 2004

warning to "wine on cygwin" experimenters

by Anonymous

I got cygwin to compile wine to the point where wine-install tried to run regedit on winedefault.reg. I should have been paying closer attention. The good news is that the wine regedit.exe works like a charm. The bad news is that it overwrote my actual windows registry with the bunk values in winedefault.reg. Not gonna be very easy to roll back. So... WATCH OUT! That last step's a doozy.

Jan. 23, 2004

RE: comctl32 resources / shlwapi prototype fixes

by Robert Shearman

> Changelog: > Sync with ReactOS 0.2 > Fix various function prototypes to conform to PSDK > > Index: dlls/shlwapi/ordinal.c > =================================================================== > RCS file: /home/wine/wine/dlls/shlwapi/ordinal.c,v > retrieving revision 1.75 > diff -u -r1.75 ordinal.c > --- dlls/shlwapi/ordinal.c 1 Oct 2003 03:10:42 -0000 1.75 > +++ dlls/shlwapi/ordinal.c 22 Jan 2004 23:41:41 -0000 > @@ -3414,7 +3414,8 @@ > * Success: A handle to the loaded module > * Failure: A NULL handle. > */ > -HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HMODULE inst_hwnd, > DWORD dwFlags) > +HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HANDLE inst_hwnd, > DWORD dwFlags, > + LPCSTR component, BOOL cross_code_page) This is wrong. Please resubmit without this change until we can discover why the prototype has 5 parameters, yet on my system the implementation only takes 3. > { > /* FIXME: Native appears to do DPA_Create and a DPA_InsertPtr for > * each call here. > @@ -3453,7 +3454,8 @@ > * > * Unicode version of MLLoadLibraryA. > */ > -HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HMODULE > inst_hwnd, DWORD dwFlags) > +HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HANDLE inst_hwnd, > DWORD dwFlags, > + LPCWSTR component, BOOL cross_code_page) Same again > { > WCHAR mod_path[2*MAX_PATH]; > LPWSTR ptr;

Jan. 23, 2004

Re: RFC on our new initiative

by Mike Hearn

On Fri, 2004-01-23 at 10:54, Francois Gouget wrote: > I believe that's why Gregory proposed to fork their code: because he > just wants a 100% open-source way to run .Net apps in Wine and thus for > him the hard-dependency on Wine is not an issue. > > Can Mono work on Windows? Or, in other words, is there an open-source > .Net implementation on Windows? If yes we could try to make that work in > Wine (as a PE binary first, then via a MinGW + Winelib port). It can yes, I can imagine that you'd be able to build Mono as a winelib app. We really need to think about this carefully. The situation is a bit sticky: * Sometimes Wine will require Mono to run apps (for instance you can have normal Win32 apps that link against the .NET runtime or use COM activation to get .NET components at runtime) * Sometimes Mono will require Wine to run apps, for programs that require System.Windows.Forms, but also for IJW binaries and for when .NET apps depend on unmanaged win32 COM components. So it goes both ways. This is really tricky. One way to do is to fork each others code and merge them into each other but that just makes me feel dirty :) There has to be a better way..... I'm not sure what it is yet though. We could probably implement our own mscorlib.dll which does the unmanaged setup then relays to libmscorlib.so or whatever it is mono uses.

Jan. 23, 2004

Re: RFC on our new initiative

by Francois Gouget

On Thu, 22 Jan 2004, Mike Hearn wrote: > On Thu, 22 Jan 2004 11:17:55 -0600, Gregory M. Turner wrote: > > Mono is LGPL/X11 (except the compiler) so we could beat them at their own game > > by forking /their/ code, turning it into a winelib app, and implementing > > Windows.Forms properly ;) > > It's not that simple. Unsurprisingly they don't want a hard dependency on Wine > when many .NET apps they write don't use SWF, so they need to be able to use wine > without being a winelib app. We simply don't support that. I believe that's why Gregory proposed to fork their code: because he just wants a 100% open-source way to run .Net apps in Wine and thus for him the hard-dependency on Wine is not an issue. Can Mono work on Windows? Or, in other words, is there an open-source .Net implementation on Windows? If yes we could try to make that work in Wine (as a PE binary first, then via a MinGW + Winelib port). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Jan. 23, 2004

Re: Systray integration patch

by Martin Garton

> I maintain that patch - does it no longer apply? I noted a single merge > conflict when I recently updated CVS but it's trivial to fix. Is this > the issue? I got: 1 out of 10 hunks FAILED -- saving rejects to file dlls/shell32/systray.c.rej 5 out of 16 hunks FAILED -- saving rejects to file dlls/x11drv/window.c.rej The systray.c problem is just in comments. The others are not (don't appear to be from my inexperienced perspective) trivial. Maybe I'm using an old version of the patch. Is there somewhere where the latest version lives? Regards, Martin.

Jan. 23, 2004

Re: Add support for MDICREATESTRUCT conversion for 16-bit windows

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Using GetExePtr is going to return the wrong instance once we get back > to 16-bit code. The instance handles are actually not supposed to be > converted at all, we just expand the 16-bit ones to 32-bit. What was > the problem with your 16-bit app? The app sends WM_MDICREATE message which fails with: win.c,create_window_handle(): error 6 creating window The WM_MDICREATE message gets translated from 16-bit to Ansi, and the following CreateWindowEx calls fails due to bad hInstance passed to create_window() server call. -- Dmitry.

Jan. 23, 2004

Re: Implement binary relocatability

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Before Wine would not be able to find libwine nor ntdll.so, now it can. > > I hope this patch is OK, as I think this is a useful feature that far more > free software should support. The list of use cases is big. As dicussed a couple of weeks ago, this needs to be optional; you don't necessarily always want that behavior, and it conflicts with the --prefix option. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2004

Re: Add support for MDICREATESTRUCT conversion for 16-bit windows

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > I've got a bug report that after my MDI rewrite some 16-bit MDI app > stopped to work. That's not a surprise at all. The surprise is that > STRUCT32_xxx conversion helpers didn't cope correctly with 16-bit > hInstance and actually that caused a 16-bit app to misbehave in > the first place. I had to use GetExePtr() because MapHModuleSL checks > for NE_FFLAGS_WIN32 (why?) and bails out. Using GetExePtr is going to return the wrong instance once we get back to 16-bit code. The instance handles are actually not supposed to be converted at all, we just expand the 16-bit ones to 32-bit. What was the problem with your 16-bit app? -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2004

FYI: Patch sent to wine-patches list. (NT) (WAS: Re: GetCommandLine issue with Dungeon Keeper)

by Frank.Schruefer＠t-online.de

Jan. 23, 2004

Re: PATCH: install more programs

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > I think we can install those safely. > > Ciao, Marcus > > Changelog: > Install rundll32,winemenubuilder and winevdm into the system. Why do you need these? They are not really supposed to be started directly by the user. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2004

Re: Wine release 20040121

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Does this mean winelib apps no longer need to be run like "wine foo.exe.so", > and can just be "./foo" like any other ELF binary? No it has nothing to do with that. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2004