March 2003 - Wine-Devel - list.winehq.org

Question about kernel32 resources

by Maxime Bellengé

I am currently working on the EnumSystemLanguageGroups/EnumLanguageGroupLocales functions. I have finished everything but there is one thing I don't know. The different language group names are stored in the kernel32.dll resources in a string table. They are indexed from 1 to 17 in the win2k/winxp kernel32 dll. However, in wine it seems these ID are used. So I am wondering how can I workaround that. I can't change the ID for the groups because they are defined in winnls.h from 1 to 17. At the present time I have a version ready to work but with the group names not stored in the resources (so only one language is possible). Do I have to change the kernel32 resources ( a lot of work) or does anyone have an idea ? Thanks Max -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

March 31, 2003

Problem with debugging: XIO: fatal IO error 0 (Success) on X server ":0.0"

by Juraj Hercek

Hi, I have troubles with debugging winelib applications. This is what makes me unhappy: --- $ gdb wine (gdb) r notepad Starting program: /usr/local/bin/wine notepad XIO: fatal IO error 0 (Success) on X server ":0.0" after 187 requests (187 known processed) with 0 events remaining. Program exited with code 01. --- I'm getting similar results with winedbg (running "winedbg notepad") - there is just bunch of debug outputs before the error is printed. However, this happens only when I'm running winedbg from outside wine directory (checked out from cvs). It works when I'm running winedbg from wine directory. I was digging inside wine and problem occurs somewhere in MODULE_DllProcessAttach() function. This lead me to assumption that problem is probably caused by incorrect paths to libraries, which couldn't be found then. I think I should mention that also wineinstall failed because regedit couldn't find "programs/regedit/regedit.exe.so" (this file is definitely there) so I had to run regedit to insert winedefault.reg into registry manualy - I needed to copy winedefault.reg file to /tmp which is accessible from inside wine system as drive E:\. My working environment is mdk-9.1 with XFree86 version 4.3.0, native nvidia driver doesn't work, the same with nvidia driver v. 41.91). If you have any idea what could be wrong with my linux box, please let me know. I prefer gdb for debugging since I can use ddd with gdb. Thanks. --Juraj

March 31, 2003

Re: wine/ scheduler/timer.c scheduler/synchro.c in ...

by Bill Medland

On March 30, 2003 05:37 pm, Alexandre Julliard wrote: > ChangeSet ID: 7728 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/03/30 19:37:05 > > Modified files: > scheduler : timer.c synchro.c > include : winternl.h > dlls/ntdll : time.c sync.c om.c ntdll_misc.h ntdll.spec > > Log message: > Moved WaitForMultipleObjects to ntdll (based on a patch by Eric > Pouech). > Added NTDLL_get_server_timeout function to compute ntdll-style > timeouts and adapted the timer code to use it. > > Patch: http://cvs.winehq.com/patch.py?id=7728 > This breaks the build (on my machine at least) sync.c contains a LARGE_INTEGER time and takes time.s.* include/wtypes.h LARGE_INTEGER only contains a QuadPart as far as I can see. > Old revision New revision Changes Path > 1.17 1.18 +9 -22 wine/scheduler/timer.c > 1.45 1.46 +16 -189 wine/scheduler/synchro.c > 1.21 1.22 +1 -0 wine/include/winternl.h > 1.28 1.29 +42 -6 wine/dlls/ntdll/time.c > 1.23 1.24 +192 -5 wine/dlls/ntdll/sync.c > 1.25 1.26 +0 -13 wine/dlls/ntdll/om.c > 1.11 1.12 +2 -0 wine/dlls/ntdll/ntdll_misc.h > 1.101 1.102 +2 -2 wine/dlls/ntdll/ntdll.spec -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

March 31, 2003

Re: lostwages/. winehq.css

by Jeremy Newman

On Mon, 2003-03-31 at 10:22, Dimitrie O. Paun wrote: > > This style sheet is for the docs only. It is not referenced from any > > other part of the site that I'm aware. See bug # 1354. The docs used to > > use a style sheet to make it look like the rest of the site, I have > > removed all of that, but forgot to at least keep the style sheet there. > > If this for docs only, it seems a bit odd that's named winehq.css, and > it's places at the root of the site, as if it's the CSS for the entire > site... It surely _looks_ like the site-wide style sheet. Thats because in the old version of the site, the docs and the site DID share the same style sheet. Now they don't. This is only a temporary fix until I come up with a better solution. Without this fix, Netscape 4 browsers will not be able to view the docs. -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon

March 31, 2003

Re: Any DCOM experts?

by Bill Medland

