- Wine-Devel - list.winehq.org

Re: MSIEXEC: Make installation of InstMsiA.exe possible
by Dmitry Timoshkov Nov. 6, 2004

Nov. 6, 2004

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > @@ -523,6 +524,11 @@ > { > InstallUILevel = INSTALLUILEVEL_BASIC|INSTALLUILEVEL_PROGRESSONLY; > } > + else if(!strcasecmp(argv[i]+2, "b+!")) Please use lstrcmpiA instead of strcasecmp. A difference between unix system locale and current ANSI code page in Wine might lead to undesired side effects. -- Dmitry.

2 1

Re: MSIEXEC: Make installation of InstMsiA.exe possible
by Tobias Burnus Nov. 6, 2004

Nov. 6, 2004

Hello, Hans Leidekker wrote: > I have an InstMsiA.exe that uses two undocumented msiexec command line > parameters: /m and /D and uses an undocumented modifier (!) with the /q > parameter. Our msiexec fails when it encounters these and responds with > a usage message. For /m I found the following, don't know whether it helps. Tobias According to http://safariexamples.informit.com/0321133455/ExecutiveSoftware/Diskeeper/D… msiexec /m MIF /qn /I DKMSI INSTALLDIR="C:\MyDir" Where MIF represents the Management Information File -- 8 characters maximum.

1 0

Re: keyboard: ISO_Left_Tab
by Andreas Mohr Nov. 6, 2004

Nov. 6, 2004

Hi, On Sat, Nov 06, 2004 at 07:30:20AM -0800, Walt Ogburn wrote: > + /* Special case: X turns shift-tab into ISO_Left_Tab. */ > + /* Here we change it back. */ > + if ((ret == 0) && (keysym == XK_ISO_Left_Tab)) > + { > + ret = 1; > + lpChar[0] = 0x09; > + } > + > if (ret == 0) > { > BYTE dead_char; Two comments: a) A return value of 0 probably is much more common than the XK_ISO_Left_Tab keysym, so the XK_ISO_Left_Tab check should be first to not have to check both conditions in the event that ret is 0. (the compiler might do reordering according to check probability, though, but OTOH I doubt that it knows which one is more likely) b) there's another if (ret == 0) *right below*, so why not add the XK_ISO_Left_Tab check there? Again useless waste of resources... Thanks for this patch! Andreas Mohr

2 1

Re: winuser.h : remove a fixme and "add" some things
by Dmitry Timoshkov Nov. 6, 2004

Nov. 6, 2004

"Rémi Assailly" <remi.assailly(a)free.fr> wrote: > Excuse me, > I did not want to write that ULONG_PTR is 32 in Win32 _and_ Win64, but I > wanted to write that ULONG_PTR and DWORD were the same. I was wrong here > : DWORD is always 32bits, no ? Right, DWORD is a 32-bit entity in both Win32 and Win64. > So, why there are a lot of ULONG_PTR instead of DWORD if it is not to be > ported in Win64 ? That's there exactly for that purpose - to be portable to Win64. That's a variable that can potentially hold a pointer or a handle value. Win64 is not binary compatible with Win32, but is aimed to be source compatible. Read some docs about porting to Win64 for further details. -- Dmitry.

1 0

err:keyboard:X11DRV_ToUnicodeEx Please report:
by Jon Griffiths Nov. 6, 2004

Nov. 6, 2004

Hi, Duly reporting: err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=9,scanCode=F,keycode=17,state=1) This happens when I shift-tab in any Wine app. System is mdk 10.0/wine cvs and this message has been there for several months at least (when I first noticed). I'm happy to provide more info on request if someone knows how to fix this. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

2 2

Frame and Button Edges
by William Poetra Yoga H Nov. 6, 2004

Nov. 6, 2004

