Re: Steam Problems
> I've sent a patch to wine-patches some time ago, but it wasn't accepted > because it's wrong. The link is > http://www.winehq.org/hypermail/wine-patches/2005/03/0504.html > > You may try it, it fixes Steam in this aspect, but it may break other apps. Yes, the patch works for Steam, and fixes this bug, which is marked as blocker. http://bugs.winehq.org/show_bug.cgi?id=2926 This will allow me to download and install HL2 over the web. What's wrong with it?
Re: dlls/ntdll/cdrom.c breakage
"Gerald Pfeifer" <[EMAIL PROTECTED]> wrote: I don't see how it worked before then, you need to investigate why '#ifdef SENSEBUFLEN' case doesn't work for you. I checked, and there is no occurrence of SENSEBUFLEN in /usr/include on a SUSE 9.2 machine nor on FreeBSD nor in the entire Wine source tree. Again, any idea why it was in the '#elif defined(__FreeBSD__)' case then? -- Dmitry.
Re: dlls/ntdll/cdrom.c breakage
"Gerald Pfeifer" <[EMAIL PROTECTED]> wrote: This means that HAVE_SCSIREQ_T_CMD is not defined for you, i.e. scsireq_t has not been detected. Very likely this is caused by a wrong/missing header includes in the configure.ac test, please fix it, it's easy enough. I found that FreeBSD does not have this type defined anywhere, so I hope Alexandre will take my patch. Any idea why it was in the '#elif defined(__FreeBSD__)' case then? -- Dmitry.
Re: dlls/ntdll/cdrom.c breakage
On Thu, 30 Jun 2005, Dmitry Timoshkov wrote: >> cdrom.c: In function `CDROM_ScsiPassThroughDirect': >> drom.c:1423: error: invalid application of `sizeof' to an incomplete type >> cdrom.c: In function `CDROM_ScsiPassThrough': >> cdrom.c:1543: error: invalid application of `sizeof' to an incomplete type > I don't see how it worked before then, you need to investigate why > '#ifdef SENSEBUFLEN' case doesn't work for you. I checked, and there is no occurrence of SENSEBUFLEN in /usr/include on a SUSE 9.2 machine nor on FreeBSD nor in the entire Wine source tree. How shall we proceed on this one? Gerald
Bug in dlls/comctl32/comctl32undoc.c
Hi, playing around a bit with wine, i found a thing that is obviously a bug. In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead. By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-) Regards Sascha P.S.: Please CC me on answers as i'm not subscribed here.
Re: dlls/ntdll/cdrom.c breakage
On Thu, 30 Jun 2005, Dmitry Timoshkov wrote: >> Alexandre, please find below another patch which does not fix this either, >> but gets rid of some unused variable warnings. >> ChangeLog: >> Avoid unused variable warnings in CDROM_ScsiPassThroughDir() and >> CDROM_ScsiPassThrough(). > This means that HAVE_SCSIREQ_T_CMD is not defined for you, i.e. scsireq_t > has not been detected. Very likely this is caused by a wrong/missing header > includes in the configure.ac test, please fix it, it's easy enough. I found that FreeBSD does not have this type defined anywhere, so I hope Alexandre will take my patch. Gerald
Re: advapi32: Branch the LSA functions from security.c to lsa.c [RESEND]
James Hawkins wrote: --- /dev/null 2005-06-27 14:12:40.646578496 -0500 +++ dlls/advapi32/lsa.c 2005-06-27 16:51:17.0 -0500 @@ -0,0 +1,433 @@ +/* + * Implementation of the Local Security Authority API + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ You should include a copyright line that states the major copyright owners of the code. You can do this by looking through the CVS history or just by copying the copyright lines from security.c -- Rob Shearman
Re: unixfs registered by default now in cvs
On Thursday 30 June 2005 21:21, Brian Vincent wrote: > Does this mean there's no longer a need to map a Z: drive to /? You still can only access the parts of the filesystem, which are accessible by a wine drive. You will see the complete unix directory structure, but you will only be able to select files, which are accessible by wine. The unix directories, which are not accessible, are much like the MyComputer folder in that they don't map to a windows filesystem location. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Wine avitools/aviplay fails with CO_E_NOTINITIALIZED for any AVI file
It worked in the past. When pclsidHandler is set to NULL it performs
a registry lookup as the native version does it. If these registry
entries are missing it has a problem and could perhaps return the
mentioned error - don't know as I have never tested it.
In the past these informations were part of the default registry of
wine but with the addition of the self-registration of many libraries
this has been removed. Don't ask me how to get the library to
register itself - guess it has to do with regsrv32.exe, but I am not
sure. I am already too long out of the substance.
Based on a certain verification in the source code, I made aviinfo to
work by adding the following to the registry:
[Software\\Classes\\CLSID\\{0002---C000-0046}\\InProcServer32]
1110571609
@="avifil32.dll"
"LoadWithoutCOM"=dword:
As far as I can see, the key "LoadWithoutCOM" only needs to exist; it
does not need to be set to any particular value. The aviplay program has
yet to work because the 128x128 AVI file I was using for the test in one
machine (apparently) mandates a 128x128 screen resolution which is (yet)
unsupported by my X configuration, and the ideal 640x480 test AVI is on
the other (currently inaccessible) machine:
trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 128:
320x240x16 @60 Hz (XRandR)
trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 129:
360x200x16 @85 Hz (XRandR)
trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 130:
320x200x16 @85 Hz (XRandR)
trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 131:
320x175x16 @85 Hz (XRandR)
trace:x11settings:X11DRV_Settings_CreateDriver Setting up display
settings for DDRAW (XRandR)
fixme:avifile:AVIFileInit (): stub!
[Stream 0: vids.cvid, cineapk.avi v�eo #0]
trace:x11settings:X11DRV_ChangeDisplaySettingsExW
((null),0x707bf768,(nil),0x0004,(nil))
trace:x11settings:X11DRV_ChangeDisplaySettingsExW flags=FULLSCREEN
trace:x11settings:X11DRV_ChangeDisplaySettingsExW
DM_fields=BITSPERPEL,PELSWIDTH,PELSHEIGHT
trace:x11settings:X11DRV_ChangeDisplaySettingsExW width=128 height=128
bpp=24 freq=1887172668 (XRandR)
err:x11settings:X11DRV_ChangeDisplaySettingsExW No matching mode found!
(XRandR)
ddraw.SetDisplayMode: 0x88760078 (change resolution!)
But this raises the following questions:
* Why is not avifil32.dll adding this key on registration by regsvr32?
(I could submit a patch to do it, but see next questions)
* Is this the correct usage of avifil32.dll? The loading of this dll
occurs via SHCoCreateInstance in shell32/shellole.c, and the comment on
the usage of the LoadWithoutCOM key goes like this:
//* if a special registry key is set, we load a shell extension
without help of OLE32 *//
bLoadWithoutCOM = (ERROR_SUCCESS == SHQueryValueExW(hKey,
sLoadWithoutCOM, 0, 0, 0, 0));
Is this the correct (or even supported) usage for avifil32.dll? This
LoadWithoutCOM kludge does not appear anywhere else in my registry, and
it looks like it is intended for shell extensions only. What is the
meaning of "shell extension" here? Does avifil32.dll qualify? (I think
not, because avifil32 is concerned with AVI file handling, not with user
interface. However, I might be wrong.)
The last thing I want is to submit a patch, only to be rejected because
it attempts to use a DLL in a way not intended by its design. So, is
this approach correct (adding LoadWithoutCOM as part or regsvr32
initialization of avifil32.dll), or should an apartment actually be
initialized in full COM style? Do you know if LoadWithoutCOM is used
anywhere else in Wine?
Alex Villacís Lasso
Re: unixfs registered by default now in cvs
On 6/30/05, Michael Jung <[EMAIL PROTECTED]> wrote: > With the current CVS version, the unixfs shell namespace extension is now > registered by default at the desktop. So if you do a 'regsvr32 shell32' you Does this mean there's no longer a need to map a Z: drive to /? -Brian
Re: Anybody looking for a pet Wine project?
I forgot to attach hh.exe...
#include
typedef int WINAPI DOWINMAIN(HMODULE hMod, LPSTR cmdline);
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdline, int
cmdshow)
{
HMODULE hModule;
DOWINMAIN *doWinMain;
hModule = LoadLibrary("hhctrl.ocx");
doWinMain = GetProcAddress(hModule, "doWinMain");
return doWinMain(hInst, cmdline);
}
Wine avitools/aviplay fails with CO_E_NOTINITIALIZED for any AVI file
I recently downloaded Wine-20050628 (self contained install with fake
Windows drive) and tried to use the aviplay program in programs/avitools
directory. However, this program fails with this odd error trace:
[bash$] WINEDEBUG=shell,ole wine
~/temp/wine/wine-20050628-patch/programs/aviplay.exe.so blur24.avi
...
trace:shell:SIC_IconAppend L"c:\\windows\\system\\shell32.dll" 37 0x1126
0x112e
trace:shell:SHAlloc 20 bytes at 0x65f43068
trace:shell:SIC_IconAppend L"c:\\windows\\system\\shell32.dll" -38
0x1126 0x112e
trace:shell:SHAlloc 20 bytes at 0x65f430d0
trace:shell:SIC_Initialize hIconSmall=0x65f2f5e0 hIconBig=0x65f31190
fixme:avifile:AVIFileInit (): stub!
trace:shell:HCR_RegOpenClassIDKey
CLSID\{00020020---c000-0046}
trace:shell:HCR_GetClassNameA --
trace:shell:HCR_RegOpenClassIDKey
CLSID\{0002---c000-0046}
trace:shell:HCR_GetClassNameA -- Microsoft AVI Files
trace:shell:SHCoCreateInstance ((nil),
{0002---c000-0046} (Microsoft AVI
Files),unk:(nil),
{00020020---c000-0046} (unknown),0x65cbf8fc)
trace:shell:SHQueryValueExW
(hkey=0x64,(null),(nil),(nil),0x65cbf338,0x65cbf330=520)
trace:shell:SHQueryValueExW
(hkey=0x64,L"LoadWithoutCOM",(nil),(nil),(nil),(nil)=0)
trace:shell:PathFindFileNameW (L"avifil32.dll")
trace:shell:SHCoCreateInstance WithoutCom=0 FromShell=0
trace:shell:HCR_RegOpenClassIDKey
CLSID\{00020020---c000-0046}
trace:shell:HCR_GetClassNameA --
trace:shell:HCR_RegOpenClassIDKey
CLSID\{0002---c000-0046}
trace:shell:HCR_GetClassNameA -- Microsoft AVI Files
err:shell:SHCoCreateInstance failed (0x800401f0) to create CLSID:
{0002---c000-0046} (Microsoft AVI Files) IID:
{00020020---c000-0046} (unknown)
err:shell:SHCoCreateInstance class not found in registry
trace:shell:SHCoCreateInstance -- instance: (nil)
AVIFileOpen: 0x800401f0
I looked up in the include files, and the value of 0x800410f0 is
CO_E_NOTINITIALIZED. This is confirmed by a check in the source code
that indicates that the apartment was not initialized (please correct me
if I get the terminology wrong). The code for aviplay and aviinfo does
not attempt to initialize any apartment prior to calling AVIFileOpen
with /pclsidHandler/ set to NULL. I looked up in MSDN, and the
documentation for AVIFileOpen does not suggest (to me at least), that an
apartment should be initialized by the caller. This seems odd, since
this means that the program should never have worked in the first place,
yet the comments in the source suggest that it worked at least once.
Are these avitools maintained? If so, does this result from a
misconfiguration (the same one in two different machines so far), or
from a genuine incomplete implementation? I would like to hear any
comment on this. The original purpose of messing with aviplay was to
test whether the Indeo video codecs are actually usable after being
installed under Wine, but this problems affects even files not encoded
with Indeo.
Alex Villacís Lasso
Re: Anybody looking for a pet Wine project?
Hello. I think it will be great to have it done. I'd like to point out one thing for the way to implement it: the most important is to have it working with native shdocvw.dll and mshtml.dll. It won't work with built in in the current state of them, but it will be fixed soon and I believe it can be in CVS even if it doesn't work without these dlls. While implementing then we shouldn't pay too much attention to get it working with Mozilla ActiveX Control - it will never work perfectly and I hope to get rid of its dependency soon. Of course you may do it working, but, as my tests show, it's far from compatible with MS. Also, we need to use itss.dll, which is impossible with Mozilla ActiveX (I'm not sure if Mozilla has support for chm protocol, but even if so it's worse to use it). About implementing hh.exe... it seams to be pretty easy. Attached is (not tested) implementation:-) Another related idea is, as I have spoken with Mike on irc, to use html help in winecfg. It looks like a nice way to have a complex and integrated help. This would mean that we need to implement the chm compiler. To do so we may use chmlib: http://66.93.236.84/~jedwin/projects/chmlib/ that Mike used in itss to decompress chm. As a conclusion: it would be really good to have this working in Wine. It uses most of IE related API (I didn't mension URLMoniker here, which also needs some work) and getting it to work out of box will be a great test for Wine. Thanks, Jacek
Re: MSHTML: fix blank.htm resources
Alexandre Julliard wrote: >That's a feature ;-) We can't support loading builtins as datafiles, >so the idea is that it's more likely that the app will be happy with >loading the native as datafile than loading the builtin in normal >mode. It does make the behavior a bit surprising I agree. > > > Good to know that Wine doesn't have such bug in so important place:-) Maybe it would be better to point it out somewhere in the documentation so that people like me won't have to cover such things themselves. Thanks, Jacek
Re: MSHTML: fix blank.htm resources
Jacek Caban <[EMAIL PROTECTED]> writes: > This patch depends on my patch to wrc. Alexandre, > I discovered why the test didn't fail for me. There is > a bug in Wine that causes loading of the native dll instead > of builtin when you load it as a data file, so I tested the > builtin dll with native resources. That's a feature ;-) We can't support loading builtins as datafiles, so the idea is that it's more likely that the app will be happy with loading the native as datafile than loading the builtin in normal mode. It does make the behavior a bit surprising I agree. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sony Station
--- Chuck Hall <[EMAIL PROTECTED]> wrote: > Was there a specific game that you wanted to test > here? > Well, I've just got a copy of Everquest II, but it would be nice to get any of the Sony Station games working. It looks like I can just change a setting in the registry so long as I've run the post-scan file update under windows. > I have not tried to install any game that required > it, but I can if you > want something tested. > > Have Fun! > Chuck Hall > > On Wed, 29 Jun 2005, Oliver Stieber wrote: > > > Hi, > > > > Has anyone managed to get sony's station > > (http://www.station.sony.com/en/) past the file > scan? > > > > > > > > > > > > > ___ > > > Yahoo! Messenger - NEW crystal clear PC to PC > calling worldwide with voicemail > http://uk.messenger.yahoo.com > > > > -- > > > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: [user/tests]: Re: Fix bug that left mouse buttons swapped after tests
* On Thu, 30 Jun 2005, Paul Vriens wrote:
>
> > Saulius Krasuckas <[EMAIL PROTECTED]>
> > - Break from the loop to restore SM_SWAPBUTTON metrics.
...
> > --- dlls/user/tests/sysparams.c 20 Jun 2005 15:36:17 - 1.38
> > +++ dlls/user/tests/sysparams.c 30 Jun 2005 07:36:40 -
> > @@ -1011,7 +1011,7 @@ static void test_SPI_SETMOUSEBUTTONSWAP(
> > rc=SystemParametersInfoA( SPI_SETMOUSEBUTTONSWAP, vals[i], 0,
> >SPIF_UPDATEINIFILE | SPIF_SENDCHANGE );
> > if (!test_error_msg(rc!=vals[i],"SPI_{GET,SET}MOUSEBUTTONSWAP"))
> > -return;
> > +break;
>
> It's nice to break but the the end-result will be that the test fails on
> all windows versions I could my hands on
Test fails because of flawed logic at if-statement, which I have no time
to debug for. So I chose to have flawed check instead of having
mouse-buttons swapped (which isn't so visible from the test results).
> and that the previous setting is restored. Not very useful it seams.
So if the buttons were standard mapped, then they got swapped during test
and then test failed, you think it is OK to leave buttons swapped?
Question about deadlock in winmm
Lately I'm seeing a lot of deadlocks in wine's sound system. Most notably
winealsa. But the code in question affects all (in my case oss since it's
working better for me then others).
I'm not sure what exactly happens (deadlock because of race condition or else)
but code bellow deadlocks with other heap functions (like GetHeap). Removing
HeapValidate didn't cause any problems for as of yet. And I haven't seen a
single deadlock here at all.
Is there are reasons we perform this heap validation here? Could someone comment
on this?
If someone interested I could reproduce backtrace of the deadlock.
--
Best regards,
Vitaliy
Index: dlls/winmm/lolvldrv.c
===
RCS file: /home/wine/wine/dlls/winmm/lolvldrv.c,v
retrieving revision 1.68
diff -u -p -r1.68 lolvldrv.c
--- dlls/winmm/lolvldrv.c 22 Jun 2005 11:59:43 - 1.68
+++ dlls/winmm/lolvldrv.c 29 Jun 2005 14:54:42 -
@@ -441,7 +441,7 @@ LPWINE_MLD MMDRV_Get(HANDLE _hndl, UINT
hndl = hndl & ~0x8000;
if (hndl < sizeof(MM_MLDrvs) / sizeof(MM_MLDrvs[0])) {
mld = MM_MLDrvs[hndl];
- if (!mld || !HeapValidate(GetProcessHeap(), 0, mld) ||
mld->type != type)
+ if (!mld || mld->type != type)
mld = NULL;
}
hndl = hndl | 0x8000;
Re: [user/tests]: Re: Fix bug that left mouse buttons swapped after tests
> Saulius Krasuckas wrote: >>>ChangeLog: Fix bug that left mouse buttons swapped after tests >>> >>>Ivan. >> >> >> I think your patch causes test to fail on Wine, Ivan. My try goes next. > > Maybe that isn't a bad thing, the results from the latest build of > winetest shows this test fails > on windows 2000, windows nt, windows me, and windows 98se, so I somewhat > doubt the wine behaviour is > correct. > > Ivan. And this is exactly why no part of winetest should be allowed to fail. //Jakob
Re: Fix ntdll compilation in Darwin
"Phil Krylov" <[EMAIL PROTECTED]> wrote: > #ifdef SENSEBUFLEN > if (pPacket->SenseInfoLength > SENSEBUFLEN) > +#elif defined( __APPLE__ ) > +if (pPacket->SenseInfoLength > kSenseDefaultSize) > #else > if (pPacket->SenseInfoLength > sizeof(struct request_sense)) > #endif Please do not introduce even more platform dependent #ifdefs into cdrom.c, currently it already has enough mess with all that #if defined(linux)/(__FreeBSD__)/ (__NetBSD__). Add proper configure checks for headers and structures your platform needs. To be sure I get you right: would changing __APPLE__ to HAVE_IOKIT (and adding HAVE_IOKIT detection to configure) be sufficient? I'd assume it's enough, yes. kSenseDefaultSize requires another test I think. -- Dmitry.
Re: Fix ntdll compilation in Darwin
Hi Dmitry, On Thu, 30 Jun 2005 22:27:01 +0900 "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: > "Phil Krylov" <[EMAIL PROTECTED]> wrote: > > > Index: dlls/ntdll/cdrom.c > > === > > RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v > > retrieving revision 1.59 > > diff -p -u -r1.59 cdrom.c > > --- dlls/ntdll/cdrom.c 29 Jun 2005 19:18:54 - 1.59 > > +++ dlls/ntdll/cdrom.c 30 Jun 2005 11:27:41 - > > @@ -75,6 +75,11 @@ > > # include > > #endif > > > > +#ifdef __APPLE__ > > +# include > > +# include > > +#endif > > + > > #define NONAMELESSUNION > > #define NONAMELESSSTRUCT > > #include "ntstatus.h" > > @@ -1418,6 +1423,8 @@ static NTSTATUS CDROM_ScsiPassThroughDir > > > > #ifdef SENSEBUFLEN > > if (pPacket->SenseInfoLength > SENSEBUFLEN) > > +#elif defined( __APPLE__ ) > > +if (pPacket->SenseInfoLength > kSenseDefaultSize) > > #else > > if (pPacket->SenseInfoLength > sizeof(struct request_sense)) > > #endif > > Please do not introduce even more platform dependent #ifdefs into cdrom.c, > currently it already has enough mess with all that #if > defined(linux)/(__FreeBSD__)/ > (__NetBSD__). Add proper configure checks for headers and structures your > platform needs. To be sure I get you right: would changing __APPLE__ to HAVE_IOKIT (and adding HAVE_IOKIT detection to configure) be sufficient? -- Ph.
Re: Fix ntdll compilation in Darwin
"Phil Krylov" <[EMAIL PROTECTED]> wrote: Index: dlls/ntdll/cdrom.c === RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v retrieving revision 1.59 diff -p -u -r1.59 cdrom.c --- dlls/ntdll/cdrom.c 29 Jun 2005 19:18:54 - 1.59 +++ dlls/ntdll/cdrom.c 30 Jun 2005 11:27:41 - @@ -75,6 +75,11 @@ # include #endif +#ifdef __APPLE__ +# include +# include +#endif + #define NONAMELESSUNION #define NONAMELESSSTRUCT #include "ntstatus.h" @@ -1418,6 +1423,8 @@ static NTSTATUS CDROM_ScsiPassThroughDir #ifdef SENSEBUFLEN if (pPacket->SenseInfoLength > SENSEBUFLEN) +#elif defined( __APPLE__ ) +if (pPacket->SenseInfoLength > kSenseDefaultSize) #else if (pPacket->SenseInfoLength > sizeof(struct request_sense)) #endif Please do not introduce even more platform dependent #ifdefs into cdrom.c, currently it already has enough mess with all that #if defined(linux)/(__FreeBSD__)/ (__NetBSD__). Add proper configure checks for headers and structures your platform needs. -- Dmitry.
Re: unixfs registered by default now in cvs
On Thursday 30 June 2005 15:01, Dimi Paun wrote: > This is fantastic! Way to go Michael, you've nailed an important > integration issue. BTW, if it is registered by default, why do we > need to 'regsvr32 shell32'? Thanks. If you start without a .wine directory, you won't need the 'regsvr32 shell32'. So for a fresh install, you will end up with unixfs. But if you already have a '.wine' directory and want unixfs to be registered, you'll have to do it by hand. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: unixfs registered by default now in cvs
On Thu, 2005-06-30 at 14:05 +0200, Michael Jung wrote: > With the current CVS version, the unixfs shell namespace extension is > now registered by default at the desktop. So if you do a 'regsvr32 > shell32' you will see the unix filesystem in the file dialogs. This is fantastic! Way to go Michael, you've nailed an important integration issue. BTW, if it is registered by default, why do we need to 'regsvr32 shell32'? -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
The wine-patches archives
Looks like ""Downloadable version" is stuck at 9 MB last time I checked we were at a new record of 10.2 MB . Newman to the rescue ? Cheers, Tom
unixfs registered by default now in cvs
Hi,
With the current CVS version, the unixfs shell namespace extension is now
registered by default at the desktop. So if you do a 'regsvr32 shell32' you
will see the unix filesystem in the file dialogs. It's probably still quite
buggy though. It would be cool if we could get the biggest problems sorted
out before the next release. So if you have an application, which doesn't
work due to unixfs, please report to wine-devel.
If you don't want to use unixfs, because you don't like it or because it
totally breaks your setup, you can delete the following registry-key and you
should be back to the old behaviour:
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace\
{9D20AAE8-0625-44B0-9CA7-71889C2254D9}
This will also help you to figure out if a problem is due to unixfs. If you do
'regsvr32 shell32' again, the key will be re-created.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Re: Delays in FileOpen
> "Michael" == Michael Jung <[EMAIL PROTECTED]> writes: Michael> On Wednesday 29 June 2005 23:36, Uwe Bonnes wrote: >> File Open Dialogs for me have some noticable initial delay when >> starting up. For example, try in internet explorer "Save under". I >> don't remember seeing that delay some time before. Dif recent >> shfolder changes cause that delay? Michael> There was a problem in SHGetPathFromIDList, which caused a Michael> delay in the file dialogs. I hope it was fixed with this patch, Michael> applied at the 2005/06/25. Michael> http://cvs.winehq.org/patch.py?id=18448 Michael> Does your local tree already contain this patch? Yes, my local tree contains the patch. But my first impression was incorrect, the delay is _not_ new. The test with ie6 where done with a wine-200410xx setup, and "save as" shows the delay too. But also other programs run against recent CVS wine show that initial delay until the file selection box starts up. Do other notice that delay too? E.g. the file -> open box from wordview97 takes several seconds on an Athlon2500. (about 500 file/directories including dot files/directory in $HOME where the file open box starts up). Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Fwd: Anybody looking for a pet Wine project?
-- Forwarded message --
From: Vijay Kiran Kamuju <[EMAIL PROTECTED]>
Date: Jun 30, 2005 3:42 PM
Subject: Re: Anybody looking for a pet Wine project?
To: Mike McCormack <[EMAIL PROTECTED]>
typelib info of hhctrl.ocx of winxp (used pe explorer)
--
//HHCtrl 4.0 Type Library
//Version: 4.0
HHCTRLLib;
GUID = {ADB880A2-D8FF-11CF-9377-00AA003B7A11};
//Event interface for HHCtrl
Dispatch _HHCtrlEvents;
GUID = {ADB880A3-D8FF-11CF-9377-00AA003B7A11};
function Click(out ParamString: BSTR); stdcall;
//HHCtrl Class
CoClass HHCtrl;
GUID = {52A2AAAE-085D-4187-97EA-8C30DB990436};
//IHHCtrl Interface
Dispatch IHHCtrl;
GUID = {ADB880A1-D8FF-11CF-9377-00AA003B7A11};
function QueryInterface(riid: ^GUID; out ppvObj: ^^VOID); stdcall;
function AddRef: UI4; stdcall;
function Release: UI4; stdcall;
function GetTypeInfoCount(out pctinfo: ^UINT); stdcall;
function GetTypeInfo(itinfo: UINT; lcid: UI4; out pptinfo: ^^VOID); stdcall;
function GetIDsOfNames(riid: ^GUID; rgszNames: ^^I1; cNames: UINT;
lcid: UI4; out rgdispid: ^I4); stdcall;
function Invoke(dispidMember: I4; riid: ^GUID; lcid: UI4; wFlags:
UI2; pdispparams: ^DISPPARAMS; out pvarResult: ^Variant; out
pexcepinfo: ^EXCEPINFO; out puArgErr: ^UINT); stdcall;
property-put Image(: BSTR); stdcall;
property-get Image: BSTR; stdcall;
//Click method
function Click; stdcall;
//Click method
function HHClick; stdcall;
//Print method
function Print; stdcall;
//syncURL method
function syncURL(out pszUrl: BSTR); stdcall;
//TCard method
function TCard(out wParam: UINT_PTR; out lParam: LONG_PTR); stdcall;
//Text Popup method
function TextPopup(out pszText: BSTR; out pszFont: BSTR; out
horzMargins: INT; out vertMargins: INT; out clrForeground: UI4; out
clrBackground: UI4); stdcall;
Alias UINT_PTR;
UI4
Alias LONG_PTR;
I4
//Deprecated HHCtrl Class 2
CoClass OldHHCtrl2;
GUID = {41B23C28-488E-4E5C-ACE2-BB0BBABE99E8};
//Deprecated HHCtrl Class 1
CoClass OldHHCtrl1;
GUID = {ADB880A6-D8FF-11CF-9377-00AA003B7A11};
On 6/30/05, Mike McCormack <[EMAIL PROTECTED]> wrote:
>
> Hi All,
>
> If anybody is looking for a small project, I've got just the thing for you!
>
> hh.exe and hhctrl.ocx are two components of the Microsoft HTML help
> engine. hh.exe is a small wrapper around hhctrl.ocx, which is the HTML
> help viewer.
>
> hhctrl.ocx embeds IE and feeds it HTML documents decoded from .chm files
> with itss.dll (the Infotech storage system). Implementing hhctrl.ocx
> would make an excellent test case for IE embedding that Jacek is working
> on, and for itss.dll.
>
> So most of the components are already in place (or will be soon) to make
> HTML help work... any takers to fill in the dots?
>
> The reward is, like most of Wine code, to say "I made that work" :)
>
> Let me know if you're interested.
>
> Mike
>
>
>
Re: [user/tests]: Re: Fix bug that left mouse buttons swapped after tests
Saulius Krasuckas wrote: ChangeLog: Fix bug that left mouse buttons swapped after tests Ivan. I think your patch causes test to fail on Wine, Ivan. My try goes next. Maybe that isn't a bad thing, the results from the latest build of winetest shows this test fails on windows 2000, windows nt, windows me, and windows 98se, so I somewhat doubt the wine behaviour is correct. Ivan.
Re: [user/tests]: Re: Fix bug that left mouse buttons swapped after tests
>> ChangeLog: Fix bug that left mouse buttons swapped after tests
>>
>> Ivan.
>
> I think your patch causes test to fail on Wine, Ivan. My try goes next.
>
>
> ChangeLog:
> Saulius Krasuckas <[EMAIL PROTECTED]>
> - Break from the loop to restore SM_SWAPBUTTON metrics.
> - SetLastError() to see if restoration changes it.
>
>
> Index: dlls/user/tests/sysparams.c
> ===
> RCS file: /home/wine/wine/dlls/user/tests/sysparams.c,v
> retrieving revision 1.38
> diff -p -u -r1.38 sysparams.c
> --- dlls/user/tests/sysparams.c 20 Jun 2005 15:36:17 - 1.38
> +++ dlls/user/tests/sysparams.c 30 Jun 2005 07:36:40 -
> @@ -1011,7 +1011,7 @@ static void test_SPI_SETMOUSEBUTTONSWAP(
> rc=SystemParametersInfoA( SPI_SETMOUSEBUTTONSWAP, vals[i], 0,
>SPIF_UPDATEINIFILE | SPIF_SENDCHANGE );
> if (!test_error_msg(rc!=vals[i],"SPI_{GET,SET}MOUSEBUTTONSWAP"))
> -return;
> +break;
It's nice to break but the the end-result will be that the test fails on
all windows versions I could my hands on and that the previous setting is
restored. Not very useful it seams.
Cheers,
Paul.
Re: Delays in FileOpen
On Wednesday 29 June 2005 23:36, Uwe Bonnes wrote: > File Open Dialogs for me have some noticable initial delay when starting > up. For example, try in internet explorer "Save under". I don't remember > seeing that delay some time before. Dif recent shfolder changes cause that > delay? There was a problem in SHGetPathFromIDList, which caused a delay in the file dialogs. I hope it was fixed with this patch, applied at the 2005/06/25. http://cvs.winehq.org/patch.py?id=18448 Does your local tree already contain this patch? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Using ReactOS Registry format
Hi! Wine had support for reading win2000 registry files once. It was dropped some time ago. I had implemented it around 1999/2000. Have a look in the CVS. Bye Juergen > Hi Martin, > Thanks for this info. It looks like this might work. How do I contact > Eric Kohl? > > Thanks, > James > > On Tue, 2005-06-21 at 17:57 +0200, Martin Fuchs wrote: > > Hi James, > > > > > Last night Martin Fuchs suggested that we look into using ReactOS's > > > registry format in order to be compatible with Windows registry > > > databases. I have the latest release of ReactOS running on QEMU on my > > > box, so I checked it out. Basically, they're using the same regedit > > > program from Wine, missing find command and all (Which I too feel is a > > > pain in the neck). > > > > A bunch of dlls and applications are synced between Wine and ROS from > > time to time, also including regedit. What about implemting the > > missing find functionality at your own to bring both projects a little > > foreward? ;-) > > > > > > > I looked at the config stuff, and I found what looked > > > like some binary database files for each of the main registry sections. > > > Unfortunately, there's no documentation at all on any of this on their > > > website. > > > > I can forward you a mail from Steven Edwards to bring a bit light into > > this issue: > > > > S> I think ReactOS's registry is binary compatible with NT4. It and > > the windows 2000 format was > > S> documented/reversed for samba and the linux ntchpwd bootdisk > > projects. If I remeber right Eric > > S> Kohl offered to release some of his work to Wine for the binary > > format so you might want to ping > > S> him about the implementation details. > > > > So Eric Kohl would be the right man to ask about the internals of NT's > > registry format. > > > > > If we decide to go this route, we may be in for a hell of a lot > > > of work. But, I do agree with all of your points. I think the current > > > system could use some improvement, especially in the area of searching. > > > Let me know what you think of all this. > > > > > > Regards, > > > >Martin > > >
Re: Mouse-buttons swapped after winetest
* On Fri, 24 Jun 2005, Paul Vriens wrote: > * On Fri, 2005-06-24 at 17:44, Saulius Krasuckas wrote: > > > > Then would be nice to print "err" in following format "err=%0x%08lx" or > > such after a restoration. Any more ideas? Sorry, I meant 0x%08lx. > Why do you want to change that? I thought %08lx is pretty common in most > of the Wine code. (I remember seeing your email on wine-devel about that > though). I just see two versions of formatting in Wine and want to get rid of one of it. Not a large difference which. OTOH, which one case brings you more clearness while reading logs: 0021 or 0x021 ? I prefer the latter one.
Anybody looking for a pet Wine project?
Hi All, If anybody is looking for a small project, I've got just the thing for you! hh.exe and hhctrl.ocx are two components of the Microsoft HTML help engine. hh.exe is a small wrapper around hhctrl.ocx, which is the HTML help viewer. hhctrl.ocx embeds IE and feeds it HTML documents decoded from .chm files with itss.dll (the Infotech storage system). Implementing hhctrl.ocx would make an excellent test case for IE embedding that Jacek is working on, and for itss.dll. So most of the components are already in place (or will be soon) to make HTML help work... any takers to fill in the dots? The reward is, like most of Wine code, to say "I made that work" :) Let me know if you're interested. Mike
Re: [MSXML] : add declarations for XMLDOM
Hi Vijay, Vijay Kiran Kamuju wrote: I am sending a new patch for th XMLDOM stuff ChangeLog add definitions and declarations for XMLDOM stuff Thanks for sending the patch in. After looking through it, here are my notes: * try cut it up into small bits, the smaller the better. Alexandre checks every line before applying a patch, so if you reduce the size of you patches, you'll reduce Alexandre's work and increase the chance that they go into Wine. So I'd suggest cut this patch up into two patches, one to add the DISPIDs and one to add the interface code. * you should add your own copyright line, instead of adding to the end of mine. eg. * Copyright (C) 2005 Mike McCormack * Copyright (c) 2005 Vijay Kiran Kamuju looks like good, Mike