On March 30, 2003 05:36 pm, Ove Kaaven wrote: > tor, 2003-03-27 kl. 20:08 skrev Bill Medland: > > To start the ball rolling I was working with MSDN's DCOMTST test program > > pair. > > I haven't looked at it myself, how does it try to locate the server? It doesn't; you specify it on the command line and (if it is anything like the sample program that it says it is based upon) then it passes that server name to the CoCreateInstanceEx function (which wine currently doesn't handle) > If > it needs to use the name service (rpcss.exe), directly or indirectly, to > find it, it's very unlikely to work with wine right now. It does use rpcss. > > > I managed to get that working using the local server (after adding the > > definition of IStream to the registry) but am having no luck getting the > > client under Wine to talk to the server under Win98. In fact the client > > side doesn't even seem to send out a single TCP/IP packet. > > It probably can't send any packets without knowing where to send them, > and if everything else is working, it probably needs rpcss to find out > (the local rpcss is usually requested to act on behalf of the client > instead of having the client contact the remote host directly, since > this lets rpcss cache such information). > > Then again, it may be that not everything else is working. > > > I am currently running native ole32 and native rpcrt4. > > I don't think native rpcrt4 and ole32 is necessarily enough; for > example, the TCP/IP stuff may not be implemented directly in rpcrt4, It isn't, but I am using the native rpc drivers too (rpclt[c,s][cm,3]) > it > might depend on other dlls to provide protocol backends and > authentication services, and registry entries to identify them (though > I'm not sure). Also, COM is married to the registry and you'll probably > need a metric ton (as if there's any other kind of ton, heh... When did that change? I was always taught that a ton was imperial and a tonne was metric (and a tun was a reasonable amount of beer for a small party) >) of > entries to get DCOM to run with native ole32. > > > The builtin rpcrt4 fails on a call to unimplemented > > RpcServerInqDefaultPrincName but I don't understand why it is even > > calling that; why does it think I have Netware only and why does it think > > this is a server process. > > What does that have to do with netware? As far as I know, the security > principal is the backbone of the NT domain's and DCOM's security model. MSDN states "In an environment that only uses NetWare, the server application calls the RpcServerInqDefaultPrincName function to obtain the name of the NetWare server, when authenticated RPC is required. The value obtained from this function is then passed to RpcServerRegisterAuthInfo." Probably my usual jumping to conclusions from MSDN documentation. Thanks for the answer but basically I am following a different solution that doesn't depend upon DCOM. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

March 31, 2003

Re: lostwages/. winehq.css

by Jeremy Newman

No, please keep page specific style sheets confined to the page they are on. This style sheet is for the docs only. It is not referenced from any other part of the site that I'm aware. See bug # 1354. The docs used to use a style sheet to make it look like the rest of the site, I have removed all of that, but forgot to at least keep the style sheet there. On Mon, 2003-03-31 at 10:01, Dimitrie O. Paun wrote: > On Mon, 31 Mar 2003, Jeremy Newman wrote: > > > ChangeSet ID: 7729 > > CVSROOT: /opt/cvs-commit > > Module name: lostwages > > Changes by: jnewman(a)wine.codeweavers.com 2003/03/31 11:03:14 > > > > Added files: > > . : winehq.css > > Should we move all CSS stuff in there (like the stuff > I use in my Fun/Winelib/etc. pages)? > > -- > Dimi. -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon

March 31, 2003

Re: lostwages/. winehq.css

by Dimitrie O. Paun

On 31 Mar 2003, Jeremy Newman wrote: > > This style sheet is for the docs only. It is not referenced from any > other part of the site that I'm aware. See bug # 1354. The docs used to > use a style sheet to make it look like the rest of the site, I have > removed all of that, but forgot to at least keep the style sheet there. If this for docs only, it seems a bit odd that's named winehq.css, and it's places at the root of the site, as if it's the CSS for the entire site... It surely _looks_ like the site-wide style sheet. -- Dimi.

March 31, 2003

Re: lostwages/. winehq.css

by Dimitrie O. Paun

On Mon, 31 Mar 2003, Jeremy Newman wrote: > ChangeSet ID: 7729 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/03/31 11:03:14 > > Added files: > . : winehq.css Should we move all CSS stuff in there (like the stuff I use in my Fun/Winelib/etc. pages)? -- Dimi.

March 31, 2003

Re: Multicast options in WinSock with java

by Mike Hearn

> A requested version is given to WSAStartup by the app. What is it? Yeah, I found that a few minutes ago, but for some reason it seems to be called twice, the first time with version 2 requested then immediately afterwards again with version 1. Pretty strange. I just traced it under XP and there it gives the correct value (9) for the socket option. I'm staring at the java source and trying to figure out how it can do that, considering it seems to pass in a constant from winsock.h, but it must fiddle things somewhere..... -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

March 31, 2003

Re: Multicast options in WinSock with java

by Ove Kaaven

man, 2003-03-31 kl. 11:38 skrev Mike Hearn: > Hi all, > > I have a bit of a problem. Essentially, the problem is that Java 1.4 is > buggy, it includes winsock.h, but then proceeds to use winsock2. That > wouldn't be an issue, except that my app uses multicast sockets, and for > reasons known only to Redmond they decided to change the values of some > of the multicast socket option constants. > > Java, therefore, passes in the winsock1 values to winsock2. Windows > apparently can deal with this just fine (well, the appw works), despite > there being no obvious way to remap them, both IP_MULTICAST_IF and > IP_HDRINCL which both == 2 in different winsock versions would be valid > at once on XP/2003 for instance. > > Marcus, I know you took a stab at implementing multicast support once, > so if you have any tips that'd be appreciated. > > If anybody knows a way you might be able to detect that a program is > using the wrong headers for the winsock2 dll, please let me know. A requested version is given to WSAStartup by the app. What is it?

March 31, 2003