Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
On Sat, Apr 21, 2007 at 12:43:57PM +1000, Jeff L wrote:
> James Hawkins wrote:
> I don't know which is better, a lot of files appearing in my home or a
> new directory. Lots of apps create directories to organise files and we
> take it on the chin.
I don't like either, so after a wineprefixcreate I use:
find windows/profiles/$USER/ -type l -print -exec "rm" '{}' ';' -exec mkdir
'{}' ';'
Jan
Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
On 4/20/07, Jeff L <[EMAIL PROTECTED]> wrote: James Hawkins wrote: >> >> Is there a reason why we should not just create a Desktop directory? >> Seems neater than cluttering up the home. >> > I sure wouldn't want some app creating a Desktop directory in my home > folder if it didn't exist before. I don't know which is better, a lot of files appearing in my home or a new directory. Lots of apps create directories to organise files and we take it on the chin. The directories you're referring to are usually hidden directories. -- James Hawkins
Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
James Hawkins wrote: Is there a reason why we should not just create a Desktop directory? Seems neater than cluttering up the home. I sure wouldn't want some app creating a Desktop directory in my home folder if it didn't exist before. I don't know which is better, a lot of files appearing in my home or a new directory. Lots of apps create directories to organise files and we take it on the chin. Jeff Latimer
Re: Fix xcopy so output is either unicode (console) or oem (file)
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote:
+/* =
+ * Output a formatted unicode string. Ideally this will go to the console
+ * and hence required WriteConsoleW to output it, however if file i/o is
+ * redirected, it needs to be WriteFile'd using OEM (not ANSI) format
+ * = */
+int XCOPY_wprintf(const wchar_t *format, ...) {
The described above behaviour should be implemented either inside of wprintf
implementation in msvcrt, or inside of the console driver of WriteConsoleW
depending on the test results IMO. That's why I asked you to solve msvcrt and
console output problems separately. Also please do not introduce wchar_t, use
WCHAR instead.
--
Dmitry.
Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
Jeff L wrote: > Lei Zhang wrote: >> Hi, >> >> As reported in bug 7373, some people do not have a Desktop directory >> in their home directory. Wineshelllink should fall back to putting >> .desktop files in the home directory if the Desktop directory does not >> exist. > Is there a reason why we should not just create a Desktop directory? > Seems neater than cluttering up the home. Because this would probably be changed again some time in the near future. There isn't anything in FreeDesktop standards about this. But some discussions going on about using localized version of this dir. So instead of stomping on some distros that show users their whole home dir, we play along and just dump more stuff there :) Vitaliy.
Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
On 4/20/07, Jeff L <[EMAIL PROTECTED]> wrote: Lei Zhang wrote: > Hi, > > As reported in bug 7373, some people do not have a Desktop directory > in their home directory. Wineshelllink should fall back to putting > .desktop files in the home directory if the Desktop directory does not > exist. Is there a reason why we should not just create a Desktop directory? Seems neater than cluttering up the home. I sure wouldn't want some app creating a Desktop directory in my home folder if it didn't exist before. -- James Hawkins
Re: wineshelllink: fall back to $HOME if $HOME/Desktop does not exist
Lei Zhang wrote: Hi, As reported in bug 7373, some people do not have a Desktop directory in their home directory. Wineshelllink should fall back to putting .desktop files in the home directory if the Desktop directory does not exist. Is there a reason why we should not just create a Desktop directory? Seems neater than cluttering up the home. Jeff
Whats the approved technique to restier a dll in registry
There seems to be two ways to do this, add the entries to wine.inf or set the dll up as self registering. There are examples of both in wine and the discussion seems to favour self registering but people still seem to be adding registry entries to wine.inf. A bit of guidance would be appreciated. Jeff Latimer
[programs/uninstaller] fixed patch, but there is a problem somewhere else...
With James' help, I managed to get the uninstaller patch done up
right, however, I am running into a small problem.
The way I had originally done the array at the top of
FetchUninstallInformation was not correct, however it allowed for
proper functionality.
HKEY hkeyroot[numrootkeys];
hkeyroot[0] = HKEY_CURRENT_USER;
hkeyroot[1] = HKEY_LOCAL_MACHINE;
With that code, I can open the uninstaller, and see all of the
uninstall entries.
With the following, correct code:
HKEY hkeyroot[] = { HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE };
When I open the uninstaller, the first uninstall entry is not shown
(and from what I can tell in the additional traces that I put in,
looks like it is not even being found). However, when I type
something into the filter editbox, like the first letter of that entry
that is missing, it appears.
The same function is being called with the dialog first opens as is
being called when the dialog refreshes.
If I type into the filter field, and then select something and hit
uninsall, and then cancel the uninstall, the window updates again, and
the first entry disappears again.
Like I said, the UNINSTALL calls UpdateList, the INITDIALOG calls
UpdateList, and the FILTER calls UpdateList as well, however in
UNINSTALL and INITDIALOG cases the first entry does not appear.
I think the problem is somewhere else in wine, but I cannot confirm
this right now without doing a trace+all, and I am leaving work for
the weekend..
The patch and registry file I am using are attached if anyone wants to
look into this while I am gone.
--
Thanks
Tom
Check out this new 3D Instant Messenger called IMVU. It's the best I
have seen yet!
http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
uninsaller.patch
Description: Binary data
uninstall.reg
Description: Binary data
winmm: Allow a FORCE_SHUTDOWN on driver close?
After trying to implement the alsa mixer I came across a problem: If winmm is unloading, a deadlock could occur if during unloading it's waiting for another thread. In winmm itself this isn't much of a problem: there aren't any threads. However, the drivers used by winmm may have threads, and if the application doesn't shut down their drivers properly, it could be possible that a deadlock occurs when the drivers unload because winmm unloads. For that reason I propose to add a flag that's passed to the sound drivers that signals a shutdown in DLL_DETACH context, so that drivers can choose to call TerminateThread instead of waiting tidily for the thread to finish running. It's not pretty, but I don't see another way how to make sure that deadlocks won't occur when unloading winmm. I'm open for other suggestions though. Maarten
Re: [1/2] Extend the testing framework to include IDL files and RPC clients (take 2)
On Fri, Apr 20, 2007 at 11:41:16AM +0200, Alexandre Julliard wrote: > Dan Hipschman <[EMAIL PROTECTED]> writes: > > > This extends the testing framework to allow for tests that need IDL > > files and RPC clients. It's the same as the last attempt, but I've > > removed two little development artifacts that slipped in last time, > > I fixed an indentation glitch, fixed one more thing in the Makefile > > so "make depend" works for ClientMakefile as well, and I separated > > the first test case from the infrastructure change (see next patch). > > That's very ugly; you shouldn't need any of that stuff, especially not > a separate makefile. You should put everything in the same exe, and > differentiate server and client through command line arguments, the > way the process test does it. Well, I tried to make it as pretty as possible. The problem is that the client and server code won't link together. For each function, there's the implementation and the stub, both with the same name. To get both into the same executable, I'd have to do some sort of renaming hack, either with the preprocessor or something like sed. The reason I like two makefiles better is that messing with the output of widl weakens the test. I can take a second look at that approach, though, or look for an entirely different way if you really hate having two makefiles/exes.
Re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
Fredag 20 april 2007 17:46, skrev Kai Blin: > On Friday 20 April 2007 15:37, Dan Kegel wrote: > > Briareos wrote: > > > The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... > > > To me it's logical that you get 127.0.0.1 when pinging your local > > > hostname, but if windows does give the IP of your NIC then wine should > > > do as well - as we want to reach compatibility. > > > > > >If, on the other hand, you say it's simply bad programming done by the > > >app-developer if he tries to fetch the IP of the NIC that way, I'd say > > > let's still comply to it, because its more likely than having a > > > programmer expecting to get 127.0.0.1 when asking for "localhostname". > > > > My understanding is that hostnames are not really hostnames, but > > interface names. > > On Unix, 127.0.0.1 is never normally returned unless you ask for > > literally "localhost". I suspect Windows behaves like Unix here. > > So this probably is a valid bug in wine. > > Looking at a simple test that does (pseudocode) > > gethostname(name, len); > hostent = gethostbyname(name); > > Windows will return 127.0.0.1 if there's no valid IP defined and there's no > IP that used to be valid either. > > Anyhow, it seems that if there is an IP address that's not loopback, that > is returned instead. I'm afraid that won't be easy to fix.. :( > > > (I suspect that the app developer is misguided, because binding > > to just one interface doesn't work well if you have multiple > > interfaces, but that's neither here nor there.) > > Well, actually the developer of the app in #7929 is misguided because he's > using gethostbyname() with winsock 2.2, which MSDN claims is deprecated. Oh > well. > > Cheers, > Kai It should be noted that the app in bug #7929 (Command & Conquer 3 Tiberium Wars) does not run networking correctly on Windows when two interfaces are present. Alexander N. Sørnes
Re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
On Friday 20 April 2007 15:37, Dan Kegel wrote: > Briareos wrote: > > The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... > > To me it's logical that you get 127.0.0.1 when pinging your local > > hostname, but if windows does give the IP of your NIC then wine should do > > as well - as we want to reach compatibility. > > > >If, on the other hand, you say it's simply bad programming done by the > >app-developer if he tries to fetch the IP of the NIC that way, I'd say > > let's still comply to it, because its more likely than having a > > programmer expecting to get 127.0.0.1 when asking for "localhostname". > > My understanding is that hostnames are not really hostnames, but > interface names. > On Unix, 127.0.0.1 is never normally returned unless you ask for > literally "localhost". I suspect Windows behaves like Unix here. > So this probably is a valid bug in wine. Looking at a simple test that does (pseudocode) gethostname(name, len); hostent = gethostbyname(name); Windows will return 127.0.0.1 if there's no valid IP defined and there's no IP that used to be valid either. Anyhow, it seems that if there is an IP address that's not loopback, that is returned instead. I'm afraid that won't be easy to fix.. :( > (I suspect that the app developer is misguided, because binding > to just one interface doesn't work well if you have multiple > interfaces, but that's neither here nor there.) Well, actually the developer of the app in #7929 is misguided because he's using gethostbyname() with winsock 2.2, which MSDN claims is deprecated. Oh well. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpB9O8BgDbtf.pgp Description: PGP signature
Re: RegDeleteTree [3rd]
Am Friday 20 April 2007 05:54 schrieb Tom Spear: > I actually have a Vista Home Basic install on a laptop that I can > check testcases on, at least for right now. I'm thinking of going out > and getting a licensed copy of xp for it (linux isn't viable for it > because it isnt my laptop and its being used as the main pc for > business transactions, so it couldnt be used to help further wine > development either, other than running testcases on windows, > unfortunately) > Hello Tom, can you build advapi32_test.exe yourself or do you need an executable? Thank you for offering your support Stefan
Re: secur32: invert error handling conditions in order to decrease indentation in secur32/wrapper.c.
On 17/04/07, Juan Lang wrote: Sorry for the late reply. > > I'm working on schannel at the moment. schannel is not a regular SSP, > > and the functions in wrapper.c can't load native. I've implemented the > > proper loading code in my local tree and I'm sending it in obvious > > pieces. no-op cleanups is the first step. I'm curious how schannel gets loaded, and how you figured it out. Could you enlighten me? Robert's patch to add schannel.dll that forwards to secur32.dll tipped me. All the regular SSP (Security Support Provider) functions are forwarded to secur32, including enumeration and initialization. secur32 has to get its entry points somehow, so I looked into the few functions that are not forwarded. It turns out that schannel is implemented as an SSP/AP (Authentication Package), which means that it is loaded into the address space of lsass too. Later reading suggested that this was done to enable single-sign-on using client certificates. I just load it into the user address space and faked the callbacks/copytouser/copyfromuser. A side effect would be that it would also load kerberos.dll and msv1_0.dll, but we don't really need them. Using native posix krb5 is not hard and would integrate with the system better. If you need reviews of this, I'm happy to look at early patches. I'll send you off-list after a small cleanup. > > The current stage is that native schannel loads and initializes, but > > builtin rsaenh does not supply everything it needs, so it can't > > complete the ssl handshake. Native rsaenh requires unimplemented stuff > > in ntdll. What stuff, out of curiosity? Small functions mostly. You'll see it in wine-patches soon. I'm very interested to see progress in this area. Thanks! I'm silently tracking your work in this area for years (and later Kai's). I was just busy with another open source project. I dropped from that one and now I have time for wine :-). --Juan -- Yuval Fledel
re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
Briareos wrote: The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility. If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname". My understanding is that hostnames are not really hostnames, but interface names. On Unix, 127.0.0.1 is never normally returned unless you ask for literally "localhost". I suspect Windows behaves like Unix here. So this probably is a valid bug in wine. (I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.) - Dan
Re: [resend]gdi32 : Completes WidenPath implementation
Laurent Vromman <[EMAIL PROTECTED]> writes:
> elp = HeapAlloc( GetProcessHeap(), 0, size );
> -
> +lp = HeapAlloc( GetProcessHeap(), 0, sizeof(LOGPEN));
> GetObjectW( dc->hPen, size, elp );
> +
> +obj_type = GetObjectType(dc->hPen);
> +if(obj_type == OBJ_PEN) {
> +memcpy(lp, elp, sizeof(LOGPEN));
> +penStyle = lp->lopnStyle;
> +}
> +else if(obj_type == OBJ_EXTPEN) {
> +penStyle = elp->elpPenStyle;
> +}
> +else {
> +SetLastError(ERROR_CAN_NOT_COMPLETE);
> +return FALSE;
> +}
There's no reason to make a copy of the structure, a typecast would
work just as well. Also you are leaking memory here.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
On Friday 20 April 2007 12:09, Briareos wrote: > My opinion is simple: > To me it's logical that you get 127.0.0.1 when pinging your local hostname, > but if windows does give the IP of your NIC then wine should do as well - > as we want to reach compatibility. > > If, on the other hand, you say it's simply bad programming done by the > app-developer if he tries to fetch the IP of the NIC that way, I'd say > let's still comply to it, because its more likely than having a programmer > expecting to get 127.0.0.1 when asking for "localhostname". There is no "bad programming" in this context. Either it works this way on Windows and we'll have to cope with it or not. I'll look at those traces again and will send a conformance test to check this. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpBXFLW28tRi.pgp Description: PGP signature
Re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
On Fri, Apr 20, 2007 at 12:09:55PM +0200, Briareos wrote: > My opinion is simple: > To me it's logical that you get 127.0.0.1 when pinging your local hostname, > but if windows does give the IP of your NIC then wine should do as well - as > we want to reach compatibility. > > If, on the other hand, you say it's simply bad programming done by the > app-developer if he tries to fetch the IP of the NIC that way, I'd say let's > still comply to it, because its more likely than having a programmer > expecting to get 127.0.0.1 when asking for "localhostname". to my very (VERY!) limited knowledge of windows somebody told me in a project (we aimed to write a proxy to make connections to a game "secure") the principle of "binding to an address" is unknown to windows - at least for the non-NT based branch. if this is true we should always bind sockets to 0/0 regardless what the app tells us. i am sure some windows/network gurus around can tell more. -- cu pgpcpk1UwM1MB.pgp Description: PGP signature
gethostbyname(my_name) and IL2-Sturmovik CONTINUED
Hello list, I want to continue a discussion about a problem already reported by David Nolden in December 2005. It is about what gethostbyname should return if given the machines name and does not only affect IL-2 Sturmovik. Placing a quick cite of him here: [...] The Problem: gethostbyname(own_name) always returns 127.0.0.1. [...] The socket is then bound to the ip-adress 127.0.0.1, and to it's corresponding loopback-interface, so it's unusable. Any connection-request times out. [...] All the discussion back then happened (in wine-devel) between the 12.12.2005 and 14.12.2005. Subject: "gethostbyname(my_name) and IL2-Sturmovik" And a Patch: wine-patches: 17.01.2006 02:00:21 Subject: gethostbyname-patch Check also Bug #7929 (duplicated by #8075). My opinion is simple: To me it's logical that you get 127.0.0.1 when pinging your local hostname, but if windows does give the IP of your NIC then wine should do as well - as we want to reach compatibility. If, on the other hand, you say it's simply bad programming done by the app-developer if he tries to fetch the IP of the NIC that way, I'd say let's still comply to it, because its more likely than having a programmer expecting to get 127.0.0.1 when asking for "localhostname". Any comments welcome!
Re: wine.inf: update registry key
"Louis. Lenders" <[EMAIL PROTECTED]> wrote: I cannot check how it looks in a default Windows setup anymore, as i installed another browser (mozilla) on my windowsXP installation. However, there's one thing I don't get: the key on my WinXp installation does have that extra "%1" now, so would that mean that picasa would crash on my windowsXp installation after i installed, or do things work differently there? Picasa doesn't crash on any setup (and the problem is not a crash but not working help items), and as far as I know help in Picasa works with Mozilla installed in XP. But that means that if you want to introduce not standard registry setup you need to make sure that applications still work, i.e. ShellExecute behaves properly in both cases. Right now adding %1 breaks ShellExecute in Wine. -- Dmitry.
Re: [1/2] Extend the testing framework to include IDL files and RPC clients (take 2)
Dan Hipschman <[EMAIL PROTECTED]> writes: > This extends the testing framework to allow for tests that need IDL > files and RPC clients. It's the same as the last attempt, but I've > removed two little development artifacts that slipped in last time, > I fixed an indentation glitch, fixed one more thing in the Makefile > so "make depend" works for ClientMakefile as well, and I separated > the first test case from the infrastructure change (see next patch). That's very ugly; you shouldn't need any of that stuff, especially not a separate makefile. You should put everything in the same exe, and differentiate server and client through command line arguments, the way the process test does it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RegDeleteTree [3rd]
On 4/19/07, Stefan Leichter <[EMAIL PROTECTED]> wrote:
Am Thursday 19 April 2007 12:14 schrieb Alexandre Julliard:
> Stefan Leichter <[EMAIL PROTECTED]> writes:
> > +/* Recursively delete all the subkeys */
> > +for (i = 0; i < dwKeyCount && !ret; i++) {
> > +dwSize = dwMaxSubkeyLen;
> > +ret = RegEnumKeyExW(hSubKey, i, lpszName, &dwSize,
> > NULL, + NULL, NULL, NULL);
>
> This won't work, the index will change as you delete keys.
>
> > + } else {
> > +if (!ret)
> > + ret = RegSetValueW(hSubKey, NULL, REG_SZ, emptyW, 0);
>
> The function is supposed to delete the key values, that's not what
> this does.
>
> You probably need to write some test cases...
Hello Paul,
i'm sorry for bothering you again on this topic, but it looks like your are
the onlyone around having a Vista installation.
Can you please verify the attached tests and report the results back.
Thanks for your help
Stefan
Hi Stefan,
I can't do this before Sunday or so. I'm in the UK and don't have my
laptop with me. I'll post the results as soon as I have something.
Cheers,
Paul.
Re: Move console input/output codepages to server
> "Kirill K. Smirnov" <[EMAIL PROTECTED]> wrote:
> > @@ -141,12 +138,19 @@ HWND WINAPI GetConsoleWindow(VOID)
> > */
> > UINT WINAPI GetConsoleCP(VOID)
> > {
> > -if (!console_input_codepage)
> > +BOOL ret;
> > +UINT codepage = GetOEMCP(); /* default value */
> > +
> > +SERVER_START_REQ(get_console_input_info)
> > {
> > -console_input_codepage = GetOEMCP();
> > - TRACE("%u\n", console_input_codepage);
> > +req->handle = 0;
> > +ret = !wine_server_call_err( req );
> > +if (ret && reply->codepage)
> > +codepage = reply->codepage;
>
> Did you test what happens when an app sets console code page to a pseudo
> cp like CP_ACP (0)? Your code will force code page to be always equal to
> what GetOEMCP returns in that case.
IsValidCodePage will fail. App is not allowed to pass CP_ACP, CP_OEMCP and
other pseudo codepages to these function.
#include
int main(void)
{
printf("%d\n", IsValidCodePage(CP_ACP));
printf("%d\n", IsValidCodePage(CP_OEMCP));
SetConsoleCP(CP_ACP);
printf("%d\n", GetConsoleCP());
SetConsoleOutputCP(CP_ACP);
printf("%d\n", GetConsoleOutputCP());
SetConsoleCP(CP_OEMCP);
printf("%d\n", GetConsoleCP());
SetConsoleOutputCP(CP_OEMCP);
printf("%d\n", GetConsoleOutputCP());
return 0;
}
Small test:
This will write under both wine and windows:
0
0
866
866
866
866
If change codepage to cp1251 via chcp, output will be:
0
0
1251
1251
1251
1251
So my code is OK.
--
Kirill
Re: wine.inf: update registry key
Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: "Louis. Lenders" wrote: > Hi, this fixes bug #7953 -> http://bugs.winehq.org/show_bug.cgi?id=7953 > Vitaly said this one won't go as it might break another app, but i don't > get that , as the key in windows looks quite the same, No it doesn't in the default Windows setup, and the key was changed for a reason to make Picasa work some time ago: http://source.winehq.org/git/wine.git/?a=commitdiff;h=f03c86a27387cd1dc27c371d52a7c72d83b70481 -- Dmitry. I cannot check how it looks in a default Windows setup anymore, as i installed another browser (mozilla) on my windowsXP installation. However, there's one thing I don't get: the key on my WinXp installation does have that extra "%1" now, so would that mean that picasa would crash on my windowsXp installation after i installed, or do things work differently there? - Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
