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

Re: GetTimeZoneInformation return value fix
by Alexandre Julliard Oct. 27, 2004

Oct. 27, 2004

Rein Klazes <rklazes(a)xs4all.nl> writes: > - reordered some code from the existing helper _GetTimeZoneBias > to make it more general useful (and changed the helper names to > TIME_xyz). > - Make GetTimeZoneInformation return the correct zone id > constants. > - changed some "const LPX_Y_Z" declarations to "const X_Y_Z *" This breaks the msvcrt tests: ../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so time.c && touch time.ok time.c:101: Test failed: Wrong date:Year 70 mon 0 yday 1 mday 2 wday 5 hour 0 min 0 sec 0 dst -1 time.c:112: Test failed: Wrong date:Year 70 mon 0 yday 1 mday 2 wday 5 hour 0 min 0 sec 0 dst -1 -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: Wine User Guide Improvements
by Scott Ritchie Oct. 27, 2004

Oct. 27, 2004

Brian, I agree with your plan to condense the guide down. I would still keep some parts of the Getting Wine chapter and put it at the end of the introduction, or possibly at the beginning of configuring wine. I agree about changing it to be mostly a reference to the relevant parts of WineHQ. Would it be duplicitous of me to just go ahead and redo the Getting Wine chapter and leave it as it is now, and perhaps merge it into configuring/introduction once you're done? That way we'll have 4 chapters: Introduction Configuring Wine Running Wine Troubleshooting The running wine chapter eventually needs to be rewritten too (outdated switches, etc.) It could probably be reorganized a bit to read nicer as well (for example, directions for uninstalling programs are given before running them.) I'd like to have the documentation revamped by the next release. Combined with the coming winecfg patches, the major red marks at http://www.winehq.org/site/todo_lists can be replaced with happy green bars. I think we can easily have the yellow bit for the User Guide finished by then too. After that, the only major things in the way of 0.9 seem to be the developer and winelib guide, which are a bit beyond my abilities. (note: forwarded to wine-devel for further feedback) Thanks, Scott Ritchie

2 1

rsaenh
by Michael Jung Oct. 26, 2004

Oct. 26, 2004

Hello, this is an updated version of the rsaenh implementation from yesterday. Updates: 1.) Broke long lines to not exceed a length of 100 characters. 2.) Substituted tabs with spaces. 3.) Removed magic constants. 4.) Rsaenh now uses MD4, MD5 and SHA from advapi32. 5.) Regression tests should work now without failures even if OpenSSL is not available. 6.) Fixed filenames in comments. If you want to try the patch note the following: - After you have applied the patch you have to run autoheader and autoconf. Then cd dlls ; make_dlls ; cd .. ; configure. - After you have compiled and installed wine, you have to unregister rsabase and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll is meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll only). Greetings, Michael

1 0

Re: WSCEnumProtocols
by Alexandre Julliard Oct. 26, 2004

Oct. 26, 2004

Hans Leidekker <hans(a)it.vu.nl> writes: > +INT WINAPI WSAEnumProtocolsA( LPINT lpiProtocols, LPWSAPROTOCOL_INFOA lpBuffer, LPDWORD lpdwLength ) > +{ > + return WINSOCK_EnumProtocols( lpiProtocols, (WSAPROTOCOL_INFOW *)lpBuffer, lpdwLength, FALSE ); > +} You cannot cast a WSAPROTOCOL_INFOA* to a WSAPROTOCOL_INFOW*, the structures don't have the same size. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: rsaenh
by Michael Jung Oct. 26, 2004

Oct. 26, 2004

On Tuesday 26 October 2004 16:56, Juan Lang wrote: > Michael wrote: > > > 1. MD4, MD5, and SHA1 are now implemented in wine's > > > advapi32. Please use these instead of OpenSSL's. > > > > Yes, that makes sense. Would it be possible to move > > the SHA1, MD4 and MD5 related code to some other > > directory in the wine tree and link to it > > statically from both advapi32 and rsaenh? Is the > > misc directory meant for this purpose? > > No. Generally, creating static libs is something we > avoid in wine. More specifically, these functions are > already exported by advapi32, and you already link > advapi32 (to get access to the registry) so there's no > advantage to having a copy in both places. There is also a DES implementation in dlls/advapi32/crypt_des.c. However, this one is not exported by advapi32.dll. I could copy the code over to dlls/rsaenh, but this would mean unnecessary code duplication. How are such cases handled in wine typically? Although it is of no concern at the moment, another problem will arise in the future: advapi32 and cryptographic service provider dll's check each other against tempering by the use of digital signatures in windows (Probably because of US export restrictions on cryptographic software). Although I don't know for sure, I could imagine that this is actually the reason, why there are MD4, MD5 and SHA implementations in advapi32. Having rsaenh.dll call advapi32.dll for these algorithms would bypass these checks. I don't know if this will be an issue for wine though. Greetings, Michael

