Re: Loading resources from wine dlls
Michael Jung wrote: Hello, I would like to add a 'My Documents' icon to shell32. This icon has a resource ID of 235 in WinXP's shell32. Apparently one can't load resources from wine's own dlls, though. If you call PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name parameter, you'll get a 'WARN: File %s not found or path too long'. I guess that's because there is no such file in wine's fake windows environment. There is a hack (which is even declared as a hack in the comment) in the initialization code of the 'Shell Icon Cache' (starting from line 372 in 'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at initialization time, and later returns them from the cache without having to access the file (which would'nt work). This seems to be a principal problem (Loading resources from wine dlls, if they are accessed by the filename they have on a windows system). Are there any plans on how to fix this? Anything that uses SearchPath is similarly broken when needing to find a builtin dll or exe. We should add a hack^H^H^H^Hextension to that function to make it be able to find installed .so files with a similar name. -- Rob Shearman
Re: Throwing in an idea (probably it was discussed before though)
Le lun 22/08/2005 à 07:58, John Smith a écrit : [snip] > 2. (not really relevant to this discussion, but relevant to the whole issue > of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are > still 20050524, and winecfg is pretty much useless there. If WINE team does > care about end-users, it would be nice to have binary RPMs for the most > popular distribution not that much out-of-date. Yes, that's my fault. After moving in June, I haven't found the time yet to reinstall all my computer stuff (I'm typing this sitting on the floor with my keybord on my knees), so I don't know when I'll get back to it. I already missed two releases, and haven't produced any rpm for FC4 (for which I get a couple emails per week). If somebody wants to step up to the task (at least temporarily), I'd be glad to share my experience with them. Vincent
Re: secur32: Getting some real functionality into the NTLM provider, try 2
Hi Kai,
In ntlm.c,
+/* convert the program name to Unicode */
(snip)
+/* and back to the CP_UNIXCP */
This round-tripping is unnecessary when the text is already ASCII. ASCII
values are just as valid in UTF8 as they are in CP1252 or whatever.
Basically, don't bother converting anything you can type.
+if(pAuthData == NULL)
In this if statement, you duplicate the business of converting the user
name and domain name to CP_UNIXCP in both branches. You should instead
store a pointer to the user name and domain name, and convert them in one
common branch after the if statement.
+SEC_CHAR *client_argv[] =
+{
+program,
+client_protocol,
+client_user_arg,
+client_domain_arg,
+NULL
+};
You must declare variables at the beginning of the block, not in the
middle. Not all C compilers allow this.
+if(pszPackage != NULL)
+{
+int package_sizeW = MultiByteToWideChar(CP_ACP, 0, pszPackage,
-1,
+NULL, 0);
Since you don't use pszPackage in ntlm_AcquireCredentialsHandleW, why
bother converting it? Just pass NULL.
+if(identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI)
(snip)
+else
+{
+memcpy(pAuthDataW, identity,
sizeof(SEC_WINNT_AUTH_IDENTITY_W));
+}
This looks funny. Why not just set pAuthDataW to identity in this case?
That way you avoid the memcpy. Something like this:
PSEC_WINNT_AUTH_IDENTITY_W pAuthDataW;
if (identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI)
{
/* convert it like you do */
}
else
pAuthDataW = (PSEC_WINNT_AUTH_IDENTITY_W)identity;
/* call ntlm_AcquireCredentialsHandleW */
if (pAuthDataW != identity)
HeapFree(GetProcessHeap(), 0, pAuthDataW);
+if((ret = encodeBase64(helper->password,
+helper->pwlen-2, buffer+3,
+max_len-3, &buffer_len)) != SEC_E_OK)
+ {
+HeapFree(GetProcessHeap(), 0, buffer);
+HeapFree(GetProcessHeap(), 0, bin);
+return ret;
+}
You ought to zero the memory of the password and free it, regardless of
whether encodeBase64 succeeds or fails. (Really you ought to call
SecureZeroMemory, but wine hasn't implemented that.. oh well.)
In tests/ntlm.c:
+//lstrcpyA(identity->Password, pass ? pass :"");
No C++ style comments, please.
More generally, on the tests, I like them because they should nearly
always succeed in Windows. But they're not very likely to succeed in
Wine, are they? You handle not having an ntlm_auth fairly gracefully, I
think, and also handle not being able to create an inbound context, which
you say may not work without some magic setup.
But this won't generally work out of the box if ntlm_auth works and an
inbound context can be created, can it? The tests will try to
authenticate with whatever domain name is in the registry, or default to
WORKGROUP if that's empty, and your UNIX username, and no password.
That's not very likely to succeed.
So, it would be nice to have these tests somewhere for people to check
that this code indeed works.. but I'm not sure they can go into the
regression test suite. Unless I'm mistaken.
Thanks,
--Juan
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Bugzilla - old rubbish bugs...
I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is >1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason
OpenGL windowing and wglMakeCurrent
Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, even if it is only a small child window, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try. It is possible that glScissor might be used. A more accurate wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome. Thanks, Russ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken
В сообщении от 24 Август 2005 22:14 Вы написали: > If Vitaly is busy and won't object, I can resync his changes to the > current CVS and send a patch from his name. Well, I resent my patch again to wine-devel... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken
* On Wed, 24 Aug 2005, Hiji wrote: > --- Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > > > > a, header of its first section refers to > >"sysparams.c" and "dlls/user/sysparams.c", > >which makes patcher to not find needed file > >(dlls/user/tests/sysparams.c). > > > > b, first hunk of the second section > >(dlls/user/sysparams.c) is already in the > >tree, so it fails too. > > Ok, I had applied it to the July release, but if some > changes are already in the tree, then that's good > news. Not very good, as the mentioned change is only cosmetic. > Vitaly, any thoughts on this? If Vitaly is busy and won't object, I can resync his changes to the current CVS and send a patch from his name.
Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken
--- Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > * On Tue, 23 Aug 2005, Hiji wrote: > > --- Vitaly Lipatov <[EMAIL PROTECTED]> wrote: > > > > > Hi, Can you pay attention to this patch? It > really fixes the problem > > > but not discussed in the list and not applied: > > > > > http://www.winehq.com/hypermail/wine-patches/2005/08/0018.html > > > > WOOHOO! This fixes "half" the problem with > Bug3148. > > Once I applied the patch, I no longer had the > problem > > with the effect of the mouse button being > continously > > pressed once I clicked on something. > ... > > So, can someone listen (pay attention) to Vitaly > and > > apply the patch so at least this bug can get > half-way > > fixed??? > > The patch has 2 points to change (I am afraid): > > a, header of its first section refers to > "sysparams.c" and >"dlls/user/sysparams.c", which makes patcher to > not find needed file >(dlls/user/tests/sysparams.c). >Command "cvs diff -pu dlls/user/" would do the > job. :-P > > b, first hunk of the second section > (dlls/user/sysparams.c) is already >in the tree, so it fails too. Ok, I had applied it to the July release, but if some changes are already in the tree, then that's good news. Vitaly, any thoughts on this? Hiji __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re[2]: Delphi 5 debugger is working!
Wednesday, August 24, 2005, 11:00:06 AM, Marco Pietrobono wrote: > Il giorno mar, 23-08-2005 alle 18:05 -0600, Vitaliy Margolen ha scritto: > [snip] >> Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others >> is not that simple. Basically there are no way to do it from other processes. >> Ok, NtQueryVirtualMemory could be implemented some-what easily using >> NtReadVirtualMemory and possibly one more server call. But for others I see >> only >> three ways to implement them: > [snip] >> Any other solutions that I have forgotten/haven't even thought of? > have you checked this one? > http://www.die.net/doc/linux/man/man5/proc.5.html > especially with regards to mem e map. > it should work, at least on linux. > bye, Ok, and how would I allocate, free, change protection with that? Wine already has read/write access using ptread. Vitaliy
Re: Delphi 5 debugger is working!
Il giorno mar, 23-08-2005 alle 18:05 -0600, Vitaliy Margolen ha scritto: [snip] > Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others > is not that simple. Basically there are no way to do it from other processes. > Ok, NtQueryVirtualMemory could be implemented some-what easily using > NtReadVirtualMemory and possibly one more server call. But for others I see > only > three ways to implement them: [snip] > Any other solutions that I have forgotten/haven't even thought of? have you checked this one? http://www.die.net/doc/linux/man/man5/proc.5.html especially with regards to mem e map. it should work, at least on linux. bye, /pietrobo -- Stud. Marco Pietrobono | Murphy's Law: if something can v. del Calice, 39 - 00178 ROMA | go wrong, it will do. Tel. +39.06.7186329 +39.339.7410893 | Legge di Murphy: se qualcosa puo' http://www.pietrobo.com | andar male, lo fara'. Strange game. The only winning move is not to play. What about a nice play of chess ? signature.asc Description: Questa parte del messaggio è firmata
Re: Software patents
On Friday 13 May 2005 19:07, Gregory M. Turner wrote: > Code using the C syntax described in the patent doesn't compile in winelib > yet [snip]. Give me a week or two... Imagine that, it seems I have once again imagined myself to have more spare time than I really do. Honestly, folks, I can't wait to lay into __TRY & family -- especially since that work brings me closer to __try & family for winelib, which, as far as I'm concerned, is unfinished business -- but I simply am not in a position to do anything about it until I finish my dissertation and take care of some other pressing matters. Regardless, I am still alive and still plan to do this, sooner than later. In the meanwhile, I'm glad to see that the rest of you are being better wine hackers than I! "I'll be back," -- gmt
Re: Delphi 5 debugger is working!
Kuba Ober <[EMAIL PROTECTED]> writes: > What are the problems with implementing those using SIGSTOP/SIGCONT and > ptrace(2)? The same problems that you'll have with signals, plus a few more -- Alexandre Julliard [EMAIL PROTECTED]
Loading resources from wine dlls
Hello, I would like to add a 'My Documents' icon to shell32. This icon has a resource ID of 235 in WinXP's shell32. Apparently one can't load resources from wine's own dlls, though. If you call PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name parameter, you'll get a 'WARN: File %s not found or path too long'. I guess that's because there is no such file in wine's fake windows environment. There is a hack (which is even declared as a hack in the comment) in the initialization code of the 'Shell Icon Cache' (starting from line 372 in 'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at initialization time, and later returns them from the cache without having to access the file (which would'nt work). This seems to be a principal problem (Loading resources from wine dlls, if they are accessed by the filename they have on a windows system). Are there any plans on how to fix this? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: solution for including itss.h in hhctrl.ocx
James Hawkins <[EMAIL PROTECTED]> writes: > I need to be able to include itss.h from dlls/itss in order to read > CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to > hhctrl's Makefile.in. The next problem comes when I run make depend. > make depend looks for itss.h but can't find it because it hasn't been > built yet. Mike then suggested adding ../dlls/itss/itss.idl to > IDL_SRCS in include/Makefile.in. No, you can't do that sort of thing. You have to move the idl file to the include directory (probably in include/wine). -- Alexandre Julliard [EMAIL PROTECTED]
Re: commctrl: dialog theming
Hi, I'm trying to have this app (http://appdb.winehq.org/appview.php?versionId=2451) with wine, but for the moment it requires native commctrl.dll && comctl32.dll, for installation (more linked with InstallShield than with app). What traces should I provide to help you with this ? Mike McCormack a écrit : Evil wrote: I'm no longer able to run programs that require the native comctl32 and commctrl DLLs, since updating to today's CVS. Could it be related to these theme patches? You shouldn't need to use the native comctl32 any longer. Please update your dll overrides to "comctl32" = "builtin". Wine's comctl32 implementation is almost complete. If there's bugs with the builtin comctl32 then please help us by reporting them rather than sweeping the problem under the carpet and using the native dll. Mike
wine error with 'wine client error:d: write: Bad file descriptor'
Hi wine-devel, i have a windows program whitch generates the attached 'wine.txt' wine output. Followed is a part of the output: >>> Threads: process tid prio (all id:s are in hex) 0042 (D) C:\MGC\LeoSpec\LS2005a_82\bin\win32\leonardo.exe 00170 000d0 <== 000e 00160 00130 00120 00110 00100 000f0 WineDbg terminated on pid 0x42 wine client error:d: write: Bad file descriptor <<< The program works with windows! Can someone help me to run the program? thanks Oliver Mössinger fixme:wtsapi:WTSEnumerateSessionsA Stub (nil) 0x 0x0001 0x406d822c 0x406d8238 fixme:wtsapi:WTSFreeMemory Stub (nil) fixme:wtsapi:WTSEnumerateSessionsA Stub (nil) 0x 0x0001 0x406d823c 0x406d8248 fixme:wtsapi:WTSFreeMemory Stub (nil) fixme:wtsapi:WTSEnumerateSessionsA Stub (nil) 0x 0x0001 0x406da310 0x406da31c fixme:wtsapi:WTSFreeMemory Stub (nil) fixme:win:LockWindowUpdate (0x70476), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 000d), starting debugger... WineDbg starting on pid 0x42 Unhandled exception: page fault on read access to 0xe360159d in 32-bit code (0x105c8eda). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:105c8eda ESP:406dfc78 EBP:107dfc5c EFLAGS:00210286( - 00 -RISP1) EAX:e360158b EBX:ff00 ECX: EDX:107e0c58 ESI: EDI:0062 Stack dump: 0x406dfc78: 105ca71f 107dfc5c 107d 406dfcf4 0x406dfc88: 006285d0 107dfc5c ff00 107dfc70 0x406dfc98: 107dfc8c 105c8f9f 107dfc5c 107dfc5c 0x406dfca8: 105c7d2a 107dfc5c 105c77ca 107dfc5c 0x406dfcb8: 105c6e3f 107dfc5c 105c6eb1 107dfc5c 0x406dfcc8: 107dfc5c 105cc38a 105cc3a3 107dfc5c Backtrace: =>1 0x105c8eda in libelsyn_s (+0x5c8eda) (0x107dfc5c) 2 0x1c0b0004 (0x10007242) 0x105c8eda: cmpw%cx,0x12(%eax) Modules: Module Address Debug info Name (88 modules) PE 0x0040-00784000 Deferredleonardo PE 0x0a93-0a951000 Deferredsh33w32 PE 0x1000-10871000 Export libelsyn_s ELF 0x4000-40018000 Deferredld-linux.so.2 ELF 0x4003e000-40056000 Deferredlibwine.so.1 ELF 0x40069000-40182000 Deferredlibc.so.6 ELF 0x40182000-40186000 Deferredlibdl.so.2 ELF 0x40187000-401fc000 Deferredntdll \-PE 0x401a-401fc000 \ ntdll ELF 0x40222000-40317000 Deferredlibwine_unicode.so.1 ELF 0x40317000-4033a000 Deferredlibm.so.6 ELF 0x4048-40581000 Deferredkernel32 \-PE 0x404b-40581000 \ kernel32 ELF 0x406e-407f6000 Deferreduser32 \-PE 0x4070-407f6000 \ user32 ELF 0x407f6000-411df000 Deferredgdi32 \-PE 0x4081-411df000 \ gdi32 ELF 0x412c3000-412cb000 Deferredlibgcc_s.so.1 ELF 0x412cb000-41308000 Deferredadvapi32 \-PE 0x412e-41308000 \ advapi32 ELF 0x41308000-41369000 Deferredmsvcrt \-PE 0x4132-41369000 \ msvcrt PE 0x4137-413b3000 Deferredxmplrtcl ELF 0x413b3000-413e6000 Deferredmsvcrt40 \-PE 0x413c-413e6000 \ msvcrt40 ELF 0x413e6000-4140d000 Deferrednetapi32 \-PE 0x413f-4140d000 \ netapi32 ELF 0x4140d000-4142b000 Deferrediphlpapi \-PE 0x4142-4142b000 \ iphlpapi ELF 0x4142b000-41453000 Deferredws2_32 \-PE 0x4143-41453000 \ ws2_32 ELF 0x4147-414f8000 Deferredcomdlg32 \-PE 0x4148-414f8000 \ comdlg32 ELF 0x414f8000-415b3000 Deferredshell32 \-PE 0x4151-415b3000 \ shell32 ELF 0x415b3000-41609000 Deferredshlwapi \-PE 0x415d-41609000 \ shlwapi ELF 0x41609000-41688000 Deferredole32 \-PE 0x4162-41688000 \ ole32 ELF 0x41688000-416cf000 Deferredrpcrt4 \-PE 0x416a-416cf000 \ rpcrt4 ELF 0x416cf000-41776000 Deferredcomctl32 \-PE 0x416e-41776000 \ comctl32 ELF 0x41776000-4179d000 Deferredwinspool.drv \-PE 0x4178-4179d000 \ winspool.drv ELF 0x4179d000-417ba000 Deferredimm32 \-PE 0x417b-417ba000 \ imm32 PE 0x417c-41853000 Deferrednlviewmd ELF 0x41879000-418e6000 Deferredlibfreetype.so.6 ELF 0x418e6000-418f7000 Deferredlibz.so.1 ELF 0x418f7000-41925000 Deferredlibfontconfig.so.1 ELF 0x419
Re: accessing WRT binaries on the web
Hi Saulius, No, this isn't intentional. The cross-building part needs patching so it knows about an additional part of the Win32 API. Nothing new there. But rather than just patching the (somewhat ancient) version of the w32api, I've decided to upgrade to the latest version. This means going through the large number of patches to Win32api figuring out which are now redundant and which are still needed, and fixing the patches so they work again. Once this is done, things should be up and running again. Cheers, Paul. On Tuesday 23 Aug 2005 17:13, Saulius Krasuckas wrote: > Now it seems test are being build daily [1], but none of them shows up on > the web [2] since 2005.08.16. > > Is this intentional state of the system or just some bug had went in it? > > > [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php > [2] http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ pgpnIxBt3TiJv.pgp Description: PGP signature
wglMakeCurrent doesn't pick up HDC region
Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re[2]: Delphi 5 debugger is working!
Wednesday, August 24, 2005, 6:20:40 AM, Kuba Ober wrote: > On Tuesday 23 August 2005 20:05, Vitaliy Margolen wrote: >> As of todays CVS Delphi 5 debugger is fixed. >> >> Well, ok, there are still some bugs. One is a minor bug (Module view >> reports all modules as a project executable name), but all exports are >> there. You can even try to disassemble them. But here is where the major >> problems start. Debugger segfaults on that. This is because >> NtQueryVirtualMemory and >> NtProtectVirtualMemory currently don't work on other processes. > What are the problems with implementing those using SIGSTOP/SIGCONT and > ptrace(2)? I imagine that for example changing memory protection for another > process could be achieved as follows: > 1. SIGSTOP to the process > 2. inject code that invokes mprotect() and stops execution > 3. change EIP, ESP, etc. then SIGCONT > 4. wait(pid,&status,WUNTRACED) on the child > 5. remove the injected code, restore registers, SIGCONT > I have never implemented such a beast so I might be way off, nevertheless it'd > be interesting to hear what the problems are. phrack might also be a useful > read in that respect. Hmm, that looks familiar. Something like that safedisc uses, that currently doesn't work. The only difference - safedisc limited to win API. I guess I can give it a try to see if it will work. Vitaliy
Re: Delphi 5 debugger is working!
Vitaliy Margolen wrote: As of todays CVS Delphi 5 debugger is fixed. Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only How does gdb do these things to a Linux process? I would think a Debugger should have such services from the Linux Kernel. Is not the Delphi debugger a Debugger through the debug services Wine implements? (dbghelp and friends) Free Life Boaz
Re: Delphi 5 debugger is working!
On Tuesday 23 August 2005 20:05, Vitaliy Margolen wrote: > As of todays CVS Delphi 5 debugger is fixed. > > Well, ok, there are still some bugs. One is a minor bug (Module view > reports all modules as a project executable name), but all exports are > there. You can even try to disassemble them. But here is where the major > problems start. Debugger segfaults on that. This is because > NtQueryVirtualMemory and > NtProtectVirtualMemory currently don't work on other processes. What are the problems with implementing those using SIGSTOP/SIGCONT and ptrace(2)? I imagine that for example changing memory protection for another process could be achieved as follows: 1. SIGSTOP to the process 2. inject code that invokes mprotect() and stops execution 3. change EIP, ESP, etc. then SIGCONT 4. wait(pid,&status,WUNTRACED) on the child 5. remove the injected code, restore registers, SIGCONT I have never implemented such a beast so I might be way off, nevertheless it'd be interesting to hear what the problems are. phrack might also be a useful read in that respect. Cheers, Kuba
Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken
* On Tue, 23 Aug 2005, Hiji wrote: > --- Vitaly Lipatov <[EMAIL PROTECTED]> wrote: > > > Hi, Can you pay attention to this patch? It really fixes the problem > > but not discussed in the list and not applied: > > http://www.winehq.com/hypermail/wine-patches/2005/08/0018.html > > WOOHOO! This fixes "half" the problem with Bug3148. > Once I applied the patch, I no longer had the problem > with the effect of the mouse button being continously > pressed once I clicked on something. ... > So, can someone listen (pay attention) to Vitaly and > apply the patch so at least this bug can get half-way > fixed??? The patch has 2 points to change (I am afraid): a, header of its first section refers to "sysparams.c" and "dlls/user/sysparams.c", which makes patcher to not find needed file (dlls/user/tests/sysparams.c). Command "cvs diff -pu dlls/user/" would do the job. :-P b, first hunk of the second section (dlls/user/sysparams.c) is already in the tree, so it fails too.
Re: secur32: Getting real functionality into the NTLM provider
Kai Blin <[EMAIL PROTECTED]> writes: > * Alexandre Julliard <[EMAIL PROTECTED]> [23/08/05, 20:39:52]: > >> You should avoid using stdio. > > How would I do this avoiding stdio? ntlm_auth uses stdin and stdout to > read input and write output. This seems to be the Unix way of doing > things. I mean the stdio functions like fdopen, fgets, etc. They are not guaranteed to be thread-safe because of the way we handle libc threads. It's better to use normal read()/write() instead. -- Alexandre Julliard [EMAIL PROTECTED]
