- Wine-Devel - list.winehq.org

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

Re: Re: Problems downloading the RedHat Packages.
by gslink Oct. 26, 2004

Oct. 26, 2004

I downloaded the Oct. Package from Heanet and got garbage. This isn't surprising if it is not there.

1 0

Wine for Solaris 2.8 assembler problems
by Doug Oct. 26, 2004

Oct. 26, 2004

I am trying to compile Wine for Solaris to get MCS working for mono. However there are problems getting Wine to work on Solaris 2.8. When first compiling wine, I was thought the errors were caused by using the assembler for Solaris so I changed the as (assembler) to the GNU version. Now I get the following errors. Any ideas of how to fix this? I have heard people getting mono to work on Solaris 2.8 so from what I know it is possible to get Wine working. gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DBINDIR="\"/usr/l ocal/bin\"" -DDLLDIR="\"/usr/local/lib/wine\"" -D_REENTRANT -fPIC -Wall -pipe -f no-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o port.o port.c {standard input}: Assembler messages: {standard input}:1162: Error: ignoring unrecognized symbol type "" {standard input}:1162: Error: Rest of line ignored. First ignored character is ` 2'.

1 0

Re: rsaenh [beware: 27kB attachment]
by Juan Lang Oct. 26, 2004

Oct. 26, 2004

Hi Michael, some very brief feedback: 1. MD4, MD5, and SHA1 are now implemented in wine's advapi32. Please use these instead of OpenSSL's. 2. The regression tests should be written so they don't fail if OpenSSL isn't available. 3. Get rid of magic numbers: What do the values 0x36 and 0x5c mean in copy_hmac_info? What is the length 64? Finally, some stylistic nits: 4. Please break long lines. 5. In some of the files you have the incorrect filename in the comments, e.g. dlls/rsabase/handle.c, dlls/rsabse/handle.h 6. Your indentation in some places is inconsistent; you mix spaces and tabs, and that makes it hard for me to guess the appropriate tab size. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

3 2

Functions For Helping FillRect
by William Poetra Yoga H Oct. 26, 2004

Oct. 26, 2004

FillRect is used in many places for drawing the GUI. But one thing I think many developers miss is that it doesn't fill the right and bottom borders of the rectangle, very much like LineTo doesn't draw the destination point (as per the MSDN docs). But when handling RECT structures we usually think about the objects, not how the objects are going to be painted on-screen. For example, if we wanted to draw a red rectangle at (10,10) with width of 50 pixels and height of 75 pixels, we do (assuming hdc and hbr is already set correctly): RECT r; r.left = 10; r.top = 10; r.right = r.left + 50; r.bottom = r.top + 75; FillRect(hdc, &r, hbr); This _will_ draw it all right, but there are conceptual errors: 1. The rectangle that we have here is not 50x75, but actually 51x76. But FillRect doesn't fill the right and bottom borders, so it appears correctly. 2. If we thought that FillRect fills the whole rectangle, then actually the above code doesn't do what we want; it should actually draw a 51x76 rectangle. So I think we have to make helper functions: RECT ToFill(RECT r) { ++r.right; ++r.bottom; return r; } RECT ToFillLP(LPRECT lpr) { RECT r = *lpr; return ToFill(r); } LPRECT LPToFill(RECT r) { ++r.right; ++r.bottom; return &r; } LPRECT LPToFillLP(LPRECT lpr) { RECT r = *lpr; return LPToFill(r); } So that: 1. Drawing with FillRect will be correct. 2. We can forget about FillRect's peculiar way of doing things. 3. We can concentrate on the actual rectangles. So instead of the above code, we do: RECT r; r.left = 10; r.top = 10; r.right = r.left + 50 - 1; r.bottom = r.top + 75 - 1; FillRect(hdc, LPToFill(r), hbr); What do you all think? Anyway, for LineTo we can just add "+ 1" at the arguments, no need for a helper function. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

4 9