2 1

Re: shell32: shellpath tests failing greatly
by Juan Lang Oct. 26, 2004

Oct. 26, 2004

Hi Rolf, try reregistering shell32; those entries are supposed to be created by wine.inf when it registers it. --Juan __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

shell32: shellpath tests failing greatly
by Rolf Kalbermatter Oct. 26, 2004

Oct. 26, 2004

The recently added tests for shellpath are failing almost completely on my system as it is missing the according registry entries. Not sure how one is supposed to get those registry entries properly. Maybe there is an install script? Although the current documentation talks about an utility wineinstall this seems to have gone completely and I doubt it would take care of those settings. Rolf Kalbermatter

1 0

FW: GetEnvironmentVariableW regression?
by Rolf Kalbermatter Oct. 26, 2004

Oct. 26, 2004

I suddenly happen to get an error when starting up any application in Wine after having upgraded to current CVS yesterday night from a version a few days ago. The error message is about: "Warning: The specified Windows directory L"c:\\windows" is not accessible" and the same applies for the system directory with the message: "Warning: The specified System directory L"c:\\windows\\system" is not accessible". Looking in the sources I can find the according message in dlls/kernel/process.c and the paths seem to get extracted with GetEnvironmentVariableW(). It seems to me that there is a problem with bad variable expanding or something as the double backslashes in the path in the warning text definitely look wrong. I'm using SUSE Linux 9.0 with XFree 4.3.99. Has this to do with some changes where the .wine/config is supposed to be moved to the registry? If so how do we get the right settings into the registry for common users? Rolf Kalbermatter

1 0

Re: WineHQ: Assorted spelling fixes
by Filip Navara Oct. 26, 2004

Oct. 26, 2004

Francois Gouget wrote: >Index: wwn/wn20041015_244.xml >=================================================================== >RCS file: /var/cvs/lostwages/wwn/wn20041015_244.xml,v >retrieving revision 1.1 >diff -u -r1.1 wn20041015_244.xml >--- wwn/wn20041015_244.xml 15 Oct 2004 03:59:52 -0000 1.1 >+++ wwn/wn20041015_244.xml 25 Oct 2004 23:10:22 -0000 >@@ -185,7 +185,7 @@ > <p>We discussed Jason Edmeades plans to work on > Direct3D 9 a few weeks ago (see WWN issue > <a href="http://www.winehq.com/?issue=240#DirectX%209%20Roadmap">#240</a>). >-The concensus seemed to be created a shared library between >+The concensus seemed to be ro create a shared library between > s/to be ro/to be to/

2 1

Re: rsaenh
by Juan Lang Oct. 26, 2004

Oct. 26, 2004

Michael wrote: > There is also a DES implementation in dlls/advapi32/crypt_des.c. > However, this one is not exported by advapi32.dll. I could copy the > code over to dlls/rsaenh, but this would mean unnecessary code > duplication. How are such cases handled in wine typically? They are typically handled by copying the code. If linking between the two requires a private export, then our DLLs can't work with native ones, and that's something we try to avoid. If we use a static library, the number of static libraries can potentially get very large, and the makefiles unmanageable. It's really best to accept code duplication, especially for something like DES that is quite stable. > Although it is of no concern at the moment, another problem will arise > in the future: advapi32 and cryptographic service provider dll's check > each other against tempering by the use of digital signatures in > windows Yes, I know. The functions in advapi32 for verifying a provider always return success at the moment, unfortunately. Maybe with more crypto support we can tackle this, but not yet. > (Probably because of US export restrictions on cryptographic software). I'd be surprised if this were the motivation. US export restriction is on key length, not on algorithm, and the signatures don't say anything about these, just that the files have not been modified and their source can be verified. I expect the motivation is more along the lines of, I'm trusting these DLLs to encrypt my credit card number and whatnot, so how can I trust the DLLs? --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

2 1