This is about frame edges and button edges on WINE... On Windows, the default behavior is the outer left-top edge of a frame is painted with COLOR_BTNFACE and the inner left-top is colored with something white (COLOR_BTNHILIGHT maybe???). But for caption buttons and push buttons, they are reversed. In WINE, the abovementioned edges, whether for a frame or for a button, are always: 1. outer left-top is COLOR_BTNFACE 2. inner left-top is white This is probably not so noticable, but it's actually quite disturbing if you ask me... For comparison, in ReactOS (0.2.4), caption buttons' edges, and toolbar buttons' edges are drawn correctly, but those of push buttons aren't. So the problem is: how do we reproduce Windows' default behavior? I have tried the styles for DrawEdge, and even made a program to try it out, but I can't seem to generate the correct edges for buttons. The source to edges.c is attached. I wanted to attach the executable but... Can I attach it? Oh, and this is off-topic: How do I use Tahoma as the default font for WINE, like in the screenshots? I think Bitstream Vera fonts look weird for Windows apps... I've searched google but found nothing that helped me... __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 1

Re: winuser.h : remove a fixme and "add" some things
by Dmitry Timoshkov Nov. 6, 2004

Nov. 6, 2004

"Rémi Assailly" <remi.assailly(a)free.fr> wrote: > There were a fixme warning us that a structure were not sure ( line 1898 ). > I checked it and it seems correct. The only differences I found are : > - ULONG_PTR dwItemData instead of DWORD dwItemData which is the same > thing with win32 and also win64 ( according to what I understood ) No, they are not the same. ULONG_PTR is a 64-bit entity in Win64, but 32-bit in Win32. -- Dmitry.

1 0

Public domain source in wine
by Michael Jung Nov. 6, 2004

Nov. 6, 2004

Hello, I would like to use source code from LibTomCrypt (http://libtomcrypt.org) in my implementation of rsaenh.dll (which I still hope has a remote chance of being accepted into wine ;-), in order to get rid of the OpenSSL dependencies. LibTomCrypt is in the public domain. I have two questions: 1. What is the legaly correct way to do this? As I understand it, public domain source can simply be taken as is and re-licensed under the LGPL. Is this correct? Am I allowed to remove the headers in the original file, which state that the code is public domain? How do you generally acknowledge the original author? 2. A more technical question: LibTomCrypt's original sources are highly customizable (A lot of conditional compilation and hook-functions). Since we have fairly special requirements for rsaenh, I could cut down the source code a lot. However, this would make it harder to incorporate code from a newer version of libtomcrypt, once it becomes available. Which way is preferable? Having less code or beeing easily upgradeable? Greetings, Michael

4 3

RE: [dx9-12] Major change to design
by Ann and Jason Edmeades Nov. 5, 2004

Nov. 5, 2004

Ha! Spot the half written note I started a week ago when I first was trying to word a reply, which was nicely hidden off the end of my previous note! - Sorry about that :-) Jason

1 0

Re: [dx9-12] Major change to desgin
by Alexandre Julliard Nov. 5, 2004

Nov. 5, 2004

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > I think this patch should keep you happy (It doesn't do any of the > IWineUserDevice stuff as the code isn't ready for it, but does the dual ref > count + adds Set/Get Stream source). Let me know if you have problems with > it. Looks much better yes, thanks. There's still something strange here: > + /* Not recording... */ > + if (oldSrc != NULL) { > + IWineD3DVertexBuffer_Release(oldSrc); > + IUnknown_Release((IUnknown *)((IWineD3DVertexBufferImpl *)oldSrc)->resource.parent); /* Released an internal reference to a VB */ > + } > + if (pStreamData != NULL) { > + IWineD3DVertexBuffer_AddRef(pStreamData); > + IUnknown_AddRef((IUnknown *)((IWineD3DVertexBufferImpl *)pStreamData)->resource.parent); /* Gained an internal reference to a VB */ > + } You shouldn't need to AddRef the parent, that's up to the object that holds the pointer (also you should do the AddRef before the Release in case old and new are the same object). -- Alexandre Julliard julliard(a)winehq.org

2 3