From mstefani at redhat.com Thu Feb 1 04:19:29 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Thu Feb 1 04:19:34 2007 Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps. In-Reply-To: <1125723f0701311611l64ec0cdj5e366e99c785b0e2@mail.gmail.com> References: <1125723f0701311611l64ec0cdj5e366e99c785b0e2@mail.gmail.com> Message-ID: <45C1BEB1.4020700@redhat.com> Hello John, thanks for the patch. You do not need to add the entry to the ChangeLog file. That is done automaticly using the git changelog entries during the release of a new Wine version. Would you mind resubmitting the patch without that? bye michael John Morris wrote: > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > From: John Morris > Date: Wed, 31 Jan 2007 17:38:04 -0600 > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > --- > ChangeLog | 5 +++++ > dlls/ole32/ole32.spec | 1 + > 2 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index 658036c..ce545d0 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2007-01-31 John Morris > + > + * dlls/ole32/ole32.spec: > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > + > 2007-01-24 Vitaliy Margolen > > * server/token.c: > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From rob at codeweavers.com Thu Feb 1 06:33:43 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 1 06:34:19 2007 Subject: Synchronize code page 20127 table with Windows one In-Reply-To: References: Message-ID: <45C1DE27.6010804@codeweavers.com> Dmitry Timoshkov wrote: > The problem is that our translation table for code page 20127 is different from > what Windows has, and the ansi_buf get mangled. Attached patch synchronizes our > code page 20127 table with Windows one and fixes the bug. If you change a codepage from a unicode.org mapping then you need to add the changed .TXT file you generated it from to the build tree and update cpmap.pl to use it. -- Rob Shearman From rob at codeweavers.com Thu Feb 1 06:37:25 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 1 06:39:34 2007 Subject: [PATCH 1/7] server: Get the primary group from the token. In-Reply-To: <45BE6E2C.90101@kievinfo.com> References: <45BE6E2C.90101@kievinfo.com> Message-ID: <45C1DF05.4040706@codeweavers.com> Vitaliy Margolen wrote: > list_add_tail( &token->groups, &group->entry ); > + /* Use first owner capable group as an owner */ > + if (!token->primary_group && group->owner) > + token->primary_group = &group->sid; > + } > + /* we really need a primary group */ > + if (!token->primary_group && group_count) > + { > + release_object( token ); > + return NULL; > } > According to documentation from Microsoft, "the primary group only needs to be set if POSIX compatibility is required." Also, the default security descriptor does not require a group - a NULL group is fine. -- Rob Shearman From rob at codeweavers.com Thu Feb 1 06:42:23 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 1 06:47:32 2007 Subject: [PATCH 3/7] server: Implement object's security descriptor check against token. In-Reply-To: <45BE6E3B.5040202@kievinfo.com> References: <45BE6E3B.5040202@kievinfo.com> Message-ID: <45C1E02F.1000409@codeweavers.com> Vitaliy Margolen wrote: > + res = token_access_check( token, obj->sd, *access, &priv, &priv_count, > + &mapping, access, &status ) == STATUS_SUCCESS && > + status == STATUS_SUCCESS; > + if (!res) > + { > + fprintf( stderr, "access check failed\n" ); > + set_error( STATUS_ACCESS_DENIED ); > + } We don't want anything in the wineserver that can possibly spam the console, so this should be made conditional on debug_level being non-zero. Also, is there any reason you return STATUS_ACCESS_DENIED instead of the statuses returned by token_access_check? Could you try writing a test that creates or opens an object with ACCESS_SYSTEM_SECURITY access and see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED? -- Rob Shearman From dmitry at codeweavers.com Thu Feb 1 07:18:15 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Thu Feb 1 07:21:32 2007 Subject: Synchronize code page 20127 table with Windows one References: <45C1DE27.6010804@codeweavers.com> Message-ID: <001201c74603$8e00c5d0$0100a8c0@DMITRY> "Robert Shearman" wrote: > If you change a codepage from a unicode.org mapping then you need to add > the changed .TXT file you generated it from to the build tree and update > cpmap.pl to use it. That's not really possible due to a confusing license accompanying the unicode.org mappings, and a policy (until at least now) to not patch unicode.org provided data. Otherwise we have to patch the unicode collation table (I had a patch for it somewhere) as well as some other code page tables (problem with cp1251 table comes to mind as was reported recently). The patch I sent mostly was provided for the reference, since I think that Alexandre won't accept it. Just for the reference I'm attaching both the patched US-ASCII-QUOTES.TXT and a diff against original version US-ASCII-QUOTES.TXT.diff. -- Dmitry. -------------- next part -------------- --- US-ASCII-QUOTES.TXT.orig 2003-05-03 00:00:00.000000000 +0900 +++ US-ASCII-QUOTES.TXT 2007-01-31 18:06:59.000000000 +0800 @@ -107,7 +107,7 @@ 0x24 0x0024 # DOLLAR SIGN 0x25 0x0025 # PERCENT SIGN 0x26 0x0026 # AMPERSAND -0x27 0x2019 # RIGHT SINGLE QUOTATION MARK +0x27 0x0027 # RIGHT SINGLE QUOTATION MARK 0x28 0x0028 # LEFT PARENTHESIS 0x29 0x0029 # RIGHT PARENTHESIS 0x2A 0x002A # ASTERISK @@ -164,7 +164,7 @@ 0x5D 0x005D # RIGHT SQUARE BRACKET 0x5E 0x005E # CIRCUMFLEX ACCENT 0x5F 0x005F # LOW LINE -0x60 0x2018 # LEFT SINGLE QUOTATION MARK +0x60 0x0060 # LEFT SINGLE QUOTATION MARK 0x61 0x0061 # LATIN SMALL LETTER A 0x62 0x0062 # LATIN SMALL LETTER B 0x63 0x0063 # LATIN SMALL LETTER C @@ -196,3 +196,132 @@ 0x7D 0x007D # RIGHT CURLY BRACKET 0x7E 0x007E # TILDE 0x7F 0x007F # DELETE + +0x80 0x0000 # NULL +0x81 0x0001 # START OF HEADING +0x82 0x0002 # START OF TEXT +0x83 0x0003 # END OF TEXT +0x84 0x0004 # END OF TRANSMISSION +0x85 0x0005 # ENQUIRY +0x86 0x0006 # ACKNOWLEDGE +0x87 0x0007 # BELL +0x88 0x0008 # BACKSPACE +0x89 0x0009 # HORIZONTAL TABULATION +0x8A 0x000A # LINE FEED +0x8B 0x000B # VERTICAL TABULATION +0x8C 0x000C # FORM FEED +0x8D 0x000D # CARRIAGE RETURN +0x8E 0x000E # SHIFT OUT +0x8F 0x000F # SHIFT IN +0x90 0x0010 # DATA LINK ESCAPE +0x91 0x0011 # DEVICE CONTROL ONE +0x92 0x0012 # DEVICE CONTROL TWO +0x93 0x0013 # DEVICE CONTROL THREE +0x94 0x0014 # DEVICE CONTROL FOUR +0x95 0x0015 # NEGATIVE ACKNOWLEDGE +0x96 0x0016 # SYNCHRONOUS IDLE +0x97 0x0017 # END OF TRANSMISSION BLOCK +0x98 0x0018 # CANCEL +0x99 0x0019 # END OF MEDIUM +0x9A 0x001A # SUBSTITUTE +0x9B 0x001B # ESCAPE +0x9C 0x001C # FILE SEPARATOR +0x9D 0x001D # GROUP SEPARATOR +0x9E 0x001E # RECORD SEPARATOR +0x9F 0x001F # UNIT SEPARATOR +0xA0 0x0020 # SPACE +0xA1 0x0021 # EXCLAMATION MARK +0xA2 0x0022 # QUOTATION MARK +0xA3 0x0023 # NUMBER SIGN +0xA4 0x0024 # DOLLAR SIGN +0xA5 0x0025 # PERCENT SIGN +0xA6 0x0026 # AMPERSAND +0xA7 0x0027 # RIGHT SINGLE QUOTATION MARK +0xA8 0x0028 # LEFT PARENTHESIS +0xA9 0x0029 # RIGHT PARENTHESIS +0xAA 0x002A # ASTERISK +0xAB 0x002B # PLUS SIGN +0xAC 0x002C # COMMA +0xAD 0x002D # HYPHEN-MINUS +0xAE 0x002E # FULL STOP +0xAF 0x002F # SOLIDUS +0xB0 0x0030 # DIGIT ZERO +0xB1 0x0031 # DIGIT ONE +0xB2 0x0032 # DIGIT TWO +0xB3 0x0033 # DIGIT THREE +0xB4 0x0034 # DIGIT FOUR +0xB5 0x0035 # DIGIT FIVE +0xB6 0x0036 # DIGIT SIX +0xB7 0x0037 # DIGIT SEVEN +0xB8 0x0038 # DIGIT EIGHT +0xB9 0x0039 # DIGIT NINE +0xBA 0x003A # COLON +0xBB 0x003B # SEMICOLON +0xBC 0x003C # LESS-THAN SIGN +0xBD 0x003D # EQUALS SIGN +0xBE 0x003E # GREATER-THAN SIGN +0xBF 0x003F # QUESTION MARK +0xC0 0x0040 # COMMERCIAL AT +0xC1 0x0041 # LATIN CAPITAL LETTER A +0xC2 0x0042 # LATIN CAPITAL LETTER B +0xC3 0x0043 # LATIN CAPITAL LETTER C +0xC4 0x0044 # LATIN CAPITAL LETTER D +0xC5 0x0045 # LATIN CAPITAL LETTER E +0xC6 0x0046 # LATIN CAPITAL LETTER F +0xC7 0x0047 # LATIN CAPITAL LETTER G +0xC8 0x0048 # LATIN CAPITAL LETTER H +0xC9 0x0049 # LATIN CAPITAL LETTER I +0xCA 0x004A # LATIN CAPITAL LETTER J +0xCB 0x004B # LATIN CAPITAL LETTER K +0xCC 0x004C # LATIN CAPITAL LETTER L +0xCD 0x004D # LATIN CAPITAL LETTER M +0xCE 0x004E # LATIN CAPITAL LETTER N +0xCF 0x004F # LATIN CAPITAL LETTER O +0xD0 0x0050 # LATIN CAPITAL LETTER P +0xD1 0x0051 # LATIN CAPITAL LETTER Q +0xD2 0x0052 # LATIN CAPITAL LETTER R +0xD3 0x0053 # LATIN CAPITAL LETTER S +0xD4 0x0054 # LATIN CAPITAL LETTER T +0xD5 0x0055 # LATIN CAPITAL LETTER U +0xD6 0x0056 # LATIN CAPITAL LETTER V +0xD7 0x0057 # LATIN CAPITAL LETTER W +0xD8 0x0058 # LATIN CAPITAL LETTER X +0xD9 0x0059 # LATIN CAPITAL LETTER Y +0xDA 0x005A # LATIN CAPITAL LETTER Z +0xDB 0x005B # LEFT SQUARE BRACKET +0xDC 0x005C # REVERSE SOLIDUS +0xDD 0x005D # RIGHT SQUARE BRACKET +0xDE 0x005E # CIRCUMFLEX ACCENT +0xDF 0x005F # LOW LINE +0xE0 0x0060 # LEFT SINGLE QUOTATION MARK +0xE1 0x0061 # LATIN SMALL LETTER A +0xE2 0x0062 # LATIN SMALL LETTER B +0xE3 0x0063 # LATIN SMALL LETTER C +0xE4 0x0064 # LATIN SMALL LETTER D +0xE5 0x0065 # LATIN SMALL LETTER E +0xE6 0x0066 # LATIN SMALL LETTER F +0xE7 0x0067 # LATIN SMALL LETTER G +0xE8 0x0068 # LATIN SMALL LETTER H +0xE9 0x0069 # LATIN SMALL LETTER I +0xEA 0x006A # LATIN SMALL LETTER J +0xEB 0x006B # LATIN SMALL LETTER K +0xEC 0x006C # LATIN SMALL LETTER L +0xED 0x006D # LATIN SMALL LETTER M +0xEE 0x006E # LATIN SMALL LETTER N +0xEF 0x006F # LATIN SMALL LETTER O +0xF0 0x0070 # LATIN SMALL LETTER P +0xF1 0x0071 # LATIN SMALL LETTER Q +0xF2 0x0072 # LATIN SMALL LETTER R +0xF3 0x0073 # LATIN SMALL LETTER S +0xF4 0x0074 # LATIN SMALL LETTER T +0xF5 0x0075 # LATIN SMALL LETTER U +0xF6 0x0076 # LATIN SMALL LETTER V +0xF7 0x0077 # LATIN SMALL LETTER W +0xF8 0x0078 # LATIN SMALL LETTER X +0xF9 0x0079 # LATIN SMALL LETTER Y +0xFA 0x007A # LATIN SMALL LETTER Z +0xFB 0x007B # LEFT CURLY BRACKET +0xFC 0x007C # VERTICAL LINE +0xFD 0x007D # RIGHT CURLY BRACKET +0xFE 0x007E # TILDE +0xFF 0x007F # DELETE -------------- next part -------------- # # Name: ANSI X3.4-1968 (US-ASCII) with 0x60/0x27 as # left/right single quotation mark to Unicode # Unicode version: 3.2 # Table version: 1.0 # Table format: Format A # Date: 2003 April 8 # Authors: Markus Kuhn # # General notes: # # The coded character set commonly known as "American Standard # Code for Information Interchange (ASCII)" originated in the # early 1960s international standardization project that led to # ECMA-6 (1965) and ISO 646 (1972). When the American National # Standards Institute adopted this specification as national # standard X3.4 in 1968, it added a national provision for # overloading the code positions 0x60 and 0x27 with the # typographic characters left and right single quotation mark. # This usage was not reflected in the international standard and # other national adoptions of it, but become widely used in some # communities in the United States and is now found in numerous # historic and still even some contemporary English-language # 7-bit ASCII text files. The Unicode Standard followed # explicitly the international standard, in which 0x27 encodes # the directionally neutral (vertical) character that is used as # both an opening and closing quotation mark as well as an # apostrophe on traditional typewriters, and where 0x60 is a # spacing grave accent that matches the spacing acute accent # found in ISO 8859-1 on position 0xb4. # # To facilitate the correct display and conversion of such ASCII # documents with directional quotation marks to Unicode, this # encoding table defines a 7-bit coded character set mapping # that differs from ISO 646-IRV in that the characters 0x60 and # 0x27 are mapped to Unicode's typographic directional quotation # marks on U+2018 and U+2019, respectively. # # Notes: # # - This historic ASCII interpretation is also used in the left # half of the PostScript StandardEncoding and (erroneously) # ISOLatin1Encoding encoding vectors. # # - Unicode features a SINGLE HIGH-REVERSED-9 QUOTATION MARK # (U+201B), whose provided example glyph has a slightly # closer ressemblance to the compromise glyphs found in many # historic US-ASCII fonts that try to represent both a left # quotation mark and a grave accent. However, since U+201B # is not actually intended to encode correct English # typographic quotation conventions, this table maps 0x60 to # the the correct English opening quotation mark U+2018 # instead (as did PostScript). # # References: # # - Markus Kuhn: ASCII and Unicode quotation marks. # http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html # # - Jukka Korpela: Character histories: notes on some Ascii # code positions. # http://www.cs.tut.fi/~jkorpela/latin1/ascii-hist.html # # Format: Three tab-separated columns # Column #1 is the ANSI X3.4 code (in hex as 0xXX) # Column #2 is the Unicode (in hex as 0xXXXX) # Column #3 the Unicode name (follows a comment sign, '#') # # The entries are in ANSI X3.4 order. # 0x00 0x0000 # NULL 0x01 0x0001 # START OF HEADING 0x02 0x0002 # START OF TEXT 0x03 0x0003 # END OF TEXT 0x04 0x0004 # END OF TRANSMISSION 0x05 0x0005 # ENQUIRY 0x06 0x0006 # ACKNOWLEDGE 0x07 0x0007 # BELL 0x08 0x0008 # BACKSPACE 0x09 0x0009 # HORIZONTAL TABULATION 0x0A 0x000A # LINE FEED 0x0B 0x000B # VERTICAL TABULATION 0x0C 0x000C # FORM FEED 0x0D 0x000D # CARRIAGE RETURN 0x0E 0x000E # SHIFT OUT 0x0F 0x000F # SHIFT IN 0x10 0x0010 # DATA LINK ESCAPE 0x11 0x0011 # DEVICE CONTROL ONE 0x12 0x0012 # DEVICE CONTROL TWO 0x13 0x0013 # DEVICE CONTROL THREE 0x14 0x0014 # DEVICE CONTROL FOUR 0x15 0x0015 # NEGATIVE ACKNOWLEDGE 0x16 0x0016 # SYNCHRONOUS IDLE 0x17 0x0017 # END OF TRANSMISSION BLOCK 0x18 0x0018 # CANCEL 0x19 0x0019 # END OF MEDIUM 0x1A 0x001A # SUBSTITUTE 0x1B 0x001B # ESCAPE 0x1C 0x001C # FILE SEPARATOR 0x1D 0x001D # GROUP SEPARATOR 0x1E 0x001E # RECORD SEPARATOR 0x1F 0x001F # UNIT SEPARATOR 0x20 0x0020 # SPACE 0x21 0x0021 # EXCLAMATION MARK 0x22 0x0022 # QUOTATION MARK 0x23 0x0023 # NUMBER SIGN 0x24 0x0024 # DOLLAR SIGN 0x25 0x0025 # PERCENT SIGN 0x26 0x0026 # AMPERSAND 0x27 0x0027 # RIGHT SINGLE QUOTATION MARK 0x28 0x0028 # LEFT PARENTHESIS 0x29 0x0029 # RIGHT PARENTHESIS 0x2A 0x002A # ASTERISK 0x2B 0x002B # PLUS SIGN 0x2C 0x002C # COMMA 0x2D 0x002D # HYPHEN-MINUS 0x2E 0x002E # FULL STOP 0x2F 0x002F # SOLIDUS 0x30 0x0030 # DIGIT ZERO 0x31 0x0031 # DIGIT ONE 0x32 0x0032 # DIGIT TWO 0x33 0x0033 # DIGIT THREE 0x34 0x0034 # DIGIT FOUR 0x35 0x0035 # DIGIT FIVE 0x36 0x0036 # DIGIT SIX 0x37 0x0037 # DIGIT SEVEN 0x38 0x0038 # DIGIT EIGHT 0x39 0x0039 # DIGIT NINE 0x3A 0x003A # COLON 0x3B 0x003B # SEMICOLON 0x3C 0x003C # LESS-THAN SIGN 0x3D 0x003D # EQUALS SIGN 0x3E 0x003E # GREATER-THAN SIGN 0x3F 0x003F # QUESTION MARK 0x40 0x0040 # COMMERCIAL AT 0x41 0x0041 # LATIN CAPITAL LETTER A 0x42 0x0042 # LATIN CAPITAL LETTER B 0x43 0x0043 # LATIN CAPITAL LETTER C 0x44 0x0044 # LATIN CAPITAL LETTER D 0x45 0x0045 # LATIN CAPITAL LETTER E 0x46 0x0046 # LATIN CAPITAL LETTER F 0x47 0x0047 # LATIN CAPITAL LETTER G 0x48 0x0048 # LATIN CAPITAL LETTER H 0x49 0x0049 # LATIN CAPITAL LETTER I 0x4A 0x004A # LATIN CAPITAL LETTER J 0x4B 0x004B # LATIN CAPITAL LETTER K 0x4C 0x004C # LATIN CAPITAL LETTER L 0x4D 0x004D # LATIN CAPITAL LETTER M 0x4E 0x004E # LATIN CAPITAL LETTER N 0x4F 0x004F # LATIN CAPITAL LETTER O 0x50 0x0050 # LATIN CAPITAL LETTER P 0x51 0x0051 # LATIN CAPITAL LETTER Q 0x52 0x0052 # LATIN CAPITAL LETTER R 0x53 0x0053 # LATIN CAPITAL LETTER S 0x54 0x0054 # LATIN CAPITAL LETTER T 0x55 0x0055 # LATIN CAPITAL LETTER U 0x56 0x0056 # LATIN CAPITAL LETTER V 0x57 0x0057 # LATIN CAPITAL LETTER W 0x58 0x0058 # LATIN CAPITAL LETTER X 0x59 0x0059 # LATIN CAPITAL LETTER Y 0x5A 0x005A # LATIN CAPITAL LETTER Z 0x5B 0x005B # LEFT SQUARE BRACKET 0x5C 0x005C # REVERSE SOLIDUS 0x5D 0x005D # RIGHT SQUARE BRACKET 0x5E 0x005E # CIRCUMFLEX ACCENT 0x5F 0x005F # LOW LINE 0x60 0x0060 # LEFT SINGLE QUOTATION MARK 0x61 0x0061 # LATIN SMALL LETTER A 0x62 0x0062 # LATIN SMALL LETTER B 0x63 0x0063 # LATIN SMALL LETTER C 0x64 0x0064 # LATIN SMALL LETTER D 0x65 0x0065 # LATIN SMALL LETTER E 0x66 0x0066 # LATIN SMALL LETTER F 0x67 0x0067 # LATIN SMALL LETTER G 0x68 0x0068 # LATIN SMALL LETTER H 0x69 0x0069 # LATIN SMALL LETTER I 0x6A 0x006A # LATIN SMALL LETTER J 0x6B 0x006B # LATIN SMALL LETTER K 0x6C 0x006C # LATIN SMALL LETTER L 0x6D 0x006D # LATIN SMALL LETTER M 0x6E 0x006E # LATIN SMALL LETTER N 0x6F 0x006F # LATIN SMALL LETTER O 0x70 0x0070 # LATIN SMALL LETTER P 0x71 0x0071 # LATIN SMALL LETTER Q 0x72 0x0072 # LATIN SMALL LETTER R 0x73 0x0073 # LATIN SMALL LETTER S 0x74 0x0074 # LATIN SMALL LETTER T 0x75 0x0075 # LATIN SMALL LETTER U 0x76 0x0076 # LATIN SMALL LETTER V 0x77 0x0077 # LATIN SMALL LETTER W 0x78 0x0078 # LATIN SMALL LETTER X 0x79 0x0079 # LATIN SMALL LETTER Y 0x7A 0x007A # LATIN SMALL LETTER Z 0x7B 0x007B # LEFT CURLY BRACKET 0x7C 0x007C # VERTICAL LINE 0x7D 0x007D # RIGHT CURLY BRACKET 0x7E 0x007E # TILDE 0x7F 0x007F # DELETE 0x80 0x0000 # NULL 0x81 0x0001 # START OF HEADING 0x82 0x0002 # START OF TEXT 0x83 0x0003 # END OF TEXT 0x84 0x0004 # END OF TRANSMISSION 0x85 0x0005 # ENQUIRY 0x86 0x0006 # ACKNOWLEDGE 0x87 0x0007 # BELL 0x88 0x0008 # BACKSPACE 0x89 0x0009 # HORIZONTAL TABULATION 0x8A 0x000A # LINE FEED 0x8B 0x000B # VERTICAL TABULATION 0x8C 0x000C # FORM FEED 0x8D 0x000D # CARRIAGE RETURN 0x8E 0x000E # SHIFT OUT 0x8F 0x000F # SHIFT IN 0x90 0x0010 # DATA LINK ESCAPE 0x91 0x0011 # DEVICE CONTROL ONE 0x92 0x0012 # DEVICE CONTROL TWO 0x93 0x0013 # DEVICE CONTROL THREE 0x94 0x0014 # DEVICE CONTROL FOUR 0x95 0x0015 # NEGATIVE ACKNOWLEDGE 0x96 0x0016 # SYNCHRONOUS IDLE 0x97 0x0017 # END OF TRANSMISSION BLOCK 0x98 0x0018 # CANCEL 0x99 0x0019 # END OF MEDIUM 0x9A 0x001A # SUBSTITUTE 0x9B 0x001B # ESCAPE 0x9C 0x001C # FILE SEPARATOR 0x9D 0x001D # GROUP SEPARATOR 0x9E 0x001E # RECORD SEPARATOR 0x9F 0x001F # UNIT SEPARATOR 0xA0 0x0020 # SPACE 0xA1 0x0021 # EXCLAMATION MARK 0xA2 0x0022 # QUOTATION MARK 0xA3 0x0023 # NUMBER SIGN 0xA4 0x0024 # DOLLAR SIGN 0xA5 0x0025 # PERCENT SIGN 0xA6 0x0026 # AMPERSAND 0xA7 0x0027 # RIGHT SINGLE QUOTATION MARK 0xA8 0x0028 # LEFT PARENTHESIS 0xA9 0x0029 # RIGHT PARENTHESIS 0xAA 0x002A # ASTERISK 0xAB 0x002B # PLUS SIGN 0xAC 0x002C # COMMA 0xAD 0x002D # HYPHEN-MINUS 0xAE 0x002E # FULL STOP 0xAF 0x002F # SOLIDUS 0xB0 0x0030 # DIGIT ZERO 0xB1 0x0031 # DIGIT ONE 0xB2 0x0032 # DIGIT TWO 0xB3 0x0033 # DIGIT THREE 0xB4 0x0034 # DIGIT FOUR 0xB5 0x0035 # DIGIT FIVE 0xB6 0x0036 # DIGIT SIX 0xB7 0x0037 # DIGIT SEVEN 0xB8 0x0038 # DIGIT EIGHT 0xB9 0x0039 # DIGIT NINE 0xBA 0x003A # COLON 0xBB 0x003B # SEMICOLON 0xBC 0x003C # LESS-THAN SIGN 0xBD 0x003D # EQUALS SIGN 0xBE 0x003E # GREATER-THAN SIGN 0xBF 0x003F # QUESTION MARK 0xC0 0x0040 # COMMERCIAL AT 0xC1 0x0041 # LATIN CAPITAL LETTER A 0xC2 0x0042 # LATIN CAPITAL LETTER B 0xC3 0x0043 # LATIN CAPITAL LETTER C 0xC4 0x0044 # LATIN CAPITAL LETTER D 0xC5 0x0045 # LATIN CAPITAL LETTER E 0xC6 0x0046 # LATIN CAPITAL LETTER F 0xC7 0x0047 # LATIN CAPITAL LETTER G 0xC8 0x0048 # LATIN CAPITAL LETTER H 0xC9 0x0049 # LATIN CAPITAL LETTER I 0xCA 0x004A # LATIN CAPITAL LETTER J 0xCB 0x004B # LATIN CAPITAL LETTER K 0xCC 0x004C # LATIN CAPITAL LETTER L 0xCD 0x004D # LATIN CAPITAL LETTER M 0xCE 0x004E # LATIN CAPITAL LETTER N 0xCF 0x004F # LATIN CAPITAL LETTER O 0xD0 0x0050 # LATIN CAPITAL LETTER P 0xD1 0x0051 # LATIN CAPITAL LETTER Q 0xD2 0x0052 # LATIN CAPITAL LETTER R 0xD3 0x0053 # LATIN CAPITAL LETTER S 0xD4 0x0054 # LATIN CAPITAL LETTER T 0xD5 0x0055 # LATIN CAPITAL LETTER U 0xD6 0x0056 # LATIN CAPITAL LETTER V 0xD7 0x0057 # LATIN CAPITAL LETTER W 0xD8 0x0058 # LATIN CAPITAL LETTER X 0xD9 0x0059 # LATIN CAPITAL LETTER Y 0xDA 0x005A # LATIN CAPITAL LETTER Z 0xDB 0x005B # LEFT SQUARE BRACKET 0xDC 0x005C # REVERSE SOLIDUS 0xDD 0x005D # RIGHT SQUARE BRACKET 0xDE 0x005E # CIRCUMFLEX ACCENT 0xDF 0x005F # LOW LINE 0xE0 0x0060 # LEFT SINGLE QUOTATION MARK 0xE1 0x0061 # LATIN SMALL LETTER A 0xE2 0x0062 # LATIN SMALL LETTER B 0xE3 0x0063 # LATIN SMALL LETTER C 0xE4 0x0064 # LATIN SMALL LETTER D 0xE5 0x0065 # LATIN SMALL LETTER E 0xE6 0x0066 # LATIN SMALL LETTER F 0xE7 0x0067 # LATIN SMALL LETTER G 0xE8 0x0068 # LATIN SMALL LETTER H 0xE9 0x0069 # LATIN SMALL LETTER I 0xEA 0x006A # LATIN SMALL LETTER J 0xEB 0x006B # LATIN SMALL LETTER K 0xEC 0x006C # LATIN SMALL LETTER L 0xED 0x006D # LATIN SMALL LETTER M 0xEE 0x006E # LATIN SMALL LETTER N 0xEF 0x006F # LATIN SMALL LETTER O 0xF0 0x0070 # LATIN SMALL LETTER P 0xF1 0x0071 # LATIN SMALL LETTER Q 0xF2 0x0072 # LATIN SMALL LETTER R 0xF3 0x0073 # LATIN SMALL LETTER S 0xF4 0x0074 # LATIN SMALL LETTER T 0xF5 0x0075 # LATIN SMALL LETTER U 0xF6 0x0076 # LATIN SMALL LETTER V 0xF7 0x0077 # LATIN SMALL LETTER W 0xF8 0x0078 # LATIN SMALL LETTER X 0xF9 0x0079 # LATIN SMALL LETTER Y 0xFA 0x007A # LATIN SMALL LETTER Z 0xFB 0x007B # LEFT CURLY BRACKET 0xFC 0x007C # VERTICAL LINE 0xFD 0x007D # RIGHT CURLY BRACKET 0xFE 0x007E # TILDE 0xFF 0x007F # DELETE From hverbeet at gmail.com Thu Feb 1 12:27:11 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Thu Feb 1 12:27:22 2007 Subject: Donation for your work on Direct 3D In-Reply-To: <200701311912.32935.stefan@codeweavers.com> References: <45C0D9C3.2050109@czela.net> <200701311912.32935.stefan@codeweavers.com> Message-ID: On 31/01/07, Stefan D?singer wrote: > Hi, > Thanks for the offer :-) I am employed by CodeWeavers, so its cw where you > should donate to. I think the best way of doing so is to just buy a copy of > CrossOver :-) > > Stefan > > > Hi Stefan and Henry, i would like to send you 35 EUR or 45 USD for your > > work on Direct 3D in wine, how can i do that? Can you send me your > > account number and prefered currency? > Send it to the Wine Party Fund, I'd say. Henri From jdemooij at gmail.com Thu Feb 1 14:40:09 2007 From: jdemooij at gmail.com (Jan de Mooij) Date: Thu Feb 1 14:41:06 2007 Subject: Office 2003 Installation Message-ID: <97ae3940702011240g244e6d03m86e8f664a51aad96@mail.gmail.com> Hi, I have tried to run the office 2003 installation, and in doing that I came across the following issues: - I think we need to undo a patch for msiexec [1]. CommandLineToArgvW does not what we want with slashes in paths followed by an " (this also happens on Windows). Therefore we need to parse the commandline arguments ourselves, what's done by reverting the patch. I can give an example of when it goes wrong if you want. - Office 2003 installation fails with this (from the log): ------------------------ Successfully launched MsiExec.... 2/1/2007 8:30:55 PM Chained install return code: 1603 Exit code was an error. Shutting down chained setup processing. Set Verbose logging for subsequent setup. ------------------------ BUT, when I add WINEDEBUG=+relay,+seh,+tid,+msi,+msiexec, it runs well and installs alright, so I think it's a timing issue. Anyone has experienced this before? What would be the best way to debug this? (I only choose to install Word, I don't know what happens when I select the other Office-applications) Thanks in advance, Jan de Mooij [1] http://source.winehq.org/git/wine.git/?a=blobdiff;f=programs/msiexec/msiexec.c;h=d63721653992302b80a0e861b8b89d2eef0db8ae;hp=809b38fb58b419a7345af66873c8133ae1fdbb2f;hb=7c35db000b26852fc2bf4a7a7e349953f60d183f;hpb=27c6c83e1ef3aad395ee2421b5241990dc194010 From truiken at gmail.com Thu Feb 1 16:42:47 2007 From: truiken at gmail.com (James Hawkins) Date: Thu Feb 1 16:42:59 2007 Subject: [PATCH] rasapi32: RasEnumConnections now returns correct buffer size (zero) when there are zero connections available In-Reply-To: <78a7dad00702011436j1134c6efr5adc0a5715b58b84@mail.gmail.com> References: <78a7dad00702011436j1134c6efr5adc0a5715b58b84@mail.gmail.com> Message-ID: <22821af30702011442p1f34e23cg19e18dae108e0f81@mail.gmail.com> On 2/1/07, John Smith wrote: > When RasEnumConnections completes the expected behaviour is to have the > needed buffer size stored in *lpcb. Right now wine just leaves it at > whatever size was passed. The windows 2000 behaviour (tested) for when > they're are zero connections, *lpcb is 0. > > Changelog: > RasEnumConnections the buffersize needed reported is now 0 when the number > of connections is 0 > You need to add a test to the test suite for this. -- James Hawkins From dmitry at codeweavers.com Thu Feb 1 23:15:02 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Thu Feb 1 23:15:12 2007 Subject: Conformance test for bug #7286 References: <1170381933.11601.6.camel@misha-laptop> Message-ID: <009b01c74689$1c344540$0100a8c0@DMITRY> "Misha Koshelev" wrote: > + /* Now create the notification thread */ > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > + 0, &threadId); > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. -- Dmitry. From mk144210 at bcm.tmc.edu Thu Feb 1 23:31:56 2007 From: mk144210 at bcm.tmc.edu (Koshelev, Misha Vladislavo) Date: Thu Feb 1 23:34:57 2007 Subject: Conformance test for bug #7286 References: <1170381933.11601.6.camel@misha-laptop> <009b01c74689$1c344540$0100a8c0@DMITRY> Message-ID: <10C24F7C4D05EB45B5F0E1B397897849010F7BCC@BCMEVS7.ad.bcm.edu> I copied and pasted that code straight from the StartNotificationThread function in the same file (well, minus the fact that I am waiting for two events, which is how the refcount problem is brought about), that is dlls/kernel32/tests/change.c. I will change it in my patch, do I also need to change it in the existing StartNotificationThread function? Misha -----Original Message----- From: Dmitry Timoshkov [mailto:dmitry@codeweavers.com] Sent: Thu 2/1/2007 11:15 PM To: Koshelev, Misha Vladislavo Cc: wine-devel@winehq.org Subject: Re: Conformance test for bug #7286 "Misha Koshelev" wrote: > + /* Now create the notification thread */ > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > + 0, &threadId); > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. -- Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070201/cf7296c8/attachment.html From mk144210 at bcm.tmc.edu Thu Feb 1 23:41:08 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Thu Feb 1 23:41:45 2007 Subject: Conformance test for bug #7286 In-Reply-To: <009b01c74689$1c344540$0100a8c0@DMITRY> References: <1170381933.11601.6.camel@misha-laptop> <009b01c74689$1c344540$0100a8c0@DMITRY> Message-ID: <1170394869.11596.0.camel@misha-laptop> Sending new patch to wine-patches now. Also, the important thing I think about this conformance test (although the checks of course are important too) is that on the current git version this conformance test will completely kill wineserver (which my other patch for this bug fixes). Misha On Fri, 2007-02-02 at 13:15 +0800, Dmitry Timoshkov wrote: > "Misha Koshelev" wrote: > > > + /* Now create the notification thread */ > > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > > + 0, &threadId); > > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); > > CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. > From dmitry at codeweavers.com Fri Feb 2 02:02:18 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Fri Feb 2 02:02:31 2007 Subject: Conformance test for bug #7286 References: <1170381933.11601.6.camel@misha-laptop><009b01c74689$1c344540$0100a8c0@DMITRY> <10C24F7C4D05EB45B5F0E1B397897849010F7BCC@BCMEVS7.ad.bcm.edu> Message-ID: <008c01c746a0$7ac6f780$0100a8c0@DMITRY> "Koshelev, Misha Vladislavo" wrote: > I copied and pasted that code straight from the StartNotificationThread function in the same > file (well, minus the fact that I am waiting for two events, which is how the refcount problem > is brought about), that is dlls/kernel32/tests/change.c. I will change it in my patch, Thanks. > do I also > need to change it in the existing StartNotificationThread function? If you do please send that fix as a separate patch. -- Dmitry. From ivan at etersoft.ru Thu Feb 1 03:15:46 2007 From: ivan at etersoft.ru (Ivan Sinitsin) Date: Fri Feb 2 09:04:13 2007 Subject: comdlg32-colordlg fix bgcolor In-Reply-To: <010501c745b5$78e57810$0100a8c0@DMITRY> References: <200701311639.09512.ivan@office.etersoft.ru> <010501c745b5$78e57810$0100a8c0@DMITRY> Message-ID: <200702011215.46375.ivan@office.etersoft.ru> ? ????????? ?? 1 ??????? 2007 07:00 Dmitry Timoshkov ???????(a): > "Ivan Sinitsin" wrote: > > The patch corrects background color of a dialogue window " Choose color " > > at copying a triangular marker, the user colors and the predetermined > > colors. Earlier the background about these elements was more dark than > > the basic background of a window. > > > > + SetClassLongPtrW( hwnd, GCLP_HBRBACKGROUND, (LONG_PTR) > > GetSysColorBrush(COLOR_BTNFACE)); > > This fix is not correct, think for instance about different color themes. > Probably CC_PaintTriangle needs to specify the background color of a > triangle explicitly. This line obviously sets color (considering the current scheme), it transfers as a background current system color of the scheme for display of a background of elements of management. Has checked up, at change of color schemes - dialogue is displayed correctly. From wine-patches at kievinfo.com Thu Feb 1 16:57:10 2007 From: wine-patches at kievinfo.com (Vitaliy Margolen) Date: Fri Feb 2 09:04:13 2007 Subject: [PATCH 1/7] server: Get the primary group from the token. In-Reply-To: <45C1DF05.4040706@codeweavers.com> References: <45BE6E2C.90101@kievinfo.com> <45C1DF05.4040706@codeweavers.com> Message-ID: <45C27046.7080006@kievinfo.com> Robert Shearman wrote: > Vitaliy Margolen wrote: >> list_add_tail( &token->groups, &group->entry ); >> + /* Use first owner capable group as an owner */ >> + if (!token->primary_group && group->owner) >> + token->primary_group = &group->sid; >> + } >> + /* we really need a primary group */ >> + if (!token->primary_group && group_count) >> + { >> + release_object( token ); >> + return NULL; >> } >> > > According to documentation from Microsoft, "the primary group only needs > to be set if POSIX compatibility is required." Also, the default > security descriptor does not require a group - a NULL group is fine. > However access check against token will fail without group being set. So I don't see why can't we require valid group in the security descriptor? Vitaliy. From wine-patches at kievinfo.com Thu Feb 1 17:10:17 2007 From: wine-patches at kievinfo.com (Vitaliy Margolen) Date: Fri Feb 2 09:04:14 2007 Subject: [PATCH 3/7] server: Implement object's security descriptor check against token. In-Reply-To: <45C1E02F.1000409@codeweavers.com> References: <45BE6E3B.5040202@kievinfo.com> <45C1E02F.1000409@codeweavers.com> Message-ID: <45C27359.70004@kievinfo.com> Robert Shearman wrote: > Vitaliy Margolen wrote: >> + res = token_access_check( token, obj->sd, *access, &priv, >> &priv_count, >> + &mapping, access, &status ) == >> STATUS_SUCCESS && >> + status == STATUS_SUCCESS; >> + if (!res) >> + { >> + fprintf( stderr, "access check failed\n" ); >> + set_error( STATUS_ACCESS_DENIED ); >> + } > > We don't want anything in the wineserver that can possibly spam the > console, so this should be made conditional on debug_level being non-zero. In case we will have any problems related to security checks this will be really helpful troubleshooting them. > Also, is there any reason you return STATUS_ACCESS_DENIED instead of the > statuses returned by token_access_check? Could you try writing a test > that creates or opens an object with ACCESS_SYSTEM_SECURITY access and > see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED? > The two programs I'm fixing does not require this. Nor do we handle it properly anyway. Vitaliy. From joonas.koivunen at gmail.com Fri Feb 2 01:34:57 2007 From: joonas.koivunen at gmail.com (Joonas Koivunen) Date: Fri Feb 2 09:04:14 2007 Subject: Getting Fallout 2 to work well Message-ID: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: opreport-40 Type: application/octet-stream Size: 3502 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070202/b63afd68/opreport-40.obj From flexo at holycrap.org Fri Feb 2 09:50:19 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Fri Feb 2 09:44:33 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> Message-ID: <45C35DBB.8050704@holycrap.org> Joonas Koivunen wrote: > The problem I have is that fallout2.exe takes all the available CPU > power, optimizing that might make other old games work better too. I'm > interested in the task, though I haven't got much of an idea how GDI or > DirectDraw api's work and I'd need some pointers where to start solving > this problem. See http://bugs.winehq.org/show_bug.cgi?id=5526 (at least that's what causing performance issues for Fallout 1 but IIRC they use the same engine) Felix From stefandoesinger at gmx.at Fri Feb 2 09:45:19 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Fri Feb 2 09:46:13 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> Message-ID: <200702021645.23102.stefandoesinger@gmx.at> Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > Profiling with oprofile (GDI session) shows that most of the time is used > in the game (I suppose it's the "anon" from wine-preload), next most time > consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be > doing the conversion. It seems that you have a game that has problems with the gdi engine(or lack thereof): http://wiki.winehq.org/DIBEngine http://bugs.winehq.org/show_bug.cgi?id=421 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070202/c7cd08c4/attachment.pgp From thunder.m at czela.net Fri Feb 2 10:15:52 2007 From: thunder.m at czela.net (Mirek) Date: Fri Feb 2 10:16:03 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> Message-ID: <45C363B8.30400@czela.net> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan patches from 26.1.2007 I have GF6800GS, GLSL enabled, FBO enabled, thread patch (for better sound), ALSA, Pixel and vertex shaders enabled too. There was big performance regression in latest wine release (0.9.30). Mirek Joonas Koivunen napsal(a): > Hello everyone! > > Recently I tried fallout2 again, and for some reason it has again > started working with wine. I searched the archives and it seems there > have been lots of times when it has worked and then again hasn't.. Glad > to see I'm not the only one interested in it :) > > From what I gathered from old postings, there had mainly been issues > with mouse input, from which I at least don't suffer. Nor are there any > more reports (appdb at least) of it not working with the latest 0.9.30 . > > The problem I have is that fallout2.exe takes all the available CPU > power, optimizing that might make other old games work better too. I'm > interested in the task, though I haven't got much of an idea how GDI or > DirectDraw api's work and I'd need some pointers where to start solving > this problem. > > Game taking all of available CPU doesn't make it unplayable. It just > makes mouse movement jerky and overall feeling is that my computer (amd > athlon xp 1800+) is too slow :) AFAIK minimum requirements for this game > were something like P90 with 16MB ram :) > > Some "features" like fading to black and white (going to menu for > example) are simply missing (these were in use a while ago, with older > wine). The rendering of animations slows down (in the combat mode) if > the animation happens to be under the animated cursor. > > I have tried Thunderbirds (from #winehq @ freenode.net > ) patch, which when rendering with opengl uses > pixel shaders to do 8bit->32bit conversion. It resulted in a bit more > sluggish (compared to GDI) game play experience. > > Profiling with oprofile (GDI session) shows that most of the time is > used in the game (I suppose it's the "anon" from wine-preload), next > most time consuming is winex11 drivers X11DRV_DIB_SetImageBits which > seems to be doing the conversion. > > I have included a bit cleaned version of opreport -l, only the first 40 > lines. Any help would be appreciated. > > -- > -- Joonas Koivunen > > > ------------------------------------------------------------------------ > > From dmitry at codeweavers.com Fri Feb 2 10:37:30 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Fri Feb 2 10:37:32 2007 Subject: comdlg32-colordlg fix bgcolor References: <200701311639.09512.ivan@office.etersoft.ru><010501c745b5$78e57810$0100a8c0@DMITRY> <200702011215.46375.ivan@office.etersoft.ru> Message-ID: <007901c746e8$73067af0$0100a8c0@DMITRY> "Ivan Sinitsin" wrote: > This line obviously sets color (considering the current scheme), it transfers > as a background current system color of the scheme for display of a > background of elements of management. Has checked up, at change of color > schemes - dialogue is displayed correctly. My concern is why do you change GCLP_HBRBACKGROUND (a system setting) at all? Should the painting code be changed instead to use explicit background color in CC_PaintTriangle? -- Dmitry. From mailjohnmorris at gmail.com Fri Feb 2 13:25:52 2007 From: mailjohnmorris at gmail.com (John Morris) Date: Fri Feb 2 13:26:13 2007 Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps. In-Reply-To: <45C1BEB1.4020700@redhat.com> References: <1125723f0701311611l64ec0cdj5e366e99c785b0e2@mail.gmail.com> <45C1BEB1.4020700@redhat.com> Message-ID: <1125723f0702021125s7c1d4a5dwa999ae111c414c15@mail.gmail.com> Sorry, I misunderstood the sending patches guideline on the winehq page. It sounds like it is instructing me to include a changelog entry. I'll resubmit it. Thanks, John On 2/1/07, Michael Stefaniuc wrote: > Hello John, > > thanks for the patch. > You do not need to add the entry to the ChangeLog file. That is done > automaticly using the git changelog entries during the release of a new > Wine version. Would you mind resubmitting the patch without that? > > bye > michael > > John Morris wrote: > > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > > From: John Morris > > Date: Wed, 31 Jan 2007 17:38:04 -0600 > > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > > > --- > > ChangeLog | 5 +++++ > > dlls/ole32/ole32.spec | 1 + > > 2 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/ChangeLog b/ChangeLog > > index 658036c..ce545d0 100644 > > --- a/ChangeLog > > +++ b/ChangeLog > > @@ -1,3 +1,8 @@ > > +2007-01-31 John Morris > > + > > + * dlls/ole32/ole32.spec: > > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > > + > > 2007-01-24 Vitaliy Margolen > > > > * server/token.c: > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani@redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > From paul.vriens.wine at gmail.com Fri Feb 2 13:59:03 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Fri Feb 2 13:59:28 2007 Subject: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. In-Reply-To: <1125723f0702021128m2422705cq5690b212bb50728f@mail.gmail.com> References: <1125723f0702021128m2422705cq5690b212bb50728f@mail.gmail.com> Message-ID: <45C39807.8000504@gmail.com> John Morris wrote: > I'm resubmitting the patch without the changelog entry. > > > ------------------------------------------------------------------------ > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > From: John Morris > Date: Fri, 2 Feb 2007 13:20:34 -0600 > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > --- > dlls/ole32/ole32.spec | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > Hi, I thought we use: @ stub CoWaitForMultipleHandles for functions that should be exported and are not implemented at all, and use @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) where we at least have something in a *.c file (although that could be a simple return): HRESULT WINAPI CoWaitForMultipleHandles() { FIXME("unimplemented stub!\n"); return E_FAIL; } Isn't the first one a stub and the second one a semi-stub, or have I mixed up things? Cheers, Paul. From mailjohnmorris at gmail.com Fri Feb 2 14:23:09 2007 From: mailjohnmorris at gmail.com (John Morris) Date: Fri Feb 2 14:23:19 2007 Subject: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. In-Reply-To: <45C39807.8000504@gmail.com> References: <1125723f0702021128m2422705cq5690b212bb50728f@mail.gmail.com> <45C39807.8000504@gmail.com> Message-ID: <1125723f0702021223h3ccfbf61sba410985b1ec2d4@mail.gmail.com> On 2/2/07, Paul Vriens wrote: > John Morris wrote: > > I'm resubmitting the patch without the changelog entry. > > > > > > ------------------------------------------------------------------------ > > > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > > From: John Morris > > Date: Fri, 2 Feb 2007 13:20:34 -0600 > > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > > > --- > > dlls/ole32/ole32.spec | 1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > Hi, > > I thought we use: > > @ stub CoWaitForMultipleHandles > > for functions that should be exported and are not implemented at all, and use > > @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > where we at least have something in a *.c file (although that could be a simple > return): > > HRESULT WINAPI CoWaitForMultipleHandles() { > FIXME("unimplemented stub!\n"); > return E_FAIL; > } > > Isn't the first one a stub and the second one a semi-stub, or have I mixed up > things? > > Cheers, > > Paul. > > > It appears to be implemented in dlls/ole32/compobj.c From wine.dev at web.de Fri Feb 2 14:35:08 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Fri Feb 2 14:36:02 2007 Subject: winetest: add support for http_proxy environment variable In-Reply-To: <45AA3A7E.9000808@freemail.hu> References: <45AA3A7E.9000808@freemail.hu> Message-ID: <1170448509.6887.20.camel@p4> On So, 2007-01-14 at 15:13 +0100, N?meth M?rton wrote: Welcome to wine. I have some comments about your Patch: > diff -u -r wine-0.9.29.orig/ChangeLog wine-0.9.29/ChangeLog > --- wine-0.9.29.orig/ChangeLog 2007-01-09 16:42:47.000000000 +0100 > +++ wine-0.9.29/ChangeLog 2007-01-14 15:02:31.000000000 +0100 The changelog will be updated during a release with the Informations from the subject. > + > + http_proxy = getenv("http_proxy"); > + if (http_proxy) { > + /* Proxy configuration found */ > + memset(®ex, 0, sizeof(regex)); > + retval = regcomp(®ex, The Idea to support a http-proxy is good, but the Programm must run on Windows. 1. I never saw an environment-variable "http_proxy" on Windows. Most Windows-Applications use the Proxy-Data from IE (Get the settings from there) 2. "regcomp" and friends are posix, but not available on windows Thanks for helping wine. -- By by ... Detlef From wine-devel at kievinfo.com Sat Feb 3 01:06:44 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 3 01:07:20 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170175430.7283.27.camel@p4> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> Message-ID: <45C43484.3070105@kievinfo.com> Detlef Riekenberg wrote: > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: >> + >> +

While there is currently no Wine package explicitly designed for >> the 64-bit version >> +of Ubuntu, there are several hacks that can be used to install the >> 32-bit package >> +into the 64-bit distribution and have it function normally. See >> +this page on the >> Ubuntu wiki >> +for more details.

> > IMHO, a link to our own Wiki should be placed on the download-deb page > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964cb670a > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > https://help.ubuntu.com/community/WineForAMD64 > > The provided automatic installation script includes the sidenet-script. > Please include a BIG WARNING, that this is never supported by winehq > and the users need a clean wine, before they ask for help on #winehq > or wine-users@winehq.org > > > You mention sidenet on that page: > "If you followed the manual instructions you need to install the Sidenet > script" > This is wrong. Please remove that line! > > Even, when the sidenet-script might help some users to run an app, > "you need to install the Sidenet script" is wrong! I still see that information listed on the mentioned page. I was hopping we could get some useful information for Ubuntu-64 users. I guess not. I will discourage anyone from referring to the above mentioned page because it has sedenet script as a "requirement". It's the same stuff as winetools and _brakes_ default Wine configuration. Vitaliy From scott at open-vote.org Sat Feb 3 03:33:45 2007 From: scott at open-vote.org (Scott Ritchie) Date: Sat Feb 3 03:33:27 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <45C43484.3070105@kievinfo.com> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> Message-ID: <1170495225.17168.5.camel@scott-desktop> On Sat, 2007-02-03 at 00:06 -0700, Vitaliy Margolen wrote: > Detlef Riekenberg wrote: > > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > >> + > >> +

While there is currently no Wine package explicitly designed for > >> the 64-bit version > >> +of Ubuntu, there are several hacks that can be used to install the > >> 32-bit package > >> +into the 64-bit distribution and have it function normally. See > >> +this page on the > >> Ubuntu wiki > >> +for more details.

> > > > IMHO, a link to our own Wiki should be placed on the download-deb page > > > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964cb670a > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > https://help.ubuntu.com/community/WineForAMD64 > > > > The provided automatic installation script includes the sidenet-script. > > Please include a BIG WARNING, that this is never supported by winehq > > and the users need a clean wine, before they ask for help on #winehq > > or wine-users@winehq.org > > > > > > You mention sidenet on that page: > > "If you followed the manual instructions you need to install the Sidenet > > script" > > This is wrong. Please remove that line! > > > > Even, when the sidenet-script might help some users to run an app, > > "you need to install the Sidenet script" is wrong! > > I still see that information listed on the mentioned page. I was hopping > we could get some useful information for Ubuntu-64 users. > I guess not. I will discourage anyone from referring to the above > mentioned page because it has sedenet script as a "requirement". It's > the same stuff as winetools and _brakes_ default Wine configuration. > > > Vitaliy I just fixed it to make it better. I have half a mind to delete all mention of sidenet from the page entirely. I'll change the link to a page on our wiki with the same info and resend. Thanks, Scott Ritchie From stefandoesinger at gmx.at Sat Feb 3 05:00:49 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sat Feb 3 05:01:30 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <45C363B8.30400@czela.net> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <45C363B8.30400@czela.net> Message-ID: <200702031200.57932.stefandoesinger@gmx.at> Am Freitag 02 Februar 2007 17:15 schrieb Mirek: > Getting Fallout 2 to work well > Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan > patches from 26.1.2007 Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 game afaik. Did you do a regression test to localize the Flatout 2 performance regression? I suspect my StretchRect patch, and I have a fix for it in my tree. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070203/d7fe2495/attachment.pgp From thunder.m at czela.net Sat Feb 3 05:20:22 2007 From: thunder.m at czela.net (Mirek) Date: Sat Feb 3 05:20:27 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <200702031200.57932.stefandoesinger@gmx.at> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <45C363B8.30400@czela.net> <200702031200.57932.stefandoesinger@gmx.at> Message-ID: <45C46FF6.2010901@czela.net> Sorry, my mistake :) How can I download wine from your tree? Yes, your latest patches from 26.1.2007 fixed this regression, great work! Mirek Stefan D?singer napsal(a): > Am Freitag 02 Februar 2007 17:15 schrieb Mirek: >> Getting Fallout 2 to work well >> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan >> patches from 26.1.2007 > > Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 > game afaik. > > Did you do a regression test to localize the Flatout 2 performance regression? > I suspect my StretchRect patch, and I have a fix for it in my tree. From dmitry at codeweavers.com Sat Feb 3 09:15:11 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 3 09:15:08 2007 Subject: [msvcrt] properly align struct _stati64's st_size References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> Message-ID: <001201c747a6$1d811310$0100a8c0@DMITRY> "Damjan Jovanovic" wrote: > In wine's struct _stati64, st_size has an offset of 20 bytes from the > beginning of the struct, unlike mingw's and Window's 24. This breaks > Java 1.4.x pretty badly, it dies on startup complaining about a > truncated class file (#2953). Using #include and #include > around the struct didn't help, so a padding field was used > instead. Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to align the Size field help? #include typedef struct _WIN32_STREAM_ID { DWORD dwStreamId; DWORD dwStreamAttributes; LARGE_INTEGER DECLSPEC_ALIGN(8) Size; DWORD dwStreamNameSize; WCHAR cStreamName[ANYSIZE_ARRAY]; } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; #include > +static void test_stat( void ) > +{ > + int offset = offsetof(struct _stati64, st_size); > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > +} This should be a part of auto generated header tests. Have a look at dlls/*/tests/generated.c files. -- Dmitry. From wine-devel at kievinfo.com Sat Feb 3 11:02:35 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 3 11:03:05 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170495225.17168.5.camel@scott-desktop> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> <1170495225.17168.5.camel@scott-desktop> Message-ID: <45C4C02B.5040209@kievinfo.com> Scott Ritchie wrote: > On Sat, 2007-02-03 at 00:06 -0700, Vitaliy Margolen wrote: >> Detlef Riekenberg wrote: >>> On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: >>>> + >>>> +

While there is currently no Wine package explicitly designed for >>>> the 64-bit version >>>> +of Ubuntu, there are several hacks that can be used to install the >>>> 32-bit package >>>> +into the 64-bit distribution and have it function normally. See >>>> +this page on the >>>> Ubuntu wiki >>>> +for more details.

>>> IMHO, a link to our own Wiki should be placed on the download-deb page >>> >>> http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964cb670a >>> >>> >>> And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and >>> https://help.ubuntu.com/community/WineForAMD64 >>> >>> The provided automatic installation script includes the sidenet-script. >>> Please include a BIG WARNING, that this is never supported by winehq >>> and the users need a clean wine, before they ask for help on #winehq >>> or wine-users@winehq.org >>> >>> >>> You mention sidenet on that page: >>> "If you followed the manual instructions you need to install the Sidenet >>> script" >>> This is wrong. Please remove that line! >>> >>> Even, when the sidenet-script might help some users to run an app, >>> "you need to install the Sidenet script" is wrong! >> I still see that information listed on the mentioned page. I was hopping >> we could get some useful information for Ubuntu-64 users. >> I guess not. I will discourage anyone from referring to the above >> mentioned page because it has sedenet script as a "requirement". It's >> the same stuff as winetools and _brakes_ default Wine configuration. >> >> >> Vitaliy > > I just fixed it to make it better. I have half a mind to delete all > mention of sidenet from the page entirely. Can you explain why is it needed? This is the same _exact_ stuff as winetools! I failed to find a single piece of it that is useful for every day user. However almost every single thing it does, will compromise Wine's integrity. Vitaliy. From hans at it.vu.nl Sat Feb 3 11:25:05 2007 From: hans at it.vu.nl (Hans Leidekker) Date: Sat Feb 3 11:25:12 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <001201c747a6$1d811310$0100a8c0@DMITRY> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> <001201c747a6$1d811310$0100a8c0@DMITRY> Message-ID: <200702031825.05296.hans@it.vu.nl> On Saturday 03 February 2007 16:15:11 Dmitry Timoshkov wrote: > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > align the Size field help? That should fix this particular struct but __int64 is used elsewhere inside and outside of Wine, so maybe the typedef for __int64 itself should get the alignment attribute? -Hans From stefandoesinger at gmx.at Sat Feb 3 14:35:58 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Sat Feb 3 14:36:39 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <45C46FF6.2010901@czela.net> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <200702031200.57932.stefandoesinger@gmx.at> <45C46FF6.2010901@czela.net> Message-ID: <200702032136.02721.stefandoesinger@gmx.at> Am Samstag 03 Februar 2007 12:20 schrieb Mirek: > Sorry, my mistake :) How can I download wine from your tree? Yes, your > latest patches from 26.1.2007 fixed this regression, great work! "In my tree" == Those patches :-) > Mirek > > Stefan D?singer napsal(a): > > Am Freitag 02 Februar 2007 17:15 schrieb Mirek: > >> Getting Fallout 2 to work well > >> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan > >> patches from 26.1.2007 > > > > Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a > > Direct3D9 game afaik. > > > > Did you do a regression test to localize the Flatout 2 performance > > regression? I suspect my StretchRect patch, and I have a fix for it in my > > tree. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070203/fc2f9dd4/attachment.pgp From wine.dev at web.de Sat Feb 3 14:52:25 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Sat Feb 3 14:54:33 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170495225.17168.5.camel@scott-desktop> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> <1170495225.17168.5.camel@scott-desktop> Message-ID: <1170535945.12990.26.camel@p4> On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > > https://help.ubuntu.com/community/WineForAMD64 > > > > > > The provided automatic installation script includes the sidenet-script. > > > Please include a BIG WARNING, that this is never supported by winehq > > > and the users need a clean wine, before they ask for help on #winehq > > > or wine-users@winehq.org > I just fixed it to make it better. I have half a mind to delete all > mention of sidenet from the page entirely. The Sidenet - Script is still there. Another Tip: "Next get the libxxf86dga1 package" Why that? DGA was dropped in July 2006: http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cddcce69e25801e3a521f IMHO, the only useful things, a wine download script can do is: - download and install wine - optional download and install the gecko-engine - add the "IE 6.0"-Version to the Registry - optional download and install mono - add the ".Net"-Version to the Registry (The above mono provides ".Net 1.1") - optional download and install the corefonts suggest a BUG-Report, when the buildin Fonts are not correct Enable download and installation for native DCOM / native MSI only as a test, when the buildin versions do not work and an active wine BUG-ID is provided. Thanks -- By by ... Detlef From scott at open-vote.org Sat Feb 3 15:00:46 2007 From: scott at open-vote.org (Scott Ritchie) Date: Sat Feb 3 15:00:35 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170535945.12990.26.camel@p4> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> <1170495225.17168.5.camel@scott-desktop> <1170535945.12990.26.camel@p4> Message-ID: <1170536446.17168.10.camel@scott-desktop> On Sat, 2007-02-03 at 21:52 +0100, Detlef Riekenberg wrote: > On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > > > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > > > https://help.ubuntu.com/community/WineForAMD64 > > > > > > > > The provided automatic installation script includes the sidenet-script. > > > > Please include a BIG WARNING, that this is never supported by winehq > > > > and the users need a clean wine, before they ask for help on #winehq > > > > or wine-users@winehq.org > > > > I just fixed it to make it better. I have half a mind to delete all > > mention of sidenet from the page entirely. > > The Sidenet - Script is still there. > I removed all traces of it from the wine wiki page I set up here, which the download-deb page should link to now: http://wiki.winehq.org/UbuntuAMD64 I agree with you and Vitaly about this, by the way. > > Another Tip: > "Next get the libxxf86dga1 package" > > Why that? > DGA was dropped in July 2006: > http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cddcce69e25801e3a521f > > The main problem is that I don't have a 64-bit machine and haven't tested the instructions myself, but as I understand it if Wine was compiled with DGA support (as the 32 bit package was) then it would go nuts if it expected to find the lib and didn't, which the DGA hack was a workaround for. But if it can be eliminated entirely that's really good news. Thanks, Scott Ritchie From wine.dev at web.de Sat Feb 3 15:06:15 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Sat Feb 3 15:06:56 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170495225.17168.5.camel@scott-desktop> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> <1170495225.17168.5.camel@scott-desktop> Message-ID: <1170536776.12990.30.camel@p4> On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > I'll change the link to a page on our wiki with the same info and > resend. Please remove the tips for libxxf86dga from http://wiki.winehq.org/UbuntuAMD64 winex11.drv dropped DGA Support at the end of July 2006 Thanks -- By by ... Detlef From hans at it.vu.nl Sat Feb 3 15:11:11 2007 From: hans at it.vu.nl (Hans Leidekker) Date: Sat Feb 3 15:11:42 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <200702031825.05296.hans@it.vu.nl> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> <001201c747a6$1d811310$0100a8c0@DMITRY> <200702031825.05296.hans@it.vu.nl> Message-ID: <200702032211.11401.hans@it.vu.nl> On Saturday 03 February 2007 18:25:05 Hans Leidekker wrote: > inside and outside of Wine, so maybe the typedef for __int64 itself > should get the alignment attribute? To answer my own question: __int64 is not a typedef when compiling with GCC, but a preprocessor define. This way it is possible to use signed/unsigned modifiers as you can on MSVC because it's a builtin type there. We can't add an alignment attribute to the preprocessor define because that will result in compiler errors when the type is used in function declarations. So it seems like we're stuck with fixing individual structs in Wine. Winelib apps will still be affected though. -Hans From fgouget at free.fr Sat Feb 3 16:52:38 2007 From: fgouget at free.fr (Francois Gouget) Date: Sat Feb 3 16:52:49 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> Message-ID: On Sat, 3 Feb 2007, Damjan Jovanovic wrote: [...] > * Added padding so that struct _stati64's st_size has an offset of 24 > bytes from the beginning of the struct like it should. Does the st_size field get the right offset when using Wine's header with the Windows compiler? -- Francois Gouget http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds From dmitry at codeweavers.com Sat Feb 3 23:58:58 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 3 23:59:08 2007 Subject: [msvcrt] properly align struct _stati64's st_size References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com><001201c747a6$1d811310$0100a8c0@DMITRY> <200702031825.05296.hans@it.vu.nl> Message-ID: <005a01c74821$94105f10$0100a8c0@DMITRY> "Hans Leidekker" wrote: >> Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to >> align the Size field help? > > That should fix this particular struct but __int64 is used elsewhere > inside and outside of Wine, so maybe the typedef for __int64 itself > should get the alignment attribute? To make sure that Wine headers are free of alignment bugs we have dlls/*/tests/generated.c auto generated by tools/winapi. We just need to add msvcrt types to tests.dat. It looks like a lot of the CRT headers in PSDK (including sys/stat.h) set alignment manually to 8, for example direct.h has the following comment: #ifdef _MSC_VER /* * Currently, all MS C compilers for Win32 platforms default to 8 byte * alignment. */ #pragma pack(push,8) #endif /* _MSC_VER */ -- Dmitry. From hans at it.vu.nl Sun Feb 4 03:21:36 2007 From: hans at it.vu.nl (Hans Leidekker) Date: Sun Feb 4 03:21:54 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <005a01c74821$94105f10$0100a8c0@DMITRY> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> <200702031825.05296.hans@it.vu.nl> <005a01c74821$94105f10$0100a8c0@DMITRY> Message-ID: <200702041021.36383.hans@it.vu.nl> On Sunday 04 February 2007 06:58:58 Dmitry Timoshkov wrote: > To make sure that Wine headers are free of alignment bugs we have > dlls/*/tests/generated.c auto generated by tools/winapi. We just need > to add msvcrt types to tests.dat. Sure, that will help fixing Wine alignment bugs. But an MSVC source that makes assumptions about the alignment of __int64, when recompiled as a Winelib app with GCC could still prove to be very hard to debug. So it's important to find a way to make all 64 bit types align on 8 byte boundaries, like MinGW does as well. We have to do it selectively of course, because Unix libraries have different assumptions about the alignment of 64 bit types. -Hans From wine.dev at web.de Sun Feb 4 04:40:31 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Sun Feb 4 04:41:05 2007 Subject: [lostwages] Update download-deb page with better information, error fixes In-Reply-To: <1170536446.17168.10.camel@scott-desktop> References: <1170148195.16624.1.camel@scott-desktop> <1170175430.7283.27.camel@p4> <45C43484.3070105@kievinfo.com> <1170495225.17168.5.camel@scott-desktop> <1170535945.12990.26.camel@p4> <1170536446.17168.10.camel@scott-desktop> Message-ID: <1170585631.6930.19.camel@p4> On Sa, 2007-02-03 at 13:00 -0800, Scott Ritchie wrote: > > The Sidenet - Script is still there. > > > I removed all traces of it from the wine wiki page I set up here, which > the download-deb page should link to now: > http://wiki.winehq.org/UbuntuAMD64 > I agree with you and Vitaly about this, by the way. Great. It's still there, but it's intresting, how fast it went away: https://help.ubuntu.com/community/WineForAMD64 > > Another Tip: > > "Next get the libxxf86dga1 package" > > > > Why that? > > DGA was dropped in July 2006: > The main problem is that I don't have a 64-bit machine and haven't > tested the instructions myself, I have also no 64-Bit machine here. > if Wine was compiled with DGA support (as the 32 bit package was) That is not possible since Aug. 2006. The Part of the Patch "Kill DGA support", that removed "-lXxf86dga": http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cddcce69e25801e3a521f#patch2 > But if it can be eliminated entirely that's really good news. You can remove the libXxf86dga-dev package and build wine again: The same "winex11.dev.so" is build. -- By by ... Detlef From der.fabe at gmx.net Sat Feb 3 16:13:50 2007 From: der.fabe at gmx.net (Fabian Bieler) Date: Sun Feb 4 11:04:34 2007 Subject: Bug 4791 - Civ4 crashes because of recent explorer/systray changes Message-ID: <200702032313.51154.der.fabe@gmx.net> Hello! I tried to look into Bug 4791 (Civ4 crashes because of recent explorer/systray changes http://bugs.winehq.org/show_bug.cgi?id=4791 ). Pretty early during initialization (before the application creates any windows itsself) a WM_FONTCHANGE message is broadcasted. The only window to which the message gets actually send is the Wine Systray Listener window. The message is immediately pulled by peek_message as a MSG_NOTIFY message. A few seconds later the WM_FONTCHANGE message is pulled from the queue of the Wine Systray Listener window again, this time of the type MSG_CALLBACK. the callback function pointer is a nullpointer resulting in a pagefault. If the Wine Desktop window is set as its own parent (like described in the bugzilla thread), the WM_FONTCHANGE message does not get send to the window and the program starts up fine. Now, I do not really understand the wine messaging system (particularly the difference between notify and callback messages) so I thought maybe somebody here could help me with that or point me to some introduction other than http://winehq.org/site/docs/winedev-guide/c3762#AEN3825 and message.c. Should the fontchange-message really be send to the Wine Systray Listener window? All test were run using wine-0.9.30, civ4 v1.61 with nocd-patch and native msxml3. Fabian From fgouget at codeweavers.com Fri Feb 2 09:31:02 2007 From: fgouget at codeweavers.com (Francois Gouget) Date: Sun Feb 4 14:32:20 2007 Subject: Detect screen resolution change errors In-Reply-To: <200701311142.06367.stefandoesinger@gmx.at> References: <45BF43AB.8000108@codeweavers.com> <200701311142.06367.stefandoesinger@gmx.at> Message-ID: <45C35936.1010400@codeweavers.com> Stefan D?singer wrote: > Am Mittwoch 31 Januar 2007 10:25 schrieb H. Verbeet: >> On 30/01/07, Francois Gouget wrote: >>> I have attached the relevant patches. Does this look ok to the DirectX >>> gurus? >> At least the wined3d part looks ok to me, although we should probably >> be cleaning up the GL context as well, there and in the other places >> where we return. > For some reason I didn't get the original patch, or I accidentally deleted > it(more likely). Yo can find it there: http://www.winehq.org/pipermail/wine-devel/2007-January/053725.html [...] > I do not know to what extend we want to catch screen res change failures. The > resolution? I'd say yes. Color depth? Propably no because we can't change it > anyway. Refresh rate? Don't think its important. There's already some code dealing with color depth issues: devmode.dmBitsPerPel = (bpp >= 24) ? 32 : bpp; /* Stupid XVidMode cannot change bpp */ But there's another place where we deal with these issues differently: if(devmode.dmBitsPerPel == 24) devmode.dmBitsPerPel = 32; [...] ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL); if (ret != DISP_CHANGE_SUCCESSFUL) { if(devmode.dmDisplayFrequency != 0) { WARN("ChangeDisplaySettingsExW failed, trying without the refresh rate\n"); devmode.dmFields &= ~DM_DISPLAYFREQUENCY; devmode.dmDisplayFrequency = 0; ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL) != DISP_CHANGE_SUCCESSFUL; } if(ret != DISP_CHANGE_SUCCESSFUL) { return DDERR_INVALIDMODE; } } -- Francois Gouget fgouget@codeweavers.com From fgouget at codeweavers.com Fri Feb 2 09:24:47 2007 From: fgouget at codeweavers.com (Francois Gouget) Date: Sun Feb 4 14:34:21 2007 Subject: Detect screen resolution change errors In-Reply-To: References: <45BF43AB.8000108@codeweavers.com> Message-ID: <45C357BF.5080907@codeweavers.com> H. Verbeet wrote: > On 30/01/07, Francois Gouget wrote: >> I have attached the relevant patches. Does this look ok to the DirectX >> gurus? >> > At least the wined3d part looks ok to me, although we should probably > be cleaning up the GL context as well, there and in the other places > where we return. Is there some code that would show what cleaning the GL context entails? I have looked at the other exit paths of CreateAdditionalSwapChain() but the only relevant one only does stuff if object->frontBuffer != NULL which cannot be the case there. -- Francois Gouget fgouget@codeweavers.com From stefandoesinger at gmx.at Sun Feb 4 23:58:41 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sun Feb 4 23:59:23 2007 Subject: Detect screen resolution change errors In-Reply-To: <45C357BF.5080907@codeweavers.com> References: <45BF43AB.8000108@codeweavers.com> <45C357BF.5080907@codeweavers.com> Message-ID: <200702050658.47271.stefandoesinger@gmx.at> Am Freitag 02 Februar 2007 16:24 schrieb Francois Gouget: > Is there some code that would show what cleaning the GL context entails? > I have looked at the other exit paths of CreateAdditionalSwapChain() > but the only relevant one only does stuff if object->frontBuffer != NULL > which cannot be the case there. I have patches in my tree which change the context creation, and they also clean up properly in the case of an error(hopefully). I'll send them when things get going again after Alexandre's return. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070205/0eea773d/attachment.pgp From damjan.jov at gmail.com Mon Feb 5 00:42:23 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Mon Feb 5 00:42:27 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <001201c747a6$1d811310$0100a8c0@DMITRY> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> <001201c747a6$1d811310$0100a8c0@DMITRY> Message-ID: <9e89675b0702042242w41e2348fwf42f921f4c285f41@mail.gmail.com> On 2/3/07, Dmitry Timoshkov wrote: > "Damjan Jovanovic" wrote: > > > In wine's struct _stati64, st_size has an offset of 20 bytes from the > > beginning of the struct, unlike mingw's and Window's 24. This breaks > > Java 1.4.x pretty badly, it dies on startup complaining about a > > truncated class file (#2953). Using #include and #include > > around the struct didn't help, so a padding field was used > > instead. > > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > align the Size field help? > > #include > typedef struct _WIN32_STREAM_ID { > DWORD dwStreamId; > DWORD dwStreamAttributes; > LARGE_INTEGER DECLSPEC_ALIGN(8) Size; > DWORD dwStreamNameSize; > WCHAR cStreamName[ANYSIZE_ARRAY]; > } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; > #include That doesn't help. I heard somewhere GCC up to version 4.1.12 or so didn't align some things properly (I'm using 4.0.3). Since mingw aligns it properly with the same declaration as wine and it uses GCC 3.4.4, maybe it's a GCC bug. > > +static void test_stat( void ) > > +{ > > + int offset = offsetof(struct _stati64, st_size); > > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > > +} > > This should be a part of auto generated header tests. Have a look at > dlls/*/tests/generated.c files. Thanks. > -- > Dmitry. Damjan From dank at kegel.com Mon Feb 5 02:16:30 2007 From: dank at kegel.com (Dan Kegel) Date: Mon Feb 5 02:16:33 2007 Subject: comctl32 kibitzers wanted Message-ID: I and Lei Zhang, with some help from James Hawkins, are leading a group of 13 UCLA students who are writing conformance tests for comctl32. Each student picked one control, and is now busily writing getter/setter tests. In the coming few weeks we'll also try more interesting tests, like verifying that the right messages are sent in the right order. If you're interested in helping the students in any way (reviewing code before it hits wine-patches, offering suggestions on how to test tricky bits, or whatever), please let me know and I can add you to the project's mailing list. Thanks, Dan From truiken at gmail.com Mon Feb 5 02:44:11 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 5 02:44:15 2007 Subject: shell32: shlfileop tests: avoid buffer overflows for paths In-Reply-To: <45C663B7.8030609@zalewski.pl> References: <45C663B7.8030609@zalewski.pl> Message-ID: <22821af30702050044m4cabaf4dk5ed92260b648c4a6@mail.gmail.com> On 2/4/07, Miko?aj Zalewski wrote: > These buffers can contain multiple paths and set_curr_dir_path can make > the paths long resulting in a buffer overflow. > > From 36e05f3140e57bad2af790c56073799d23f7ef60 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= > Date: Thu, 25 Jan 2007 12:17:11 +0100 > Subject: [PATCH] shell32: shlfileop tests: avoid buffer overflows for paths > > --- > dlls/shell32/tests/shlfileop.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index b363c5e..23aaeba 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -329,8 +329,8 @@ static void test_delete(void) > static void test_rename(void) > { > SHFILEOPSTRUCTA shfo, shfo2; > - CHAR from[MAX_PATH]; > - CHAR to[MAX_PATH]; > + CHAR from[5*MAX_PATH]; > + CHAR to[5*MAX_PATH]; > DWORD retval; > > shfo.hwnd = NULL; > This is really hacky. If this is fixed, it needs to be fixed properly. -- James Hawkins From s0238762 at sms.ed.ac.uk Mon Feb 5 05:46:19 2007 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Mon Feb 5 05:46:36 2007 Subject: help in debugging Message-ID: <45C7190B.9050201@sms.ed.ac.uk> Hello Wine developers, I've decided to see what causes floAt's Mobile Agent[1] to fail with wine I checked the wine developers' cheatsheet to help me debug the application, but I'm lost. The application installs but with some error: "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll Unable to register the DLL/OCX: LoadLibrary failed; code 126 Module not found." I click "ignore" and the installation continues. When I try to execute the installed binary "MobileAgent.exe" it fails. I invoke it like this: WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe no error messages are produce by the app itself. on wine's debug log I see the following, just before winedbg starts: 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade flags=1 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:__regs_RtlUnwind code=eedfade flags=3 trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade flags=3 trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade flags=1 trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade flags=1 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 (thread 0009), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" this is not the first "trace:seh". Relatively early in the call stack there is this: 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=ffffffff trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 edx=0000ffff esi=00000000 edi=ffffffff trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010206 trace:seh:call_stack_handlers calling handler at 0x602b5540 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 ffffffff (invalid)) ret=6033e95f which looks suspicious to me. Am I on the right track? Unfortunately I'm not familiar with windows API or wine's underlying architecture. I need some guidance please :) I'm an experienced C/C++ programmer. thanks -Ioannis [1] http://fma.sourceforge.net/index2.htm From damjan.jov at gmail.com Mon Feb 5 06:07:17 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Mon Feb 5 06:07:26 2007 Subject: help in debugging In-Reply-To: <45C7190B.9050201@sms.ed.ac.uk> References: <45C7190B.9050201@sms.ed.ac.uk> Message-ID: <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> On 2/5/07, Ioannis Nousias wrote: > Hello Wine developers, > > I've decided to see what causes floAt's Mobile Agent[1] to fail with wine > > I checked the wine developers' cheatsheet to help me debug the > application, but I'm lost. > > The application installs but with some error: > "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll > Unable to register the DLL/OCX: LoadLibrary failed; code 126 > Module not found." Can you try typing $ regsvr32 BramusICQ.dll manually? You'll have to do it from the directory it's in. > I click "ignore" and the installation continues. When I try to execute > the installed binary "MobileAgent.exe" it fails. > > I invoke it like this: > > WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe > > no error messages are produce by the app itself. > > on wine's debug log I see the following, just before winedbg starts: > > 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade > flags=1 > 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c > 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:__regs_RtlUnwind code=eedfade flags=3 > trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade > flags=3 > trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 > 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c > 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade > flags=1 > trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 > trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade > flags=1 > 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc > wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 > (thread 0009), starting debugger... > trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" > > this is not the first "trace:seh". Relatively early in the call stack > there is this: > > 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b > trace:seh:raise_exception info[0]=00000000 > trace:seh:raise_exception info[1]=ffffffff > trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 > edx=0000ffff esi=00000000 edi=ffffffff > trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b > es=007b fs=0033 gs=003b flags=00010206 > trace:seh:call_stack_handlers calling handler at 0x602b5540 > code=c0000005 flags=0 > trace:seh:__regs_RtlUnwind code=c0000005 flags=2 > trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 > flags=2 > trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 > ffffffff (invalid)) ret=6033e95f > > which looks suspicious to me. > > Am I on the right track? Unfortunately I'm not familiar with windows API > or wine's underlying architecture. I need some guidance please :) I'm an > experienced C/C++ programmer. > > thanks > > -Ioannis > > > > > > > > > > > > [1] http://fma.sourceforge.net/index2.htm > > > From s0238762 at sms.ed.ac.uk Mon Feb 5 06:49:27 2007 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Mon Feb 5 06:49:46 2007 Subject: help in debugging In-Reply-To: <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> References: <45C7190B.9050201@sms.ed.ac.uk> <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> Message-ID: <45C727D7.8050601@sms.ed.ac.uk> Damjan Jovanovic wrote: > On 2/5/07, Ioannis Nousias wrote: >> Hello Wine developers, >> >> I've decided to see what causes floAt's Mobile Agent[1] to fail with >> wine >> >> I checked the wine developers' cheatsheet to help me debug the >> application, but I'm lost. >> >> The application installs but with some error: >> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >> Module not found." > > Can you try typing > $ regsvr32 BramusICQ.dll > manually? You'll have to do it from the directory it's in. > sure. $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll err:module:import_dll Library MSVBVM60.DLL (which is needed by L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found Failed to load DLL BramusICQ.dll it's seems I need this MSVBVM60.DLL. It's nowhere in the application's installation or wine's systems folders. >> I click "ignore" and the installation continues. When I try to execute >> the installed binary "MobileAgent.exe" it fails. >> >> I invoke it like this: >> >> WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe >> >> no error messages are produce by the app itself. >> >> on wine's debug log I see the following, just before winedbg starts: >> >> 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 >> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade >> flags=1 >> 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) >> ret=0040427c >> 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >> flags= >> 00200246 >> trace:seh:__regs_RtlUnwind code=eedfade flags=3 >> trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade >> flags=3 >> trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 >> 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c >> 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >> flags= >> 00200246 >> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade >> flags=1 >> trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade >> flags=1 >> 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc >> wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 >> (thread 0009), starting debugger... >> trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" >> >> this is not the first "trace:seh". Relatively early in the call stack >> there is this: >> >> 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b >> trace:seh:raise_exception info[0]=00000000 >> trace:seh:raise_exception info[1]=ffffffff >> trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 >> edx=0000ffff esi=00000000 edi=ffffffff >> trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b >> es=007b fs=0033 gs=003b flags=00010206 >> trace:seh:call_stack_handlers calling handler at 0x602b5540 >> code=c0000005 flags=0 >> trace:seh:__regs_RtlUnwind code=c0000005 flags=2 >> trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 >> flags=2 >> trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 >> ffffffff (invalid)) ret=6033e95f >> >> which looks suspicious to me. >> >> Am I on the right track? Unfortunately I'm not familiar with windows API >> or wine's underlying architecture. I need some guidance please :) I'm an >> experienced C/C++ programmer. >> >> thanks >> >> -Ioannis >> >> >> >> >> >> >> >> >> >> >> >> [1] http://fma.sourceforge.net/index2.htm >> >> >> From mikolaj at zalewski.pl Mon Feb 5 07:12:13 2007 From: mikolaj at zalewski.pl (=?ISO-8859-2?Q?Miko=B3aj_Zalewski?=) Date: Mon Feb 5 07:12:16 2007 Subject: shell32: shlfileop tests: avoid buffer overflows for paths In-Reply-To: <22821af30702050044m4cabaf4dk5ed92260b648c4a6@mail.gmail.com> References: <45C663B7.8030609@zalewski.pl> <22821af30702050044m4cabaf4dk5ed92260b648c4a6@mail.gmail.com> Message-ID: <45C72D2D.20206@zalewski.pl> >> @@ -329,8 +329,8 @@ static void test_delete(void) >> static void test_rename(void) >> { >> SHFILEOPSTRUCTA shfo, shfo2; >> - CHAR from[MAX_PATH]; >> - CHAR to[MAX_PATH]; >> + CHAR from[5*MAX_PATH]; >> + CHAR to[5*MAX_PATH]; >> DWORD retval; >> >> shfo.hwnd = NULL; >> > > This is really hacky. If this is fixed, it needs to be fixed properly. > I thought this is enough - we never put more that three paths in the buffer and tester probably won't have paths longer than MAX_PATH as they are not supported by the shell. What do you mean by a proper fix - some overflow checking in set_curr_dir_path and skipping the rest of tests in such a case? Mikolaj Zalewski From kuba at mareimbrium.org Mon Feb 5 08:29:33 2007 From: kuba at mareimbrium.org (Kuba Ober) Date: Mon Feb 5 08:29:38 2007 Subject: help in debugging In-Reply-To: <45C727D7.8050601@sms.ed.ac.uk> References: <45C7190B.9050201@sms.ed.ac.uk> <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> <45C727D7.8050601@sms.ed.ac.uk> Message-ID: <200702050929.33687.kuba@mareimbrium.org> > >> The application installs but with some error: > >> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll > >> Unable to register the DLL/OCX: LoadLibrary failed; code 126 > >> Module not found." > > > > Can you try typing > > $ regsvr32 BramusICQ.dll > > manually? You'll have to do it from the directory it's in. > > sure. > > $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll > err:module:import_dll Library MSVBVM60.DLL (which is needed by > L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found > Failed to load DLL BramusICQ.dll > > it's seems I need this MSVBVM60.DLL. It's nowhere in the application's > installation or wine's systems folders. Er, google for it? The first hit is a free download of that dll. The application's installer is probably broken in assuming that such a dll will exist on all windows systems (it probably doesn't exist on a clean win95, at least). Cheers, Kuba From dimi at lattica.com Mon Feb 5 08:59:44 2007 From: dimi at lattica.com (Dimi Paun) Date: Mon Feb 5 08:59:49 2007 Subject: comctl32 kibitzers wanted In-Reply-To: References: Message-ID: <2661.207.245.37.34.1170687584.squirrel@lattica.com> On Mon, February 5, 2007 03:16, Dan Kegel wrote: > I and Lei Zhang, with some help from James Hawkins, > are leading a group of 13 UCLA students who are > writing conformance tests for comctl32. Brilliant! > Each student picked one control, and is now busily writing > getter/setter tests. In the coming few weeks we'll > also try more interesting tests, like verifying that > the right messages are sent in the right order. > If you're interested in helping the students in any way > (reviewing code before it hits wine-patches, offering > suggestions on how to test tricky bits, or whatever), > please let me know and I can add you to the project's > mailing list. Sure, please add me to the list. I've had my share of work in that area (comboex, listview, progressbar, updown, etc.) and I might be able to help. -- Dimi Paun Lattica, Inc. From s0238762 at sms.ed.ac.uk Mon Feb 5 09:11:53 2007 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Mon Feb 5 09:12:00 2007 Subject: help in debugging In-Reply-To: <200702050929.33687.kuba@mareimbrium.org> References: <45C7190B.9050201@sms.ed.ac.uk> <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> <45C727D7.8050601@sms.ed.ac.uk> <200702050929.33687.kuba@mareimbrium.org> Message-ID: <45C74939.4080309@sms.ed.ac.uk> Kuba Ober wrote: >>>> The application installs but with some error: >>>> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >>>> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >>>> Module not found." >>>> >>> Can you try typing >>> $ regsvr32 BramusICQ.dll >>> manually? You'll have to do it from the directory it's in. >>> >> sure. >> >> $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll >> err:module:import_dll Library MSVBVM60.DLL (which is needed by >> L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found >> Failed to load DLL BramusICQ.dll >> >> it's seems I need this MSVBVM60.DLL. It's nowhere in the application's >> installation or wine's systems folders. >> > > Er, google for it? The first hit is a free download of that dll. The > application's installer is probably broken in assuming that such a dll will > exist on all windows systems (it probably doesn't exist on a clean win95, at > least). > :) yes, of course. done that already. The dll registers fine. unfortunately, that was not the problem. thanks. -Ioannis From mitchell.mebane at gmail.com Mon Feb 5 10:19:49 2007 From: mitchell.mebane at gmail.com (Mitchell Mebane) Date: Mon Feb 5 10:19:58 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <200702021645.23102.stefandoesinger@gmx.at> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <200702021645.23102.stefandoesinger@gmx.at> Message-ID: <45C75925.9010501@gmail.com> Stefan D?singer wrote: > Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > >> Profiling with oprofile (GDI session) shows that most of the time is used >> in the game (I suppose it's the "anon" from wine-preload), next most time >> consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be >> doing the conversion. >> > It seems that you have a game that has problems with the gdi engine(or lack > thereof): http://wiki.winehq.org/DIBEngine > > http://bugs.winehq.org/show_bug.cgi?id=421 > > ------------------------------------------------------------------------ > > > How much work would this be? I know nothing about Windows or X11 programming, but is it something that I might be able to study up on and propose for a Summer of Code project? --mmebane -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070205/ea133754/attachment.htm From s0238762 at sms.ed.ac.uk Mon Feb 5 11:33:12 2007 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Mon Feb 5 11:33:58 2007 Subject: help in debugging In-Reply-To: <45C727D7.8050601@sms.ed.ac.uk> References: <45C7190B.9050201@sms.ed.ac.uk> <9e89675b0702050407l46ef178dqd17bd61a696f211e@mail.gmail.com> <45C727D7.8050601@sms.ed.ac.uk> Message-ID: <45C76A58.9010405@sms.ed.ac.uk> forgot to mention that I've added a bug report for this few weeks ago: http://bugs.winehq.org/show_bug.cgi?id=7227 and an entry in wine's Application Database: http://appdb.winehq.org/appview.php?iAppId=2922 regards Ioannis > Damjan Jovanovic wrote: >> On 2/5/07, Ioannis Nousias wrote: >>> Hello Wine developers, >>> >>> I've decided to see what causes floAt's Mobile Agent[1] to fail with >>> wine >>> >>> I checked the wine developers' cheatsheet to help me debug the >>> application, but I'm lost. >>> >>> The application installs but with some error: >>> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >>> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >>> Module not found." >> >> Can you try typing >> $ regsvr32 BramusICQ.dll >> manually? You'll have to do it from the directory it's in. >> > sure. > > $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll > err:module:import_dll Library MSVBVM60.DLL (which is needed by > L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found > Failed to load DLL BramusICQ.dll > > it's seems I need this MSVBVM60.DLL. It's nowhere in the application's > installation or wine's systems folders. > >>> I click "ignore" and the installation continues. When I try to execute >>> the installed binary "MobileAgent.exe" it fails. >>> >>> I invoke it like this: >>> >>> WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe >>> >>> no error messages are produce by the app itself. >>> >>> on wine's debug log I see the following, just before winedbg starts: >>> >>> 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 >>> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade >>> flags=1 >>> 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) >>> ret=0040427c >>> 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >>> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >>> flags= >>> 00200246 >>> trace:seh:__regs_RtlUnwind code=eedfade flags=3 >>> trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade >>> flags=3 >>> trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 >>> 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c >>> 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >>> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >>> flags= >>> 00200246 >>> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade >>> flags=1 >>> trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade >>> flags=1 >>> 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc >>> wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 >>> (thread 0009), starting debugger... >>> trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" >>> >>> this is not the first "trace:seh". Relatively early in the call stack >>> there is this: >>> >>> 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b >>> trace:seh:raise_exception info[0]=00000000 >>> trace:seh:raise_exception info[1]=ffffffff >>> trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 >>> edx=0000ffff esi=00000000 edi=ffffffff >>> trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b >>> es=007b fs=0033 gs=003b flags=00010206 >>> trace:seh:call_stack_handlers calling handler at 0x602b5540 >>> code=c0000005 flags=0 >>> trace:seh:__regs_RtlUnwind code=c0000005 flags=2 >>> trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 >>> flags=2 >>> trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 >>> ffffffff (invalid)) ret=6033e95f >>> >>> which looks suspicious to me. >>> >>> Am I on the right track? Unfortunately I'm not familiar with windows >>> API >>> or wine's underlying architecture. I need some guidance please :) >>> I'm an >>> experienced C/C++ programmer. >>> >>> thanks >>> >>> -Ioannis >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [1] http://fma.sourceforge.net/index2.htm >>> >>> >>> > > > From fgouget at free.fr Mon Feb 5 12:48:31 2007 From: fgouget at free.fr (Francois Gouget) Date: Mon Feb 5 12:48:48 2007 Subject: Bugzilla: Adding a 'patch' keyword In-Reply-To: References: Message-ID: On Tue, 30 Jan 2007, Francois Gouget wrote: [...] > But it would be nice if there was an easy way to find bugs that have a > patch, even, and maybe especially, if it is incorrect. This would make > it easier for interested parties to survey what potential fixes are > languishing in Bugzilla and push them to wine-devel or wine-patches. I see everyone agrees :-/ So could someone add the 'patch' keyword? -- Francois Gouget http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages. From julliard at winehq.org Mon Feb 5 13:29:21 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 5 13:29:35 2007 Subject: Synchronize code page 20127 table with Windows one In-Reply-To: <001201c74603$8e00c5d0$0100a8c0@DMITRY> (Dmitry Timoshkov's message of "Thu\, 1 Feb 2007 21\:18\:15 +0800") References: <45C1DE27.6010804@codeweavers.com> <001201c74603$8e00c5d0$0100a8c0@DMITRY> Message-ID: <874pq0iesu.fsf@wine.dyndns.org> "Dmitry Timoshkov" writes: > That's not really possible due to a confusing license accompanying the unicode.org > mappings, and a policy (until at least now) to not patch unicode.org provided data. > Otherwise we have to patch the unicode collation table (I had a patch for it somewhere) > as well as some other code page tables (problem with cp1251 table comes to mind as was > reported recently). Distributing patched unicode.org files is not something we want to do, but modifying the mapping tables in cpmap.pl after they are loaded is acceptable, we already have a couple of cases where we do that. -- Alexandre Julliard julliard@winehq.org From damjan.jov at gmail.com Mon Feb 5 15:06:31 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Mon Feb 5 15:06:50 2007 Subject: [msvcrt] properly align struct _stati64's st_size In-Reply-To: <9e89675b0702042242w41e2348fwf42f921f4c285f41@mail.gmail.com> References: <9e89675b0702030247t17e67bd6p877084e0a6d77528@mail.gmail.com> <001201c747a6$1d811310$0100a8c0@DMITRY> <9e89675b0702042242w41e2348fwf42f921f4c285f41@mail.gmail.com> Message-ID: <9e89675b0702051306u3ada27eh380fd4ddb0e4e42d@mail.gmail.com> On 2/5/07, Damjan Jovanovic wrote: > On 2/3/07, Dmitry Timoshkov wrote: > > "Damjan Jovanovic" wrote: > > > > > In wine's struct _stati64, st_size has an offset of 20 bytes from the > > > beginning of the struct, unlike mingw's and Window's 24. This breaks > > > Java 1.4.x pretty badly, it dies on startup complaining about a > > > truncated class file (#2953). Using #include and #include > > > around the struct didn't help, so a padding field was used > > > instead. > > > > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > > align the Size field help? > > > > #include > > typedef struct _WIN32_STREAM_ID { > > DWORD dwStreamId; > > DWORD dwStreamAttributes; > > LARGE_INTEGER DECLSPEC_ALIGN(8) Size; > > DWORD dwStreamNameSize; > > WCHAR cStreamName[ANYSIZE_ARRAY]; > > } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; > > #include > > That doesn't help. Sorry, that (as in DECLSPEC_ALIGN(8)) DOES work, I didn't see it before. I'll send a patch that does that instead of using a padding field. > > Dmitry. > > Damjan Damjan From flexo at holycrap.org Mon Feb 5 15:29:23 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Mon Feb 5 15:23:16 2007 Subject: [PATCH] coverity: CID35: fixed wrong condition Message-ID: <45C7A1B3.9040203@holycrap.org> Marcus Meissner wrote: > - if(nRelPos>=0) { /* if this or preceding row */ > + if(nRelPos<=0) { /* if this or preceding row */ > while(nRelPos<=0) { Shouldn't that become a "do { ... } while()" then? From thestig at google.com Mon Feb 5 15:47:39 2007 From: thestig at google.com (Lei Zhang) Date: Mon Feb 5 15:48:02 2007 Subject: [Bug 6689] Created links do not reflect WINEPREFIX used In-Reply-To: <200701300016.28713.alex@thehandofagony.com> References: <45BE33D7.4090909@dbservice.com> <200701291458.23201.kuba@mareimbrium.org> <200701300016.28713.alex@thehandofagony.com> Message-ID: <558b2f5c0702051347o2172a5e1q47eb1bd4c46b21e5@mail.gmail.com> On 1/29/07, Alexander Nicolaysen S?rnes wrote: > Mandag 29 januar 2007 20:58, skrev Kuba Ober: > > On Monday 29 January 2007 12:50, Tomas Carnecky wrote: > > > Lei Zhang wrote: > > > > Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar > > > > worked in KDE. In Gnome, it works if "run from the terminal" is set. > > > > > > > > Unfortunately the Freedesktop spec for desktop entries does not > > > > specify a way to add environment variables. So yes, it looks like > > > > we'll need a wrapper script, or perhaps add a --prefix option to Wine? > > > > > > or change the exec line to: > > > /bin/sh -i -c "WINEPREFIX=foo wine" > > > > Instead, wouldn't > > /bin/sh -i -c "WINEPREFIX=foo exec wine" > > also properly dispose of the now useless copy of the shell? > > > > You don't have to start a new shell if you use > > env WINEPREFIX=foo wine > > > Regards, > > Alexander N. S?rnes > > > Cheers, Kuba > > > This sounds like the best solution so far. If nobody else has any objections, I'll test it out in Gnome and KDE, and then send in a patch. From lich at star.math.spbu.ru Mon Feb 5 12:30:34 2007 From: lich at star.math.spbu.ru (Kirill K. Smirnov) Date: Mon Feb 5 15:57:13 2007 Subject: [try3]: user32/tests: add tests for WM_SETICON - what's wrong? Message-ID: <200702052130.34220.lich@star.math.spbu.ru> Hi, I've asked before: What's wrong with them? Maybe, unnecessary PeekMessage in tests??? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Please, answer! Do not ignore! -- Kirill From jwhite at codeweavers.com Mon Feb 5 16:26:04 2007 From: jwhite at codeweavers.com (Jeremy White) Date: Mon Feb 5 16:26:15 2007 Subject: It's that time again - time to start thinking about WineConf 2007! Message-ID: <45C7AEFC.1000404@codeweavers.com> So we can ask, once again: when will 1.0 ship!?!?! I'd invite anyone with an interest in attending to subscribe to the Wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf I think an approach that makes sense is for us to discuss options as to where to hold it this year on that list, and then present either a consensus or choices back to the wine-devel list once we're done. So please come join us, particularly if you have a suggestion or preference for where it should be held! Cheers, Jeremy p.s. I think Wine will go 1.0 in the same year that is the year of Linux on the Desktop . From xixsimplicityxix at gmail.com Mon Feb 5 16:45:51 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Mon Feb 5 16:46:04 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <45C7AEFC.1000404@codeweavers.com> References: <45C7AEFC.1000404@codeweavers.com> Message-ID: <78a7dad00702051445j15c7f3edted3ade7d4a648fb6@mail.gmail.com> You mean once wine 1.0 is shipped that will bring about the year of linux on the desktop. =) On 2/5/07, Jeremy White wrote: > > So we can ask, once again: when will 1.0 ship!?!?! > > I'd invite anyone with an interest in attending to subscribe > to the Wineconf mailing list: > > http://www.winehq.org/mailman/listinfo/wineconf > > I think an approach that makes sense is for us to discuss > options as to where to hold it this year on that list, and > then present either a consensus or choices back to the wine-devel list > once we're done. > > So please come join us, particularly if you have a suggestion > or preference for where it should be held! > > Cheers, > > Jeremy > > p.s. I think Wine will go 1.0 in the same year that is the > year of Linux on the Desktop . > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070205/b476e135/attachment.htm From fpga at pacbell.net Mon Feb 5 16:55:25 2007 From: fpga at pacbell.net (Duane Clark) Date: Mon Feb 5 16:56:49 2007 Subject: Window focus testing Message-ID: <45C7B5DD.8050907@pacbell.net> Is it possible to do window focus testing in Wine conformance tests? Or does the windows not being mapped mean that this testing cannot be done? Or maybe I am doing something completely wrong; which is likely ;) I am specifically trying to test window focus in this bug: http://bugs.winehq.org/show_bug.cgi?id=7280 As mentioned in the bug, I turned the treeview conformance test into a standalone test with a mapped window, and added testing that does show focus behavior. But so far I have not been able to get it to give good results in a Wine conformance test. From kai.blin at gmail.com Mon Feb 5 18:05:43 2007 From: kai.blin at gmail.com (Kai Blin) Date: Mon Feb 5 18:07:24 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <45C7AEFC.1000404@codeweavers.com> References: <45C7AEFC.1000404@codeweavers.com> Message-ID: <200702060106.02145.kai.blin@gmail.com> On Monday 05 February 2007 23:26, Jeremy White wrote: > So we can ask, once again: when will 1.0 ship!?!?! [...] > p.s. I think Wine will go 1.0 in the same year that is the > year of Linux on the Desktop . Oooh, can we make "Duke Nukem Forever runs" a 1.0 release requirement? Then we could bundle Wine 1.0 with DNF. ;) Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/3f66c2fd/attachment.pgp From twickline at gmail.com Mon Feb 5 19:16:24 2007 From: twickline at gmail.com (Tom Wickline) Date: Mon Feb 5 19:16:33 2007 Subject: Donation for your work on Direct 3D In-Reply-To: References: <45C0D9C3.2050109@czela.net> <200701311912.32935.stefan@codeweavers.com> Message-ID: <53e3a9930702051716x128d6a56r423b985da6418389@mail.gmail.com> On 2/1/07, H. Verbeet wrote: > > > Send it to the Wine Party Fund, I'd say. Here is the link: http://www.winehq.org/site/contributing#wpf Cheers, Tom > > Henri > > > From mk144210 at bcm.tmc.edu Mon Feb 5 20:33:15 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 5 20:33:52 2007 Subject: msi patch: Is this too hacky? Message-ID: <1170729195.8463.4.camel@misha-laptop> Hi, I submitted the following patch to wine-patches but was thinking about it some more. The problem is that you have the following UI levels and flags: INSTALLUILEVEL_NOCHANGE = 0, INSTALLUILEVEL_DEFAULT = 1, INSTALLUILEVEL_NONE = 2, INSTALLUILEVEL_BASIC = 3, INSTALLUILEVEL_REDUCED = 4, INSTALLUILEVEL_FULL = 5, INSTALLUILEVEL_HIDECANCEL = 0x20, INSTALLUILEVEL_PROGRESSONLY = 0x40, INSTALLUILEVEL_ENDDIALOG = 0x80, INSTALLUILEVEL_SOURCERESONLY = 0x100 and the code to check for the level was: if ( msi_get_property_int(package, szUILevel, 0) >= INSTALLUILEVEL_REDUCED) but the problem is that if any of the flags are set, then immediately this would assume full UI install even though this is not the case for some installers (see bug #6992). I proposed this change: if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >= INSTALLUILEVEL_REDUCED ) It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both of which are greater than or equal to four. However, if for some reason these UI levels were to change in the future, or if someone decided to further modify this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So is this too hacky? Is there a simple, better way to do this? Thanks Misha -------------- next part -------------- From 0e3caffc0ca5e5617ee6d494d28a2c180227c09a Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 4 Feb 2007 01:07:15 -0600 Subject: msi: InstallPackage check for UI level must not disregard INSTALLUILEVEL flags. --- dlls/msi/action.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/msi/action.c b/dlls/msi/action.c index 0c8ac79..89bf1dd 100644 --- a/dlls/msi/action.c +++ b/dlls/msi/action.c @@ -642,7 +642,7 @@ UINT MSI_InstallPackage( MSIPACKAGE *pac msi_apply_transforms( package ); msi_apply_patches( package ); - if ( msi_get_property_int(package, szUILevel, 0) >= INSTALLUILEVEL_REDUCED ) + if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >= INSTALLUILEVEL_REDUCED ) { package->script->InWhatSequence |= SEQUENCE_UI; rc = ACTION_ProcessUISequence(package); -- 1.4.1 From twickline at gmail.com Mon Feb 5 21:03:45 2007 From: twickline at gmail.com (Tom Wickline) Date: Mon Feb 5 21:03:58 2007 Subject: Dead links In-Reply-To: <558b2f5c0701190948h76c305f4xe2de2b608e0b091a@mail.gmail.com> References: <53e3a9930701190334s30401a53u1a451ab6d65964e@mail.gmail.com> <558b2f5c0701190948h76c305f4xe2de2b608e0b091a@mail.gmail.com> Message-ID: <53e3a9930702051903v4c2e94ccke8cea28c8bb3aeb@mail.gmail.com> Hello, It's kind of bad when you intend on fixing broken URLs and then send one :) I have that page linked on my wiki page (and have since fixed) and was in a hurry and sent the old broke link. If all goes as planed I should have some free time starting next week to work on this. Cheers, Tom On 1/19/07, Lei Zhang wrote: > I get the 403 error as well, most of time from pages under hypermail/ > Google indexed. I don't know when the mailing list archives changed, > but the page is still viewable here: > http://winehq.org/pipermail/wine-devel/2003-June/017893.html > > On 1/19/07, Francois Gouget wrote: > > On Fri, 19 Jan 2007, Tom Wickline wrote: > > [...] > > > http://www.winehq.com/hypermail/wine-devel/2003/06/0325.html > > > > Does this URL work for you? > > It gives me a 403 Forbidden error here. From trent.waddington at gmail.com Mon Feb 5 21:13:47 2007 From: trent.waddington at gmail.com (Trent Waddington) Date: Mon Feb 5 21:14:04 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. Message-ID: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> These changes make the Carbon Poker (www.carbonpoker.com) client work. Run the Carbon Poker installer; then Run c:/windows/system32/Macromed/Flash/GetFlash.exe; then Run c:/windows/CarbonPoker/Poker.exe Screenshot: http://rtfm.insomnia.org/~qg/CarbonPoker-Ubuntu-wine.png If someone would like to implement PKCS7 support in crypt32, this patch could be much cleaner. --- ChangeLog | 15 +++++++++++++++ dlls/crypt32/cert.c | 16 ++++++++++++++++ dlls/crypt32/crypt32.spec | 2 +- dlls/crypt32/main.c | 12 +++++++++++- dlls/crypt32/store.c | 4 ++++ dlls/usp10/usp10.c | 33 +++++++++++++++++++++++++++++++++ dlls/usp10/usp10.spec | 2 +- dlls/wininet/http.c | 4 ++-- 8 files changed, 83 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 658036c..297fb08 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2007-02-06 Trent Waddington + + * dlls/crypt32/cert.c: + dlls/crypt32/main.c: + dlls/crypt32/store.c: + dlls/crypt32/crypt32.spec: + crypt32: Hacks to make Macromedia's GetFlash.exe not complain about the lack of PKCS7 support. + + * dlls/usp10/usp10.c: + dlls/usp10/usp10.spec: + usp10: Implemented ScriptGetLogicalWidths. + + * dlls/wininet/http.c: + wininet: Implement a feature of HttpOpenRequestA where lpszAcceptTypes can be terminated with an empty string instead of a NULL. + 2007-01-24 Vitaliy Margolen * server/token.c: diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c index b39c3ca..e3ed7e0 100644 --- a/dlls/crypt32/cert.c +++ b/dlls/crypt32/cert.c @@ -130,6 +130,10 @@ BOOL WINAPI CertFreeCertificateContext(PCCERT_CONTEXT pCertContext) { TRACE("(%p)\n", pCertContext); + // HACK for GetFlash.exe + if (pCertContext == 0xdeadbeef) + return TRUE; + if (pCertContext) Context_Release((void *)pCertContext, sizeof(CERT_CONTEXT), CertDataContext_Free); @@ -921,6 +925,12 @@ PCCERT_CONTEXT WINAPI CertFindCertificateInStore(HCERTSTORE hCertStore, TRACE("(%p, %d, %d, %d, %p, %p)\n", hCertStore, dwCertEncodingType, dwFlags, dwType, pvPara, pPrevCertContext); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) { + ret = 0xdeadbeef; + return ret; + } + switch (dwType >> CERT_COMPARE_SHIFT) { case CERT_COMPARE_ANY: @@ -987,6 +997,12 @@ BOOL WINAPI CertVerifySubjectCertificateContext(PCCERT_CONTEXT pSubject, static const DWORD supportedFlags = CERT_STORE_REVOCATION_FLAG | CERT_STORE_SIGNATURE_FLAG | CERT_STORE_TIME_VALIDITY_FLAG; + // HACK for GetFlash.exe + if (pSubject == 0xdeadbeef || pIssuer == 0xdeadbeef) { + *pdwFlags = 0; + return TRUE; + } + if (*pdwFlags & ~supportedFlags) { SetLastError(E_INVALIDARG); diff --git a/dlls/crypt32/crypt32.spec b/dlls/crypt32/crypt32.spec index 7ee23f4..705fb8f 100644 --- a/dlls/crypt32/crypt32.spec +++ b/dlls/crypt32/crypt32.spec @@ -118,7 +118,7 @@ @ stub CryptGetAsyncParam @ stdcall CryptGetDefaultOIDDllList(long long ptr ptr) @ stdcall CryptGetDefaultOIDFunctionAddress(long long wstr long ptr ptr) -@ stub CryptGetMessageCertificates +@ stdcall CryptGetMessageCertificates(long long long ptr long) @ stub CryptGetMessageSignerCount @ stdcall CryptGetOIDFunctionAddress(long long str long ptr ptr) @ stdcall CryptGetOIDFunctionValue(long str str wstr ptr ptr ptr) diff --git a/dlls/crypt32/main.c b/dlls/crypt32/main.c index dd9e1fb..80567ab 100644 --- a/dlls/crypt32/main.c +++ b/dlls/crypt32/main.c @@ -238,5 +238,15 @@ BOOL WINAPI CryptVerifyMessageSignature(PCRYPT_VERIFY_MESSAGE_PARA pVerifyPara, FIXME("stub: %p, %d, %p, %d, %p, %p, %p\n", pVerifyPara, dwSignerIndex, pbSignedBlob, cbSignedBlob, pbDecoded, pcbDecoded, ppSignerCert); - return FALSE; + return TRUE; +} + +HCERTSTORE WINAPI CryptGetMessageCertificates(DWORD dwMsgAndCertEncodingType, + HCRYPTPROV hCryptProv, DWORD dwFlags, const BYTE* pbSignedBlob, + DWORD cbSignedBlob) +{ + FIXME("stub: %d, %p, %d, %p, %d\n", + dwMsgAndCertEncodingType, hCryptProv, dwFlags, pbSignedBlob, + cbSignedBlob); + return 0xdeadbeef; // HACK for GetFlash.exe } diff --git a/dlls/crypt32/store.c b/dlls/crypt32/store.c index 8c8cda5..c82fcbc 100644 --- a/dlls/crypt32/store.c +++ b/dlls/crypt32/store.c @@ -2431,6 +2431,10 @@ BOOL WINAPI CertCloseStore(HCERTSTORE hCertStore, DWORD dwFlags) TRACE("(%p, %08x)\n", hCertStore, dwFlags); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) + return TRUE; + if( ! hCertStore ) return TRUE; diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c index c3b0a17..6f860e0 100644 --- a/dlls/usp10/usp10.c +++ b/dlls/usp10/usp10.c @@ -1553,6 +1553,39 @@ HRESULT WINAPI ScriptStringGetLogicalWidths(SCRIPT_STRING_ANALYSIS ssa, int *piD } /*********************************************************************** + * ScriptGetLogicalWidths (USP10.@) + * + * Returns logical widths from an analysis. + * + * PARAMS + * psa [I] analysis. + * cChars [I] count of logical code points in the run. + * cGlyphs [I] count of glyphs in the run. + * piGlyphWidth [I] array of glyph advance widths. + * pwLogClust [I] array of logical clusters. + * psva [I] visual attributes. + * piDx [O] logical widths returned. + * + * RETURNS + * Success: S_OK + * Failure: a non-zero HRESULT. + */ +HRESULT WINAPI ScriptGetLogicalWidths(const SCRIPT_ANALYSIS *psa, int cChars, + int cGlyphs, const int *piGlyphWidth, const WORD *pwLogClust, + const SCRIPT_VISATTR *psva, int *piDx) +{ + int i; + + TRACE("%p, %d, %d, %p %p, %p, %p\n", psa, cChars, cGlyphs, piGlyphWidth, pwLogClust, psva, piDx); + + for (i = 0; i < cGlyphs; i++) + { + piDx[i] = piGlyphWidth[i]; + } + return S_OK; +} + +/*********************************************************************** * ScriptStringValidate (USP10.@) * * Validate a string analysis. diff --git a/dlls/usp10/usp10.spec b/dlls/usp10/usp10.spec index df07f43..ac1506e 100644 --- a/dlls/usp10/usp10.spec +++ b/dlls/usp10/usp10.spec @@ -8,7 +8,7 @@ @ stdcall ScriptGetCMap(ptr ptr ptr long long ptr) @ stdcall ScriptGetFontProperties(long ptr ptr) @ stdcall ScriptGetGlyphABCWidth(ptr ptr long ptr) -@ stub ScriptGetLogicalWidths +@ stdcall ScriptGetLogicalWidths(ptr long long ptr ptr ptr ptr) @ stdcall ScriptGetProperties(ptr long) @ stdcall ScriptIsComplex(wstr long long) @ stdcall ScriptItemize(wstr long long ptr ptr ptr ptr) diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index 8a34749..379b03e 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -803,11 +803,11 @@ HINTERNET WINAPI HttpOpenRequestA(HINTERNET hHttpSession, if (lpszAcceptTypes) { /* find out how many there are */ - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) acceptTypesCount++; szAcceptTypes = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR *) * (acceptTypesCount+1)); acceptTypesCount = 0; - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) { len = MultiByteToWideChar(CP_ACP, 0, lpszAcceptTypes[acceptTypesCount], -1, NULL, 0 ); -- 1.4.4.3 From dmitry at codeweavers.com Mon Feb 5 22:08:21 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 5 22:08:24 2007 Subject: Window focus testing References: <45C7B5DD.8050907@pacbell.net> Message-ID: <00fc01c749a4$7439fcd0$0100a8c0@DMITRY> "Duane Clark" wrote: > Is it possible to do window focus testing in Wine conformance tests? Or > does the windows not being mapped mean that this testing cannot be done? > Or maybe I am doing something completely wrong; which is likely ;) Have a look at dlls/user32/tests/win.c,test_SetFocus(). -- Dmitry. From dmitry at codeweavers.com Mon Feb 5 22:15:06 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 5 22:15:09 2007 Subject: msi patch: Is this too hacky? References: <1170729195.8463.4.camel@misha-laptop> Message-ID: <011701c749a5$65cfb0d0$0100a8c0@DMITRY> "Misha Koshelev" wrote: > Hi, I submitted the following patch to wine-patches but was thinking > about it some more. The problem is that you have the following UI levels > and flags: > INSTALLUILEVEL_NOCHANGE = 0, > INSTALLUILEVEL_DEFAULT = 1, > INSTALLUILEVEL_NONE = 2, > INSTALLUILEVEL_BASIC = 3, > INSTALLUILEVEL_REDUCED = 4, > INSTALLUILEVEL_FULL = 5, > INSTALLUILEVEL_HIDECANCEL = 0x20, > INSTALLUILEVEL_PROGRESSONLY = 0x40, > INSTALLUILEVEL_ENDDIALOG = 0x80, > INSTALLUILEVEL_SOURCERESONLY = 0x100 > and the code to check for the level was: > > if ( msi_get_property_int(package, szUILevel, 0) >= > INSTALLUILEVEL_REDUCED) > > but the problem is that if any of the flags are set, then immediately > this would assume full UI install even though this is not the case for > some installers (see bug #6992). I proposed this change: > > if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >>= > INSTALLUILEVEL_REDUCED ) > > It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with > INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both > of which are greater than or equal to four. However, if for some reason these UI > levels were to change in the future, or if someone decided to further modify > this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually > be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So > is this too hacky? Is there a simple, better way to do this? Looks like that the flags are placed in the bits higher than 4, so I'd vote for something like the following: if ( (msi_get_property_int(package, szUILevel, 0) & 0x0f)>= INSTALLUILEVEL_REDUCED ) ... -- Dmitry. From richardvoigt at gmail.com Mon Feb 5 22:26:27 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Mon Feb 5 22:26:32 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <200702060106.02145.kai.blin@gmail.com> References: <45C7AEFC.1000404@codeweavers.com> <200702060106.02145.kai.blin@gmail.com> Message-ID: <2e59e6970702052026w54c0b6d2n6b95c1a49f7c1cd0@mail.gmail.com> On 2/5/07, Kai Blin wrote: > On Monday 05 February 2007 23:26, Jeremy White wrote: > > So we can ask, once again: when will 1.0 ship!?!?! > [...] > > p.s. I think Wine will go 1.0 in the same year that is the > > year of Linux on the Desktop . > > Oooh, can we make "Duke Nukem Forever runs" a 1.0 release requirement? Then we > could bundle Wine 1.0 with DNF. ;) That would change the critical path... how do you put that requirement on a Gantt chart? :) > > Cheers, > Kai > > -- > Kai Blin, > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin/ > -- > Will code for cotton. > > > > > From dmitry at codeweavers.com Mon Feb 5 22:29:37 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 5 22:29:40 2007 Subject: msvcrt: implement _mbbtype according to MSDN References: <837649.18691.qm@web39711.mail.mud.yahoo.com> Message-ID: <018501c749a7$6cde42e0$0100a8c0@DMITRY> "Juan Lang" wrote: > /********************************************************************* > + * _mbbtype(MSVCRT.@) > + */ > +int CDECL _mbbtype(unsigned char c, int type) > +{ > + if (type == 1) > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x40 && c <= 0x7e) || (c >= 0x80 && c <= 0xfc)) > + return _MBC_TRAIL; > + else > + return _MBC_ILLEGAL; > + } > + else > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x81 && c <= 0x9f) || (c >= 0xe0 && c <= 0xfc)) > + return _MBC_LEAD; > + else > + return _MBC_ILLEGAL; > + } Since MSVCRT_mbctype array is not currently being initialized, probably using MSVCRT_current_ctype would be good enough for now. -- Dmitry. From trent.waddington at gmail.com Mon Feb 5 22:31:05 2007 From: trent.waddington at gmail.com (Trent Waddington) Date: Mon Feb 5 22:31:15 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. In-Reply-To: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> References: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> Message-ID: <3d57814d0702052031p7d4d50f4hdbdd8dab821b706a@mail.gmail.com> On 2/6/07, Trent Waddington wrote: > These changes make the Carbon Poker (www.carbonpoker.com) client work. > > Run the Carbon Poker installer; then > Run c:/windows/system32/Macromed/Flash/GetFlash.exe; then > Run c:/windows/CarbonPoker/Poker.exe That should be c:/Program Files/CarbonPoker/Poker.exe Sorry, Trent From dmitry at codeweavers.com Mon Feb 5 22:32:37 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 5 22:32:42 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. References: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> Message-ID: <019c01c749a7$d83a3d50$0100a8c0@DMITRY> "Trent Waddington" wrote: > These changes make the Carbon Poker (www.carbonpoker.com) client work. Please break your patch into logical pieces per dll and submit them separately. There is no need to patch ChangeLog, just provide a comment what your patch is doing. -- Dmitry. From trent.waddington at gmail.com Mon Feb 5 22:46:41 2007 From: trent.waddington at gmail.com (Trent Waddington) Date: Mon Feb 5 22:46:47 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. In-Reply-To: <019c01c749a7$d83a3d50$0100a8c0@DMITRY> References: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> <019c01c749a7$d83a3d50$0100a8c0@DMITRY> Message-ID: <3d57814d0702052046n5f8283e5y39ec7aafba5cc139@mail.gmail.com> On 2/6/07, Dmitry Timoshkov wrote: > Please break your patch into logical pieces per dll and submit them > separately. There is no need to patch ChangeLog, just provide a comment > what your patch is doing. Ok. Seperate patches are attached, comment at the top of each. Thanks, Trent -------------- next part -------------- A non-text attachment was scrubbed... Name: hack-around-lack-of-pkcs7-support.diff Type: application/octet-stream Size: 3201 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/68adcb7f/hack-around-lack-of-pkcs7-support.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: implement-empty-string-termination-feature-of-HttpOpenRequestA.diff Type: application/octet-stream Size: 1001 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/68adcb7f/implement-empty-string-termination-feature-of-HttpOpenRequestA.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: implement-ScriptGetLogicalWidths.diff Type: application/octet-stream Size: 1983 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/68adcb7f/implement-ScriptGetLogicalWidths.obj From twickline at gmail.com Mon Feb 5 22:54:18 2007 From: twickline at gmail.com (Tom Wickline) Date: Mon Feb 5 22:54:18 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <2e59e6970702052026w54c0b6d2n6b95c1a49f7c1cd0@mail.gmail.com> References: <45C7AEFC.1000404@codeweavers.com> <200702060106.02145.kai.blin@gmail.com> <2e59e6970702052026w54c0b6d2n6b95c1a49f7c1cd0@mail.gmail.com> Message-ID: <53e3a9930702052054u65604220m12ff8fceb93f6796@mail.gmail.com> On 2/5/07, richardvoigt@gmail.com wrote: > > That would change the critical path... how do you put that requirement > on a Gantt chart? Have a list of requirements that DNF depends on? :D Tom > > :) > From xixsimplicityxix at gmail.com Mon Feb 5 23:05:50 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Mon Feb 5 23:05:50 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <53e3a9930702052054u65604220m12ff8fceb93f6796@mail.gmail.com> References: <45C7AEFC.1000404@codeweavers.com> <200702060106.02145.kai.blin@gmail.com> <2e59e6970702052026w54c0b6d2n6b95c1a49f7c1cd0@mail.gmail.com> <53e3a9930702052054u65604220m12ff8fceb93f6796@mail.gmail.com> Message-ID: <78a7dad00702052105j61ffa486x1d3de3de6d6f2d72@mail.gmail.com> Yeah, I can no longer find them on MSDN. On 2/5/07, Tom Wickline wrote: > > On 2/5/07, richardvoigt@gmail.com wrote: > > > > That would change the critical path... how do you put that requirement > > on a Gantt chart? > > Have a list of requirements that DNF depends on? > > :D > > Tom > > > > > :) > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070205/74aa54bb/attachment.htm From xixsimplicityxix at gmail.com Mon Feb 5 23:15:15 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Mon Feb 5 23:15:19 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. In-Reply-To: <3d57814d0702052046n5f8283e5y39ec7aafba5cc139@mail.gmail.com> References: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> <019c01c749a7$d83a3d50$0100a8c0@DMITRY> <3d57814d0702052046n5f8283e5y39ec7aafba5cc139@mail.gmail.com> Message-ID: <78a7dad00702052115h46cd9c59y5dd12dfe9741e68b@mail.gmail.com> Is the GPL w/ library exception compatible with LGPL? Seems like they could be similair. If so we could utilize the gnu PKCS7 code. Does any one know? John On 2/5/07, Trent Waddington wrote: > > On 2/6/07, Dmitry Timoshkov wrote: > > Please break your patch into logical pieces per dll and submit them > > separately. There is no need to patch ChangeLog, just provide a comment > > what your patch is doing. > > Ok. Seperate patches are attached, comment at the top of each. > > Thanks, > > Trent > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070205/7b5fc058/attachment.html From mk144210 at bcm.tmc.edu Mon Feb 5 23:25:36 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 5 23:25:56 2007 Subject: msi patch: Is this too hacky? In-Reply-To: <011701c749a5$65cfb0d0$0100a8c0@DMITRY> References: <1170729195.8463.4.camel@misha-laptop> <011701c749a5$65cfb0d0$0100a8c0@DMITRY> Message-ID: <1170739536.8463.15.camel@misha-laptop> That seems like a good way to do it. I sent an updated patch to wine-patches. Misha On Tue, 2007-02-06 at 12:15 +0800, Dmitry Timoshkov wrote: > "Misha Koshelev" wrote: > > > Hi, I submitted the following patch to wine-patches but was thinking > > about it some more. The problem is that you have the following UI levels > > and flags: > > INSTALLUILEVEL_NOCHANGE = 0, > > INSTALLUILEVEL_DEFAULT = 1, > > INSTALLUILEVEL_NONE = 2, > > INSTALLUILEVEL_BASIC = 3, > > INSTALLUILEVEL_REDUCED = 4, > > INSTALLUILEVEL_FULL = 5, > > INSTALLUILEVEL_HIDECANCEL = 0x20, > > INSTALLUILEVEL_PROGRESSONLY = 0x40, > > INSTALLUILEVEL_ENDDIALOG = 0x80, > > INSTALLUILEVEL_SOURCERESONLY = 0x100 > > and the code to check for the level was: > > > > if ( msi_get_property_int(package, szUILevel, 0) >= > > INSTALLUILEVEL_REDUCED) > > > > but the problem is that if any of the flags are set, then immediately > > this would assume full UI install even though this is not the case for > > some installers (see bug #6992). I proposed this change: > > > > if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) > >>= > > INSTALLUILEVEL_REDUCED ) > > > > It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with > > INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both > > of which are greater than or equal to four. However, if for some reason these UI > > levels were to change in the future, or if someone decided to further modify > > this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually > > be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So > > is this too hacky? Is there a simple, better way to do this? > > Looks like that the flags are placed in the bits higher than 4, so I'd vote > for something like the following: > > if ( (msi_get_property_int(package, szUILevel, 0) & 0x0f)>= INSTALLUILEVEL_REDUCED ) > ... > From richardvoigt at gmail.com Mon Feb 5 23:33:41 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Mon Feb 5 23:33:41 2007 Subject: It's that time again - time to start thinking about WineConf 2007! In-Reply-To: <78a7dad00702052105j61ffa486x1d3de3de6d6f2d72@mail.gmail.com> References: <45C7AEFC.1000404@codeweavers.com> <200702060106.02145.kai.blin@gmail.com> <2e59e6970702052026w54c0b6d2n6b95c1a49f7c1cd0@mail.gmail.com> <53e3a9930702052054u65604220m12ff8fceb93f6796@mail.gmail.com> <78a7dad00702052105j61ffa486x1d3de3de6d6f2d72@mail.gmail.com> Message-ID: <2e59e6970702052133m6c1cc4a8m7b08354571b82ca1@mail.gmail.com> On 2/5/07, John Smith wrote: > Yeah, I can no longer find them on MSDN. Laying the blame on MS.... all I can say is "nice!". > > > On 2/5/07, Tom Wickline wrote: > > On 2/5/07, richardvoigt@gmail.com wrote: > > > > > > That would change the critical path... how do you put that requirement > > > on a Gantt chart? > > > > Have a list of requirements that DNF depends on? > > > > :D > > > > Tom > > > > > > > > :) > > > > > > > > > > > From dmitry at codeweavers.com Tue Feb 6 00:17:27 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 6 00:17:23 2007 Subject: user32: WM_SETFONT on button doesn't repaint directly References: <45C8192A.9040804@utwire.net> Message-ID: <03bb01c749b6$7de650f0$0100a8c0@DMITRY> "Clinton Stimpson" wrote: > This patch fixes WM_SETFONT on a button to not paint directly. Instead, > it calls InvalidateRect. > A test is included that demonstrates that no paint events come out of > sending a WM_SETFONT. > > > Thanks, > Clinton Stimpson > > ChangeLog: > Setting font on button doesn't repaint directly. I think that your previous version of the test that called UpdateWindow and demonstrated that WM_SETFONT triggers full painting sequence was more correct. I have no idea though why it has not been accepted. Also, as a way to simplify the test there is no need to create a font, I'd suggest to use GetStockObject to retrieve a handle to one of the stock fonts. -- Dmitry. From jan.wine at zerebecki.de Tue Feb 6 01:20:16 2007 From: jan.wine at zerebecki.de (Jan Zerebecki) Date: Tue Feb 6 01:20:25 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. In-Reply-To: <78a7dad00702052115h46cd9c59y5dd12dfe9741e68b@mail.gmail.com> References: <3d57814d0702051913l15953aabged283a00a5cec875@mail.gmail.com> <019c01c749a7$d83a3d50$0100a8c0@DMITRY> <3d57814d0702052046n5f8283e5y39ec7aafba5cc139@mail.gmail.com> <78a7dad00702052115h46cd9c59y5dd12dfe9741e68b@mail.gmail.com> Message-ID: <20070206072016.GA24565@crissy.swd.zerebecki.de> On Mon, Feb 05, 2007 at 11:15:15PM -0600, John Smith wrote: > Is the GPL w/ library exception compatible with LGPL? Seems like they could > be similair. If so we could utilize the gnu PKCS7 code. Does any one know? IANAL but AFAIK, Yes, GPL w/ library exception like on http://www.gnu.org/software/gnu-crypto/ is compatible with LGPL. Jan From truiken at gmail.com Tue Feb 6 01:54:24 2007 From: truiken at gmail.com (James Hawkins) Date: Tue Feb 6 01:54:24 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <1170739515.8463.14.camel@misha-laptop> References: <1170739515.8463.14.camel@misha-laptop> Message-ID: <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> On 2/5/07, Misha Koshelev wrote: > This is an update, a little less hacky thanks to advice from Dmitry > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > getting to the > point where it was trying to launch the .msi files that do the actual > install, but was quitting with the message "This module is not designed > for direct execution." Install worked fine with native MSI. After a > while of playing with it and disassembling the MSI file with dark.exe > tool, I noticed that the .msi files ran in execute mode but not UI mode. > Finally, I checked the UI level that wine msi was reading, and it was > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > MSI_InstallPackage was only checking if the uilevel >= > INSTALLUILEVEL_REDUCED, which would have been true in this case as > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > patch fixes this check, and now the installer finished successfully > (although it seems upon a quick check that there are more install bugs > for this program in wine, as not all files that should be there seem to > be there after this install). > > Changelog: > > * msi: InstallPackage check for UI level must not disregard > INSTALLUILEVEL flags. > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > Magic numbers are bad. What is 0xF? -- James Hawkins From truiken at gmail.com Tue Feb 6 01:57:31 2007 From: truiken at gmail.com (James Hawkins) Date: Tue Feb 6 01:57:35 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> References: <1170739515.8463.14.camel@misha-laptop> <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> Message-ID: <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> On 2/6/07, James Hawkins wrote: > On 2/5/07, Misha Koshelev wrote: > > This is an update, a little less hacky thanks to advice from Dmitry > > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > > getting to the > > point where it was trying to launch the .msi files that do the actual > > install, but was quitting with the message "This module is not designed > > for direct execution." Install worked fine with native MSI. After a > > while of playing with it and disassembling the MSI file with dark.exe > > tool, I noticed that the .msi files ran in execute mode but not UI mode. > > Finally, I checked the UI level that wine msi was reading, and it was > > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > > MSI_InstallPackage was only checking if the uilevel >= > > INSTALLUILEVEL_REDUCED, which would have been true in this case as > > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > > patch fixes this check, and now the installer finished successfully > > (although it seems upon a quick check that there are more install bugs > > for this program in wine, as not all files that should be there seem to > > be there after this install). > > > > Changelog: > > > > * msi: InstallPackage check for UI level must not disregard > > INSTALLUILEVEL flags. > > > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > > > > Magic numbers are bad. What is 0xF? > I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins From stefan.munz at itomig.de Tue Feb 6 03:26:00 2007 From: stefan.munz at itomig.de (Stefan Munz) Date: Tue Feb 6 03:26:16 2007 Subject: Linuxtag 2007 in Berlin Message-ID: <200702061026.11933.stefan.munz@itomig.de> Hi, there is a "CALL FOR PROJECTS" for Linuxtag 2007 in Germany/Berlin from May 30 to June 2. Is anybody interested in participating in a Wine booth? More information (in german) is here: http://www.linuxtag.org/2007/de/community/projects/cfpro/call-for-projects.html Projects should be registered until February 23. cu, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/f9d30dab/attachment.pgp From meissner at suse.de Tue Feb 6 04:52:07 2007 From: meissner at suse.de (Marcus Meissner) Date: Tue Feb 6 04:52:26 2007 Subject: [PATCH] coverity: CID35: fixed wrong condition In-Reply-To: <45C7A1B3.9040203@holycrap.org> References: <45C7A1B3.9040203@holycrap.org> Message-ID: <20070206105207.GA32523@suse.de> On Mon, Feb 05, 2007 at 10:29:23PM +0100, Felix Nawothnig wrote: > Marcus Meissner wrote: > >- if(nRelPos>=0) { /* if this or preceding row */ > >+ if(nRelPos<=0) { /* if this or preceding row */ > > while(nRelPos<=0) { > > Shouldn't that become a "do { ... } while()" then? No, since there is a return item; after the while () loop. Actually we might want to kill the whole function, it seems not to be used. I am just not comfortable with removing it. Ciao, Marcus From nlaw at nildram.co.uk Tue Feb 6 05:31:22 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Tue Feb 6 05:33:10 2007 Subject: Numeric keypad fix for WoW & Warcraft Bug 6323 In-Reply-To: <200702061026.11933.stefan.munz@itomig.de> References: <200702061026.11933.stefan.munz@itomig.de> Message-ID: <45C8670A.5030303@nildram.co.uk> Hi Dean Kuslar has patched keyboard.c so that the numeric keypad now works in both World of Warcraft and Warcraft. If anybody is currently doing any development or bug fixing to other games and the numeric keypad doesn't work on the game your working on, we would be interested in hearing if this patch fixes the numeric keypad on your game. The patch is here .. http://bugs.winehq.org/attachment.cgi?id=4730&action=view and the bug is 6323. Regards Nick From shachar at shemesh.biz Tue Feb 6 06:11:21 2007 From: shachar at shemesh.biz (Shachar Shemesh) Date: Tue Feb 6 06:11:26 2007 Subject: Daylight saving changes In-Reply-To: <45BF3E86.9050803@codeweavers.com> References: <45BF3E86.9050803@codeweavers.com> Message-ID: <45C87069.6080209@shemesh.biz> Francois Gouget wrote: > Israel Standard Time At least with this one I can help. Feel free to use the data under LGPL: http://lingnu.com/support.html#timezone Which is not to say that I know what to do about it..... :-) Shachar From frick at sc-networks.de Tue Feb 6 07:13:32 2007 From: frick at sc-networks.de (Christoph Frick) Date: Tue Feb 6 07:13:22 2007 Subject: DirectDrawRenderer=opengl - screen size changeable for final rendering? Message-ID: <20070206131332.GW1252@byleth.sc-networks.de> hiho what i ever wondered but never dared to ask: i tried recently the said key with jagged alliance 2. as the game has quite a low resolution 640 or 800 it would be nice to allow higher resolutions when rendering ddraw with opengl (e.g. game wants 800 but for the final rendering use 1600). is this doable via registry or somewhere else? for the files: i run the apps in desktop-mode. -- cu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/fdaf41dc/attachment.pgp From dank at kegel.com Tue Feb 6 08:03:51 2007 From: dank at kegel.com (Dan Kegel) Date: Tue Feb 6 08:03:58 2007 Subject: Presenting at LinuxTag? Message-ID: David asked if anyone's interested in manning a Wine booth at Linuxtag. A related question: is anybody proposing a Wine talk or tutorial at Linuxtag? The deadline for submitting proposals is Feb 16th. (Here's the CFP: http://www.linuxtag.org/2007/en/conf/cfp/cfp-target.html ) From der.fabe at gmx.net Tue Feb 6 08:08:21 2007 From: der.fabe at gmx.net (Fabian Bieler) Date: Tue Feb 6 08:04:01 2007 Subject: Bug 4791 - Civ4 crashes because of recent explorer/systray changes In-Reply-To: <200702032313.51154.der.fabe@gmx.net> References: <200702032313.51154.der.fabe@gmx.net> Message-ID: <200702061508.21447.der.fabe@gmx.net> Hello! In my last mail I confused a few message types. However, I think I know why this bug occurs. Apparently windows silently ignores nullpointer callbacks passed to SendMessageCallback (although it does deliver the message). Fabian From mk144210 at bcm.tmc.edu Tue Feb 6 08:20:54 2007 From: mk144210 at bcm.tmc.edu (Koshelev, Misha Vladislavo) Date: Tue Feb 6 08:22:35 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) References: <1170739515.8463.14.camel@misha-laptop><22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> Message-ID: <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Should this be in msi.h (or would this be confusing as this is not defined in Windows I don't think) or just in the same file where the other change is being made? Thanks Misha -----Original Message----- From: James Hawkins [mailto:truiken@gmail.com] Sent: Tue 2/6/2007 1:57 AM To: wine-devel@winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: msi: InstallPackage check for UI level must not disregard flags (updated) On 2/6/07, James Hawkins wrote: > On 2/5/07, Misha Koshelev wrote: > > This is an update, a little less hacky thanks to advice from Dmitry > > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > > getting to the > > point where it was trying to launch the .msi files that do the actual > > install, but was quitting with the message "This module is not designed > > for direct execution." Install worked fine with native MSI. After a > > while of playing with it and disassembling the MSI file with dark.exe > > tool, I noticed that the .msi files ran in execute mode but not UI mode. > > Finally, I checked the UI level that wine msi was reading, and it was > > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > > MSI_InstallPackage was only checking if the uilevel >= > > INSTALLUILEVEL_REDUCED, which would have been true in this case as > > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > > patch fixes this check, and now the installer finished successfully > > (although it seems upon a quick check that there are more install bugs > > for this program in wine, as not all files that should be there seem to > > be there after this install). > > > > Changelog: > > > > * msi: InstallPackage check for UI level must not disregard > > INSTALLUILEVEL flags. > > > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > > > > Magic numbers are bad. What is 0xF? > I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070206/e2b5c6ae/attachment.htm From kai.blin at gmail.com Tue Feb 6 09:40:25 2007 From: kai.blin at gmail.com (Kai Blin) Date: Tue Feb 6 09:41:44 2007 Subject: Linuxtag 2007 in Berlin In-Reply-To: <200702061026.11933.stefan.munz@itomig.de> References: <200702061026.11933.stefan.munz@itomig.de> Message-ID: <200702061640.28718.kai.blin@gmail.com> On Tuesday 06 February 2007 10:26, Stefan Munz wrote: > Is anybody interested in participating in a Wine booth? More information > (in german) is here: > > http://www.linuxtag.org/2007/de/community/projects/cfpro/call-for-projects. >html English link is http://www.linuxtag.org/2007/en/community/projects/cfpro/call-for-projects.html Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070206/25559881/attachment.pgp From juan_lang at yahoo.com Tue Feb 6 10:38:24 2007 From: juan_lang at yahoo.com (Juan Lang) Date: Tue Feb 6 10:39:06 2007 Subject: [PATCH] make CarbonPoker (previously Poker.com) client work. Message-ID: <10581.69178.qm@web39707.mail.mud.yahoo.com> Hi Trent, thanks for the patches. Please send the split up patches to wine-patches instead of wine-devel. The crypt32 patches won't make it in as-is, but I think you can get a better quality hack accepted. As MSDN states, CryptGetMessageCertificates is just a wrapper around CertOpenStore. So you could write something like the following: HCERTSTORE WINAPI CryptGetMessageCertificates( DWORD dwMsgAndCertEncodingType, HCRYPTPROV hCryptProv, DWORD dwFlags, const BYTE* pbSignedBlob, DWORD cbSignedBlob) { CRYPT_DATA_BLOB blob = { cbSignedBlob, (LPBYTE)pbSignedBlob }; TRACE("%d, %p, %d, %p, %d\n", dwMsgAndCertEncodingType, hCryptProv, dwFlags, pbSignedBlob, cbSignedBlob); return CertOpenStore(CERT_STORE_PROV_PKCS7, dwMsgAndCertEncodingType, hCryptProv, dwFlags, &blob); } Then in store.c, add a stub function for opening and closing PKCS7 stores - look at CRYPT_PhysOpenStore for an example. Cheers, --Juan ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL From truiken at gmail.com Tue Feb 6 12:09:59 2007 From: truiken at gmail.com (James Hawkins) Date: Tue Feb 6 12:10:10 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> References: <1170739515.8463.14.camel@misha-laptop> <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> Message-ID: <22821af30702061009hd42fe46nc3aeb85217b570b3@mail.gmail.com> On 2/6/07, Koshelev, Misha Vladislavo wrote: > > > > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere > set to 0xf then? Should > this be in msi.h (or would this be confusing as this is not defined in > Windows I don't think) or > just in the same file where the other change is being made? > The patch was accepted as-is, so I wouldn't worry about it. P.S. Please bottom-post on replies. -- James Hawkins From flexo at holycrap.org Tue Feb 6 12:20:40 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 6 12:14:31 2007 Subject: [PATCH] coverity: CID35: fixed wrong condition In-Reply-To: <20070206105207.GA32523@suse.de> References: <45C7A1B3.9040203@holycrap.org> <20070206105207.GA32523@suse.de> Message-ID: <45C8C6F8.30109@holycrap.org> Marcus Meissner wrote: >>>- if(nRelPos>=0) { /* if this or preceding row */ >>>+ if(nRelPos<=0) { /* if this or preceding row */ >>> while(nRelPos<=0) { >>Shouldn't that become a "do { ... } while()" then? > No, since there is a return item; after the while () loop. I meant replacing just the while(), not the if() while(). It's mostly a matter of style though as gcc most likely will compile it to a do {} while() anyway. Felix From flexo at holycrap.org Tue Feb 6 12:23:47 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 6 12:17:34 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> References: <1170739515.8463.14.camel@misha-laptop><22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> Message-ID: <45C8C7B3.2040906@holycrap.org> Koshelev, Misha Vladislavo wrote: > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > somewhere set to 0xf then? Shouldn't that be 0x7? From dclark at akamail.com Tue Feb 6 12:34:35 2007 From: dclark at akamail.com (Duane Clark) Date: Tue Feb 6 12:35:01 2007 Subject: Window focus testing In-Reply-To: <00fc01c749a4$7439fcd0$0100a8c0@DMITRY> References: <45C7B5DD.8050907@pacbell.net> <00fc01c749a4$7439fcd0$0100a8c0@DMITRY> Message-ID: Dmitry Timoshkov wrote: > "Duane Clark" wrote: > >> Is it possible to do window focus testing in Wine conformance tests? Or >> does the windows not being mapped mean that this testing cannot be done? >> Or maybe I am doing something completely wrong; which is likely ;) > > Have a look at dlls/user32/tests/win.c,test_SetFocus(). > > Ah, ok. This test shows the window temporarily. Somewhere I had gotten the idea that we didn't do that. Thanks. From mk144210 at bcm.tmc.edu Tue Feb 6 12:35:20 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Tue Feb 6 12:36:10 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <45C8C7B3.2040906@holycrap.org> References: <1170739515.8463.14.camel@misha-laptop> <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> <45C8C7B3.2040906@holycrap.org> Message-ID: <1170786920.7166.8.camel@misha-laptop> On Tue, 2007-02-06 at 19:23 +0100, Felix Nawothnig wrote: > Koshelev, Misha Vladislavo wrote: > > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > > somewhere set to 0xf then? > > Shouldn't that be 0x7? I guess either one would work since the first flag is 0x20. Do I need to change it to 0x7 or leave as is? Misha From flexo at holycrap.org Tue Feb 6 12:51:06 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 6 12:44:50 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <1170786920.7166.8.camel@misha-laptop> References: <1170739515.8463.14.camel@misha-laptop> <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> <45C8C7B3.2040906@holycrap.org> <1170786920.7166.8.camel@misha-laptop> Message-ID: <45C8CE1A.1020803@holycrap.org> Misha Koshelev wrote: >>>So do you think I should add a define like INSTALLUILEVEL_NOFLAGS >>>somewhere set to 0xf then? >>Shouldn't that be 0x7? > I guess either one would work since the first flag is 0x20. Do I need to > change it to 0x7 or leave as is? So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if there are undocumented flags (that gap before 0x20 looks suspicious to me...) - and that's more likely than undocumented levels imho (and even with 0x7 we cover another 2). Felix From mk144210 at bcm.tmc.edu Tue Feb 6 12:50:41 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Tue Feb 6 12:51:07 2007 Subject: msi: InstallPackage check for UI level must not disregard flags (updated) In-Reply-To: <45C8CE1A.1020803@holycrap.org> References: <1170739515.8463.14.camel@misha-laptop> <22821af30702052354h487c07e4sa9a472f70cb70a66@mail.gmail.com> <22821af30702052357i4b2fe70dqbc6c1c4e4b6f21f5@mail.gmail.com> <10C24F7C4D05EB45B5F0E1B397897849010F7BD8@BCMEVS7.ad.bcm.edu> <45C8C7B3.2040906@holycrap.org> <1170786920.7166.8.camel@misha-laptop> <45C8CE1A.1020803@holycrap.org> Message-ID: <1170787841.7166.13.camel@misha-laptop> On Tue, 2007-02-06 at 19:51 +0100, Felix Nawothnig wrote: > Misha Koshelev wrote: > >>>So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > >>>somewhere set to 0xf then? > >>Shouldn't that be 0x7? > > I guess either one would work since the first flag is 0x20. Do I need to > > change it to 0x7 or leave as is? > > So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if > there are undocumented flags (that gap before 0x20 looks suspicious to > me...) - and that's more likely than undocumented levels imho (and even > with 0x7 we cover another 2). > > Felix Ok, sent a patch update. Sound reasonable. Misha From wine.dev at web.de Tue Feb 6 14:40:40 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Tue Feb 6 14:43:22 2007 Subject: qemu-0.9.0 and kqemu-1.3.0pre10 (now GPL) released Message-ID: <1170794440.6915.10.camel@p4> http://www.qemu.org/ QEMU 0.9.0 was released. The QEMU Accelerator Module kqemu-1.3.0pre10 was released and is now available under the GPL license. Thanks Fabrice, the qemu-team and every contributor. -- By by ... Detlef From flexo at holycrap.org Tue Feb 6 15:28:01 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 6 15:21:43 2007 Subject: Undoc. comctl32 mem management functions Message-ID: <45C8F2E1.5090400@holycrap.org> Hi. comctl32 exports (undocumented) Alloc() and friends which call LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() directly? If Global/Local* behave different than Heap* on Windows - wouldn't it then be desirable to replace the Alloc()/etc. calls in our comctl32 (we use it all over the place) by Heap*? Reason I'm asking: Since it's not documented the Free(NULL) semantics are not clear (although it's safe in our implementation) - and I'm wondering if we really want to internally use undocumented functions with unclear semantics when there is an easy (documented) way. And besides - the comctl32 code is full of "if(p) Free(p);"... Felix From flexo at holycrap.org Tue Feb 6 16:33:32 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 6 16:27:12 2007 Subject: comctl32: tab: update the item mask after a TB_SETITEM (fixes bug #7345) In-Reply-To: <45C8FDE1.7050707@zalewski.pl> References: <45C8FDE1.7050707@zalewski.pl> Message-ID: <45C9023C.4080304@holycrap.org> Miko?aj Zalewski wrote: > Tab uses a mask to mark which fields are set but it new fields were set > by SetItem the mask wasn't updated. Actually all members are always valid (for the internal structure at least). I already sent a patch which removes the mask. Felix From mikolaj at zalewski.pl Tue Feb 6 16:42:04 2007 From: mikolaj at zalewski.pl (=?UTF-8?B?TWlrb8WCYWogWmFsZXdza2k=?=) Date: Tue Feb 6 16:42:12 2007 Subject: comctl32: tab: update the item mask after a TB_SETITEM (fixes bug #7345) In-Reply-To: <45C9023C.4080304@holycrap.org> References: <45C8FDE1.7050707@zalewski.pl> <45C9023C.4080304@holycrap.org> Message-ID: <45C9043C.5050805@zalewski.pl> > Actually all members are always valid (for the internal structure at > least). I already sent a patch which removes the mask. > > Felix Sorry, I didn't notice the patch. Mikolaj From kde at 3danim.de Tue Feb 6 17:14:50 2007 From: kde at 3danim.de (Markus) Date: Tue Feb 6 17:14:34 2007 Subject: How to find rendering code Message-ID: <200702070014.50521.kde@3danim.de> Hi, I am new to Wine development and wanted to ask on the list, whether someone could point me to the correct place where the code for issues 3 and 4 in http://bugs.winehq.org/show_bug.cgi?id=7273 might be located. It looks like the solution could be rather straightforward to implement but I have no idea how to find the respective rendering method. Any help would be greatly appreciated. Thanks. -- Markus From mstefani at redhat.com Wed Feb 7 05:27:10 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Wed Feb 7 05:27:16 2007 Subject: Undoc. comctl32 mem management functions In-Reply-To: <45C8F2E1.5090400@holycrap.org> References: <45C8F2E1.5090400@holycrap.org> Message-ID: <45C9B78E.5030004@redhat.com> Felix Nawothnig wrote: > Hi. comctl32 exports (undocumented) Alloc() and friends which call > LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any fancy > LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() directly? > > If Global/Local* behave different than Heap* on Windows - wouldn't it > then be desirable to replace the Alloc()/etc. calls in our comctl32 (we > use it all over the place) by Heap*? > > Reason I'm asking: Since it's not documented the Free(NULL) semantics > are not clear (although it's safe in our implementation) - and I'm > wondering if we really want to internally use undocumented functions > with unclear semantics when there is an easy (documented) way. > > And besides - the comctl32 code is full of "if(p) Free(p);"... Looks like i need to add Free() to my redundant_null_check.pl Smatch script. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From joris_huizer at yahoo.com Wed Feb 7 05:56:24 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Wed Feb 7 05:57:01 2007 Subject: [urlmon 1/2] Cast-qual warning fix In-Reply-To: <45C97A81.8070409@gmail.com> Message-ID: <576415.87262.qm@web52712.mail.yahoo.com> --- Paul Vriens wrote: > Hi, > > Fix a warning and remove the now not needed cast. > > Changelog > Cast-qual warning fix > > Cheers, > > Paul. > > > > diff --git a/dlls/urlmon/umon.c b/dlls/urlmon/umon.c > index 49260ab..d593c81 100644 > --- a/dlls/urlmon/umon.c > +++ b/dlls/urlmon/umon.c > @@ -1605,7 +1605,7 @@ HRESULT WINAPI > URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller, > LPCWSTR szURL, LPW > HRESULT hr; > LPWSTR ext; > > - static const WCHAR header[] = { > + static WCHAR header[] = { > 'H','T','T','P','/','1','.','0',' > ','2','0','0',' ', > > 'O','K','\\','r','\\','n','\\','r','\\','n',0 > }; > @@ -1631,7 +1631,7 @@ HRESULT WINAPI > URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller, > LPCWSTR szURL, LPW > modified.dwLowDateTime = 0; > > if (!CommitUrlCacheEntryW(szURL, cache_path, > expire, modified, NORMAL_CACHE_ENTRY, > - (LPWSTR)header, > sizeof(header), NULL, NULL)) > + header, > sizeof(header), NULL, NULL)) > return E_FAIL; > > if (lstrlenW(cache_path) > dwBufLength) > -- If CommitUrlCacheEntryW does not take a constant pointer, this might be dangerous - if it changes the string, the next time this code executes the wrong (modified) string gets used If this is indeed possible, the static keyword needs to be dropped too (ensuring the string is reinitialised with the next call) If it is only not possible in this particular case, sorry for complaining; (though it may be possible to factor out that part of the code that is used, thus ensuring constness) If this is not possible in general, the function CommitUrlCacheEntryW should take a constant pointer instead (same for the other patch) regards, Joris ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From mk144210 at bcm.tmc.edu Wed Feb 7 08:33:05 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 08:33:46 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. Message-ID: <1170858785.6010.7.camel@misha-laptop> Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :) -------------- next part -------------- From 55b39a67676e2bd8c01c0b17b677298c9d22a46c Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Wed, 7 Feb 2007 08:10:19 -0600 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. --- dlls/msi/tests/install.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c index 00b7763..facd280 100644 --- a/dlls/msi/tests/install.c +++ b/dlls/msi/tests/install.c @@ -105,6 +105,12 @@ static const CHAR install_exec_seq_dat[] "LaunchConditions\t\t100\n" "WriteRegistryValues\tSourceDir And SOURCEDIR\t5000"; +/* as a proper check for INSTALLUILEVEL flags processing, make sure a UI install fails */ +static const CHAR install_ui_seq_dat[] = "Action\tCondition\tSequence\n" + "s72\tS255\tI2\n" + "InstallUISequence\tAction\n" + "AllocateRegistrySpace\tNOT Installed\t1550\n"; + static const CHAR media_dat[] = "DiskId\tLastSequence\tDiskPrompt\tCabinet\tVolumeLabel\tSource\n" "i2\ti4\tL64\tS255\tS32\tS72\n" "Media\tDiskId\n" @@ -231,6 +237,7 @@ static const msi_table tables[] = ADD_TABLE(feature_comp), ADD_TABLE(file), ADD_TABLE(install_exec_seq), + ADD_TABLE(install_ui_seq), ADD_TABLE(media), ADD_TABLE(property), ADD_TABLE(registry), @@ -689,6 +696,12 @@ static void test_MsiInstallProduct(void) create_test_files(); create_database(msifile, tables, sizeof(tables) / sizeof(msi_table)); + /* Make sure that the UI level flags are taken into account when determining whether to + * start a graphical UI or execute only mode (bug 6992). If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. */ + MsiSetInternalUI(INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCERESONLY, NULL); + r = MsiInstallProductA(msifile, NULL); ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %u\n", r); -- 1.4.1 From joris_huizer at yahoo.com Wed Feb 7 08:38:10 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Wed Feb 7 08:38:36 2007 Subject: winegcc: sign-compare fixes In-Reply-To: <20070207141809.67076.qmail@web52711.mail.yahoo.com> Message-ID: <116527.29393.qm@web52714.mail.yahoo.com> I believe this one causes problems -- please do not commit yet Joris Huizer wrote: --------------------------------- Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.>From 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17 00:00:00 2001 From: Joris Huizer Date: Wed, 7 Feb 2007 15:19:25 +0100 Subject: [PATCH] winegcc sign-compare fixes To: wine-patches --- tools/winegcc/utils.c | 13 +++++++------ tools/winegcc/winegcc.c | 11 ++++++----- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c index 1af91e9..c144077 100644 --- a/tools/winegcc/utils.c +++ b/tools/winegcc/utils.c @@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c void strarray_del(strarray* arr, int i) { - if (i < 0 || i >= arr->size) error("Invalid index i=%d", i); + if (i < 0 || (unsigned int)i >= arr->size) error("Invalid index i=%d", i); memmove(&arr->base[i], &arr->base[i + 1], (arr->size - i - 1) * sizeof(arr->base[0])); arr->size--; } void strarray_addall(strarray* arr, const strarray* from) { - int i; + unsigned int i; for (i = 0; i < from->size; i++) strarray_add(arr, from->base[i]); @@ -136,7 +136,7 @@ void strarray_addall(strarray* arr, cons strarray* strarray_dup(const strarray* arr) { strarray* dup = strarray_alloc(); - int i; + unsigned int i; for (i = 0; i < arr->size; i++) strarray_add(dup, arr->base[i]); @@ -160,7 +160,7 @@ strarray* strarray_fromstring(const char char* strarray_tostring(const strarray* arr, const char* sep) { char *str, *newstr; - int i; + unsigned int i; str = strmake("%s", arr->base[0]); for (i = 1; i < arr->size; i++) @@ -277,7 +277,7 @@ static file_type guess_lib_type(const ch file_type get_lib_type(strarray* path, const char* library, char** file) { - int i; + unsigned int i; for (i = 0; i < path->size; i++) { @@ -289,7 +289,8 @@ file_type get_lib_type(strarray* path, c void spawn(const strarray* prefix, const strarray* args, int ignore_errors) { - int i, status; + unsigned int i; + int status; strarray* arr = strarray_dup(args); const char** argv; char* prog = 0; diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c index f1aa87e..f1a7bb0 100644 --- a/tools/winegcc/winegcc.c +++ b/tools/winegcc/winegcc.c @@ -170,7 +170,7 @@ struct options static void clean_temp_files(void) { - int i; + unsigned int i; if (keep_generated) return; @@ -239,7 +239,8 @@ static const strarray* get_translator(en static void compile(struct options* opts, const char* lang) { strarray* comp_args = strarray_alloc(); - int j, gcc_defs = 0; + unsigned int j; + int gcc_defs = 0; switch(opts->processor) { @@ -434,7 +435,7 @@ static void build(struct options* opts) const char *output_name, *spec_file, *lang; const char* winebuild = getenv("WINEBUILD"); int generate_app_loader = 1; - int j; + unsigned int j; /* NOTE: for the files array we'll use the following convention: * -axxx: xxx is an archive (.a) @@ -719,7 +720,7 @@ static int is_linker_arg(const char* arg "-static", "-static-libgcc", "-shared", "-shared-libgcc", "-symbolic", "-framework" }; - int j; + unsigned int j; switch (arg[1]) { @@ -769,7 +770,7 @@ static int is_mingw_arg(const char* arg) { "-mno-cygwin", "-mwindows", "-mconsole", "-mthreads", "-municode" }; - int j; + unsigned int j; for (j = 0; j < sizeof(mingw_switches)/sizeof(mingw_switches[0]); j++) if (strcmp(mingw_switches[j], arg) == 0) return 1; -- 1.4.4 --------------------------------- Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070207/4d062c9b/attachment.html From joris_huizer at yahoo.com Wed Feb 7 09:23:00 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Wed Feb 7 09:23:25 2007 Subject: winegcc: sign-compare fixes In-Reply-To: <116527.29393.qm@web52714.mail.yahoo.com> Message-ID: <152240.48757.qm@web52714.mail.yahoo.com> Joris Huizer wrote: I believe this one causes problems -- please do not commit yet Sorry for the spamming - the patch should be alright --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070207/0ad29c83/attachment.html From dmitry at codeweavers.com Wed Feb 7 10:13:09 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Wed Feb 7 10:12:59 2007 Subject: winedump: sign-compare fixes References: <798569.45081.qm@web52709.mail.yahoo.com> Message-ID: <016b01c74ad2$def56440$0100a8c0@DMITRY> "Joris Huizer" wrote: > -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) > +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) Please keep white space unchanged. > - while (ptr - (const unsigned char*)table < len) > + while ((unsigned long)(ptr - (const unsigned char*)table) < len) > - int i, length; > + unsigned long int i, length; > - while (file - (const char*)symbols < sizeof(PDB_SYMBOLS) + symbols->module_size) > + while ((unsigned long int)(file - (const char*)symbols) < sizeof(PDB_SYMBOLS) + symbols->module_size) Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? -- Dmitry. From mk144210 at bcm.tmc.edu Wed Feb 7 11:18:44 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 11:19:40 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170858785.6010.7.camel@misha-laptop> References: <1170858785.6010.7.camel@misha-laptop> Message-ID: <1170868724.6115.3.camel@misha-laptop> On Wed, 2007-02-07 at 08:33 -0600, Misha Koshelev wrote: > Hi, just wanted to double-check with msi ppl and other wine developers > if it's okay to add my conformance test to the test_MsiInstallProduct > function. My reasons for doing this versus a completely separate test > function are as follows: > > 1. The test is already testing a full product install (installs files, > services, registry values, etc) and my modification will simply result > in either no modification to these actions if UI level processing is > good or complete failure if it is bad, which will make the problem very > easy to diagnose. > 2. Looking through instructions on msdn it seems that there isn't a > kosher way to make a very simple MSI file that just, say, writes a > registry value (without doing costing, install validation, having a full > features table, installing some features, etc.) which would make a > separate function easy to implement and it does not really seem > necessary to copy and paste the whole test_MsiInstallProduct (or > similar) function just to check UI level processing. > > I could do a separate function, it just seems unnecessary. > > Misha > > p.s. For some reason, I can't compile the msi crosstests (it gives an > error on linking with -lcabinet, whereas, say, kernel32 crosstests > compile file), so if anyone can crosstest it for me that would be > great :) Alright, got the crosstest to work, no new errors with and without my patch on Windows XP. Misha From wine-devel at kievinfo.com Wed Feb 7 12:20:35 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Wed Feb 7 12:20:59 2007 Subject: advapi32: sign-compare fixes Message-ID: <45CA1873.4060104@kievinfo.com> Joris Huizer wrote: > - int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, > + unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, This isn't right. WideCharToMultiByte returns INT, which is signed. > @@ -1995,11 +1995,11 @@ LookupAccountSidW( > > if (dm) { > BOOL status = TRUE; > - if (*accountSize > lstrlenW(ac)) { > + if (*accountSize > (unsigned)lstrlenW(ac)) { > if (account) > lstrcpyW(account, ac); > } > - if (*domainSize > lstrlenW(dm)) { > + if (*domainSize > (unsigned)lstrlenW(dm)) { > if (domain) > lstrcpyW(domain, dm); > } This isn't correct either. lstrlenW() also returns INT and you can't just cast it to (unsigned). Unsigned what? int/long/dword? Vitaliy. From truiken at gmail.com Wed Feb 7 12:30:18 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 7 12:30:23 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170858652.6010.3.camel@misha-laptop> References: <1170858652.6010.3.camel@misha-laptop> Message-ID: <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> On 2/7/07, Misha Koshelev wrote: > Hi, here is my proposed patch to the current msi MsiInstallProduct > consistency test that will make it's success depend on proper process of > UI flags (as well as everything else it depends on to make a successful > install). It seems to me like this is the simplest way to add this test > (it is only 5-6 lines added total), and it seems fair to me to add it to > this existing test for two reasons: > 1. The test is already testing a full product install (installs files, > services, registry values, etc) and my modification will simply result > in either no modification to these actions if UI level processing is > good or complete failure if it is bad, which will make the problem very > easy to diagnose. > 2. Looking through instructions on msdn it seems that there isn't a > kosher way to make a very simple MSI file that just, say, writes a > registry value (without doing costing, install validation, having a full > features table, installing some features, etc.) which would make a > separate function easy to implement and it does not really seem > necessary to copy and paste the whole test_MsiInstallProduct (or > similar) function just to check UI level processing. > > Changelog: > > * msi: Make MsiInstallProduct conformance test depend on proper UI > level processing. > You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. > If the full UI is started (incorrectly) > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. -- James Hawkins From joris_huizer at yahoo.com Wed Feb 7 12:38:57 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Wed Feb 7 12:39:33 2007 Subject: advapi32: sign-compare fixes In-Reply-To: <45CA1873.4060104@kievinfo.com> Message-ID: <167207.85616.qm@web52713.mail.yahoo.com> Vitaliy Margolen wrote: Joris Huizer wrote: > - int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, > + unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, This isn't right. WideCharToMultiByte returns INT, which is signed. > @@ -1995,11 +1995,11 @@ LookupAccountSidW( > > if (dm) { > BOOL status = TRUE; > - if (*accountSize > lstrlenW(ac)) { > + if (*accountSize > (unsigned)lstrlenW(ac)) { > if (account) > lstrcpyW(account, ac); > } > - if (*domainSize > lstrlenW(dm)) { > + if (*domainSize > (unsigned)lstrlenW(dm)) { > if (domain) > lstrcpyW(domain, dm); > } This isn't correct either. lstrlenW() also returns INT and you can't just cast it to (unsigned). Unsigned what? int/long/dword? Vitaliy. Sorry I'll fix it; Will try and check in future Joris --------------------------------- Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070207/41dced37/attachment.html From mk144210 at bcm.tmc.edu Wed Feb 7 13:09:46 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 13:10:19 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> Message-ID: <1170875386.6115.9.camel@misha-laptop> On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev wrote: > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > consistency test that will make it's success depend on proper process of > > UI flags (as well as everything else it depends on to make a successful > > install). It seems to me like this is the simplest way to add this test > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > this existing test for two reasons: > > 1. The test is already testing a full product install (installs files, > > services, registry values, etc) and my modification will simply result > > in either no modification to these actions if UI level processing is > > good or complete failure if it is bad, which will make the problem very > > easy to diagnose. > > 2. Looking through instructions on msdn it seems that there isn't a > > kosher way to make a very simple MSI file that just, say, writes a > > registry value (without doing costing, install validation, having a full > > features table, installing some features, etc.) which would make a > > separate function easy to implement and it does not really seem > > necessary to copy and paste the whole test_MsiInstallProduct (or > > similar) function just to check UI level processing. > > > > Changelog: > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > level processing. > > > > You need to put whatever you're trying to test into a new test > function. As-is, it's not clear what you're testing and we need to > keep the tests logically separate. Test both a success and a failure > case, plus all the in between cases. > > > If the full UI is started (incorrectly) > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > + * not started (correctly) the InstallExecuteSequence table will be used. > > Why does the install fail if we run the InstallUISequence action?. > Also, InstallExecuteSequence runs no matter what so this comment would > need to be fixed. > a fa Weird, because it does indeed fail when running in full UI mode. Do you know a better (more proper) way to do this then? I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? Thanks Misha From truiken at gmail.com Wed Feb 7 13:23:30 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 7 13:24:00 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170875386.6115.9.camel@misha-laptop> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> Message-ID: <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> On 2/7/07, Misha Koshelev wrote: > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev wrote: > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > consistency test that will make it's success depend on proper process of > > > UI flags (as well as everything else it depends on to make a successful > > > install). It seems to me like this is the simplest way to add this test > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > this existing test for two reasons: > > > 1. The test is already testing a full product install (installs files, > > > services, registry values, etc) and my modification will simply result > > > in either no modification to these actions if UI level processing is > > > good or complete failure if it is bad, which will make the problem very > > > easy to diagnose. > > > 2. Looking through instructions on msdn it seems that there isn't a > > > kosher way to make a very simple MSI file that just, say, writes a > > > registry value (without doing costing, install validation, having a full > > > features table, installing some features, etc.) which would make a > > > separate function easy to implement and it does not really seem > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > similar) function just to check UI level processing. > > > > > > Changelog: > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > level processing. > > > > > > > You need to put whatever you're trying to test into a new test > > function. As-is, it's not clear what you're testing and we need to > > keep the tests logically separate. Test both a success and a failure > > case, plus all the in between cases. > > > > > If the full UI is started (incorrectly) > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > Why does the install fail if we run the InstallUISequence action?. > > Also, InstallExecuteSequence runs no matter what so this comment would > > need to be fixed. > > a fa > > Weird, because it does indeed fail when running in full UI mode. > It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. > > Do you know a better (more proper) way to do this then? > Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. > > I was researching this last night and I found either custom action 19 (this > number is off the top of my head) that will fail the install and display > a message or a failed Launch Condition which will also fail install and > display a message. > Why do you want the install to fail? > The custom action 19 (?) worked beautifully in my > tests, but the problem is that it display a dialog box if it thinks it > is in full UI mode and waits for the user to press okay, and if I > understand correctly user input like this is a no no in writing wine > conformance tests > Correct. No user intervention. > > Do you have any suggestions for how to fail an > install in full UI mode without displaying a dialog box, or would this > be okay in the case of this specific conformance test? > I don't know why you want the install to fail, so I don't have any suggestions. -- James Hawkins From mk144210 at bcm.tmc.edu Wed Feb 7 13:36:42 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 13:37:20 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> Message-ID: <1170877002.6115.17.camel@misha-laptop> On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev wrote: > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > On 2/7/07, Misha Koshelev wrote: > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > consistency test that will make it's success depend on proper process of > > > > UI flags (as well as everything else it depends on to make a successful > > > > install). It seems to me like this is the simplest way to add this test > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > this existing test for two reasons: > > > > 1. The test is already testing a full product install (installs files, > > > > services, registry values, etc) and my modification will simply result > > > > in either no modification to these actions if UI level processing is > > > > good or complete failure if it is bad, which will make the problem very > > > > easy to diagnose. > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > registry value (without doing costing, install validation, having a full > > > > features table, installing some features, etc.) which would make a > > > > separate function easy to implement and it does not really seem > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > similar) function just to check UI level processing. > > > > > > > > Changelog: > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > level processing. > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > function. As-is, it's not clear what you're testing and we need to > > > keep the tests logically separate. Test both a success and a failure > > > case, plus all the in between cases. > > > > > > > If the full UI is started (incorrectly) > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > need to be fixed. > > > a fa > > > > Weird, because it does indeed fail when running in full UI mode. > > > > It's failing because you don't have the InstallUISequence set up > correctly. I suggest you read through msdn about Windows Installer. > > > > > Do you know a better (more proper) way to do this then? > > > > Like I said before, I don't know what you're trying to do. It wasn't > obvious from the last patch. > > > > > I was researching this last night and I found either custom action 19 (this > > number is off the top of my head) that will fail the install and display > > a message or a failed Launch Condition which will also fail install and > > display a message. > > > > Why do you want the install to fail? > > > The custom action 19 (?) worked beautifully in my > > tests, but the problem is that it display a dialog box if it thinks it > > is in full UI mode and waits for the user to press okay, and if I > > understand correctly user input like this is a no no in writing wine > > conformance tests > > > > Correct. No user intervention. > > > > > Do you have any suggestions for how to fail an > > install in full UI mode without displaying a dialog box, or would this > > be okay in the case of this specific conformance test? > > > > I don't know why you want the install to fail, so I don't have any suggestions. > Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account. This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement. Any advice would be appreciated. Thanks. Misha From julliard at winehq.org Wed Feb 7 13:53:14 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 7 13:53:30 2007 Subject: msi: Register the typelib In-Reply-To: <45C9B50D.7040701@codeweavers.com> (Mike McCormack's message of "Wed\, 07 Feb 2007 20\:16\:29 +0900") References: <45C9B50D.7040701@codeweavers.com> Message-ID: <878xf9hhhx.fsf@wine.dyndns.org> Mike McCormack writes: > +ITypeLib *get_msi_typelib( LPWSTR *path ) > +{ > + static CRITICAL_SECTION cs = { NULL, -1, 0, 0, 0, 0 }; Please use the standard pattern for static critical sections. Setting the debug info to NULL is reserved for global sections. -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Wed Feb 7 15:24:45 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 7 15:24:48 2007 Subject: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly. In-Reply-To: <45CA26BD.9050508@codeweavers.com> (Robert Shearman's message of "Wed\, 07 Feb 2007 19\:21\:33 +0000") References: <45CA26BD.9050508@codeweavers.com> Message-ID: <874ppxhd9e.fsf@wine.dyndns.org> Robert Shearman writes: > This fixes a bunch of tmarshal tests. It doesn't seem to make any difference for me: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 make: *** [tmarshal.ok] Error 7 -- Alexandre Julliard julliard@winehq.org From rob at codeweavers.com Wed Feb 7 15:47:31 2007 From: rob at codeweavers.com (Robert Shearman) Date: Wed Feb 7 15:48:02 2007 Subject: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly. In-Reply-To: <874ppxhd9e.fsf@wine.dyndns.org> References: <45CA26BD.9050508@codeweavers.com> <874ppxhd9e.fsf@wine.dyndns.org> Message-ID: <45CA48F3.6090805@codeweavers.com> Alexandre Julliard wrote: > Robert Shearman writes: > > >> This fixes a bunch of tmarshal tests. >> > > It doesn't seem to make any difference for me: > > ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok > tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 > tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 > tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 > make: *** [tmarshal.ok] Error 7 Did you remove ~/.wine? It only registers the typelib if the typelib hasn't already been registered (perhaps this should be changed.) -- Rob Shearman From julliard at winehq.org Wed Feb 7 15:57:07 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 7 15:57:11 2007 Subject: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly. In-Reply-To: <45CA48F3.6090805@codeweavers.com> (Robert Shearman's message of "Wed\, 07 Feb 2007 21\:47\:31 +0000") References: <45CA26BD.9050508@codeweavers.com> <874ppxhd9e.fsf@wine.dyndns.org> <45CA48F3.6090805@codeweavers.com> Message-ID: <87y7n9fx70.fsf@wine.dyndns.org> Robert Shearman writes: > Did you remove ~/.wine? It only registers the typelib if the typelib > hasn't already been registered (perhaps this should be changed.) Ah sorry, I missed that part. Yes, I think that needs to be changed, we can't ask people to rm -rf their .wine dir all the time. At the very least there needs to be an easy way to force the re-registration. -- Alexandre Julliard julliard@winehq.org From rob at codeweavers.com Wed Feb 7 15:57:27 2007 From: rob at codeweavers.com (Robert Shearman) Date: Wed Feb 7 15:57:59 2007 Subject: Undoc. comctl32 mem management functions In-Reply-To: <45C8F2E1.5090400@holycrap.org> References: <45C8F2E1.5090400@holycrap.org> Message-ID: <45CA4B47.3030005@codeweavers.com> Felix Nawothnig wrote: > Hi. comctl32 exports (undocumented) Alloc() and friends which call > LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any > fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() > directly? > > If Global/Local* behave different than Heap* on Windows - wouldn't it > then be desirable to replace the Alloc()/etc. calls in our comctl32 > (we use it all over the place) by Heap*? There are probably quite a few locations where it doesn't make a difference, but there are also probably a few locations where it does. Since it is easier to use the Alloc/ReAlloc/Free functions, why bother changing them to the longer Heap* variants? > > Reason I'm asking: Since it's not documented the Free(NULL) semantics > are not clear (although it's safe in our implementation) - and I'm > wondering if we really want to internally use undocumented functions > with unclear semantics when there is an easy (documented) way. Well, I think it needs to be tested on Windows if Free(NULL) is valid before changing the calls in comctl32. -- Rob Shearman From truiken at gmail.com Wed Feb 7 16:46:13 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 7 16:46:35 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170877002.6115.17.camel@misha-laptop> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> Message-ID: <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> On 2/7/07, Misha Koshelev wrote: > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev wrote: > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > On 2/7/07, Misha Koshelev wrote: > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > consistency test that will make it's success depend on proper process of > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > install). It seems to me like this is the simplest way to add this test > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > this existing test for two reasons: > > > > > 1. The test is already testing a full product install (installs files, > > > > > services, registry values, etc) and my modification will simply result > > > > > in either no modification to these actions if UI level processing is > > > > > good or complete failure if it is bad, which will make the problem very > > > > > easy to diagnose. > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > registry value (without doing costing, install validation, having a full > > > > > features table, installing some features, etc.) which would make a > > > > > separate function easy to implement and it does not really seem > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > similar) function just to check UI level processing. > > > > > > > > > > Changelog: > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > level processing. > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > function. As-is, it's not clear what you're testing and we need to > > > > keep the tests logically separate. Test both a success and a failure > > > > case, plus all the in between cases. > > > > > > > > > If the full UI is started (incorrectly) > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > need to be fixed. > > > > a fa > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > It's failing because you don't have the InstallUISequence set up > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > obvious from the last patch. > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > number is off the top of my head) that will fail the install and display > > > a message or a failed Launch Condition which will also fail install and > > > display a message. > > > > > > > Why do you want the install to fail? > > > > > The custom action 19 (?) worked beautifully in my > > > tests, but the problem is that it display a dialog box if it thinks it > > > is in full UI mode and waits for the user to press okay, and if I > > > understand correctly user input like this is a no no in writing wine > > > conformance tests > > > > > > > Correct. No user intervention. > > > > > > > > Do you have any suggestions for how to fail an > > > install in full UI mode without displaying a dialog box, or would this > > > be okay in the case of this specific conformance test? > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > Ok sorry, I will make it clearer. The reason I am writing this > conformance test is to tickle the bug that my patch fixed earlier (6992) > in which the Vector NTI installer failed because MSI_InstallPackage was > not properly checking the UI level (using the mask) and so having any > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > was making it think a full graphical install was wanted (because > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > that it would only work for a non-UI install (initiated by the actual > main MSI/installer which first sets the internal install level, and not > be the user clicking on one of the "child" MSIs), it would quit with a > message (custom action 19). I would like to make a consistency check > that checks this to make sure that MSI_InstallPackage does in fact check > the UI level correctly, taking the mask on the UILevel property into > account. > > This, my original idea was to have a full install in the > ExecuteSequence, and have just one action in the UISequence that would > fail the install. Thus, to test this check one would set the UI level > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > MSI to install the package. If the package succeeded, that means that > MSI_InstallPackage was checking the UI level correctly (as it does now > since my patch that fixed bug 6992), and everything would be installed. > Otherwise, it would fail, nothing would be installed, and we would know > that the consistency check failed and wine MSI was not properly checking > UI level flags (as it was before my patch and as it would if some > regression occurred, e.g., changes in the MSI_InstallPackage code that > used the UI level without regard for the flags). So that is what I am > trying to do. Just write a conformance test that fails (in some kind of > proper way) in UI install but does not in the non-UI install in a way > that would be easy to determine with an ok(soemthing) statement. > You can't do this test by making the install fail, because you have no way to check why the install failed. Anything you test with the UI sequence cannot present a UI to the user. Why don't you just use a custom action 51 in the install ui seq to set a property to some value, and then make the condition of the component of an install file the value of the property? That way you can check if the file was installed or not. Either way, you're going to have to write a new test function for this. -- James Hawkins From dank at kegel.com Wed Feb 7 18:42:08 2007 From: dank at kegel.com (Dan Kegel) Date: Wed Feb 7 18:42:32 2007 Subject: Helping a user migrate an odbc app to Wine Message-ID: Can somebody help this (german-speaking) fellow: http://www.unixboard.de/vb3/showthread.php?t=26943 He says his company's internal application requires you to input a DSN when installing it, and he doesn't know how to come up with a DSN under Wine. Presumably he doesn't want to mess with Unixodbc, he just wants to keep using the Microsoft drivers...? - Dan From richardvoigt at gmail.com Wed Feb 7 20:42:28 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Wed Feb 7 20:42:27 2007 Subject: winegcc: sign-compare fixes In-Reply-To: <116527.29393.qm@web52714.mail.yahoo.com> References: <20070207141809.67076.qmail@web52711.mail.yahoo.com> <116527.29393.qm@web52714.mail.yahoo.com> Message-ID: <2e59e6970702071842t48327e97o6919092703a8ad48@mail.gmail.com> On 2/7/07, Joris Huizer wrote: > I believe this one causes problems -- please do not commit yet > > Joris Huizer wrote: > > ________________________________ > Need Mail bonding? > Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.>From > 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17 > 00:00:00 2001 > From: Joris Huizer > Date: Wed, 7 Feb 2007 15:19:25 +0100 > Subject: [PATCH] winegcc sign-compare fixes > To: wine-patches > > --- > tools/winegcc/utils.c | 13 +++++++------ > tools/winegcc/winegcc.c | 11 ++++++----- > 2 files changed, 13 insertions(+), 11 deletions(-) > > diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c > index 1af91e9..c144077 100644 > --- a/tools/winegcc/utils.c > +++ b/tools/winegcc/utils.c > @@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c > > void strarray_del(strarray* arr, int i) > { > - if (i < 0 || i >= arr->size) error("Invalid index i=%d", i); > + if (i < 0 || (unsigned int)i >= arr->size) error("Invalid index i=%d", i); The unsigned int comparison here makes the negative check superfluous. Perhaps the argument should even be changed to unsigned as well, to match the range of arr->size (if the element is one byte). > memmove(&arr->base[i], &arr->base[i + 1], (arr->size - i - 1) * > sizeof(arr->base[0])); > arr->size--; > } If the element size could be greater than one byte, the multiplication here should be checked for overflow (actually, this is more necessary when the array is created or expanded). > From richardvoigt at gmail.com Wed Feb 7 20:44:36 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Wed Feb 7 20:44:40 2007 Subject: winedump: sign-compare fixes In-Reply-To: <016b01c74ad2$def56440$0100a8c0@DMITRY> References: <798569.45081.qm@web52709.mail.yahoo.com> <016b01c74ad2$def56440$0100a8c0@DMITRY> Message-ID: <2e59e6970702071844t65007a6fm53b4ef0550512f67@mail.gmail.com> On 2/7/07, Dmitry Timoshkov wrote: > "Joris Huizer" wrote: > > > -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) > > +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) > > Please keep white space unchanged. > > > - while (ptr - (const unsigned char*)table < len) > > + while ((unsigned long)(ptr - (const unsigned char*)table) < len) > > > - int i, length; > > + unsigned long int i, length; > > > - while (file - (const char*)symbols < sizeof(PDB_SYMBOLS) + symbols->module_size) > > + while ((unsigned long int)(file - (const char*)symbols) < sizeof(PDB_SYMBOLS) + symbols->module_size) > > Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', > sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? > Seeing int extended to unsigned long like this makes me question whether the correct type wouldn't be size_t.... especially as it is compared to sizeof(...) > -- > Dmitry. > > > From mk144210 at bcm.tmc.edu Wed Feb 7 20:51:36 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 20:52:11 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> Message-ID: <1170903096.12591.5.camel@misha-laptop> On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev wrote: > > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > > On 2/7/07, Misha Koshelev wrote: > > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > > On 2/7/07, Misha Koshelev wrote: > > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > > consistency test that will make it's success depend on proper process of > > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > > install). It seems to me like this is the simplest way to add this test > > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > > this existing test for two reasons: > > > > > > 1. The test is already testing a full product install (installs files, > > > > > > services, registry values, etc) and my modification will simply result > > > > > > in either no modification to these actions if UI level processing is > > > > > > good or complete failure if it is bad, which will make the problem very > > > > > > easy to diagnose. > > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > > registry value (without doing costing, install validation, having a full > > > > > > features table, installing some features, etc.) which would make a > > > > > > separate function easy to implement and it does not really seem > > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > > similar) function just to check UI level processing. > > > > > > > > > > > > Changelog: > > > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > > level processing. > > > > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > > function. As-is, it's not clear what you're testing and we need to > > > > > keep the tests logically separate. Test both a success and a failure > > > > > case, plus all the in between cases. > > > > > > > > > > > If the full UI is started (incorrectly) > > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > > need to be fixed. > > > > > a fa > > > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > > > > It's failing because you don't have the InstallUISequence set up > > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > > obvious from the last patch. > > > > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > > number is off the top of my head) that will fail the install and display > > > > a message or a failed Launch Condition which will also fail install and > > > > display a message. > > > > > > > > > > Why do you want the install to fail? > > > > > > > The custom action 19 (?) worked beautifully in my > > > > tests, but the problem is that it display a dialog box if it thinks it > > > > is in full UI mode and waits for the user to press okay, and if I > > > > understand correctly user input like this is a no no in writing wine > > > > conformance tests > > > > > > > > > > Correct. No user intervention. > > > > > > > > > > > Do you have any suggestions for how to fail an > > > > install in full UI mode without displaying a dialog box, or would this > > > > be okay in the case of this specific conformance test? > > > > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > > > > Ok sorry, I will make it clearer. The reason I am writing this > > conformance test is to tickle the bug that my patch fixed earlier (6992) > > in which the Vector NTI installer failed because MSI_InstallPackage was > > not properly checking the UI level (using the mask) and so having any > > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > > was making it think a full graphical install was wanted (because > > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > > that it would only work for a non-UI install (initiated by the actual > > main MSI/installer which first sets the internal install level, and not > > be the user clicking on one of the "child" MSIs), it would quit with a > > message (custom action 19). I would like to make a consistency check > > that checks this to make sure that MSI_InstallPackage does in fact check > > the UI level correctly, taking the mask on the UILevel property into > > account. > > > > This, my original idea was to have a full install in the > > ExecuteSequence, and have just one action in the UISequence that would > > fail the install. Thus, to test this check one would set the UI level > > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > > MSI to install the package. If the package succeeded, that means that > > MSI_InstallPackage was checking the UI level correctly (as it does now > > since my patch that fixed bug 6992), and everything would be installed. > > Otherwise, it would fail, nothing would be installed, and we would know > > that the consistency check failed and wine MSI was not properly checking > > UI level flags (as it was before my patch and as it would if some > > regression occurred, e.g., changes in the MSI_InstallPackage code that > > used the UI level without regard for the flags). So that is what I am > > trying to do. Just write a conformance test that fails (in some kind of > > proper way) in UI install but does not in the non-UI install in a way > > that would be easy to determine with an ok(soemthing) statement. > > > > You can't do this test by making the install fail, because you have no > way to check why the install failed. Anything you test with the UI > sequence cannot present a UI to the user. Why don't you just use a > custom action 51 in the install ui seq to set a property to some > value, and then make the condition of the component of an install file > the value of the property? That way you can check if the file was > installed or not. Either way, you're going to have to write a new > test function for this. > That sounds good. I actually made a new function doing what you said, and in testing under the wine MSI it works perfectly (writes specific file in UI mode but not in execute only mode, returns success, everything okay), but when I tried in XP I got a very weird behavior (or maybe not so weird). Specifically, XP MSI seems to reset the property between the UI sequence and execute sequence (no errors occur, but the file does not get written in UI sequence; if I take the condition out the file does get written; in fact I decided to make a custom action called StopMessage that displays the value of my property, that is simply a custom action 19, and in Wine MSI it displays my modified property value if I put it in the UI table or the execute table, but in Win XP MSI it only displays my modified value in the UI table, but in the Execute table it goes back either to blank or to the initial value if I define it in Properties; I even tried adding it to the SecureCustomProperties property but it did not help). Is this just a weird XP thing that I should just ignore and post my code as is, or is there some other way to set a property in the UI sequence that retains its value in the execute sequence in wine and XP? What if wine MSI decides to copy this behavior at a later date, my conformance test would not work anymore. Thanks Misha From truiken at gmail.com Wed Feb 7 21:05:16 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 7 21:05:10 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170903096.12591.5.camel@misha-laptop> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> <1170903096.12591.5.camel@misha-laptop> Message-ID: <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> On 2/7/07, Misha Koshelev wrote: > On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev wrote: > > > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > > > On 2/7/07, Misha Koshelev wrote: > > > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > > > On 2/7/07, Misha Koshelev wrote: > > > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > > > consistency test that will make it's success depend on proper process of > > > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > > > install). It seems to me like this is the simplest way to add this test > > > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > > > this existing test for two reasons: > > > > > > > 1. The test is already testing a full product install (installs files, > > > > > > > services, registry values, etc) and my modification will simply result > > > > > > > in either no modification to these actions if UI level processing is > > > > > > > good or complete failure if it is bad, which will make the problem very > > > > > > > easy to diagnose. > > > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > > > registry value (without doing costing, install validation, having a full > > > > > > > features table, installing some features, etc.) which would make a > > > > > > > separate function easy to implement and it does not really seem > > > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > > > similar) function just to check UI level processing. > > > > > > > > > > > > > > Changelog: > > > > > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > > > level processing. > > > > > > > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > > > function. As-is, it's not clear what you're testing and we need to > > > > > > keep the tests logically separate. Test both a success and a failure > > > > > > case, plus all the in between cases. > > > > > > > > > > > > > If the full UI is started (incorrectly) > > > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > > > need to be fixed. > > > > > > a fa > > > > > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > > > > > > > It's failing because you don't have the InstallUISequence set up > > > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > > > obvious from the last patch. > > > > > > > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > > > number is off the top of my head) that will fail the install and display > > > > > a message or a failed Launch Condition which will also fail install and > > > > > display a message. > > > > > > > > > > > > > Why do you want the install to fail? > > > > > > > > > The custom action 19 (?) worked beautifully in my > > > > > tests, but the problem is that it display a dialog box if it thinks it > > > > > is in full UI mode and waits for the user to press okay, and if I > > > > > understand correctly user input like this is a no no in writing wine > > > > > conformance tests > > > > > > > > > > > > > Correct. No user intervention. > > > > > > > > > > > > > > Do you have any suggestions for how to fail an > > > > > install in full UI mode without displaying a dialog box, or would this > > > > > be okay in the case of this specific conformance test? > > > > > > > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > > > > > > > Ok sorry, I will make it clearer. The reason I am writing this > > > conformance test is to tickle the bug that my patch fixed earlier (6992) > > > in which the Vector NTI installer failed because MSI_InstallPackage was > > > not properly checking the UI level (using the mask) and so having any > > > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > > > was making it think a full graphical install was wanted (because > > > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > > > that it would only work for a non-UI install (initiated by the actual > > > main MSI/installer which first sets the internal install level, and not > > > be the user clicking on one of the "child" MSIs), it would quit with a > > > message (custom action 19). I would like to make a consistency check > > > that checks this to make sure that MSI_InstallPackage does in fact check > > > the UI level correctly, taking the mask on the UILevel property into > > > account. > > > > > > This, my original idea was to have a full install in the > > > ExecuteSequence, and have just one action in the UISequence that would > > > fail the install. Thus, to test this check one would set the UI level > > > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > > > MSI to install the package. If the package succeeded, that means that > > > MSI_InstallPackage was checking the UI level correctly (as it does now > > > since my patch that fixed bug 6992), and everything would be installed. > > > Otherwise, it would fail, nothing would be installed, and we would know > > > that the consistency check failed and wine MSI was not properly checking > > > UI level flags (as it was before my patch and as it would if some > > > regression occurred, e.g., changes in the MSI_InstallPackage code that > > > used the UI level without regard for the flags). So that is what I am > > > trying to do. Just write a conformance test that fails (in some kind of > > > proper way) in UI install but does not in the non-UI install in a way > > > that would be easy to determine with an ok(soemthing) statement. > > > > > > > You can't do this test by making the install fail, because you have no > > way to check why the install failed. Anything you test with the UI > > sequence cannot present a UI to the user. Why don't you just use a > > custom action 51 in the install ui seq to set a property to some > > value, and then make the condition of the component of an install file > > the value of the property? That way you can check if the file was > > installed or not. Either way, you're going to have to write a new > > test function for this. > > > > That sounds good. I actually made a new function doing what you said, > and in testing under the wine MSI it works perfectly (writes specific > file in UI mode but not in execute only mode, returns success, > everything okay), but when I tried in XP I got a very weird behavior (or > maybe not so weird). Specifically, XP MSI seems to reset the property > between the UI sequence and execute sequence (no errors occur, but the > file does not get written in UI sequence; if I take the condition out > the file does get written; in fact I decided to make a custom action > called StopMessage that displays the value of my property, that is > simply a custom action 19, and in Wine MSI it displays my modified > property value if I put it in the UI table or the execute table, but in > Win XP MSI it only displays my modified value in the UI table, but in > the Execute table it goes back either to blank or to the initial value > if I define it in Properties; I even tried adding it to the > SecureCustomProperties property but it did not help). Is this just a > weird XP thing that I should just ignore and post my code as is, or is > there some other way to set a property in the UI sequence that retains > its value in the execute sequence in wine and XP? What if wine MSI > decides to copy this behavior at a later date, my conformance test would > not work anymore. > Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table? http://msdn2.microsoft.com/en-us/library/aa370912.aspx -- James Hawkins From mk144210 at bcm.tmc.edu Wed Feb 7 23:20:35 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 23:21:05 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> <1170903096.12591.5.camel@misha-laptop> <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> Message-ID: <1170912035.12591.12.camel@misha-laptop> > Well, by definition, that's not really a conformance test because it > doesn't conform to windows. Did you make the property public and add > the property to the Property table? > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > First of all, I added the Property to the Property table, which is, what I understand from that link (paragraph three I think) all that it takes to make it public (in fact, what happens when you go from UI to Execute is that the value of the property seems to be reset back to the value from the Properties table). Two things: 1) I am testing the behavior in UI mode to make sure the test works, but the actual "test" is to test the mode NONE | otherflags, which, before the bug fix, would result in a UI install, whereas in Windows (all versions) it would result in an execute-only install. This test breaks on wine without the patch to fix it, whereas it would execute on all Windows version without error, thus in this sense it "conforms" to Windows. The question is whether we are able to detect a failure to conform. 2) I tried on Win98 and in Win98 it works the same way it does on Wine. I will play with it some more, but because of these points it seems to me that it is still a reasonable test (it will succeed on all version of Windows, on Wine that properly detects UI flags, but fail on wine that does not detect UI flags; however, in the future, if wine MSI is made more like Win XP MSI, it would be possible that we will not be able to detect failure anymore). Misha From mk144210 at bcm.tmc.edu Wed Feb 7 23:43:36 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 7 23:44:34 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> <1170903096.12591.5.camel@misha-laptop> <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> Message-ID: <1170913416.12591.13.camel@misha-laptop> > Well, by definition, that's not really a conformance test because it > doesn't conform to windows. Did you make the property public and add > the property to the Property table? > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Misha From truiken at gmail.com Wed Feb 7 23:46:38 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 7 23:46:29 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <1170913416.12591.13.camel@misha-laptop> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> <1170903096.12591.5.camel@misha-laptop> <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> <1170913416.12591.13.camel@misha-laptop> Message-ID: <22821af30702072146i7139c5b4ic7baed44e38f4e85@mail.gmail.com> On 2/7/07, Misha Koshelev wrote: > > > Well, by definition, that's not really a conformance test because it > > doesn't conform to windows. Did you make the property public and add > > the property to the Property table? > > > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > > > > Aha, google search figured it out: > > * Property name ALL CAPS - passed from UI to execute. > * otherwise not. > > Too bad it's not documented on msdn (you think they would...) > "Properties with names containing no lowercase letters are public properties..." http://msdn2.microsoft.com/en-us/library/aa370905.aspx -- James Hawkins From mk144210 at bcm.tmc.edu Thu Feb 8 00:21:36 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Thu Feb 8 00:22:00 2007 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. In-Reply-To: <22821af30702072146i7139c5b4ic7baed44e38f4e85@mail.gmail.com> References: <1170858652.6010.3.camel@misha-laptop> <22821af30702071030p7942b9d0wdb0f4166c3c4b75f@mail.gmail.com> <1170875386.6115.9.camel@misha-laptop> <22821af30702071123y5a71ee62x4e809430b9ea7796@mail.gmail.com> <1170877002.6115.17.camel@misha-laptop> <22821af30702071446y4db9c084kb107649452c3077e@mail.gmail.com> <1170903096.12591.5.camel@misha-laptop> <22821af30702071905m3f209254q13b99d18900d14ea@mail.gmail.com> <1170913416.12591.13.camel@misha-laptop> <22821af30702072146i7139c5b4ic7baed44e38f4e85@mail.gmail.com> Message-ID: <1170915697.12591.16.camel@misha-laptop> On Wed, 2007-02-07 at 23:46 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev wrote: > > > > > Well, by definition, that's not really a conformance test because it > > > doesn't conform to windows. Did you make the property public and add > > > the property to the Property table? > > > > > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > > > > > > > Aha, google search figured it out: > > > > * Property name ALL CAPS - passed from UI to execute. > > * otherwise not. > > > > Too bad it's not documented on msdn (you think they would...) > > > > "Properties with names containing no lowercase letters are public properties..." > > http://msdn2.microsoft.com/en-us/library/aa370905.aspx > Too bad I don't read things carefully enough :) Anyway, I am sending the patch to wine-patches now. It is able to determine UI level properly (UI vs execute-only) on Win98, WinXP, and wine. Phew, time to go to bed. Misha From kai.blin at gmail.com Thu Feb 8 01:23:02 2007 From: kai.blin at gmail.com (Kai Blin) Date: Thu Feb 8 01:24:35 2007 Subject: Helping a user migrate an odbc app to Wine In-Reply-To: References: Message-ID: <200702080823.09175.kai.blin@gmail.com> On Thursday 08 February 2007 01:42, Dan Kegel wrote: > Can somebody help this (german-speaking) fellow: > http://www.unixboard.de/vb3/showthread.php?t=26943 > > He says his company's internal application requires > you to input a DSN when installing it, and he doesn't > know how to come up with a DSN under Wine. The german speaking part is not a problem, I just don't know my way around that odbc stuff, not even on win32 native. > Presumably he doesn't want to mess with Unixodbc, > he just wants to keep using the Microsoft drivers...? I figure using the appropriate native dlls would work? I vaguely remember Windows had a tool to set up odbc drivers, what was the exe called? Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/ab57d684/attachment.pgp From rob at codeweavers.com Thu Feb 8 01:45:45 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 8 01:46:22 2007 Subject: ole32: Remove casts In-Reply-To: <45CA8332.9090101@codeweavers.com> References: <45CA8332.9090101@codeweavers.com> Message-ID: <45CAD529.6050000@codeweavers.com> Mike McCormack wrote: > --- > This is the way ref counting is done everywhere else in Wine. > > Ref counts can be assumed to be between 0 and MAXLONG, so the fact > that LONG is signed isn't important. NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, therefore the ref counts can be assumed to be up to MAXULONG. Therefore, this change is incorrect and it would lead to subtle signedness errors. > > Casting ULONG* to LONG* to solve the above problem is unnecessary. > -- Rob Shearman From mike at codeweavers.com Thu Feb 8 02:00:21 2007 From: mike at codeweavers.com (Mike McCormack) Date: Thu Feb 8 02:00:20 2007 Subject: ole32: Remove casts In-Reply-To: <45CAD529.6050000@codeweavers.com> References: <45CA8332.9090101@codeweavers.com> <45CAD529.6050000@codeweavers.com> Message-ID: <45CAD895.1040206@codeweavers.com> Robert Shearman wrote: >> Ref counts can be assumed to be between 0 and MAXLONG, so the fact >> that LONG is signed isn't important. > > NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, > therefore the ref counts can be assumed to be up to MAXULONG. Therefore, > this change is incorrect and it would lead to subtle signedness errors. Do you have a specific example of these errors? The only operations that are done (and should be done) on ref counts are initialization, InterlockedIncrement and InterlockedDecrement. asm generated will be exactly the same. In the highly unlikely case that the refcount passes MAXLONG, the behaviour will still be correct, but if refcounts are getting up that high, then you need to start worrying about them wrapping around to zero anyway. Casts are more problematic than the problems that you're imagining. Mike From r.kalbermatter at hccnet.nl Thu Feb 8 02:38:00 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Thu Feb 8 02:38:22 2007 Subject: Helping a user migrate an odbc app to Wine In-Reply-To: Message-ID: <003101c74b5c$70d9b9e0$4001a8c0@glis> Dan Kegel [mailto:dank@kegel.com] wrote: >Can somebody help this (german-speaking) fellow: >http://www.unixboard.de/vb3/showthread.php?t=26943 > >He says his company's internal application requires you to >input a DSN when installing it, and he doesn't know how to >come up with a DSN under Wine. Hmm, the DSN is just a name. You first would have to configure it and yes that means under Wine to deal with unixODBC. Alternatively you could change the connection string to pass all relevant information to the driver directly and have the configuration of those parameters in the application itself. >Presumably he doesn't want to mess with Unixodbc, he just wants >to keep using the Microsoft drivers...? Ouch, I wouldn't see how this could work. Running the Microsoft drivers together with the whole Microsoft ODBC manager under Wine too would probably be the only way to get that working. But I think it is safe to assume that that would require quite some work in Wine before this could possibly work, not to talk about license issues. Rolf Kalbermatter From meissner at suse.de Thu Feb 8 03:53:21 2007 From: meissner at suse.de (Marcus Meissner) Date: Thu Feb 8 03:53:31 2007 Subject: [PATCH] coverity: CID35: fixed wrong condition In-Reply-To: <45C8C6F8.30109@holycrap.org> References: <45C7A1B3.9040203@holycrap.org> <20070206105207.GA32523@suse.de> <45C8C6F8.30109@holycrap.org> Message-ID: <20070208095321.GA1569@suse.de> On Tue, Feb 06, 2007 at 07:20:40PM +0100, Felix Nawothnig wrote: > Marcus Meissner wrote: > >>>- if(nRelPos>=0) { /* if this or preceding row */ > >>>+ if(nRelPos<=0) { /* if this or preceding row */ > >>> while(nRelPos<=0) { > >>Shouldn't that become a "do { ... } while()" then? > >No, since there is a return item; after the while () loop. > > I meant replacing just the while(), not the if() while(). > > It's mostly a matter of style though as gcc most likely will compile it > to a do {} while() anyway. I only wanted to do the minimalistic change to avoid errors creeping in ;) Ciao, Marcus From fgouget at free.fr Thu Feb 8 05:49:26 2007 From: fgouget at free.fr (Francois Gouget) Date: Thu Feb 8 05:49:18 2007 Subject: advapi32: sign-compare fixes In-Reply-To: <45CA1873.4060104@kievinfo.com> References: <45CA1873.4060104@kievinfo.com> Message-ID: On Wed, 7 Feb 2007, Vitaliy Margolen wrote: [...] > This isn't correct either. lstrlenW() also returns INT and you > can't just cast it to (unsigned). Unsigned what? int/long/dword? In C, 'unsigned' is synonymous with 'unsigned int'. So it's unambiguous. -- Francois Gouget http://fgouget.free.fr/ Dieu dit: "M-x Lumi?re". Et la lumi?re fut. From xixsimplicityxix at gmail.com Thu Feb 8 08:04:11 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Thu Feb 8 08:04:24 2007 Subject: RasError.h? Where is this or does it not exist? Message-ID: <78a7dad00702080604w74f0cb26i6daccf11adf194aa@mail.gmail.com> Hey all, I cannot find the raserror.h file. I have tried looking around the wine directories to no avail. A find ./wine -name raserror.h -type f -print turns up nothing. Am I looking in the wrong spot or in the wrong way? I really want to think that the file isn't there but I can't rule out that I'm not somewhat stupid =P. So I appeal to you such wise guys as you are. Sorry for the dumb question, I just would hate to make the file if it already exists somewhere. Regards, John Klehm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070208/7cd85887/attachment.html From xixsimplicityxix at gmail.com Thu Feb 8 08:54:11 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Thu Feb 8 08:54:04 2007 Subject: [GDI32] Fix for GetTextExtentExPointW() and ExtTextOutW() - Fixes Bug 50 In-Reply-To: References: Message-ID: <78a7dad00702080654o57b7081dse79cac0d8d2682e2@mail.gmail.com> Hey Pedro, Was there supposed to be an attachment on your last message? I didn't see one. Regards, John Klehm On 2/8/07, Pedro Araujo Chaves Jr. wrote: > > Attached is my proposed patch for Bug #50; the test case was attached > in my previous message. > -- > Patch description: > > This patch fixes Wine's Bug #50: "PrgWin95: Text justification needs > beefing up". > > What it does: first, it takes in consideration that not always the > number of extra pixels will be a multiple of the number of break > characters in a given extent of a given string that should be > justified, and so the integer division of extra by breaks in > SetTextJustification() is likely to leave a remainder (which the > latter function addresses, of course, but ExtTextOutW() seems to > overlook ? that's the reason for the changes at lines 1788 (breakRem), > and 1901 and 1922 (dc->breakExtra || breakRem), which prevent some > lines from being ignored in the justification). > > That fixed, if there remained any pixels indeed, their number > shouldn't be greater than dc->breakCount; then the first breakRem > break characters in that given extent are widened by one pixel (lines > 1925-1929 added). > > GetTextExtentExPointW() is also fixed so that it now returns the > expected width of the text when it is to be justified. This has the > good side effect that TabbedTextOut() now also returns the proper > width when called after SetTextJustification(). What the patch does > here is that GetTextExtentExPointW() now calculates the extra width > only when (breakExtra || breakRem) resolves TRUE , and corrects the > extra space additions by applying them only to break characters. What > was broken before is that it always added extra space, regardless of > whether it was measuring a single character or a full string, or > whether it was a break character or not. (Lines added: 1191, 1199, > 1227, 1229, 1236-1245, 1254-1268). > > This patch is copyrighted by Banco do Brasil under the LGPL. > > -- > Regards, > Pedro Ara?jo. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070208/146b6933/attachment.htm From wine-devel at kievinfo.com Thu Feb 8 09:38:07 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Thu Feb 8 09:38:29 2007 Subject: [2] wineshelllink: Keep using the slash as path separator. Message-ID: <45CB43DF.2030205@kievinfo.com> Hans Leidekker wrote: > Fixes incorrect handling of paths with dashes. > And creates invalid menu entries. Did you test this patch with multi-level menu structure? When I tried your patch it created all menu entries in the top level menu, with the name like: wine-Programs-Ubi Soft-IL-2 Sturmovik Demo Instead of being a menu: wine Programs Ubi Soft IL-2 Sturmovik Demo Last one is the way it should be but now it's 2 menus: IL 2 Sturmovik Demo Vitaliy. From joris_huizer at yahoo.com Thu Feb 8 10:36:15 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Thu Feb 8 10:36:42 2007 Subject: winegcc: sign-compare fixes In-Reply-To: <2e59e6970702071842t48327e97o6919092703a8ad48@mail.gmail.com> Message-ID: <581692.69421.qm@web52703.mail.yahoo.com> --- "richardvoigt@gmail.com" wrote: > On 2/7/07, Joris Huizer > wrote: > > I believe this one causes problems -- please do > not commit yet > > > > Joris Huizer wrote: > > > > ________________________________ > > Need Mail bonding? > > Go to the Yahoo! Mail Q&A for great tips from > Yahoo! Answers users.>From > > 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep > 17 > > 00:00:00 2001 > > From: Joris Huizer > > Date: Wed, 7 Feb 2007 15:19:25 +0100 > > Subject: [PATCH] winegcc sign-compare fixes > > To: wine-patches > > > > --- > > tools/winegcc/utils.c | 13 +++++++------ > > tools/winegcc/winegcc.c | 11 ++++++----- > > 2 files changed, 13 insertions(+), 11 > deletions(-) > > > > diff --git a/tools/winegcc/utils.c > b/tools/winegcc/utils.c > > index 1af91e9..c144077 100644 > > --- a/tools/winegcc/utils.c > > +++ b/tools/winegcc/utils.c > > @@ -120,14 +120,14 @@ void strarray_add(strarray* > arr, const c > > > > void strarray_del(strarray* arr, int i) > > { > > - if (i < 0 || i >= arr->size) error("Invalid > index i=%d", i); > > + if (i < 0 || (unsigned int)i >= arr->size) > error("Invalid index i=%d", i); > > The unsigned int comparison here makes the negative > check superfluous. > Perhaps the argument should even be changed to > unsigned as well, to > match the range of arr->size (if the element is one > byte). Alright, that makes sence, will do > > > memmove(&arr->base[i], &arr->base[i + 1], > (arr->size - i - 1) * > > sizeof(arr->base[0])); > > arr->size--; > > } > > If the element size could be greater than one byte, > the multiplication > here should be checked for overflow (actually, this > is more necessary > when the array is created or expanded). > > > > Well, the base field in the structure is defined as "const char** base" so sizeof(base[0]) == sizeof(const char *), should be 4 or so. How do you mean overflow in this case? sorry for asking dumb questions... ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 From billmedland at shaw.ca Thu Feb 8 10:50:00 2007 From: billmedland at shaw.ca (Bill Medland) Date: Thu Feb 8 10:50:15 2007 Subject: RedHat rpms Message-ID: <1170953400.8373.5.camel@medbi01-9.localdomain> Just checking I'm looking to see if there are rpms being built for Red Hate Enterprise Linux 3 these days. I see that the Red Hat rpms nowadays are for fc. but they aren't suitable for RHEL3 The download page says that the RedHat/Fedora area is for RedAht 8,9 and fedora, but I don't see any RedHat 8 or 9 there. Are they not there or am I looking in the wrong place? -- Bill Medland From stefandoesinger at gmx.at Thu Feb 8 11:25:43 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Thu Feb 8 11:26:13 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <45C75925.9010501@gmail.com> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <200702021645.23102.stefandoesinger@gmx.at> <45C75925.9010501@gmail.com> Message-ID: <200702081825.48363.stefandoesinger@gmx.at> Am Montag 05 Februar 2007 17:19 schrieb Mitchell Mebane: > How much work would this be? I know nothing about Windows or X11 > programming, but is it something that I might be able to study up on and > propose for a Summer of Code project? It was suggested as a SOC project last year, but nobody showed interest in it. So I guess yes. Search a bit in the forums, there is a lot of information about this topic, and transgaming offered us their GDI engine some time ago, but it never made it into the wine tree(don't ask me for the details, but I think Alexandre didn't like it). So you have some code to illustrate what needs to be done. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/04be10d3/attachment.pgp From stefandoesinger at gmx.at Thu Feb 8 12:01:04 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Thu Feb 8 12:02:06 2007 Subject: DirectDrawRenderer=opengl - screen size changeable for final rendering? In-Reply-To: <20070206131332.GW1252@byleth.sc-networks.de> References: <20070206131332.GW1252@byleth.sc-networks.de> Message-ID: <200702081901.14117.stefandoesinger@gmx.at> Am Dienstag 06 Februar 2007 14:13 schrieb Christoph Frick: > hiho > > what i ever wondered but never dared to ask: > > i tried recently the said key with jagged alliance 2. as the game has > quite a low resolution 640 or 800 it would be nice to allow higher > resolutions when rendering ddraw with opengl (e.g. game wants 800 but > for the final rendering use 1600). is this doable via registry or > somewhere else? for the files: i run the apps in desktop-mode. Do you mean if if you can use a higher resolution than the game sets? For Direct3D games this can work, but for DirectDraw it is going to fail. Direct3D games which draw only untransformed vertices pass coordinates in the range of [-1.0 ; +1.0], which later get scaled to viewport coordinates. With a different viewport we can trick the game into doing that. It will get tricky when the app draws transformed vertices(which have screen coordinates). DirectDraw games access the screen directly by using coordinates from 0, 0 to with, height. If wine makes the surface bigger the rendering will just end up in a corner. The best thing we can do is to scale it, but that is what your monitor does if you set a lower resoltution. So you *may* be able to trick the game into using a different resolution, but this will have to be a per-game hack and can't be done in general. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/14661c12/attachment.pgp From thestig at google.com Thu Feb 8 12:09:19 2007 From: thestig at google.com (Lei Zhang) Date: Thu Feb 8 12:10:09 2007 Subject: RedHat rpms In-Reply-To: <1170953400.8373.5.camel@medbi01-9.localdomain> References: <1170953400.8373.5.camel@medbi01-9.localdomain> Message-ID: <558b2f5c0702081009q12a209bbgd684ed02e33941@mail.gmail.com> I build RPMs for RHEL 3, give them a try: http://linux.ucla.edu/~leiz/software/wine/rpms.php On 2/8/07, Bill Medland wrote: > Just checking > > I'm looking to see if there are rpms being built for Red Hate Enterprise > Linux 3 these days. > I see that the Red Hat rpms nowadays are for fc. but they aren't > suitable for RHEL3 > The download page says that the RedHat/Fedora area is for RedAht 8,9 and > fedora, but I don't see any RedHat 8 or 9 there. Are they not there or > am I looking in the wrong place? > -- > Bill Medland > > > > From stefandoesinger at gmx.at Thu Feb 8 12:10:03 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 8 12:11:13 2007 Subject: How to find rendering code In-Reply-To: <200702070014.50521.kde@3danim.de> References: <200702070014.50521.kde@3danim.de> Message-ID: <200702081910.07399.stefandoesinger@gmx.at> Am Mittwoch 07 Februar 2007 00:14 schrieb Markus: > Hi, > > I am new to Wine development and wanted to ask on the list, whether someone > could point me to the correct place where the code for issues 3 and 4 in > http://bugs.winehq.org/show_bug.cgi?id=7273 might be located. It looks like > the solution could be rather straightforward to implement but I have no > idea how to find the respective rendering method. The first step is usually to find out which library the game uses for rendering: Try some debug channels: d3d7, d3d8, d3d9, opengl . Whatever channel spits out most lines during rendering is the most likely rendering method used. I suspect d3d9 for this game. For d3d games the code you will find most interesting is in dlls/wined3d. Opengl is located in dlls/opengl32 and dlls/winex11.drv. d3d7 has some parts in dlls/ddraw, d3d8 in dlls/d3d8 and d3d9 in dlls/d3d9. But those libraries are usually not the cause for bugs like the ones you see. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/d25aed41/attachment.pgp From frick at sc-networks.de Thu Feb 8 12:19:54 2007 From: frick at sc-networks.de (Christoph Frick) Date: Thu Feb 8 12:19:59 2007 Subject: DirectDrawRenderer=opengl - screen size changeable for final rendering? In-Reply-To: <200702081901.14117.stefandoesinger@gmx.at> References: <20070206131332.GW1252@byleth.sc-networks.de> <200702081901.14117.stefandoesinger@gmx.at> Message-ID: <20070208181954.GV1252@byleth.sc-networks.de> On Thu, Feb 08, 2007 at 07:01:04PM +0100, Stefan D?singer wrote: > DirectDraw games access the screen directly by using coordinates from > 0, 0 to with, height. If wine makes the surface bigger the rendering > will just end up in a corner. The best thing we can do is to scale it, > but that is what your monitor does if you set a lower resoltution. thats the point. i dont know how wine handles the ddraw-over-opengl scenario. i just had very blury graphics in JA2. nothing to wonder about as i assume at least one quad is drawn with the image as texture. so the filtering kicks in and voila we have bad image quality. so i wondered if i could configre somewhere to render this quad instead of 800x600 like the app wants it but with 1600x1200 i would get quite some good antialiasing for this old game. this would of course assume, that wine "fakes" the screen until a redraw, where the polygon is drawn again. if i would just change the res of the monitor there i get also some fsaa for free because the tft would scale it for me - changing the res each time is a cumbersome task for one how does not like to change res at all ;) > So you *may* be able to trick the game into using a different > resolution, but this will have to be a per-game hack and can't be done > in general. assuming that my "render a quad" theory is right it would work to place a key in the registry, where i would tell the ogl-ddraw-renderer to use my res instead of the one the apps wants. -- cu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/9e438d2f/attachment.pgp From marcus at jet.franken.de Thu Feb 8 13:11:33 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Thu Feb 8 13:11:50 2007 Subject: winealsa commit d2f29311caa8041bd992a3867d71d6311c7ff8fa Message-ID: <20070208191133.GA5129@galeere> Hi Marten, Your commit: http://source.winehq.org/git/wine.git/?a=commit;h=d2f29311caa8041bd992a3867d71d6311c7ff8fa Has some regressions on Coverity. Namely Coverity complains that "areas" is used uninitializied. And yes it is: static DWORD CALLBACK DBSB_MMAPLoop(LPVOID data) { IDsDriverBufferImpl* pdbi = (IDsDriverBufferImpl*)data; WINE_WAVEDEV *wwo = &(WOutDev[pdbi->drv->wDevID]); snd_pcm_uframes_t frames, wanted, ofs; const snd_pcm_channel_area_t *areas; int state = WINE_WS_STOPPED; snd_pcm_state_t alsastate; TRACE_(waveloop)("0x%8p\n", data); TRACE("0x%8p, framelength: %lu, area: %8p\n", data, pdbi->mmap_buflen_frames, pdbi->mmap_areas); if (areas != pdbi->mmap_areas || areas->addr != pdbi->mmap_areas->addr) FIXME("Can't access sound driver's buffer directly.\n"); Please fix :) Ciao, Marcus From joonas.koivunen at gmail.com Wed Feb 7 14:43:41 2007 From: joonas.koivunen at gmail.com (Joonas Koivunen) Date: Thu Feb 8 13:32:50 2007 Subject: Getting Fallout 2 to work well In-Reply-To: <45C75925.9010501@gmail.com> References: <47bdc81c0702012334n7b4c4b72xaf5fcfe1503a21b9@mail.gmail.com> <200702021645.23102.stefandoesinger@gmx.at> <45C75925.9010501@gmail.com> Message-ID: <47bdc81c0702071243j5f4343fdr9f7fbe76bc040884@mail.gmail.com> 2007/2/5, Mitchell Mebane : > > Stefan D?singer wrote: > > Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > > Profiling with oprofile (GDI session) shows that most of the time is used > in the game (I suppose it's the "anon" from wine-preload), next most time > consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be > > doing the conversion. > > It seems that you have a game that has problems with the gdi engine(or lack > thereof): http://wiki.winehq.org/DIBEngine > > http://bugs.winehq.org/show_bug.cgi?id=421 > > How much work would this be? I know nothing about Windows or X11 > programming, but is it something that I might be able to study up on and > propose for a Summer of Code project? > > --mmebane > For the past days, after Stefan pointed me to that bug and article, I've been trying to figure out what would be needed in order to fasten at least Fallout 2 up. I haven't been able to pinpoint any call made by the game requesting an image from X, and it always blits the whole screen at a time. Doing 640x480 8bpp -> 32bpp seems to be the problem and the fact that it does as many as possible blits. Nor have I been able to find a call asking it to blend two surfaces.. Could someone give me any hints on this? The 8bpp -> 32bpp conversion could possibly be optimized.. But I haven't yet looked at it. A bit out of topic; playing fallout2.exe makes X11 grow much larger, and it doesn't seem to free the memory. A SoC project sounds great! -- -- Joonas Koivunen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070207/36afb839/attachment.htm From esrever_otua at pythonhacker.is-a-geek.net Thu Feb 8 02:52:22 2007 From: esrever_otua at pythonhacker.is-a-geek.net (Darryl Dixon) Date: Thu Feb 8 13:32:51 2007 Subject: IE Dev Toolbar now compatible! Message-ID: <1170924742.24765.6.camel@darrylsfc3box.ddnet.co.nz> Hi All, Just a brief to let you know that it looks like Microsoft is finally taking compatability seriously ;) - the new Beta 3 version of the IE Developers Toolbar (http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en) improves on the previous Beta release by installing and working correctly with wine 0.9.30 with an IE6 'ies4linux' install. In the previous Beta, the 'View DOM' button did not work in wine 0.9.30 - this new version fixes that and adds lots of enhancements. I don't know if this is useful to many here, but it sure is for me, so I thought I'd share. Nice to see Microsoft improving their software to work better with Wine for once (even though I'm sure it's unintentional ;). Keep up the good work, guys. regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070208/e567469b/attachment.html From boazharrosh at gmail.com Thu Feb 8 11:52:39 2007 From: boazharrosh at gmail.com (Boaz Harrosh) Date: Thu Feb 8 13:32:52 2007 Subject: Helping a user migrate an odbc app to Wine In-Reply-To: <003101c74b5c$70d9b9e0$4001a8c0@glis> References: <003101c74b5c$70d9b9e0$4001a8c0@glis> Message-ID: On 2/8/07, Rolf Kalbermatter wrote: > Ouch, I wouldn't see how this could work. Running the Microsoft > drivers together with the whole Microsoft ODBC manager under Wine > too would probably be the only way to get that working. But I think > it is safe to assume that that would require quite some work in Wine > before this could possibly work, not to talk about license issues. > > Rolf Kalbermatter > > This is totally not true and it is right there in documentation. (User guide) All you do is install mdac downloadable from Microsoft.com, or any MS product like Office. Than run odbcad32.exe to set your DSNs. that's it, works like a charm and is the only known way to man to connect to an MSSQL server from Unix. After you install MDAC, you can also install Oracle's drivers for windows but that is a bit more tricky, just like on windows. Also search archives it was there before. Free Life Boaz From jnewman at codeweavers.com Thu Feb 8 14:10:32 2007 From: jnewman at codeweavers.com (Jeremy Newman) Date: Thu Feb 8 14:10:42 2007 Subject: Bugzilla: Adding a 'patch' keyword In-Reply-To: References: Message-ID: <1170965432.12181.7.camel@localhost.localdomain> Since nobody else jumped on this, I went ahead and added a "patch" keyword. On Mon, 2007-02-05 at 19:48 +0100, Francois Gouget wrote: > On Tue, 30 Jan 2007, Francois Gouget wrote: > [...] > > But it would be nice if there was an easy way to find bugs that have a > > patch, even, and maybe especially, if it is incorrect. This would make > > it easier for interested parties to survey what potential fixes are > > languishing in Bugzilla and push them to wine-devel or wine-patches. > > I see everyone agrees :-/ > So could someone add the 'patch' keyword? > From r.kalbermatter at hccnet.nl Thu Feb 8 14:20:30 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Thu Feb 8 14:21:14 2007 Subject: Helping a user migrate an odbc app to Wine In-Reply-To: Message-ID: <005c01c74bbe$94939d80$4001a8c0@glis> Boaz Harrosh [mailto:boazharrosh@gmail.com] wrote: >This is totally not true and it is right there in documentation. (User guide) Ok! I stand corrected. Sorry. >All you do is install mdac downloadable from Microsoft.com, or any MS product >like Office. Than run odbcad32.exe to set your DSNs. I had expected some of these drivers to make use of private APIs that might not be available under Wine. >That's it, works like a charm and is the only known way to man to connect to >an MSSQL server from Unix. Well there is at least FreeTDS unless you need to communicate with the server through other means than TCP/IP. Rolf Kalbermatter From hans at it.vu.nl Thu Feb 8 14:20:52 2007 From: hans at it.vu.nl (Hans Leidekker) Date: Thu Feb 8 14:21:35 2007 Subject: [2] wineshelllink: Keep using the slash as path separator. In-Reply-To: <45CB43DF.2030205@kievinfo.com> References: <45CB43DF.2030205@kievinfo.com> Message-ID: <200702082120.52681.hans@it.vu.nl> On Thursday 08 February 2007 16:38:07 Vitaliy Margolen wrote: > And creates invalid menu entries. Did you test this patch with > multi-level menu structure? When I tried your patch it created all menu > entries in the top level menu, with the name like: Strange, I tested the patch extensively before sending it including multilevel menu structures. It showed no differences for paths without dashes and fixed paths with dashes for me. I just tested it again and still produces the correct results here. I even tried /bin/bash instead of /bin/sh but I can't reproduce what you're seeing. Could you send me a good and a bad tarball created like this? tar zcvf good.tar.gz \ $HOME/.local/share/applications \ $HOME/.local/share/desktop-directories \ $HOME/.config/menus/applications-merged -Hans From wine-devel at kievinfo.com Thu Feb 8 15:38:21 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Thu Feb 8 15:39:01 2007 Subject: [2] wineshelllink: Keep using the slash as path separator. In-Reply-To: <200702082120.52681.hans@it.vu.nl> References: <45CB43DF.2030205@kievinfo.com> <200702082120.52681.hans@it.vu.nl> Message-ID: <45CB984D.5030703@kievinfo.com> Hans Leidekker wrote: > On Thursday 08 February 2007 16:38:07 Vitaliy Margolen wrote: > >> And creates invalid menu entries. Did you test this patch with >> multi-level menu structure? When I tried your patch it created all menu >> entries in the top level menu, with the name like: > > Strange, I tested the patch extensively before sending it including > multilevel menu structures. It showed no differences for paths without > dashes and fixed paths with dashes for me. I just tested it again and > still produces the correct results here. I even tried /bin/bash instead > of /bin/sh but I can't reproduce what you're seeing. > > Could you send me a good and a bad tarball created like this? > > tar zcvf good.tar.gz \ > $HOME/.local/share/applications \ > $HOME/.local/share/desktop-directories \ > $HOME/.config/menus/applications-merged > > -Hans Ok I figured it out I think. It's the older stuff that I had in there that was messing things up. After cleaning it up and using your patch, everything worked like a charm. So nvm - false alarm. Thanks for a good job! Vitaliy. From stefandoesinger at gmx.at Thu Feb 8 16:19:19 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Thu Feb 8 16:20:08 2007 Subject: DirectDrawRenderer=opengl - screen size changeable for final rendering? In-Reply-To: <20070208181954.GV1252@byleth.sc-networks.de> References: <20070206131332.GW1252@byleth.sc-networks.de> <200702081901.14117.stefandoesinger@gmx.at> <20070208181954.GV1252@byleth.sc-networks.de> Message-ID: <200702082319.25956.stefandoesinger@gmx.at> > thats the point. i dont know how wine handles the ddraw-over-opengl > scenario. i just had very blury graphics in JA2. nothing to wonder > about as i assume at least one quad is drawn with the image as texture. > so the filtering kicks in and voila we have bad image quality. No, I think opengl ddraw rendering is still pretty buggy. I wrote the code to do it mainly for Direct3D7 games which blit their HUD onto the screen using DirectDraw blitting calls. I tested it with Prince of Persia 3D, Swat 3 and Battlezone 2. I have some fixes in my patch list I'm going to send in the next days to fix some readback bugs. (Half-Life 2 uses the blitting code to make screenshots and savegame images). Furthermore partial render target locking is completely broken in git, I have fixes for that too. > assuming that my "render a quad" theory is right it would work to place > a key in the registry, where i would tell the ogl-ddraw-renderer to use > my res instead of the one the apps wants. OpenGL DirectDraw rendering renders by setting up the projection matrix to have 0/0 at the top left of the screen and with/height at the bottom right. Then it calculates the source coordinates with Xsrc / Source->pow2Width and Ysrc / Source->pow2Height and draws a quad. So yes, in theory we could scale things up by just setting a higher resolution. One could get nicer graphics with linear / bilinear / anisotropic texture filtering, but there are some issues: * Color keying: Filtering will change the color values slightly, so mess up color keying * Mouse input: We'd have to do the same for received mouse events * readback: If the application locks the render target or reads it back into an offscreen texture, you have to undo filtering and scaling It will be easier to just use multisampling on the final rendering. The nvidia driver has such an option to force multisampling. But that is I think simmilar to what your tft does. Of course for properly changed resolutions you have to run in fullscreen, not virtual desktop. It would be a pretty messy thing to force a foreign resolution onto a game. You can try to do that of course, but I don't think such a patch would be accepted into wine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070208/860cab20/attachment.pgp From mike at codeweavers.com Thu Feb 8 18:52:43 2007 From: mike at codeweavers.com (Mike McCormack) Date: Thu Feb 8 18:52:46 2007 Subject: comctl32: datetime: initial tests for date and time picker In-Reply-To: <1170964237.4713.13.camel@dellnotebook> References: <1170964237.4713.13.camel@dellnotebook> Message-ID: <45CBC5DB.8070708@codeweavers.com> Kanit Therdsteerasukdi wrote: > I'm a student at UCLA taking CS130: Software Engineering. For CS130, we > are writing conformance tests for Common Controls (comctl32). I will be > working on the Date and Time Picker. Attached is an initial test, > testing the getters and setters. Looks like good work. > +#include This is possibly not needed. > +static HINSTANCE g_hinst; You should be able to use NULL instead of the hinst when creating the window, which would eliminate the need for g_hinst. > + assert(hWndDateTime!=NULL); > + return hWndDateTime; Maybe it would be nicer to check hWndDateTime with an ok() macro in test_datetime_control() then use skip() if it's NULL. This way the test will fail without crashing in the case that Window creation fails, for example, when there's no X display available. When tests crash, make doesn't detect that they failed. > + return; > +} The return is redundant, and probably better off removed. > + r = SendMessage(hWndDateTime, DTM_SETRANGE, GDTR_MIN | GDTR_MAX, (LPARAM)st); > + ok(r != 0, "Expected nonzero, got %ld\n", r); MSDN does say "returns nonzero if successful", but it's probably better to check the exact value that it does return, in case there's a program out there that does the same. ie. ok(r == 1, "Expected nonzero, got %ld\n", r); Mike From richardvoigt at gmail.com Thu Feb 8 19:01:35 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Thu Feb 8 19:01:45 2007 Subject: winegcc: sign-compare fixes In-Reply-To: <581692.69421.qm@web52703.mail.yahoo.com> References: <2e59e6970702071842t48327e97o6919092703a8ad48@mail.gmail.com> <581692.69421.qm@web52703.mail.yahoo.com> Message-ID: <2e59e6970702081701tfb260fbq5195ecbbbde9ebd5@mail.gmail.com> > > > memmove(&arr->base[i], &arr->base[i + 1], > > (arr->size - i - 1) * > > > sizeof(arr->base[0])); > > > arr->size--; > > > } > > > > If the element size could be greater than one byte, > > the multiplication > > here should be checked for overflow (actually, this > > is more necessary > > when the array is created or expanded). > > > > > > > > > Well, the base field in the structure is defined as > "const char** base" so sizeof(base[0]) == sizeof(const > char *), should be 4 or so. > How do you mean overflow in this case? sorry for > asking dumb questions... > One desires that the argument is the size of memory which holds numelems = (arr->size - i - 1) elements of each = sizeof (arr->base[0]) bytes each. As you say each = 4 bytes on 32-bit systems. Then the value is numelems * each = numelems * 4 = numelems << 2. Thus if either of the two most significant bits in numelems are set, they will be lost as a result of the shift (multiplication). In this case the correct value is larger than addressable virtual memory, which should be illegal. Actually though, the limit should be placed on arr->size in the allocation function. The essential problem here is that this can be used to remove sanity checking in the case where the inputs are supplied by a client with lesser permissions. Imagine, for example, a kernel function being invoked via an ioctl... though the problem is equally valid for any network-facing service. Say a client is allowed to create and access buffer for exchange with a device (USB printer or the like), and that the client can allocate the buffer by providing the number of buffer elements, and the element size is fixed and non-unity, we'll use 4 in this example. If the privileged service does something like the following: handle createbuffer(int buflen) { if (buflen <= 0) return NULL int bytecount = 4 * buflen; if (bytecount > quota) return NULL; int* p = malloc(bytecount); if (!p) return NULL; return createbufferhandle(buflen, p); } and lets the client read from the buffer: int readbufferatindex(handle buffer, int index) { int size = buffersizefromhandle(buffer); if (index < 0 || index >= size) return 0; return bufferptrfromhandle(buffer)[index]; } Seems safe enough, right? Each client is allowed only a limited buffer, maybe elsewhere the number of buffers is limited, so the client can't execute a DOS attack. malloc guarantees that the buffer doesn't overlap any other buffer, and the bounds checking in readbufferatindex prevents clients from reading outside their buffer. Until I do this: buffer = createbuffer(0x40000010); Uh-oh. I passed the quota check, because bytecount was calculated at 64 bytes. malloc easily allocated 64 bytes not overlapping with any other user. But the stored buffersize is set so large that the bounds check is worthless; I can read any memory I want. From r.kalbermatter at hccnet.nl Fri Feb 9 04:41:19 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Fri Feb 9 04:42:03 2007 Subject: Some thoughts about the ominous DIB Engine Message-ID: <000901c74c36$d56a7fe0$4001a8c0@glis> I have been following this discussion for quite some time and finally decided to look into it a little bit. While the Wiki mentions that a difficult part of this would be to get any design accepted by Alexandre it does absolutely not say in any way what kind of approach would be likely to be accepted, other than it needs to be in small incremental steps. I must admit that I haven't entirely looked through the whole Wine tree yet so I might be missing something but from the old Transgaming patch and some investigation into GDI32 I would see two principal aproaches to add such an interface to Wine. 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. Obviously 1) has been tried and seemed to work in some ways eventhough there would still need to be quite some more work to be done. What I don't like about this aproach is that conceptually it seems to add this functionality at the wrong end. If there is ever going to be another display driver than winex11.drv all the hooking would have to be done again and also adding new GDI methods to the driver as development goes always requires also some significant changes to winex11.drv. Not sure if someone ever attempted 2) but IMHO it would place DIB handling where it conceptually should be. The dibdrv function array could be added as extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches. Possible problems I could see are however synchronizing with X (not sure if that is really a possible problem as I do not understand X so far) and maybe other drivers such as wine3d3.drv that seem to hook into winex11.drv too (not sure if for DIB related operations). This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too. I would like to hear comments of anyone that could add something to this and maybe we can then add the result to the wiki page for further reference. As it is now Wiki mostly says it is rather desirable, sort of hard to do and the hardest part would be getting it into Wine at all. Maybe if there is a more clear picture as to how it could be done and what is likely to have a chance to pass Alexandre's critical eyes, there would be a bigger chance of someone trying to get it finally started the right way. Rolf Kalbermatter From julliard at winehq.org Fri Feb 9 05:05:08 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Fri Feb 9 05:05:24 2007 Subject: [1/9] WineD3D: BeginScene and EndScene tests and fixes In-Reply-To: <200702082230.05722.stefan@codeweavers.com> (Stefan =?utf-8?Q?D=C3=B6singer's?= message of "Thu\, 8 Feb 2007 22\:30\:04 +0100") References: <200702082230.05722.stefan@codeweavers.com> Message-ID: <87y7n7egm3.fsf@wine.dyndns.org> Stefan D?singer writes: > From 4dc1b3cd7faf9c61bc6f862f416b6af07e1e85e8 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Fri, 19 Jan 2007 19:30:09 +0100 > Subject: [PATCH] WineD3D: BeginScene and EndScene tests and fixes This causes 'make test' to fail to restore the correct display resolution, it's stuck at 800x600 on exit. -- Alexandre Julliard julliard@winehq.org From mstefani at redhat.com Fri Feb 9 05:18:40 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Fri Feb 9 05:18:47 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <000901c74c36$d56a7fe0$4001a8c0@glis> References: <000901c74c36$d56a7fe0$4001a8c0@glis> Message-ID: <45CC5890.4030307@redhat.com> Rolf Kalbermatter wrote: > I have been following this discussion for quite some time and finally > decided to look into it a little bit. While the Wiki mentions that a > difficult part of this would be to get any design accepted by Alexandre it > does absolutely not say in any way what kind of approach would be likely to > be accepted, other than it needs to be in small incremental steps. > > I must admit that I haven't entirely looked through the whole Wine tree yet > so I might be missing something but from the old Transgaming patch and some > investigation into GDI32 I would see two principal aproaches to add such an > interface to Wine. > > 1) Like in the Transgaming patch hook into winex11.drv where apropriate. > 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has > been done for enhmfdrv and mfdrv already. > > Obviously 1) has been tried and seemed to work in some ways eventhough there > would still need to be quite some more work to be done. What I don't like > about this aproach is that conceptually it seems to add this functionality > at the wrong end. If there is ever going to be another display driver than > winex11.drv all the hooking would have to be done again and also adding new > GDI methods to the driver as development goes always requires also some > significant changes to winex11.drv. There is already an other display driver: winequartz.drv for MacOS. And Pierre is working to move code out of winex11.drv and into the GDI and User dlls to not have to duplicate it again in winequartz.drv. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From ken at codeweavers.com Fri Feb 9 05:53:32 2007 From: ken at codeweavers.com (Ken Thomases) Date: Fri Feb 9 05:48:30 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <45CC5890.4030307@redhat.com> References: <000901c74c36$d56a7fe0$4001a8c0@glis> <45CC5890.4030307@redhat.com> Message-ID: <099F9E9A-CE08-4446-A74B-C9C2909CA45B@codeweavers.com> On Feb 9, 2007, at 5:18 AM, Michael Stefaniuc wrote: > Rolf Kalbermatter wrote: >> I have been following this discussion for quite some time and finally >> decided to look into it a little bit. While the Wiki mentions that a >> difficult part of this would be to get any design accepted by >> Alexandre it >> does absolutely not say in any way what kind of approach would be >> likely to >> be accepted, other than it needs to be in small incremental steps. >> >> I must admit that I haven't entirely looked through the whole Wine >> tree yet >> so I might be missing something but from the old Transgaming patch >> and some >> investigation into GDI32 I would see two principal aproaches to >> add such an >> interface to Wine. >> >> 1) Like in the Transgaming patch hook into winex11.drv where >> apropriate. >> 2) Add the dib engine as a dibdrv into GDI32 directly similar to >> what has >> been done for enhmfdrv and mfdrv already. >> >> Obviously 1) has been tried and seemed to work in some ways >> eventhough there >> would still need to be quite some more work to be done. What I >> don't like >> about this aproach is that conceptually it seems to add this >> functionality >> at the wrong end. If there is ever going to be another display >> driver than >> winex11.drv all the hooking would have to be done again and also >> adding new >> GDI methods to the driver as development goes always requires also >> some >> significant changes to winex11.drv. > There is already an other display driver: winequartz.drv for MacOS. > And > Pierre is working to move code out of winex11.drv and into the GDI and > User dlls to not have to duplicate it again in winequartz.drv. Pierre could speak to this better than I, but my understanding is that the Quartz driver does not need the DIB engine. Quartz (the Mac's imaging and windowing API) is capable of drawing to offscreen bitmaps directly, at color depths that need not match the display's. This has implications for the design of the DIB engine, because it should be designed to allow the graphics driver to override/bypass it. -Ken From fgouget at free.fr Fri Feb 9 05:56:40 2007 From: fgouget at free.fr (Francois Gouget) Date: Fri Feb 9 05:56:38 2007 Subject: Bugzilla: Adding a 'patch' keyword In-Reply-To: <1170965432.12181.7.camel@localhost.localdomain> References: <1170965432.12181.7.camel@localhost.localdomain> Message-ID: On Thu, 8 Feb 2007, Jeremy Newman wrote: > Since nobody else jumped on this, I went ahead and added a "patch" > keyword. Argh! So now I finally discover that after all it is possible to use the query system to get a list of the bugs that have patches. So we don't need the 'patch' keyword :-/ Sorry for all the noise. The trick is to use the 'Advanced Querying Using Boolean Charts' at the bottom, select 'Attachment is patch', 'is equal to' and '1'. Or as a neat URL: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=attachments.ispatch&type0-0-0=equals&value0-0-0=1 So this shows that there are 128 open bugs with patches. So that's 128 bugs to check: * either the patch has been applied to WineHQ and then the bug should be closed (unless there are other issues, but then maybe these should go in a separate bug). * or the patch is just waiting for someone to review it, polish it up and send it to wine-patches (ok it might need a bit more than just polishing, but still, it's a start). -- Francois Gouget http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. From flexo at holycrap.org Fri Feb 9 06:06:09 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Fri Feb 9 05:59:35 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <099F9E9A-CE08-4446-A74B-C9C2909CA45B@codeweavers.com> References: <000901c74c36$d56a7fe0$4001a8c0@glis> <45CC5890.4030307@redhat.com> <099F9E9A-CE08-4446-A74B-C9C2909CA45B@codeweavers.com> Message-ID: <45CC63B1.4090000@holycrap.org> Ken Thomases wrote: > Pierre could speak to this better than I, but my understanding is that > the Quartz driver does not need the DIB engine. Quartz (the Mac's > imaging and windowing API) is capable of drawing to offscreen bitmaps > directly, at color depths that need not match the display's. > > This has implications for the design of the DIB engine, because it > should be designed to allow the graphics driver to override/bypass it. I suggested to do all the work server-side a while back: http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html Especially see: http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html Now, in my opinion we shouldn't care about those apps but it's not up to me. :) Felix From flexo at holycrap.org Fri Feb 9 06:10:18 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Fri Feb 9 06:03:49 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <45CC63B1.4090000@holycrap.org> References: <000901c74c36$d56a7fe0$4001a8c0@glis> <45CC5890.4030307@redhat.com> <099F9E9A-CE08-4446-A74B-C9C2909CA45B@codeweavers.com> <45CC63B1.4090000@holycrap.org> Message-ID: <45CC64AA.8000700@holycrap.org> Felix Nawothnig wrote: >> Pierre could speak to this better than I, but my understanding is >> that the Quartz driver does not need the DIB engine. Quartz (the >> Mac's imaging and windowing API) is capable of drawing to offscreen >> bitmaps directly, at color depths that need not match the display's. > I suggested to do all the work server-side a while back: Uhm, dunno where I just got the idea that Quartz would feature network transparency. Just ignore me. I really need some coffee now. From laurent at vromman.org Fri Feb 9 06:09:42 2007 From: laurent at vromman.org (Laurent Vromman) Date: Fri Feb 9 06:09:59 2007 Subject: Questions about gdi32:WidenPath patch sent on jan. 27 Message-ID: <57949.80.156.46.119.1171022982.squirrel@maiou.hd.free.fr> Hi, I've tried to send my first patch on jan. 27. This patch is supposed to add a partial implementation of WidenPath to gdi32.dll. After two weeks, I don't have any news about the patch. Is it still pending ? Is there something wrong with it ? I am ready to improve it if necessary, but I need some advice to now what needs to be improved in it. Thank you for your help. Laurent From damjan.jov at gmail.com Fri Feb 9 06:17:10 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Fri Feb 9 06:17:14 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <000901c74c36$d56a7fe0$4001a8c0@glis> References: <000901c74c36$d56a7fe0$4001a8c0@glis> Message-ID: <9e89675b0702090417r40b4bc67le1df22a811ab98b0@mail.gmail.com> On 2/9/07, Rolf Kalbermatter wrote: > I have been following this discussion for quite some time and finally > decided to look into it a little bit. While the Wiki mentions that a > difficult part of this would be to get any design accepted by Alexandre it > does absolutely not say in any way what kind of approach would be likely to > be accepted, other than it needs to be in small incremental steps. > > I must admit that I haven't entirely looked through the whole Wine tree yet > so I might be missing something but from the old Transgaming patch and some > investigation into GDI32 I would see two principal aproaches to add such an > interface to Wine. Look at bug 3902 (and 421) for some more ideas. An optimization was suggested to reduce the size of the data copied between wine and the X server, where an invalid rectangle is set/cleared by each drawing function and only the contents of that rectangle (if any) are copied, instead of the entire bitmap. It's not hard to do, but it isn't an overnight thing either - each and every drawing function has to be patched to do this for it to work, and there is a several dozen. Preliminary tests showed some improvements using this approach. And it would still help even if we had a DIB engine, because the volume of data copied would still be lower. My client-side DIB copy patch from bug 3902 was accepted into wine a few versions back, and it already makes a huge difference for some applications and games. > 1) Like in the Transgaming patch hook into winex11.drv where apropriate. > 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has > been done for enhmfdrv and mfdrv already. > Obviously 1) has been tried and seemed to work in some ways eventhough there > would still need to be quite some more work to be done. What I don't like > about this aproach is that conceptually it seems to add this functionality > at the wrong end. If there is ever going to be another display driver than > winex11.drv all the hooking would have to be done again and also adding new > GDI methods to the driver as development goes always requires also some > significant changes to winex11.drv. > > Not sure if someone ever attempted 2) but IMHO it would place DIB handling > where it conceptually should be. The dibdrv function array could be added as > extra field to the private DIB data structure and initialized on DIB > creation. On non existing DIB methods (NULL pointer) the operation would be > simply sent to the display driver as is done now. I believe this could be > generalized enough to make it a single time change, with new dibdrv methods > getting then available whenever implemented in small incremental patches. > > Possible problems I could see are however synchronizing with X (not sure if > that is really a possible problem as I do not understand X so far) and maybe > other drivers such as wine3d3.drv that seem to hook into winex11.drv too > (not sure if for DIB related operations). X synchronization is done in winex11.drv. Calling X11DRV_LockDIBSection returns where the DIB is, and if it is client-side, you just draw to it by accessing memory - otherwise you draw by using equivalent xlib functions. It would be pointless and extremely difficult making a dibdrv - just patch winex11.drv; dibdrv would need access to many internal X11DRV_ functions. > This last one could however be gotten around by implementing the dibdrv as > loadable driver too, so that other drivers needing to use operations from it > could load it too. > > I would like to hear comments of anyone that could add something to this and > maybe we can then add the result to the wiki page for further reference. > > As it is now Wiki mostly says it is rather desirable, sort of hard to do and > the hardest part would be getting it into Wine at all. Maybe if there is a > more clear picture as to how it could be done and what is likely to have a > chance to pass Alexandre's critical eyes, there would be a bigger chance of > someone trying to get it finally started the right way. The hard part is not the X11 stuff, it is writing drawing algorithms that not only draw in all of 1, 4, 8, 16, 24, and 32 bit colour-depth and are pixel-for-pixel equivalent with the way Windows does them, but the dozens of little things like patterns, brushes, raster ops, custom region clipping, and others which affect each other and almost everything else, making the implementation of a client-side DIB engine a real PITA. > Rolf Kalbermatter Damjan Jovanovic From julliard at winehq.org Fri Feb 9 06:19:20 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Fri Feb 9 06:19:25 2007 Subject: ntdll: Add prototypes to winnt.h for the SList functions. In-Reply-To: (Francois Gouget's message of "Fri\, 9 Feb 2007 12\:34\:37 +0100 \(CET\)") References: Message-ID: <87tzxved6f.fsf@wine.dyndns.org> Francois Gouget writes: > Fix the implementation to match the official prototypes. > --- > > I've had trouble with the placement of 'volatile' in 'const > SLIST_HEADER* volatile'. I think putting 'volatile' last is correct > because it applies to the pointer, not to the pointed-to data like > 'const'. No, it applies to the data, it doesn't make sense to have the pointer itself be volatile. Though it's probably useless either way, and since the SDK prototypes apparently don't have it we shouldn't either. -- Alexandre Julliard julliard@winehq.org From rob at codeweavers.com Fri Feb 9 07:52:42 2007 From: rob at codeweavers.com (Robert Shearman) Date: Fri Feb 9 07:53:31 2007 Subject: shell32: make sure BrowseForFolder doesn't return NULL for the Desktop folder as this means a cancel (should fix bug #5533) In-Reply-To: <45C9C5A3.7070608@zalewski.pl> References: <45C9C5A3.7070608@zalewski.pl> Message-ID: <45CC7CAA.2090202@codeweavers.com> Miko?aj Zalewski wrote: > +/************************************************************************* > + * _ILMakePidlNotNull > + * > + * A null pidl is a valid pidl that represents the Desktop. However if we don't > + * want a NULL pidl (e.g. because NULL indicates an error) this function will > + * make an explicit empty pidl if the parameter is NULL. > + */ > +HRESULT _ILMakePidlNotNull(LPITEMIDLIST *pidl) > +{ > + if (*pidl == NULL) > + *pidl = _ILCreateDesktop(); > + if (*pidl == NULL) > + return E_OUTOFMEMORY; > + return S_OK; > +} > This function is a bit ugly. It seems this policy should be made in the BrsFolder_OnCommand function, rather than in pidl.c as a file. -- Rob Shearman From rob at codeweavers.com Fri Feb 9 07:57:02 2007 From: rob at codeweavers.com (Robert Shearman) Date: Fri Feb 9 07:57:45 2007 Subject: comctl32: rebar: rewrite the layouting code In-Reply-To: <45C66F05.3030805@zalewski.pl> References: <45C66F05.3030805@zalewski.pl> Message-ID: <45CC7DAE.2050300@codeweavers.com> Miko?aj Zalewski wrote: > I've been trying to fix the rebar layouting code. But fixes in one > place caused regressions because of bugs in other places and I ended > up rewriting the whole layouting code. It does roughly the same as the > current code however the details are quite different and I hope more > correct. It's also much shorter so it should be earier to > understand/debug. My code work for me for all apps I tested (except > for the sidebars of IE but I'm trying to find out why). It also passes > some tests I've written and produces identical results that the > native. Two things could be potentially better in the old code: > - it contains some support for RBBS_FIXEDSIZE (however different from > what Windows does) > - it can break rows to fill the given space (but that should be only > done for RBS_AUTOSIZE rebars) > > I have yet to test the REBAR_Maximize and REBAR_Minimize but I have > two questions. Does this code cause regressions in apps that works > with the current code and would such big patch be accepted? I haven't got any apps to test with (other than IE and it looks like you've already tried that), but nice work! -- Rob Shearman From fgouget at free.fr Fri Feb 9 08:02:48 2007 From: fgouget at free.fr (Francois Gouget) Date: Fri Feb 9 08:02:51 2007 Subject: RasError.h? Where is this or does it not exist? In-Reply-To: <78a7dad00702080604w74f0cb26i6daccf11adf194aa@mail.gmail.com> References: <78a7dad00702080604w74f0cb26i6daccf11adf194aa@mail.gmail.com> Message-ID: On Thu, 8 Feb 2007, John Smith wrote: > Hey all, > I cannot find the raserror.h file. I have tried looking around the wine > directories to no avail. A find ./wine -name raserror.h -type f -print > turns up nothing. Am I looking in the wrong spot or in the wrong way? I can confirm that it is missing. So feel free to add it as include/raserror.h. But no verbatim copying from the PSDK! Work from the MSDN or other documentation sources. -- Francois Gouget http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages. From mikolaj at zalewski.pl Fri Feb 9 08:03:25 2007 From: mikolaj at zalewski.pl (=?UTF-8?B?TWlrb8WCYWogWmFsZXdza2k=?=) Date: Fri Feb 9 08:03:37 2007 Subject: shell32: make sure BrowseForFolder doesn't return NULL for the Desktop folder as this means a cancel (should fix bug #5533) In-Reply-To: <45CC7CAA.2090202@codeweavers.com> References: <45C9C5A3.7070608@zalewski.pl> <45CC7CAA.2090202@codeweavers.com> Message-ID: <45CC7F2D.3080000@zalewski.pl> > This function is a bit ugly. It seems this policy should be made in > the BrsFolder_OnCommand function, rather than in pidl.c as a file. Yes, after I've found _ILCreateDesktop there is no need for a helper funciton. I'll send a patch without it. Mikolaj Zalewski From tony.lambregts at gmail.com Fri Feb 9 08:12:46 2007 From: tony.lambregts at gmail.com (Tony Lambregts) Date: Fri Feb 9 08:11:55 2007 Subject: Bugzilla: Adding a 'patch' keyword In-Reply-To: References: Message-ID: <45CC815E.2070401@gmail.com> Francois Gouget wrote: > On Tue, 30 Jan 2007, Francois Gouget wrote: > [...] >> But it would be nice if there was an easy way to find bugs that have a >> patch, even, and maybe especially, if it is incorrect. This would make >> it easier for interested parties to survey what potential fixes are >> languishing in Bugzilla and push them to wine-devel or wine-patches. > > I see everyone agrees :-/ > So could someone add the 'patch' keyword? > I had added this keyword when you first asked for it... I just did not comment on it. http://bugs.winehq.org/describekeywords.cgi -- Tony Lambregts From mikolaj at zalewski.pl Fri Feb 9 08:17:31 2007 From: mikolaj at zalewski.pl (=?UTF-8?B?TWlrb8WCYWogWmFsZXdza2k=?=) Date: Fri Feb 9 08:17:40 2007 Subject: comctl32: rebar: rewrite the layouting code In-Reply-To: <45CC7DAE.2050300@codeweavers.com> References: <45C66F05.3030805@zalewski.pl> <45CC7DAE.2050300@codeweavers.com> Message-ID: <45CC827B.6080402@zalewski.pl> Robert Shearman napisa?(a): > Miko?aj Zalewski wrote: >> I've been trying to fix the rebar layouting code. But fixes in one >> place caused regressions because of bugs in other places and I ended >> up rewriting the whole layouting code. It does roughly the same as >> the current code however the details are quite different and I hope >> more correct. It's also much shorter so it should be earier to >> understand/debug. My code work for me for all apps I tested (except >> for the sidebars of IE but I'm trying to find out why). It also >> passes some tests I've written and produces identical results that >> the native. Two things could be potentially better in the old code: >> - it contains some support for RBBS_FIXEDSIZE (however different >> from what Windows does) >> - it can break rows to fill the given space (but that should be only >> done for RBS_AUTOSIZE rebars) >> >> I have yet to test the REBAR_Maximize and REBAR_Minimize but I have >> two questions. Does this code cause regressions in apps that works >> with the current code and would such big patch be accepted? > > I haven't got any apps to test with (other than IE and it looks like > you've already tried that), but nice work! > I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? Mikolaj Zalewski From dank at kegel.com Fri Feb 9 09:02:33 2007 From: dank at kegel.com (Dan Kegel) Date: Fri Feb 9 09:02:46 2007 Subject: comctl32: rebar: rewrite the layouting code Message-ID: Miko?aj wrote: >I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the >last two have Bugzilla entries and are fixed by the new code). The only >thing I've found not to work are the sidebars of IE. Did they work with the old code? > For the next week I won't work on wine but what should I do later - > would such a big patch be accepted? As long as it doesn't cause regressions in IE, probably, though adding more conformance tests would make acceptance more likely. I think everyone would be thrilled to see progress in rebar, especially if the code ends up simpler. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv From xixsimplicityxix at gmail.com Fri Feb 9 09:24:36 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Fri Feb 9 09:24:39 2007 Subject: RasError.h? Where is this or does it not exist? In-Reply-To: References: <78a7dad00702080604w74f0cb26i6daccf11adf194aa@mail.gmail.com> Message-ID: <78a7dad00702090724q7f0bf258qb6c17bba264c7c3d@mail.gmail.com> Right oh! We will see perhaps today. A bit of studying to do first though. Thanks for helping me! Regards, John Klehm On 2/9/07, Francois Gouget wrote: > > On Thu, 8 Feb 2007, John Smith wrote: > > > Hey all, > > I cannot find the raserror.h file. I have tried looking around the > wine > > directories to no avail. A find ./wine -name raserror.h -type f -print > > turns up nothing. Am I looking in the wrong spot or in the wrong way? > > I can confirm that it is missing. So feel free to add it as > include/raserror.h. But no verbatim copying from the PSDK! Work from the > MSDN or other documentation sources. > > > -- > Francois Gouget http://fgouget.free.fr/ > The last time religion ruled, it was called the dark ages. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070209/fff8e0cb/attachment.html From wine.dev at web.de Fri Feb 9 09:21:56 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Fri Feb 9 09:25:34 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <000901c74c36$d56a7fe0$4001a8c0@glis> References: <000901c74c36$d56a7fe0$4001a8c0@glis> Message-ID: <1171034516.6917.60.camel@p4> On Fr, 2007-02-09 at 11:41 +0100, Rolf Kalbermatter wrote: > 1) Like in the Transgaming patch hook into winex11.drv where apropriate. > 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has > been done for enhmfdrv and mfdrv already. > extra field to the private DIB data structure and initialized on DIB > creation. On non existing DIB methods (NULL pointer) the operation would be > simply sent to the display driver as is done now. I believe this could be > generalized enough to make it a single time change, with new dibdrv methods > getting then available whenever implemented in small incremental patches. I suggest option 2), but without the need of a Display-Driver at all as the long-term target. The API for that Engine is exported by GDI32 ("Eng*" ) and when we implement that, we can reuse the API for more drivers (OpenGL, VNC, RDP, SDL, Printer-Drivers ...) The API-declaration for "Eng*" is in "ddk/winddi.h" A line from the current wine GDI-Engine as Example: ("LineTo" from dlls/gdi32/painting.c): ---- cut ---- > ret = dc->funcs->pLineTo && dc->funcs->pLineTo(dc->physDev,x,y); ---- cut ---- We simple call the Driver, and when the Driver does not support that painting-function, the API failed. On windows, gdi32.dll and the Driver can fallback at any time to "Eng*" ("EngLineTo" in the Example) and the drawing is split in more primitive API-calls whith setting a single pixel at the end. (You can think of a Driver, that implement "LineTo" only for horizontal and vertical lines and fallback to "EngLineTo" for diagonal lines) So instead of implementing a full DIB-Engine in a dibdrv, we should split the implementation in a logical part ("Eng*" API) and a drawing part. > Possible problems I could see are however synchronizing with X (not sure if I have no Idea, what is needed here. > This last one could however be gotten around by implementing the dibdrv as > loadable driver too, so that other drivers needing to use operations from it > could load it too. When we use "Eng*", it's there for all drivers and is the same API as in windows. Thanks for looking at the dib-issue -- By by ... Detlef From mikolaj at zalewski.pl Fri Feb 9 09:33:14 2007 From: mikolaj at zalewski.pl (=?UTF-8?B?TWlrb8WCYWogWmFsZXdza2k=?=) Date: Fri Feb 9 09:33:27 2007 Subject: comctl32: rebar: rewrite the layouting code In-Reply-To: References: Message-ID: <45CC943A.2060702@zalewski.pl> Dan Kegel wrote: > Miko?aj wrote: > >> I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the >> last two have Bugzilla entries and are fixed by the new code). The only >> thing I've found not to work are the sidebars of IE. > > Did they work with the old code? WinRAR did. Other had bigger or smaller problems. >> For the next week I won't work on wine but what should I do later - >> would such a big patch be accepted? > > As long as it doesn't cause regressions in IE, probably, > though adding more conformance tests would > make acceptance more likely. IE sidebars didn't work before and the main toolbar seems to work OK. Even the sidebars seems to work slighty better as some horizontal toolbar are now visible. Next week I'll add some more tests - especially I'd need to test RB_MAXIMIZE/RB_MINIMIZE and changing the band cx. Mikolaj Zalewski From rob at codeweavers.com Fri Feb 9 10:36:53 2007 From: rob at codeweavers.com (Robert Shearman) Date: Fri Feb 9 10:37:32 2007 Subject: shell32[2/3]: add a confirmation dialog with a "Yes to All" option In-Reply-To: <45CC9A6F.6000408@zalewski.pl> References: <45CC9A6F.6000408@zalewski.pl> Message-ID: <45CCA325.50104@codeweavers.com> Miko?aj Zalewski wrote: > +SHELL_YESTOALL_MSGBOX DIALOG 200, 100, 280, 90 > +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU > +CAPTION "Message" > +FONT 8, "MS Shell Dlg" > +{ > + DEFPUSHBUTTON "&Yes", IDYES, 34, 69, 53, 14, WS_GROUP | WS_TABSTOP > + PUSHBUTTON "Yes to &all", IDD_YESTOALL, 92, 69, 65, 14, WS_GROUP | WS_TABSTOP > + PUSHBUTTON "&No", IDNO, 162, 69, 53, 14, WS_GROUP | WS_TABSTOP > + PUSHBUTTON "&Cancel", IDCANCEL, 220, 69, 53, 14, WS_GROUP | WS_TABSTOP > + ICON "", IDD_ICON, 10, 10, 16, 16 > + LTEXT "", IDD_MESSAGE, 40, 10, 238, 52, 0 > +} > + > The usual convention is that IDD_* are used for IDs of dialogs and IDC_* are used for IDs of controls. -- Rob Shearman From mikolaj at zalewski.pl Fri Feb 9 10:54:51 2007 From: mikolaj at zalewski.pl (=?UTF-8?B?TWlrb8WCYWogWmFsZXdza2k=?=) Date: Fri Feb 9 10:55:01 2007 Subject: shell32[2/3]: add a confirmation dialog with a "Yes to All" option In-Reply-To: <45CCA325.50104@codeweavers.com> References: <45CC9A6F.6000408@zalewski.pl> <45CCA325.50104@codeweavers.com> Message-ID: <45CCA75B.8080906@zalewski.pl> > The usual convention is that IDD_* are used for IDs of dialogs and > IDC_* are used for IDs of controls. The Browse For Folders dialog uses IDD_ for controls and I wanted to follow the convention in this file. Mikolaj Zalewski From paul.vriens.wine at gmail.com Fri Feb 9 12:33:38 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Fri Feb 9 12:34:17 2007 Subject: comctl32: rebar: rewrite the layouting code In-Reply-To: <45CC943A.2060702@zalewski.pl> References: <45CC943A.2060702@zalewski.pl> Message-ID: <45CCBE82.3010901@gmail.com> Miko?aj Zalewski wrote: > Dan Kegel wrote: > >> Miko?aj wrote: >> >>> I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the >>> last two have Bugzilla entries and are fixed by the new code). The only >>> thing I've found not to work are the sidebars of IE. >> >> Did they work with the old code? > > WinRAR did. Other had bigger or smaller problems. > >>> For the next week I won't work on wine but what should I do later - >>> would such a big patch be accepted? >> >> As long as it doesn't cause regressions in IE, probably, >> though adding more conformance tests would >> make acceptance more likely. > > IE sidebars didn't work before and the main toolbar seems to work OK. > Even the sidebars seems to work slighty better as some horizontal > toolbar are now visible. Next week I'll add some more tests - especially > I'd need to test RB_MAXIMIZE/RB_MINIMIZE and changing the band cx. > > Mikolaj Zalewski > > > Hi, I think Process Explorer (V10.21) benefits from your patch as well. The only issue I've seen so far (with the patch) is minimizing/maximizing the window and when the whole window has to be redrawn (basically the same thing). Without the patch it's far worse. Cheers, Paul. From t.e.tonnessen at losmail.no Fri Feb 9 13:18:38 2007 From: t.e.tonnessen at losmail.no (Tor Einar =?ISO-8859-1?Q?T=F8nnessen?=) Date: Fri Feb 9 13:19:29 2007 Subject: Wine beta ASIO-driver. Message-ID: <1171048718.7467.17.camel@tor> Hello, First let me introduce myself. I am Tor Einar Toennessen ( actually T?nnessen ). I am from Norway. I have followed the development of Wine a little bit on and off over some years ( maybe about 10 ). My main interrest with Wine is in the audio and midi area. I would like to comment on the asio-driver. I think its marvellous that wine has got an ASIO-capable audio-driver. The patch do however no longer apply cleanly to todays git-version. Secondly I had some trouble getting it to work, until I found out that I had to run "autoheader" not just "autoconf" in order to to get the symbol HAVE_ASIO_SDK_ASIO_H into config.h (via config.h.in). Also I would like very much that you (Robert Reif isn't it ?) develop the driver a little further. The first thing beeing a control-panel. But what is most import I think , is to make a new patch that works on todays wine, and get it into the ReadMe that one must run autoheader to. In that way more people can make it work and test it out... Tor Einar From nlaw at nildram.co.uk Fri Feb 9 15:08:13 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Fri Feb 9 15:08:45 2007 Subject: Bugzilla: Adding a 'patch' keyword In-Reply-To: <45CC815E.2070401@gmail.com> References: <45CC815E.2070401@gmail.com> Message-ID: <45CCE2BD.3040709@nildram.co.uk> Tony Lambregts wrote: > Francois Gouget wrote: > >> On Tue, 30 Jan 2007, Francois Gouget wrote: >> [...] >> >>> But it would be nice if there was an easy way to find bugs that have a >>> patch, even, and maybe especially, if it is incorrect. This would make >>> it easier for interested parties to survey what potential fixes are >>> languishing in Bugzilla and push them to wine-devel or wine-patches. >>> >> I see everyone agrees :-/ >> So could someone add the 'patch' keyword? >> >> > > I had added this keyword when you first asked for it... I just did not comment > on it. http://bugs.winehq.org/describekeywords.cgi > > -- > > Tony Lambregts > > > Thanks. I've added the 'patch' keyword to bug 6323 (numeric keypad) patch that's been submitted but waiting for Alexandre to commit it. Fixes a known issue in World of Warcraft & Warcraft, but I would imagine fixes many other apps that use the numeric keypad ? From truiken at gmail.com Fri Feb 9 15:39:45 2007 From: truiken at gmail.com (James Hawkins) Date: Fri Feb 9 15:40:00 2007 Subject: shell32[3/3]: allow overwriting files in SHFileOperation(FO_COPY) (with confirmation dialogs, fixes bug #7046) In-Reply-To: <45CC9DA5.2080906@zalewski.pl> References: <45CC9DA5.2080906@zalewski.pl> Message-ID: <22821af30702091339o1755568cq6200b5b33220b82b@mail.gmail.com> On 2/9/07, Miko?aj Zalewski wrote: > The return codes when the user cancelled the operation as in Vista, as > they are more logical and easier to implement than the XP ones. If > Microsoft changed them there are probably not many apps that would > depend on it. With this change the program in bug #7046 works fine. > > From 799ff7b7cc6092fbd3e2030c7b4eb84d829b9842 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= > Date: Fri, 9 Feb 2007 16:43:06 +0100 > Subject: [PATCH] shell32: allow overwriting files in SHFileOperation(FO_COPY) (with confirmation dialogs) > > --- > dlls/shell32/shell32_Bg.rc | 6 ++- > dlls/shell32/shell32_Cs.rc | 8 ++- > dlls/shell32/shell32_De.rc | 6 ++- > dlls/shell32/shell32_En.rc | 8 ++- > dlls/shell32/shell32_Eo.rc | 6 ++- > dlls/shell32/shell32_Es.rc | 6 ++- > dlls/shell32/shell32_Fi.rc | 6 ++- > dlls/shell32/shell32_Fr.rc | 6 ++- > dlls/shell32/shell32_It.rc | 6 ++- > dlls/shell32/shell32_Ko.rc | 6 ++- > dlls/shell32/shell32_No.rc | 6 ++- > dlls/shell32/shell32_Pl.rc | 6 ++- > dlls/shell32/shell32_Pt.rc | 6 ++- > dlls/shell32/shell32_Ru.rc | 6 ++- > dlls/shell32/shell32_Tr.rc | 6 ++- > dlls/shell32/shell32_Uk.rc | 6 ++- > dlls/shell32/shell32_main.h | 3 +- > dlls/shell32/shfldr_unixfs.c | 2 +- > dlls/shell32/shlfileop.c | 128 +++++++++++++++++++++++++++++++--------- > dlls/shell32/shresdef.h | 1 + > dlls/shell32/tests/shlfileop.c | 55 +++++++++++++++++ > 21 files changed, 241 insertions(+), 48 deletions(-) > > diff --git a/dlls/shell32/shell32_Bg.rc b/dlls/shell32/shell32_Bg.rc > index 100b9b6..4c4d16b 100644 > --- a/dlls/shell32/shell32_Bg.rc > +++ b/dlls/shell32/shell32_Bg.rc > @@ -165,8 +165,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEITEM_TEXT "???????? ?? ?????? ?? ???????? '%1'?" > IDS_DELETEMULTIPLE_TEXT "???????? ?? ?????? ?? ???????? ???? %1 ?????????" > IDS_DELETESELECTED_TEXT "???????? ?? ?????? ?? ???????? ????????? ?????????" > - IDS_OVERWRITEFILE_TEXT "???????? ?? ?????? ?? ??????????? %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "?????????? ????????? ?? ?????" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "????????????" > diff --git a/dlls/shell32/shell32_Cs.rc b/dlls/shell32/shell32_Cs.rc > index 6451dbb..8790db4 100644 > --- a/dlls/shell32/shell32_Cs.rc > +++ b/dlls/shell32/shell32_Cs.rc > @@ -163,10 +163,14 @@ STRINGTABLE DISCARDABLE > IDS_CREATEFOLDER_CAPTION "Chyba p?i pokusu vytvo?it nov? adres??" > IDS_DELETEITEM_CAPTION "Potvrdit odstran?n? souboru" > IDS_DELETEFOLDER_CAPTION "Potvrdit odstran?n? adres??e" > - IDS_OVERWRITEFILE_CAPTION "Potvrdit p?eps?n? souboru" > IDS_DELETEITEM_TEXT "Opravdu chcete odstranit '%1'?" > IDS_DELETEMULTIPLE_TEXT "Opravdu chcete odstranit t?chto %1 polo?ek?" > - IDS_OVERWRITEFILE_TEXT "P?ejete si p?epsat soubor '%1'?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > + IDS_OVERWRITEFILE_CAPTION "Potvrdit p?eps?n? souboru" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > } > > /* columns in the shellview */ > diff --git a/dlls/shell32/shell32_De.rc b/dlls/shell32/shell32_De.rc > index bde62bf..d6cb815 100644 > --- a/dlls/shell32/shell32_De.rc > +++ b/dlls/shell32/shell32_De.rc > @@ -173,8 +173,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Sind Sie sich sicher, dass Sie '%1' und seinen Inhalt in den M?ll verschieben m?chten?" > IDS_TRASHMULTIPLE_TEXT "Sind Sie sich sicher, dass Sie diese %1 Dateien in den M?ll verschieben m?chten?" > IDS_CANTTRASH_TEXT "Das Objekt '%1' kann nicht in den M?ll verschoben werden. M?chten Sie es stattdessen l?schen?" > - IDS_OVERWRITEFILE_TEXT "M?chten Sie, dass die Datei '%1' ?berschrieben wird ?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Best?tigung: Datei ?berschreiben" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Neustarten" > diff --git a/dlls/shell32/shell32_En.rc b/dlls/shell32/shell32_En.rc > index 09530c6..a67cc8a 100644 > --- a/dlls/shell32/shell32_En.rc > +++ b/dlls/shell32/shell32_En.rc > @@ -185,8 +185,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Are you sure that you want to send '%1' and all it's content to the Trash?" > IDS_TRASHMULTIPLE_TEXT "Are you sure that you want to send these %1 items to the Trash?" > IDS_CANTTRASH_TEXT "The item '%1' can't be sent to Trash. Do you want to delete it instead?" > - IDS_OVERWRITEFILE_TEXT "OverWrite File %1?" > - IDS_OVERWRITEFILE_CAPTION "Confirm File OverWrite" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > + IDS_OVERWRITEFILE_CAPTION "Confirm file overwrite" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Restart" > diff --git a/dlls/shell32/shell32_Eo.rc b/dlls/shell32/shell32_Eo.rc > index e8fa407..3bfca07 100644 > --- a/dlls/shell32/shell32_Eo.rc > +++ b/dlls/shell32/shell32_Eo.rc > @@ -163,8 +163,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Konfirmu forigon de dosierujo" > IDS_DELETEITEM_TEXT "?u vi estas certa pri forigo de '%1'?" > IDS_DELETEMULTIPLE_TEXT "?u vi estas certa pri forigo de ?i tiuj %1 komponantoj?" > - IDS_OVERWRITEFILE_TEXT "?u vi supreskribas la dosieron %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Konfirmu supreskribiton de dosieron" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > } > > /* columns in the shellview */ > diff --git a/dlls/shell32/shell32_Es.rc b/dlls/shell32/shell32_Es.rc > index dd83a6e..c3d2f4c 100644 > --- a/dlls/shell32/shell32_Es.rc > +++ b/dlls/shell32/shell32_Es.rc > @@ -162,8 +162,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confirmar eliminaci?n de carpeta" > IDS_DELETEITEM_TEXT "?Seguro que desea eliminar '%1'?" > IDS_DELETEMULTIPLE_TEXT "?Seguro que desea eliminar estos %1 elementos?" > - IDS_OVERWRITEFILE_TEXT "?Sobreescribir el archivo '%1'?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmar sobreescritura de archivo" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > } > > /* columns in the shellview */ > diff --git a/dlls/shell32/shell32_Fi.rc b/dlls/shell32/shell32_Fi.rc > index e842bbd..e43a94e 100644 > --- a/dlls/shell32/shell32_Fi.rc > +++ b/dlls/shell32/shell32_Fi.rc > @@ -164,8 +164,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Vahvista kansion tuhoaminen" > IDS_DELETEITEM_TEXT "Haluatko varmasti tuhota '%1':n?" > IDS_DELETEMULTIPLE_TEXT "Haluatko varmasti tuhota n?m? %1?" > - IDS_OVERWRITEFILE_TEXT "Ylikirjoita tiedosto %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Vahvista tiedoston ylikirjoitus" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "K?ynnist? uudelleen" > diff --git a/dlls/shell32/shell32_Fr.rc b/dlls/shell32/shell32_Fr.rc > index 043c66c..246045c 100644 > --- a/dlls/shell32/shell32_Fr.rc > +++ b/dlls/shell32/shell32_Fr.rc > @@ -176,8 +176,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "?tes-vous s?r de vouloir mettre ?%1? et tout ce qu'il contient dans la corbeille?" > IDS_TRASHMULTIPLE_TEXT "?tes-vous s?r de vouloir mettre ces %1 ?l?ments dans la corbeille?" > IDS_CANTTRASH_TEXT "L'?l?ment ?%1? ne peut pas ?tre mis dans la corbeille. Souhaitez-vous le supprimer ? la place?" > - IDS_OVERWRITEFILE_TEXT "?craser le fichier %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmer l'?crasement du fichier" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Red?marrer" > diff --git a/dlls/shell32/shell32_It.rc b/dlls/shell32/shell32_It.rc > index 809f44a..19f7339 100644 > --- a/dlls/shell32/shell32_It.rc > +++ b/dlls/shell32/shell32_It.rc > @@ -164,8 +164,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confermare la cancellazione della cartella" > IDS_DELETEITEM_TEXT "Sei sicuro di voler cancellare '%1'?" > IDS_DELETEMULTIPLE_TEXT "Sei sicuro di voler cancellare questi %1 elementi?" > - IDS_OVERWRITEFILE_TEXT "Sovrascrivere il File %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confermare la sovrascrizione del File" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Riavvia" > diff --git a/dlls/shell32/shell32_Ko.rc b/dlls/shell32/shell32_Ko.rc > index 413ad7b..bb00f83 100644 > --- a/dlls/shell32/shell32_Ko.rc > +++ b/dlls/shell32/shell32_Ko.rc > @@ -173,8 +173,12 @@ IDS_TRASHITEM_TEXT "?????? '%1' ??(??) ?????????? ???????? ?????????" > IDS_TRASHFOLDER_TEXT "?????? '%1' ?? ?? ???? ?????? ?????????? ???????? ?????????" > IDS_TRASHMULTIPLE_TEXT "?????? '%1' ????(??) ?????????? ???????? ?????????" > IDS_CANTTRASH_TEXT "The item '%1' can't be sent to Trash. Do you want to delete it instead?" > -IDS_OVERWRITEFILE_TEXT "???? %1?? ???????????????" > +IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "???? ???????? ?(r)??" > +IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "???? ????" > diff --git a/dlls/shell32/shell32_No.rc b/dlls/shell32/shell32_No.rc > index a7ad4f4..c7ec269 100644 > --- a/dlls/shell32/shell32_No.rc > +++ b/dlls/shell32/shell32_No.rc > @@ -172,8 +172,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Virkelig legge ?%1? og alt innholdet i papirkurven?" > IDS_TRASHMULTIPLE_TEXT "Virkelig legge disse %1 valgte elementene i papirkurven?" > IDS_CANTTRASH_TEXT "Elementet ?%1? kan ikke legges i papirkurven. Vil du slette det i stedet?" > - IDS_OVERWRITEFILE_TEXT "Overskrive filen ?%1??" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Bekreft overskriving av fil" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Starte p? nytt" > diff --git a/dlls/shell32/shell32_Pl.rc b/dlls/shell32/shell32_Pl.rc > index 60b6a75..d6139e7 100644 > --- a/dlls/shell32/shell32_Pl.rc > +++ b/dlls/shell32/shell32_Pl.rc > @@ -173,8 +173,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Czy jeste? pewien, ?e chcesz umie?ci? folder '%1' i ca?? jego zawarto?? w koszu" > IDS_TRASHMULTIPLE_TEXT "Element?w: %1 - czy na pewno chcesz je umie?ci? w Koszu?" > IDS_CANTTRASH_TEXT "Nie mog? przenie?? elementu '%1' do Kosza. Czy chcesz go zamiast tego usun???" > - IDS_OVERWRITEFILE_TEXT "Zast?pi? plik %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Potwierd? zast?pienie pliku" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Uruchom ponownie" > diff --git a/dlls/shell32/shell32_Pt.rc b/dlls/shell32/shell32_Pt.rc > index 1826162..0a6a274 100644 > --- a/dlls/shell32/shell32_Pt.rc > +++ b/dlls/shell32/shell32_Pt.rc > @@ -256,8 +256,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confirmar exclus?o de pasta" > IDS_DELETEITEM_TEXT "Voc? tem certeza que deseja excluir '%1'?" > IDS_DELETEMULTIPLE_TEXT "Voc? tem certeza que deseja excluir estes %1 itens?" > - IDS_OVERWRITEFILE_TEXT "Sobreescrever arquivo %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmar sobreescrever arquivo" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Reiniciar" > diff --git a/dlls/shell32/shell32_Ru.rc b/dlls/shell32/shell32_Ru.rc > index a3c5da8..65fa824 100644 > --- a/dlls/shell32/shell32_Ru.rc > +++ b/dlls/shell32/shell32_Ru.rc > @@ -165,8 +165,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "????????????? ???????? ?????" > IDS_DELETEITEM_TEXT "??????? '%1'?" > IDS_DELETEMULTIPLE_TEXT "??????? ??? ??????? (%1?" > - IDS_OVERWRITEFILE_TEXT "???????? ????(?) %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "????????????? ?????? ?????" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "?????????????" > diff --git a/dlls/shell32/shell32_Tr.rc b/dlls/shell32/shell32_Tr.rc > index b41be53..197562c 100644 > --- a/dlls/shell32/shell32_Tr.rc > +++ b/dlls/shell32/shell32_Tr.rc > @@ -172,8 +172,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "'%1' adl? ??eyi ve t?m i?eri?ini ??pe g?ndermek istedi?inizden emin misiniz?" > IDS_TRASHMULTIPLE_TEXT "Bu %1 ??eyi ??pe g?ndermek istedi?inizden emin misiniz?" > IDS_CANTTRASH_TEXT "'%1' adl? ??e ??pe g?nderilemiyor. Tamamen silmek ister misiniz?" > - IDS_OVERWRITEFILE_TEXT "%1 dosyas?n?n ?zerine yazmak istiyor musunuz?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Dosya ?zerine Yazmay? Onayla" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > > /* message box strings */ > IDS_RESTART_TITLE "Yeniden Ba?lat" > diff --git a/dlls/shell32/shell32_Uk.rc b/dlls/shell32/shell32_Uk.rc > index c535ba9..a4cf564 100644 > --- a/dlls/shell32/shell32_Uk.rc > +++ b/dlls/shell32/shell32_Uk.rc > @@ -161,8 +161,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "????????????? ????????? ????" > IDS_DELETEITEM_TEXT "?? ????????, ?? ?????? ???????? '%1'?" > IDS_DELETEMULTIPLE_TEXT "?? ????????, ?? ?????? ???????? ?? %1 ????????(??)?" > - IDS_OVERWRITEFILE_TEXT "?????????? ???? %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "????????????? ?????????? ?????" > + IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > + "If the files in the destination folder have the same names as files in the\n"\ > + "selected folder they will be replaced. Do you still want to move or copy\n"\ > + "the folder?" > } > > /* columns in the shellview */ > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index a17eec4..2937065 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -153,9 +153,10 @@ void FreeChangeNotifications(void); > #define ASK_TRASH_FOLDER 8 > #define ASK_TRASH_MULTIPLE_ITEM 9 > #define ASK_CANT_TRASH_ITEM 10 > +#define ASK_OVERWRITE_FOLDER 11 > > BOOL SHELL_DeleteDirectoryW(HWND hwnd, LPCWSTR pwszDir, BOOL bShowUI); > -BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir); > +BOOL SHELL_ConfirmYesNoW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir); > > /* 16-bit functions */ > void WINAPI DragAcceptFiles16(HWND16 hWnd, BOOL16 b); > diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c > index 4668afe..a4f4ade 100644 > --- a/dlls/shell32/shfldr_unixfs.c > +++ b/dlls/shell32/shfldr_unixfs.c > @@ -1829,7 +1829,7 @@ static HRESULT UNIXFS_delete_with_syscalls(UnixFolder *This, UINT cidl, LPCITEMI > static const WCHAR empty[] = {0}; > int i; > > - if (!SHELL_ConfirmDialogW(GetActiveWindow(), ASK_DELETE_SELECTED, empty)) > + if (!SHELL_ConfirmYesNoW(GetActiveWindow(), ASK_DELETE_SELECTED, empty)) > return S_OK; > > lstrcpyA(szAbsolute, This->m_pszPath); > diff --git a/dlls/shell32/shlfileop.c b/dlls/shell32/shlfileop.c > index d1ea475..b245e00 100644 > --- a/dlls/shell32/shlfileop.c > +++ b/dlls/shell32/shlfileop.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > > #include "windef.h" > #include "winbase.h" > @@ -65,6 +66,14 @@ static DWORD SHNotifyMoveFileW(LPCWSTR src, LPCWSTR dest); > static DWORD SHNotifyCopyFileW(LPCWSTR src, LPCWSTR dest, BOOL bFailIfExists); > static DWORD SHFindAttrW(LPCWSTR pName, BOOL fileOnly); > > +typedef struct > +{ > + SHFILEOPSTRUCTW *req; > + DWORD dwYesToAllMask; > + BOOL bManyItems; > + BOOL bCancelled; > +} FILE_OPERATION; > + > /* Confirm dialogs with an optional "Yes To All" as used in file operations confirmations > */ > static const WCHAR CONFIRM_MSG_PROP[] = {'W','I','N','E','_','C','O','N','F','I','R','M','E',0}; > @@ -250,22 +259,32 @@ static BOOL SHELL_ConfirmIDs(int nKindOfDialog, SHELL_ConfirmIDstruc *ids) > ids->icon_resource_id = IDI_WARNING; > ids->caption_resource_id = IDS_OVERWRITEFILE_CAPTION; > ids->text_resource_id = IDS_OVERWRITEFILE_TEXT; > - return TRUE; > + return TRUE; > + case ASK_OVERWRITE_FOLDER: > + ids->hIconInstance = NULL; > + ids->icon_resource_id = IDI_WARNING; > + ids->caption_resource_id = IDS_OVERWRITEFILE_CAPTION; > + ids->text_resource_id = IDS_OVERWRITEFOLDER_TEXT; > + return TRUE; > default: > FIXME(" Unhandled nKindOfDialog %d stub\n", nKindOfDialog); > } > return FALSE; > } > > -BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir) > +static BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir, FILE_OPERATION *op) > { > WCHAR szCaption[255], szText[255], szBuffer[MAX_PATH + 256]; > SHELL_ConfirmIDstruc ids; > DWORD_PTR args[1]; > HICON hIcon; > + int ret; > > - if (!SHELL_ConfirmIDs(nKindOfDialog, &ids)) > - return FALSE; > + assert(nKindOfDialog >= 0 && nKindOfDialog < 32); > + if (op && (op->dwYesToAllMask & (1 << nKindOfDialog))) > + return IDYES; > + > + assert(SHELL_ConfirmIDs(nKindOfDialog, &ids)); > > LoadStringW(shell32_hInstance, ids.caption_resource_id, szCaption, sizeof(szCaption)/sizeof(WCHAR)); > LoadStringW(shell32_hInstance, ids.text_resource_id, szText, sizeof(szText)/sizeof(WCHAR)); > @@ -275,7 +294,23 @@ BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir) > szText, 0, 0, szBuffer, sizeof(szBuffer), (va_list*)args); > hIcon = LoadIconW(ids.hIconInstance, (LPWSTR)MAKEINTRESOURCE(ids.icon_resource_id)); > > - return (IDYES == SHELL_ConfirmMsgBox(hWnd, szBuffer, szCaption, hIcon, FALSE)); > + ret = SHELL_ConfirmMsgBox(hWnd, szBuffer, szCaption, hIcon, op && op->bManyItems); > + if (op) { > + if (ret == IDD_YESTOALL) { > + op->dwYesToAllMask |= (1 << nKindOfDialog); > + ret = IDYES; > + } > + if (ret == IDCANCEL) > + op->bCancelled = TRUE; > + if (ret != IDYES) > + op->req->fAnyOperationsAborted = TRUE; > + } > + return ret == IDYES; > +} > You need to conform to the style of the rest of the file, e.g., if (IsAttribDir(entryToCopy->attributes) && bCancelIfAnyDirectories) return ERROR_CANCELLED; create_dest_dirs(fileDest->szDirectory); if (!lstrcmpiW(entryToCopy->szFullPath, fileDest->szFullPath)) { if (IsAttribFile(entryToCopy->attributes)) return ERROR_NO_MORE_SEARCH_HANDLES; else return ERROR_SUCCESS; } 4 space indentation, empty lines between logical pieces of code, brackets underneath. -- James Hawkins From wine-devel at kievinfo.com Fri Feb 9 17:33:13 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Fri Feb 9 17:33:47 2007 Subject: winecfg: Add check for device access to Drives tab. Message-ID: <45CD04B9.7080600@kievinfo.com> Any reasons why this patch is not applied? http://www.winehq.org/pipermail/wine-patches/2007-January/035264.html This is one of the major headaches for users trying to get programs requiring direct CD-ROM drive access to work. And it's nearly impossible to get required information from users to find if the direct access actually works or not. If there are some other ways to check this, please let me know. I'm sure everyone who tried to get something like Diablo II working will appreciate it! Vitaliy. From mk144210 at bcm.tmc.edu Fri Feb 9 22:12:16 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Fri Feb 9 22:12:53 2007 Subject: wineboot: Start items in StartUp folder on boot. Message-ID: <1171080736.17227.13.camel@misha-laptop> Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder (Programs) just like Windows. The reason this is necessary, well #1 this is something Windows does that Wine doesn't do, but #2 this is required by the Vector NTI installer (bug #7384), which installs necessary dependencies (MDAC and about 6 other things) by installing one, then placing a link to itself in StartUp, then rebooting. With this patch, it will actually restart correctly, and in fact just running wine installer.exe will actually successfully do the install from start to finish (for the alternative to install this prior to this and a few other patches, see my shell script http://misha680.googlepages.com/InstallVectorNTI10.sh). There is still the lack of JScript support which fails to install some things, but that's about it.y (and freely available to academic researchers) can be installed on Wine and run with quite little problem with a quite complicated install script I made http://misha680.googlepages.com/InstallVectorNTI10.sh). There was one pretty significant bug, but after that I wanted to try to track down and patch other bugs that forced the above script to be required. With the exception of a pretty significant lack of JScript support in wine/MSI which causes installation of quite a few files to fail (and thus still require native jscript.dll and native MSI), this final patch I just sent out makes the install work from start to finish, which is quite a change from before. I posted two patches earlier (a conformance test and a fix) that adds path searching to shell link creation (which the conformance test shows exists in Windows for a file like rundll32.exe that is not found in the current directory), and if anyone has comments about those patches please send them to me. My last patch ensures that this shelllink that the Vector NTI installer creates every time it tries to restart (about six or so times after every Microsoft component it installs that it needs and comes with) will be executed, and in fact is meant to reproduce the Windows behavior of starting items in the StartUp program group on login that occurs in Windows. I am new to the whole IShellFolder thing, though, and I tried to make it as proper as I could. But I certainly feel that I would like to have someone more experience to look at it. Oh, and I just wanted to say a big thanks to Dan Kegel, James Hawkings, Mike McCormack, and others who have helped me so far (not to mention Alexandre Julliard for committing some of my patches). Misha -------------- next part -------------- From 446dbc9d3f961bff416e20b3504305763d145a78 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Fri, 9 Feb 2007 21:48:21 -0600 Subject: wineboot: Start items in StartUp folder on boot. --- programs/wineboot/Makefile.in | 3 + programs/wineboot/wineboot.c | 92 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 93 insertions(+), 2 deletions(-) diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in index 08c27a5..bf1b723 100644 --- a/programs/wineboot/Makefile.in +++ b/programs/wineboot/Makefile.in @@ -4,7 +4,8 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = wineboot.exe APPMODE = -mconsole -IMPORTS = version user32 advapi32 kernel32 +IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi +EXTRALIBS = -luuid C_SRCS = \ shutdown.c \ diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c index 1434003..bda10b1 100644 --- a/programs/wineboot/wineboot.c +++ b/programs/wineboot/wineboot.c @@ -63,6 +63,12 @@ #endif #include #include +#define COBJMACROS +#include +#include +#include +#include + WINE_DEFAULT_DEBUG_CHANNEL(wineboot); #define MAX_LINE_LENGTH (2*MAX_PATH+2) @@ -616,6 +622,88 @@ static int ProcessWindowsFileProtection( return 1; } +/* Process items in the StartUp group of the user's Programs under the Start Menu. Some installers put + * shell links here to restart themselves after boot. */ +static BOOL ProcessStartupItems() +{ + BOOL ret = FALSE; + HRESULT hr; + int iRet; + IMalloc *ppM = NULL; + IShellFolder *psfDesktop = NULL, *psfStartup = NULL; + LPITEMIDLIST pidlStartup = NULL, pidlItem; + ULONG NumPIDLs; + IEnumIDList *iEnumList = NULL; + STRRET strret; + WCHAR wszCommand[MAX_PATH]; + + WINE_TRACE("Processing items in the StartUp folder.\n"); + + hr = SHGetMalloc(&ppM); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get IMalloc object.\n"); + goto done; + } + + hr = SHGetDesktopFolder(&psfDesktop); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get desktop folder.\n"); + goto done; + } + + hr = SHGetSpecialFolderLocation(NULL, CSIDL_STARTUP, &pidlStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't get StartUp folder location.\n"); + goto done; + } + + hr = IShellFolder_BindToObject(psfDesktop, pidlStartup, NULL, &IID_IShellFolder, (LPVOID*)&psfStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't bind IShellFolder to StartUp folder.\n"); + goto done; + } + + hr = IShellFolder_EnumObjects(psfStartup, NULL, SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &iEnumList); + if (FAILED(hr)) + { + WINE_TRACE("Unable to enumerate StartUp objects.\n"); + goto done; + } + + while (IEnumIDList_Next(iEnumList, 1, &pidlItem, &NumPIDLs) == S_OK && + (NumPIDLs) == 1) + { + hr = IShellFolder_GetDisplayNameOf(psfStartup, pidlItem, SHGDN_FORPARSING, &strret); + if (FAILED(hr)) + WINE_TRACE("Unable to get display name of enumeration item.\n"); + else + { + hr = StrRetToBufW(&strret, pidlItem, wszCommand, MAX_PATH); + if (FAILED(hr)) + WINE_TRACE("Unable to parse display name.\n"); + else + if ((iRet = (int)ShellExecuteW(NULL, NULL, wszCommand, NULL, NULL, 0)) <= 32) + WINE_ERR("Error %d executing command %s.\n", iRet, wine_dbgstr_w(wszCommand)); + } + + IMalloc_Free(ppM, pidlItem); + } + + /* Return success */ + ret = TRUE; + +done: + if (iEnumList) IEnumIDList_Release(iEnumList); + if (psfStartup) IShellFolder_Release(psfStartup); + if (pidlStartup) IMalloc_Free(ppM, pidlStartup); + + return ret; +} + static void usage(void) { WINE_MESSAGE( "Usage: wineboot [options]\n" ); @@ -732,7 +820,9 @@ int main( int argc, char *argv[] ) FALSE, FALSE )) && (!ops.postlogin || !ops.startup || ProcessRunKeys( HKEY_CURRENT_USER, runkeys_names[RUNKEY_RUN], - FALSE, FALSE )); + FALSE, FALSE )) && + (!ops.postlogin || !ops.startup || + ProcessStartupItems( )); WINE_TRACE("Operation done\n"); -- 1.4.1 From wine-devel at kievinfo.com Fri Feb 9 22:20:34 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Fri Feb 9 22:21:05 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <1171080736.17227.13.camel@misha-laptop> References: <1171080736.17227.13.camel@misha-laptop> Message-ID: <45CD4812.2010103@kievinfo.com> Misha Koshelev wrote: > Hi, > > As you all may have noticed, I have been making quite a few patches > within the last two weeks (or at least quite a few when compared to zero > before then) because I had figured out that the Vector NTI program that > is quite important in molecular biologThis patch makes sure that wine > will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy. From mk144210 at bcm.tmc.edu Fri Feb 9 22:45:06 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Fri Feb 9 22:45:43 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <45CD4812.2010103@kievinfo.com> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> Message-ID: <1171082707.17227.16.camel@misha-laptop> On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: > Misha Koshelev wrote: > > Hi, > > > > As you all may have noticed, I have been making quite a few patches > > within the last two weeks (or at least quite a few when compared to zero > > before then) because I had figured out that the Vector NTI program that > > is quite important in molecular biologThis patch makes sure that wine > > will start items in the StartUp folder > IMHO this should not be fixed. > > I've seen lots and lots of malicious programs using this mechanism to > start themselves. And even worse if installer uses this to restart > itself. That means this installer might not work most of the time on > windows. > > Vitaliy. Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha From xixsimplicityxix at gmail.com Sat Feb 10 01:29:45 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Sat Feb 10 01:29:48 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <1171082707.17227.16.camel@misha-laptop> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> <1171082707.17227.16.camel@misha-laptop> Message-ID: <78a7dad00702092329o11bc9ffcha238e43d3f00404@mail.gmail.com> I thought wine's goal was "bug for bug" with windows, for good or for ill. On 2/9/07, Misha Koshelev wrote: > > On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: > > Misha Koshelev wrote: > > > Hi, > > > > > > As you all may have noticed, I have been making quite a few patches > > > within the last two weeks (or at least quite a few when compared to > zero > > > before then) because I had figured out that the Vector NTI program > that > > > is quite important in molecular biologThis patch makes sure that wine > > > will start items in the StartUp folder > > IMHO this should not be fixed. > > > > I've seen lots and lots of malicious programs using this mechanism to > > start themselves. And even worse if installer uses this to restart > > itself. That means this installer might not work most of the time on > > windows. > > > > Vitaliy. > > Well that is fair if that is the consensus. I did try the installer on a > plain Win98 system and this restart does work for it there. Maybe have > some kind of option to optionally do this or is that out of the question > too? > > Thanks for the info. > > Misha > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070210/a3039e7d/attachment.html From r.kalbermatter at hccnet.nl Sat Feb 10 02:49:18 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Sat Feb 10 02:50:11 2007 Subject: Some thoughts about the ominous DIB Engine Message-ID: <001a01c74cf0$59c5dd70$4001a8c0@glis> Felix Nawothnig wrote: >I suggested to do all the work server-side a while back: > >http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html > >Especially see: > >http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html Well, this would mostly mirror the Windows architecture nowadays where almost all of this is in win32k.sys and GDI32 is mostly a user space wrapper around that. A bit like ntdll does for kernel operations. But I would be a bit concerned about performance if most calls have to be passed to the server side to be handled but maybe that is not really an issue? Didn't MS put part of the GDI somehow back in user space when going from NT4 to 2K just because of performance concerns? Would still remain the question where and how to hook this into dib handling but I think GDI would be better. Basically call the dc driver and if that fails branch into the local dibeng API for apropriate functions. Rolf Kalbermatter From stefan.munz at itomig.de Sat Feb 10 03:39:39 2007 From: stefan.munz at itomig.de (Stefan Munz) Date: Sat Feb 10 03:39:46 2007 Subject: Helping a user migrate an odbc app to Wine In-Reply-To: <200702080823.09175.kai.blin@gmail.com> References: <200702080823.09175.kai.blin@gmail.com> Message-ID: <200702101039.45323.stefan.munz@itomig.de> Am Donnerstag, 8. Februar 2007 08:23 schrieb Kai Blin: > On Thursday 08 February 2007 01:42, Dan Kegel wrote: > > Can somebody help this (german-speaking) fellow: > > http://www.unixboard.de/vb3/showthread.php?t=26943 > > > > He says his company's internal application requires > > you to input a DSN when installing it, and he doesn't > > know how to come up with a DSN under Wine. > > The german speaking part is not a problem, I just don't know my way around > that odbc stuff, not even on win32 native. > > > Presumably he doesn't want to mess with Unixodbc, > > he just wants to keep using the Microsoft drivers...? > > I figure using the appropriate native dlls would work? > I vaguely remember Windows had a tool to set up odbc drivers, what was the > exe called? it is located in windows/system32 normally. Something like odbcconf.exe or odbcad32.exe. With one of those you can create a DSN and after that provide it to the app. I post a similiar reply in the unixboard. cu, Stefan -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz@itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 T?bingen . . . . . . . . . . . . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070210/a450f4d9/attachment.pgp From wes.parish at paradise.net.nz Sat Feb 10 03:51:28 2007 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Sat Feb 10 03:49:02 2007 Subject: name conflicts - Wine and OpenWatcom Message-ID: <200702102251.30197.wes.parish@paradise.net.nz> I'm running Mandriva 2k7 and started installing Wine. The installation stalled on discovering I have OpenWatcom installed. Wine didn't like /usr/bin/wrc, the OpenWatcom Windows Resource Compiler. I could rename wrc to wwrc - what would people suggest? Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. From stefandoesinger at gmx.at Sat Feb 10 03:54:54 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sat Feb 10 03:55:28 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <45CD4812.2010103@kievinfo.com> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> Message-ID: <200702101055.00924.stefandoesinger@gmx.at> Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > Misha Koshelev wrote: > > Hi, > > > > As you all may have noticed, I have been making quite a few patches > > within the last two weeks (or at least quite a few when compared to zero > > before then) because I had figured out that the Vector NTI program that > > is quite important in molecular biologThis patch makes sure that wine > > will start items in the StartUp folder > > IMHO this should not be fixed. > > I've seen lots and lots of malicious programs using this mechanism to > start themselves. And even worse if installer uses this to restart > itself. That means this installer might not work most of the time on > windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070210/3f7904af/attachment.pgp From stefandoesinger at gmx.at Sat Feb 10 04:11:40 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sat Feb 10 04:12:11 2007 Subject: Some thoughts about the ominous DIB Engine In-Reply-To: <001a01c74cf0$59c5dd70$4001a8c0@glis> References: <001a01c74cf0$59c5dd70$4001a8c0@glis> Message-ID: <200702101111.45278.stefandoesinger@gmx.at> Am Samstag 10 Februar 2007 09:49 schrieb Rolf Kalbermatter: > Felix Nawothnig wrote: > >I suggested to do all the work server-side a while back: > > > >http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html > > > >Especially see: > > > >http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html > > Well, this would mostly mirror the Windows architecture nowadays where > almost all of this is in win32k.sys and GDI32 is mostly a user space > wrapper around that. A bit like ntdll does for kernel operations. > > But I would be a bit concerned about performance if most calls have to > be passed to the server side to be handled but maybe that is not really > an issue? Didn't MS put part of the GDI somehow back in user space when > going from NT4 to 2K just because of performance concerns? I think performance could be ok if we use shared memory to get the dibs in and out of the server, but I think Alexandre does not like shmmem for the one or other reason. Afaik MS had GDI in user space in NT 3.5, but for performance reasons they put it into the kernel in 4.0 and win95. But I think for windows some considerations regarding hardware acceleration also apply. If I understand things correctly, performance problems occur if a DIB section is switched from server mode to app mode, or vice versa. As long as it stays in one or the other mode it is fine. DirectDraw is a much simpler interface than GDI. DDraw currently draws mainly in appmod, problems occur if GetDC is used on a surface. This could maybe avoided if the ddraw implementation was changed to use GDI for blitting too, instead of its own code. However, problems will occur if the application Locks the surface. So I think this would only shift the problem to other apps, and it would not help Direct3D apps, or opengl accelerated DirectDraw. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070210/f038ff8c/attachment.pgp From twickline at gmail.com Sat Feb 10 05:03:04 2007 From: twickline at gmail.com (Tom Wickline) Date: Sat Feb 10 05:03:18 2007 Subject: Wine beta ASIO-driver. In-Reply-To: <1171048718.7467.17.camel@tor> References: <1171048718.7467.17.camel@tor> Message-ID: <53e3a9930702100303s2b20f51ew736031ab6ca78676@mail.gmail.com> On 2/9/07, Tor Einar T?nnessen wrote: > > Also I would like very much that you (Robert Reif isn't it ?) develop > the driver a little further. The first thing beeing a control-panel. You may want to read this post and the thread : http://www.winehq.org/pipermail/wine-devel/2006-September/050639.html Tom > > Tor Einar > From joris_huizer at yahoo.com Sat Feb 10 07:01:02 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Sat Feb 10 07:01:33 2007 Subject: signedness/WINAPI changing question Message-ID: <639467.6460.qm@web52701.mail.yahoo.com> I have a small question: I find some function LONG WINAPI AVIStreamSampleToTime(PAVISTREAM pstream, LONG lSample) (in the avifil32 dll), the second parameter should really be an ULONG instead of a LONG. It'd fix the signedness problems. My question is, is such a change allowed? And what should I do to update for such a change (except for the header gcc warns about) In case such change must not be performed, I'll just add a local variable which is a casted version. I thought this needs asking; adding in unnecessary variables doesn't seem the best fix to me. regards, Joris ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html From nlaw at nildram.co.uk Sat Feb 10 08:24:04 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Sat Feb 10 08:22:25 2007 Subject: opengl code, WoW and graphic cards with 64MB video memory In-Reply-To: <200702101111.45278.stefandoesinger@gmx.at> References: <001a01c74cf0$59c5dd70$4001a8c0@glis> <200702101111.45278.stefandoesinger@gmx.at> Message-ID: <45CDD584.7090006@nildram.co.uk> This is probably a question for Roderick or Stefan or anybody that is familiar with the opengl code in wine. It could be just a coincidence, however it seems that most users that have the problem where WoW hangs after login in, seem to have graphics cards with 64MB memory. Is it possible that the opengl code may not handle a condition where memory runs out on the graphics card and generates the following error .. /The instruction at '0x00000000' referenced memory at '0x00000000'. The memory could not be "read"./ Does the opengl code test for such a condition or does it assume there is an infinite amount of graphics card memory and the application should test for this anyway ? Regards Nick Law From chris.kcat at gmail.com Sat Feb 10 08:44:49 2007 From: chris.kcat at gmail.com (Chris Robinson) Date: Sat Feb 10 08:45:38 2007 Subject: opengl code, WoW and graphic cards with 64MB video memory In-Reply-To: <45CDD584.7090006@nildram.co.uk> References: <001a01c74cf0$59c5dd70$4001a8c0@glis> <200702101111.45278.stefandoesinger@gmx.at> <45CDD584.7090006@nildram.co.uk> Message-ID: <200702100644.49593.chris.kcat@gmail.com> On Saturday 10 February 2007 06:24:04 am Nick Law wrote: > It could be just a coincidence, however it seems that most users that > have the problem where WoW hangs after login in, seem to have graphics > cards with 64MB memory. Is it possible that the opengl code may not > handle a condition where memory runs out on the graphics card and > generates the following error .. > > /The instruction at '0x00000000' referenced memory at '0x00000000'. > The memory could not be "read"./ > > Does the opengl code test for such a condition or does it assume there > is an infinite amount of graphics card memory and the application should > test for this anyway ? AFAIK, OpenGL doesn't really care how much video memory you have. If you run out, it'll just start hapilly swapping to your system RAM automatically (with a nice performance hit). If your system RAM runs out, then you can have problems. That error, though, looks like its trying to use an extension that the driver/card doesn't fully support. It gets a NULL pointer for some function, tries to call it without checking, and you get a nice NULL pointer dereference. From wine-devel at kievinfo.com Sat Feb 10 09:45:16 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 10 09:45:46 2007 Subject: Fullscreen broken in XVidMode Message-ID: <45CDE88C.6050602@kievinfo.com> For about a month now Wine is completely unusable for fullscreen games when using XVidMode instead of XRandr extension. Worse, this is a regression, caused by this patch: f6702ec4afb4098cbb67d6bd670a9f0527191f80 is first bad commit commit f6702ec4afb4098cbb67d6bd670a9f0527191f80 Author: Dmitry Timoshkov Date: Tue Jan 9 23:57:33 2007 +0800 winex11.drv: Force the fullscreen state update once the window is mapped. :040000 040000 f83b3a76eeecd52a04ed04201c49ac15244b0a25 d57c3162633300eabdb9fea65d530eb91cd929f5 M dlls Can we get some ideas going about why this is happening and how to fix it? Vitaliy Margolen. From wine-devel at kievinfo.com Sat Feb 10 09:51:55 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 10 09:52:26 2007 Subject: Handling of EXCEPTION_BREAKPOINT Message-ID: <45CDEA1B.9020500@kievinfo.com> It seems Wine has problems with correct return address for the int3 brakepoint exception. It's covered in bug http://bugs.winehq.org/show_bug.cgi?id=7063 There is even a test case with a proposed fixes. Can anyone with knowledge of the debugger events take a look at it? If the patch can be committed Wine will get that much closer to the supporting more unti-debugger protection schemes. Vitaliy Margolen. From laviddichterman at gmail.com Sat Feb 10 10:06:46 2007 From: laviddichterman at gmail.com (David Lichterman) Date: Sat Feb 10 10:15:02 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <200702101055.00924.stefandoesinger@gmx.at> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> <200702101055.00924.stefandoesinger@gmx.at> Message-ID: Stefan D?singer wrote: > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: >> Misha Koshelev wrote: >>> Hi, >>> >>> As you all may have noticed, I have been making quite a few patches >>> within the last two weeks (or at least quite a few when compared to zero >>> before then) because I had figured out that the Vector NTI program that >>> is quite important in molecular biologThis patch makes sure that wine >>> will start items in the StartUp folder >> IMHO this should not be fixed. >> >> I've seen lots and lots of malicious programs using this mechanism to >> start themselves. And even worse if installer uses this to restart >> itself. That means this installer might not work most of the time on >> windows. > Malicious programs can also write themselves to > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > see any advantage in implementing the Run key, but not the autostart folder. > > > ------------------------------------------------------------------------ > > I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? /2cents -Dave From alex at thehandofagony.com Sat Feb 10 10:19:32 2007 From: alex at thehandofagony.com (Alexander Nicolaysen =?iso-8859-1?q?S=F8rnes?=) Date: Sat Feb 10 10:19:21 2007 Subject: wineshelllink: disable startup notification In-Reply-To: <200702091825.38719.tijl@ulyssis.org> References: <200702091825.38719.tijl@ulyssis.org> Message-ID: <200702101719.32414.alex@thehandofagony.com> Fredag 09 februar 2007 18:25, skrev Tijl Coosemans: > Wine doesn't support startup notification afaict and endlessly bouncing > cursors are annoying. Wine does support startup notifications, but not if the 'enable window manager to control windows applications' is disabled in winecfg. Regards, Alexander N. S?rnes > > --- tools/wineshelllink.orig Fri Feb 9 17:46:58 2007 > +++ tools/wineshelllink Fri Feb 9 17:59:14 2007 > @@ -88,6 +88,7 @@ > [Desktop Entry] > Name=$linkname > Exec=wine "$path" $args > +StartupNotify=false > Type=Application > EOF > [ -z "$descr" ] || echo "Comment=$descr" From richardvoigt at gmail.com Sat Feb 10 20:53:24 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sat Feb 10 20:53:31 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> <200702101055.00924.stefandoesinger@gmx.at> Message-ID: <2e59e6970702101853n60e40b83vaf599aa1b4ad2b22@mail.gmail.com> On 2/10/07, David Lichterman wrote: > Stefan D?singer wrote: > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > >> Misha Koshelev wrote: > >>> Hi, > >>> > >>> As you all may have noticed, I have been making quite a few patches > >>> within the last two weeks (or at least quite a few when compared to zero > >>> before then) because I had figured out that the Vector NTI program that > >>> is quite important in molecular biologThis patch makes sure that wine > >>> will start items in the StartUp folder > >> IMHO this should not be fixed. > >> > >> I've seen lots and lots of malicious programs using this mechanism to > >> start themselves. And even worse if installer uses this to restart > >> itself. That means this installer might not work most of the time on > >> windows. > > Malicious programs can also write themselves to > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > > see any advantage in implementing the Run key, but not the autostart folder. > > > > > > ------------------------------------------------------------------------ > > > > > I second that opinion. I do computer tech support (ie getting viruses > and spy/malware off of windows) at my university and if there's a case > for not implementing one of those two run at boot features, disabling > the Run key would be the stronger since most, if not all malicious > programs now use the run registry location as opposed to the Startup folder. > > It really comes down to the amount of power a user should have. Maybe > require a gksu whenever an app tries to write something to that folder > or that registry location? What a gksu? How about prompting the user during startup? e.g., "Start using command line <program + args>? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny. From jacob.alberty at vetmanage.com Sat Feb 10 21:34:40 2007 From: jacob.alberty at vetmanage.com (Jacob Alberty) Date: Sat Feb 10 21:34:45 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <2e59e6970702101853n60e40b83vaf599aa1b4ad2b22@mail.gmail.com> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> <200702101055.00924.stefandoesinger@gmx.at> <eqkqi3$sr5$1@sea.gmane.org> <2e59e6970702101853n60e40b83vaf599aa1b4ad2b22@mail.gmail.com> Message-ID: <ad22ffac0702101934g4c98b583p2e3c02f7b3b1e086@mail.gmail.com> Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. On 2/10/07, richardvoigt@gmail.com <richardvoigt@gmail.com> wrote: > > On 2/10/07, David Lichterman <laviddichterman@gmail.com> wrote: > > Stefan D?singer wrote: > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > > >> Misha Koshelev wrote: > > >>> Hi, > > >>> > > >>> As you all may have noticed, I have been making quite a few patches > > >>> within the last two weeks (or at least quite a few when compared to > zero > > >>> before then) because I had figured out that the Vector NTI program > that > > >>> is quite important in molecular biologThis patch makes sure that > wine > > >>> will start items in the StartUp folder > > >> IMHO this should not be fixed. > > >> > > >> I've seen lots and lots of malicious programs using this mechanism to > > >> start themselves. And even worse if installer uses this to restart > > >> itself. That means this installer might not work most of the time on > > >> windows. > > > Malicious programs can also write themselves to > > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I > do not > > > see any advantage in implementing the Run key, but not the autostart > folder. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > > and spy/malware off of windows) at my university and if there's a case > > for not implementing one of those two run at boot features, disabling > > the Run key would be the stronger since most, if not all malicious > > programs now use the run registry location as opposed to the Startup > folder. > > > > It really comes down to the amount of power a user should have. Maybe > > require a gksu whenever an app tries to write something to that folder > > or that registry location? > > What a gksu? > > How about prompting the user during startup? > > e.g., "Start <title> using command line <program + args>? Yes/No ([x] > Don't ask again" > Don't ask again items could either be stored as hash codes in a > configuration file outside the wine filesystem, or else by deleting > command/moving to a usual Unixy autostart location. > > This should be done for all startup programs, whether start menu or > registry. > > It would be the best of both worlds, it works as expected for the user > without requiring them to give up control of their system. > > There could even be a winecfg option whether to prompt the user, > silently allow, automatically+loudly deny, or silently deny. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070210/4c049a26/attachment.htm From flexo at holycrap.org Sat Feb 10 22:45:58 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sat Feb 10 22:39:16 2007 Subject: Comctl32 Status Bar Test In-Reply-To: <e0b856d20702092352r66842469t28bc14fead5b30a3@mail.gmail.com> References: <e0b856d20702092352r66842469t28bc14fead5b30a3@mail.gmail.com> Message-ID: <45CE9F86.1060507@holycrap.org> Alex Arazi wrote: > - ok(rc.top == 2, "Expected 2, got %d\n", rc.top); > - ok(rc.bottom == 21, "Expected 21, got %d\n", rc.bottom); > - ok(rc.left == 0, "Expected 0, got %d\n", rc.left); > - ok(rc.right == 50, "Expected 50, got %d\n", rc.right); I didn't really look at your new tests but the second of those tests you removed failed ("got 1" IIRC) on Windows (XP) because we don't create a parent window (and because the 21 is wrong. Should be 22 IIRC) - native comctl32 sometimes does some strange stuff when a control doesn't have one - so the test should create it. Felix From richardvoigt at gmail.com Sat Feb 10 23:55:08 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sat Feb 10 23:55:08 2007 Subject: wineboot: Start items in StartUp folder on boot. In-Reply-To: <ad22ffac0702101934g4c98b583p2e3c02f7b3b1e086@mail.gmail.com> References: <1171080736.17227.13.camel@misha-laptop> <45CD4812.2010103@kievinfo.com> <200702101055.00924.stefandoesinger@gmx.at> <eqkqi3$sr5$1@sea.gmane.org> <2e59e6970702101853n60e40b83vaf599aa1b4ad2b22@mail.gmail.com> <ad22ffac0702101934g4c98b583p2e3c02f7b3b1e086@mail.gmail.com> Message-ID: <2e59e6970702102155q30548f30h1b9c1b4e905318b1@mail.gmail.com> On 2/10/07, Jacob Alberty <jacob.alberty@vetmanage.com> wrote: > Why not integrate this functionality into wineboot? That way if a user wants > to completely deny the start-up folder they can just not add wineboot to the > list of programs to be started on login, but if they want that functionality > they can simply add wineboot to the list of programs for start up when they > login? It would allow similar functionality to windows whilst still keeping > it a separate system. I think everyone agrees that wineboot is where this functionality should be, if it's implemented at all? Well, part of my idea was that even if the configuration option is set to "silently deny", any option that was previously accepted with the don't ask again option checked (or Always in case wine has buttons for Never, Not This Time, Run This Time, Always) would still execute, which is rather different from totally disabling wineboot. Then you could presumably run wineboot explicitly or some helper program, in order to manage the entries. > > > On 2/10/07, richardvoigt@gmail.com <richardvoigt@gmail.com> wrote: > > On 2/10/07, David Lichterman <laviddichterman@gmail.com > wrote: > > > Stefan D?singer wrote: > > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > > > >> Misha Koshelev wrote: > > > >>> Hi, > > > >>> > > > >>> As you all may have noticed, I have been making quite a few patches > > > >>> within the last two weeks (or at least quite a few when compared to > zero > > > >>> before then) because I had figured out that the Vector NTI program > that > > > >>> is quite important in molecular biologThis patch makes sure that > wine > > > >>> will start items in the StartUp folder > > > >> IMHO this should not be fixed. > > > >> > > > >> I've seen lots and lots of malicious programs using this mechanism to > > > >> start themselves. And even worse if installer uses this to restart > > > >> itself. That means this installer might not work most of the time on > > > >> windows. > > > > Malicious programs can also write themselves to > > > > HKLM/Software/Microsoft/Windows/Run, a key that > wineboot reads. So I do not > > > > see any advantage in implementing the Run key, but not the autostart > folder. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > > > and spy/malware off of windows) at my university and if there's a case > > > for not implementing one of those two run at boot features, disabling > > > the Run key would be the stronger since most, if not all malicious > > > programs now use the run registry location as opposed to the Startup > folder. > > > > > > It really comes down to the amount of power a user should have. Maybe > > > require a gksu whenever an app tries to write something to that folder > > > or that registry location? > > > > What a gksu? > > > > How about prompting the user during startup? > > > > e.g., "Start <title> using command line <program + args>? Yes/No ([x] > > Don't ask again" > > Don't ask again items could either be stored as hash codes in a > > configuration file outside the wine filesystem, or else by deleting > > command/moving to a usual Unixy autostart location. > > > > This should be done for all startup programs, whether start menu or > registry. > > > > It would be the best of both worlds, it works as expected for the user > > without requiring them to give up control of their system. > > > > There could even be a winecfg option whether to prompt the user, > > silently allow, automatically+loudly deny, or silently deny. > > > > > > > > From timschmidt at gmail.com Sun Feb 11 02:01:49 2007 From: timschmidt at gmail.com (Tim Schmidt) Date: Sun Feb 11 02:01:56 2007 Subject: DirectX related question Message-ID: <2c97fe9d0702110001h735e4b78ocefe4e532b123aa4@mail.gmail.com> Already looking at buying a new computer to play Supreme Commander (http://en.wikipedia.org/wiki/Supreme_commander), is there anything I can do (including, but not limited to purchasing hardware) to help get this game running under Wine? I can't promise miracles, but if I can break down a few obstacles, consider it done. --tim From lats at yless4u.com.au Sun Feb 11 02:32:10 2007 From: lats at yless4u.com.au (Jeff L) Date: Sun Feb 11 02:32:19 2007 Subject: doc: Add a Quick start to the Wine User Guide Message-ID: <45CED48A.5070006@yless4u.com.au> This change came about when a friend described his problems in getting wine going to see if it would help him with making a Windows app run under Linux. He did not want to get into the details of wine as his was a opportunistic need and his comment that hit home was "that many a newbie expects software to just install but wine seems too complicated and there is not a cheat sheet". It seems that there is nowhere where the basics are described step by step for the first time casual user. Jeff Latimer -------------- next part -------------- Index: en/wineusr-introduction.sgml =================================================================== RCS file: /cvsroot/wine/docs/en/wineusr-introduction.sgml,v retrieving revision 1.4 diff -u -u -r1.4 wineusr-introduction.sgml --- en/wineusr-introduction.sgml 12 Dec 2006 04:11:06 -0000 1.4 +++ en/wineusr-introduction.sgml 11 Feb 2007 08:04:31 -0000 @@ -52,6 +52,50 @@ </para> </sect2> + <sect2> + <title>Quick start + + The process of installing and running wine can be summarised as + follows: + + + + Get a distribution as indicated in Getting Wine and see + the Wine + Downloads page. For the casual or new user the simplest + is to get an rpm distribution. + + + + + Configure wine using the winecfg + command. For most people wine should now be usable. + + + + + To test your installation run wine's Windows 3.1 like file + manager using the wine winefile command. + + + + + Run wine using the wine + filespec/appname.exe command. + + + The first command you will run will be to install a package. + Typically something like wine + /media/cdrom/setup.exe or the equivalent. + + + + + + From mstefani at redhat.com Sun Feb 11 04:33:14 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Sun Feb 11 04:33:26 2007 Subject: signedness/WINAPI changing question In-Reply-To: <639467.6460.qm@web52701.mail.yahoo.com> References: <639467.6460.qm@web52701.mail.yahoo.com> Message-ID: <45CEF0EA.1000108@redhat.com> Joris Huizer wrote: > I have a small question: > > I find some function > LONG WINAPI AVIStreamSampleToTime(PAVISTREAM > pstream, LONG lSample) > (in the avifil32 dll), the second parameter should > really be an ULONG instead of a LONG. It'd fix the > signedness problems. > > My question is, is such a change allowed? If it is a official WinAPI you have to conform to what Windows has there. If it is an internal function you can change it. > And what should I do to update for such a change > (except for the header gcc warns about) > > In case such change must not be performed, I'll just > add a local variable which is a casted version. > I thought this needs asking; adding in unnecessary > variables doesn't seem the best fix to me. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From fgouget at free.fr Sun Feb 11 04:50:32 2007 From: fgouget at free.fr (Francois Gouget) Date: Sun Feb 11 04:50:40 2007 Subject: signedness/WINAPI changing question In-Reply-To: <639467.6460.qm@web52701.mail.yahoo.com> References: <639467.6460.qm@web52701.mail.yahoo.com> Message-ID: On Sat, 10 Feb 2007, Joris Huizer wrote: > > I find some function > LONG WINAPI AVIStreamSampleToTime(PAVISTREAM > pstream, LONG lSample) > (in the avifil32 dll), the second parameter should > really be an ULONG instead of a LONG. It'd fix the > signedness problems. > > My question is, is such a change allowed? No. Our headers must match the PSDK ones otherwise it would cause trouble for people trying to recompile Windows code with them. Since the PSDK says the second parameter is a LONG, that's what we have to use too. -- Francois Gouget http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different. From twickline at gmail.com Sun Feb 11 05:22:47 2007 From: twickline at gmail.com (Tom Wickline) Date: Sun Feb 11 05:22:52 2007 Subject: DirectX related question In-Reply-To: <2c97fe9d0702110001h735e4b78ocefe4e532b123aa4@mail.gmail.com> References: <2c97fe9d0702110001h735e4b78ocefe4e532b123aa4@mail.gmail.com> Message-ID: <53e3a9930702110322h27e075dar4c13a79998e382eb@mail.gmail.com> On 2/11/07, Tim Schmidt wrote: > Already looking at buying a new computer to play Supreme Commander > (http://en.wikipedia.org/wiki/Supreme_commander), is there anything I > can do (including, but not limited to purchasing hardware) to help get > this game running under Wine? I can't promise miracles, but if I can > break down a few obstacles, consider it done. Fix the bugs in Wine and send your patches to wine-patches. File bug reports pertaining to this game, as well as become a maintainer for the game in our AppDB: http://appdb.winehq.org/appview.php?iAppId=4051 Purchase a copy of CrossOver and vote for DirectX support: http://www.codeweavers.com/compatibility/browse/name?app_id=249 Tom > > --tim > > > From stefandoesinger at gmx.at Sun Feb 11 06:53:15 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sun Feb 11 06:54:04 2007 Subject: opengl code, WoW and graphic cards with 64MB video memory In-Reply-To: <200702100644.49593.chris.kcat@gmail.com> References: <001a01c74cf0$59c5dd70$4001a8c0@glis> <45CDD584.7090006@nildram.co.uk> <200702100644.49593.chris.kcat@gmail.com> Message-ID: <200702111353.26744.stefandoesinger@gmx.at> Am Samstag 10 Februar 2007 15:44 schrieb Chris Robinson: > AFAIK, OpenGL doesn't really care how much video memory you have. If you > run out, it'll just start hapilly swapping to your system RAM automatically > (with a nice performance hit). If your system RAM runs out, then you can > have problems. Yes, opengl does not have the concept of video memory like DirectX has. OpenGL implementations can work without video memory, for example mesa software rendering, or rendering using a remote opengl server. On implementations with video memory, the opengl driver has to take care of that. The way it does that is transparent to wine and the applications. > That error, though, looks like its trying to use an extension that the > driver/card doesn't fully support. It gets a NULL pointer for some > function, tries to call it without checking, and you get a nice NULL > pointer dereference. It doesn't have to be caused by opengl at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070211/9ec6933c/attachment.pgp From skorka at gmx.net Sun Feb 11 04:26:22 2007 From: skorka at gmx.net (Daniel) Date: Sun Feb 11 11:01:51 2007 Subject: doc: Add a Quick start to the Wine User Guide In-Reply-To: <45CED48A.5070006@yless4u.com.au> References: <45CED48A.5070006@yless4u.com.au> Message-ID: <20070211102622.GB4221@iapetus.hadiko.de> On Sun, Feb 11, 2007 at 07:32:10PM +1100, Jeff L wrote: > + Run wine using the + linkend="running">wine > + filespec/appname.exe command. This > + The first command you will run will be to install a package. > + Typically something like wine > + /media/cdrom/setup.exe or the equivalent. and this is asking for pain. $ cd filespec && wine appname.exe and $ cd /media/cdrom && wine setup.exe are what you want to use. Daniel -- A: Because it reverses the logical flow of conservation. Q: Why is top posting frowned upon? From truiken at gmail.com Sun Feb 11 11:53:10 2007 From: truiken at gmail.com (James Hawkins) Date: Sun Feb 11 11:53:04 2007 Subject: comtctl32 : updown : Getter and Setter Tests for Updown control In-Reply-To: References: Message-ID: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> On 2/10/07, Leslie Choong wrote: > Hi there, My name is Leslie Choong and I am currently finishing up my > under graduate work at UCLA. This patch is being sent as part of the > coursework for CS 130 : Software Engineering. Please take a look and > let me know if you have any suggestions or comments for change. > Thanks! > -Leslie Choong > + /* Set Range from 0 to 100 */ + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); + r= SendMessage(updown, UDM_GETRANGE, 0,0); If you're not going to check the first return value, then take out the 'r =', else it seems like you're missing a test. On the other hand, why don't you test the return value? -- James Hawkins From kai.blin at gmail.com Sun Feb 11 12:33:42 2007 From: kai.blin at gmail.com (Kai Blin) Date: Sun Feb 11 12:35:57 2007 Subject: First implementation of a directplay service provider In-Reply-To: <200702101939.55344.alex.pigna@inventati.org> References: <200702101939.55344.alex.pigna@inventati.org> Message-ID: <200702111933.46693.kai.blin@gmail.com> On Saturday 10 February 2007 19:39, Alessandro Pignotti wrote: > I'm working to implement a service provider compatible with the protocol > used by directplay over TCP/IP. > Currently i've implemented the lobby code and tested it against > simpleconnect.exe and chatconnect.exe from the DirectX 7 SDK. At the very end of the patch, you missed a C++ style comment. (+ data->dwReserved1=0x1f4; //Values taken from registry (are they useful at all?)) Btw, I think you should set that data to NULL for now, rather than any random magic value. You shouldn't need the +#define LOBBYINFORMATIONFLAG_CLIENTSERVER 0x00000001 +#define LOBBYINFORMATIONFLAG_MIGRATEHOST 0x00000004 +#define LOBBYINFORMATIONFLAG_NODPSRV 0x00000040 +#define LOBBYINFORMATIONFLAG_PASSWORD 0x00000080 +#define LOBBYINFORMATIONFLAG_NOENUMS 0x00000100 +#define LOBBYINFORMATIONFLAG_FASTSIGN 0x00000200 +#define LOBBYINFORMATIONFLAG_FULLSIGN 0x00000400 +#define LOBBYINFORMATIONFLAG_ENCAPSULATE 0x00002000 stuff, as dplay.h defines that already, iirc. + inf->lobbyID=0x01020304;//Just a fixed Id now, will randomize someday There is some pattern to the DPIDs after the first. They're not random. I just didn't quite figure out how it works yet. Btw, you missed a C++ style comment there.. A few lines over that line, too. You're not sending a dplay version in your header so far. Is that intentional? Why are you declaring dummy functions and then comment out setting them in SPInit()? Good work, anyhow. Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070211/ef754bbe/attachment.pgp From timschmidt at gmail.com Sun Feb 11 14:21:53 2007 From: timschmidt at gmail.com (Tim Schmidt) Date: Sun Feb 11 14:21:58 2007 Subject: DirectX related question In-Reply-To: <53e3a9930702110322h27e075dar4c13a79998e382eb@mail.gmail.com> References: <2c97fe9d0702110001h735e4b78ocefe4e532b123aa4@mail.gmail.com> <53e3a9930702110322h27e075dar4c13a79998e382eb@mail.gmail.com> Message-ID: <2c97fe9d0702111221x1a80ec47o7293815aa54002c@mail.gmail.com> On 2/11/07, Tom Wickline wrote: > Fix the bugs in Wine and send your patches to wine-patches. > > File bug reports pertaining to this game, as well as become a maintainer > for the game in our AppDB: > http://appdb.winehq.org/appview.php?iAppId=4051 > > Purchase a copy of CrossOver and vote for DirectX support: > http://www.codeweavers.com/compatibility/browse/name?app_id=249 I'll purchase crossover, but it looks like SupComm wants pixel shader 2.0, so I was thinking more along the lines of someone who wants to hack on DirectX 10, but has no DirectX 10 capable hardware. Or no DirectX 10 games to test against, etc. Anyone? --tim From septikus at gmail.com Sun Feb 11 12:39:30 2007 From: septikus at gmail.com (Leslie Choong) Date: Sun Feb 11 15:29:31 2007 Subject: comtctl32 : updown : Getter and Setter Tests for Updown control In-Reply-To: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> References: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> Message-ID: Thanks for the input. UDM_SETRANGE has no return value according to MSDN so I'll remove those assignments. On 2/11/07, James Hawkins wrote: > On 2/10/07, Leslie Choong wrote: > > Hi there, My name is Leslie Choong and I am currently finishing up my > > under graduate work at UCLA. This patch is being sent as part of the > > coursework for CS 130 : Software Engineering. Please take a look and > > let me know if you have any suggestions or comments for change. > > Thanks! > > -Leslie Choong > > > > + /* Set Range from 0 to 100 */ > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > If you're not going to check the first return value, then take out the > 'r =', else it seems like you're missing a test. On the other hand, > why don't you test the return value? > > -- > James Hawkins > From mk144210 at bcm.tmc.edu Sun Feb 11 15:34:22 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Sun Feb 11 15:35:02 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. Message-ID: <1171229662.9224.10.camel@misha-laptop> Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value "always" or "never." When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? Thanks Misha p.s. please please please anyone who is familiar with IShellFolder if you could look over those parts and just say yes it looks good that would make me feel better. I think it is correct but really an expert's opinion would be great. From joris_huizer at yahoo.com Sun Feb 11 16:01:45 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Sun Feb 11 16:02:24 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <1171229496.9224.6.camel@misha-laptop> Message-ID: <858119.38158.qm@web52702.mail.yahoo.com> It seems the patch itself got lost ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From truiken at gmail.com Sun Feb 11 16:09:35 2007 From: truiken at gmail.com (James Hawkins) Date: Sun Feb 11 16:09:44 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <1171229496.9224.6.camel@misha-laptop> References: <1171229496.9224.6.camel@misha-laptop> Message-ID: <22821af30702111409o5247f02ay430b9165011eb8ed@mail.gmail.com> On 2/11/07, Misha Koshelev wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins From r.kalbermatter at hccnet.nl Sun Feb 11 16:13:15 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Sun Feb 11 16:15:24 2007 Subject: DIB Engine, some summarization Message-ID: <003901c74e29$d44955b0$4001a8c0@glis> This is getting a bit long so if you do not have time, then skip this. I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea what the possible architecture could be. First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys. Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine. A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS. If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the according Eng... function. GDI32 exports most of those Eng... functions too but that are simply user space wrappers around the win32k.sys entry points for those functions. >From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys eventhough they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Eventhough Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point. There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same. I can't really see however how it would be possible to change that interface to match the modern NT display driver interface in a seemless manner as it would mean a significant change in winex11.drv, winequartz.drv and the GDI32 (aka win32k.sys) that would need to be done mostly in a few big chunks to not completly break everything. So what would remain is adding the actual Eng... and object access API to GDI. These APIs are (all?) documented in the DDK and could be implemented based on MSDN information alone together with maybe some test cases. The actual driver interface might remain mostly the same as it is now with some extra addition to return to the GDI engine extra flags to indicate hooks for DIB surfaces. Then implementation of the Eng... functions would have to start and as they are fleshed out and work they get integrated into the calling logic one for one. Until this is completely done the current separations for DIBs into appstate and serverstate would have to remain, so that the X11 driver can still pass them to the X11 server for rendering of not implemented DIB engine operations. Once the DIB engine is finished (if ever :-) this could be removed as the X11 driver would not anymore hook any of the DIB operations. If winequartz.drv wants to continue hooking DIB operations it can do so of course. To start with, the actual header winddi.h defining most of the Eng.. calls could be added as ddk header to Wine. There seems to be a copyright free version of this header file from Casper S. Hornstrup that is part of the w32api package. I have thought about modifying the driver function call array instead as Alexandre has pointed out in the past as possible solution instead of adding the actual Eng... calls explicitedly into the GDI engine as fall back. But this seems not a good solution to me. The driver wants to be informed of graphic operations for device specific surfaces most often I would assume and only might want to not get called for device contexts containing a dib section. And as some have pointed out winequartz may even want to get called for DIBs too. In order to allow for such a dynamic overriding of function pointers in the driver function array, that array would have to be allocated dynamically on a device context base and I think this would make everything slower, more memory consuming and it wouldn't really be easier although I admit that adding Eng.. calls everywhere and correctly is quite some work to do. The issue about network transparency for the display driver would not be an issue IMO. Once complete the DIB engine would handle all DIB operations locally and so no need for translating direct memory access into remote calls to some display server would be necessary. And the blitting of DIBs to the display when necessary would still be done through the driver of course so everything would be transparent as far as the capabilities of the used display device itself allow for that. Rolf Kalbermatter From mk144210 at bcm.tmc.edu Sun Feb 11 16:33:00 2007 From: mk144210 at bcm.tmc.edu (Koshelev, Misha Vladislavo) Date: Sun Feb 11 16:36:28 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. References: <1171229496.9224.6.camel@misha-laptop> <22821af30702111409o5247f02ay430b9165011eb8ed@mail.gmail.com> Message-ID: <10C24F7C4D05EB45B5F0E1B397897849010F7BDB@BCMEVS7.ad.bcm.edu> Well, that is what I thought too, I sent out another patch that does not have these anti-security measures, but there were a lot of responses about them being necessary and someone marked the bug report as WILLNOTFIX. Anyhow, both patches have been sent to wine-patches and also are available in the bug report #7384, so I think Alexandre can choose one or the other. Anyone have any comments about the IShellFolder code or jus want to check it over and give me a yay or nay? It works for me, but I just wanted to check with an expert. Misha -----Original Message----- From: James Hawkins [mailto:truiken@gmail.com] Sent: Sun 2/11/2007 4:09 PM To: wine-devel@winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: wineboot: Start items in StartUp folder on boot, includes security measures. On 2/11/07, Misha Koshelev wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070211/b35c988e/attachment.html From mk144210 at bcm.tmc.edu Sun Feb 11 17:58:47 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Sun Feb 11 17:59:29 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. [with the patch] Message-ID: <1171238327.6269.4.camel@misha-laptop> I forgot to include the patch, so here it is. Misha --- Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value "always" or "never." When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? Thanks Misha -------------- next part -------------- From 47a35d8e5296a094b14b03d01ab001f90a60b50e Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 11 Feb 2007 15:19:46 -0600 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. --- programs/wineboot/En.rc | 36 +++++++ programs/wineboot/Makefile.in | 5 + programs/wineboot/wineboot.c | 201 +++++++++++++++++++++++++++++++++++++++++ programs/wineboot/wineboot.h | 21 ++++ programs/wineboot/wineboot.rc | 26 +++++ 5 files changed, 286 insertions(+), 3 deletions(-) diff --git a/programs/wineboot/En.rc b/programs/wineboot/En.rc new file mode 100644 index 0000000..286b03c --- /dev/null +++ b/programs/wineboot/En.rc @@ -0,0 +1,36 @@ +/* + * Wine Boot + * English Language Support + * + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT + +Run_Confirmation_Dialog DIALOG 100, 200, 300, 70 +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION +CAPTION "Simulating Windows Boot" +FONT 8, "MS Shell Dlg" +{ + LTEXT "The following program would like to be run:", -1, 20, 10, 260, 12 + LTEXT "Program name here", ID_PROGRAM, 20, 22, 260, 12 + LTEXT "Would you like to run the program?", -1, 20, 34, 260, 12 + PUSHBUTTON "Always", ID_ALWAYS, 40, 50, 50, 14, WS_GROUP | WS_TABSTOP + PUSHBUTTON "Yes", IDYES, 100, 50, 50, 14, WS_GROUP | WS_TABSTOP + DEFPUSHBUTTON "No", IDNO, 160, 50, 50, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP + PUSHBUTTON "Never", ID_NEVER, 220, 50, 50, 14, WS_GROUP | WS_TABSTOP +} diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in index 08c27a5..7437cab 100644 --- a/programs/wineboot/Makefile.in +++ b/programs/wineboot/Makefile.in @@ -4,12 +4,15 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = wineboot.exe APPMODE = -mconsole -IMPORTS = version user32 advapi32 kernel32 +IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi +EXTRALIBS = -luuid C_SRCS = \ shutdown.c \ wineboot.c +RC_SRCS = wineboot.rc + @MAKE_PROG_RULES@ @DEPENDENCIES@ # everything below this line is overwritten by make depend diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c index 1434003..d4095aa 100644 --- a/programs/wineboot/wineboot.c +++ b/programs/wineboot/wineboot.c @@ -37,7 +37,7 @@ * - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, synch) * - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch) * - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch) - * - Startup folders (all, ?asynch?, no imp) + * - Startup folders (all, ?asynch?) * - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, asynch) * * Somewhere in there is processing the RunOnceEx entries (also no imp) @@ -63,6 +63,14 @@ #endif #include #include +#define COBJMACROS +#include +#include +#include +#include + +#include "wineboot.h" + WINE_DEFAULT_DEBUG_CHANNEL(wineboot); #define MAX_LINE_LENGTH (2*MAX_PATH+2) @@ -616,6 +624,193 @@ static int ProcessWindowsFileProtection( return 1; } +/* A dialog box handler for the run confirmation dialog box. */ +static INT_PTR rcd_Setup(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) +{ + HWND hWndDesktop; + RECT rcDesktop, rc; + LPCWSTR wProgram; + + switch(uMsg) + { + case WM_INITDIALOG: + /* Center the dialog box */ + hWndDesktop = GetDesktopWindow(); + GetWindowRect(hWndDesktop, &rcDesktop); + GetWindowRect(hWnd, &rc); + SetWindowPos(hWnd, HWND_TOP, (rcDesktop.right/2)-((rc.right-rc.left)/2), + (rcDesktop.bottom/2)-((rc.bottom-rc.top)/2), + 0, 0, SWP_NOSIZE); + + /* Set the program name. */ + wProgram = (LPCWSTR)lParam; + SetDlgItemTextW(hWnd, ID_PROGRAM, wProgram); + return TRUE; + + case WM_COMMAND: + if (wParam == ID_ALWAYS || wParam == IDYES || wParam == IDNO || wParam == ID_NEVER) + EndDialog(hWnd, wParam); + return TRUE; + + default: + return FALSE; /* since I don't process this particular message */ + } +} + +/* Process items in the StartUp group of the user's Programs under the Start Menu. Some installers put + * shell links here to restart themselves after boot. */ +static BOOL ProcessStartupItems() +{ + static const WCHAR AlwaysW[] = { 'a','l','w','a','y','s',0 }; + static const WCHAR NeverW[] = { 'n','e','v','e','r',0 }; + static const WCHAR StartupItemsW[] = { 'S','o','f','t','w','a','r','e','\\', + 'W','i','n','e','\\', + 'S','t','a','r','t','u','p','I','t','e','m','s',0 }; + + BOOL ret = FALSE; + HRESULT hr; + int iRet; + IMalloc *ppM = NULL; + IShellFolder *psfDesktop = NULL, *psfStartup = NULL; + LPITEMIDLIST pidlStartup = NULL, pidlItem; + ULONG NumPIDLs; + IEnumIDList *iEnumList = NULL; + STRRET strret; + WCHAR wszCommand[MAX_PATH], wszBuffer[MAX_PATH]; + HINSTANCE hInst = GetModuleHandle(NULL); + DWORD res, bufLength; + HKEY hKeyStartupItems = NULL; + + WINE_TRACE("Processing items in the StartUp folder.\n"); + + RegOpenKeyExW( HKEY_CURRENT_USER, StartupItemsW, 0, KEY_ALL_ACCESS, &hKeyStartupItems ); + + hr = SHGetMalloc(&ppM); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get IMalloc object.\n"); + goto done; + } + + hr = SHGetDesktopFolder(&psfDesktop); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get desktop folder.\n"); + goto done; + } + + hr = SHGetSpecialFolderLocation(NULL, CSIDL_STARTUP, &pidlStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't get StartUp folder location.\n"); + goto done; + } + + hr = IShellFolder_BindToObject(psfDesktop, pidlStartup, NULL, &IID_IShellFolder, (LPVOID*)&psfStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't bind IShellFolder to StartUp folder.\n"); + goto done; + } + + hr = IShellFolder_EnumObjects(psfStartup, NULL, SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &iEnumList); + if (FAILED(hr)) + { + WINE_TRACE("Unable to enumerate StartUp objects.\n"); + goto done; + } + + while (IEnumIDList_Next(iEnumList, 1, &pidlItem, &NumPIDLs) == S_OK && + (NumPIDLs) == 1) + { + hr = IShellFolder_GetDisplayNameOf(psfStartup, pidlItem, SHGDN_FORPARSING, &strret); + if (FAILED(hr)) + WINE_TRACE("Unable to get display name of enumeration item.\n"); + else + { + hr = StrRetToBufW(&strret, pidlItem, wszCommand, MAX_PATH); + if (FAILED(hr)) + WINE_TRACE("Unable to parse display name.\n"); + else { + /* Our default behavior is not to run */ + iRet = IDNO; + + /* Check the registry to see if a default behavior was previously selected for this item */ + if (hKeyStartupItems) { + bufLength = MAX_PATH; + res = RegQueryValueExW(hKeyStartupItems, wszCommand, NULL, NULL, (LPBYTE)wszBuffer, &bufLength); + if (res == ERROR_SUCCESS) { + /* Two possibilities here, always or never */ + if (!StrCmpW(wszBuffer, AlwaysW)) iRet = ID_ALWAYS; + else if (!StrCmpW(wszBuffer, NeverW)) iRet = ID_NEVER; + else + WINE_ERR("StartupItem %s has undefined registry action %s.\n", wine_dbgstr_w(wszCommand), wine_dbgstr_w(wszBuffer)); + } + } + + /* If did not find a key (our behavior is still not to run), ask the user */ + if (iRet == IDNO) + iRet = DialogBoxParam(hInst, "Run_Confirmation_Dialog", NULL, (DLGPROC)rcd_Setup, (LPARAM)wszCommand); + + /* Now do what we determined either from the registry or from the user */ + switch (iRet) { + case ID_ALWAYS: + /* Set the appropriate registry key */ + if (!hKeyStartupItems && + (res = RegCreateKeyExW(HKEY_CURRENT_USER, StartupItemsW, 0, NULL, + REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, + &hKeyStartupItems, NULL)) != ERROR_SUCCESS) + WINE_ERR("Error %d creating registry key %s.\n", res, wine_dbgstr_w(StartupItemsW)); + else if ((res = RegSetValueExW(hKeyStartupItems, wszCommand, 0, REG_SZ, + (LPBYTE) AlwaysW, + (lstrlenW(AlwaysW)+1)*sizeof(WCHAR))) != ERROR_SUCCESS) + WINE_ERR("Error %d setting registry key %s value to %s.\n", res, + wine_dbgstr_w(wszCommand), wine_dbgstr_w(AlwaysW)); + + /* Go from always to running the command, no break needed here. */ + + case IDYES: + if ((iRet = (int)ShellExecuteW(NULL, NULL, wszCommand, NULL, NULL, 0)) <= 32) + WINE_ERR("Error %d executing command %s.\n", iRet, wine_dbgstr_w(wszCommand)); + break; + + case IDNO: /* don't run, but leave file intact. */ + break; + + case ID_NEVER: /* don't run, set registry key. */ + if (!hKeyStartupItems && + (res = RegCreateKeyExW(HKEY_CURRENT_USER, StartupItemsW, 0, NULL, + REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, + &hKeyStartupItems, NULL)) != ERROR_SUCCESS) + WINE_ERR("Error %d creating registry key %s.\n", res, wine_dbgstr_w(StartupItemsW)); + else if ((res = RegSetValueExW(hKeyStartupItems, wszCommand, 0, REG_SZ, + (LPBYTE) NeverW, + (lstrlenW(NeverW)+1)*sizeof(WCHAR))) != ERROR_SUCCESS) + WINE_ERR("Error %d setting registry key %s value to %s.\n", res, + wine_dbgstr_w(wszCommand), wine_dbgstr_w(NeverW)); + break; + + default: /* Unknown return value */ + WINE_ERR("DialogBoxParam returned an unknown value %d.\n", iRet); + } + } + } + + IMalloc_Free(ppM, pidlItem); + } + + /* Return success */ + ret = TRUE; + +done: + if (iEnumList) IEnumIDList_Release(iEnumList); + if (psfStartup) IShellFolder_Release(psfStartup); + if (pidlStartup) IMalloc_Free(ppM, pidlStartup); + if (hKeyStartupItems) RegCloseKey(hKeyStartupItems); + + return ret; +} + static void usage(void) { WINE_MESSAGE( "Usage: wineboot [options]\n" ); @@ -732,7 +927,9 @@ int main( int argc, char *argv[] ) FALSE, FALSE )) && (!ops.postlogin || !ops.startup || ProcessRunKeys( HKEY_CURRENT_USER, runkeys_names[RUNKEY_RUN], - FALSE, FALSE )); + FALSE, FALSE )) && + (!ops.postlogin || !ops.startup || + ProcessStartupItems( )); WINE_TRACE("Operation done\n"); diff --git a/programs/wineboot/wineboot.h b/programs/wineboot/wineboot.h new file mode 100644 index 0000000..5c838b4 --- /dev/null +++ b/programs/wineboot/wineboot.h @@ -0,0 +1,21 @@ +/* + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define ID_PROGRAM 997 +#define ID_ALWAYS 998 +#define ID_NEVER 999 diff --git a/programs/wineboot/wineboot.rc b/programs/wineboot/wineboot.rc new file mode 100644 index 0000000..0abd583 --- /dev/null +++ b/programs/wineboot/wineboot.rc @@ -0,0 +1,26 @@ +/* + * WINEBOOT.RC + * + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include +#include "wineboot.h" + +#include "En.rc" + +LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL -- 1.4.1 From richardvoigt at gmail.com Sun Feb 11 20:49:58 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sun Feb 11 20:50:06 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <1171229662.9224.10.camel@misha-laptop> References: <1171229662.9224.10.camel@misha-laptop> Message-ID: <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> On 2/11/07, Misha Koshelev wrote: > Hi everybody, > > Thanks for your suggestions. I just posted a new patch on wine-patches > where I tried to incorporate these and now it does the following (in > addition to my previous patch which just started items in the StartUp > folder): > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > What do you guys think? If you like the system, it would be pretty easy > to incorporate this into the run key running as well (which are > currently just run without any user confirmation)? This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Startup items behavior: (*) Silently allow <-- This is "bug-for-bug compatibility" ( ) Ask <-- Most computer-savvy folks would want this ( ) Silently block ( ) Block and notify me Perhaps this should be independently set for each kind of startup item (startmenu\programs\startup, registry run key, profile settings, etc), but I think that's not really necessary. Also, I would suggest that the list of approved start items be stored outside of winespace, so that malware can't bypass the protection by setting the key. Of course, really nasty stuff could still call into Linux, but that would require some hybrid system that was aware of the ELF dynamic loader in order to not fall afoul of address space randomization. Ultimately I think wine is about more than just running Windows-compatible programs without the Microsoft tax. It's about running those programs without ceding control of your computer to an untrustworthy party. We don't want the limitations that Windows imposes... true bug-for-bug compatibility would mean only being able to access files on a FAT or NTFS partition, but I don't hear anyone advocating for that kind of crippling behavior. > > Thanks > Misha > > p.s. please please please anyone who is familiar with IShellFolder if > you could look over those parts and just say yes it looks good that > would make me feel better. I think it is correct but really an expert's > opinion would be great. > > > From flexo at holycrap.org Sun Feb 11 21:14:13 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sun Feb 11 21:07:35 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> Message-ID: <45CFDB85.4030609@holycrap.org> richardvoigt@gmail.com wrote: > This sounds almost perfect. I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Since we want winecfg to be gone in the long-term a registry key alone would probably do fine. Felix From tony.lambregts at gmail.com Sun Feb 11 21:17:54 2007 From: tony.lambregts at gmail.com (Tony Lambregts) Date: Sun Feb 11 21:17:08 2007 Subject: AppDB performance issue In-Reply-To: <45CE4FB4.6040403@mic-nucmed.co.uk> References: <45CE4FB4.6040403@mic-nucmed.co.uk> Message-ID: <45CFDC62.6020009@gmail.com> Nick Law wrote: > Hi Tony, > Just lately, I've noticed that AppDB seems to be very slow, i.e it can > take15 seconds or more for a page to come up or simply to login. Is > there a bandwidth problem or is the server getting overwhelmed or is > it a problem at my end (UK). 30 seconds later it's back to being very > responsive as if the server was a bit overloaded for 30 seconds or so. > Other websites I try at the time work fine including winehq. Is winehq > on a different server ? > I have noticed this too and it is very annoying. Yes www.winehq.org qpdb.winehq.or and bugs.winehq.org are all on the same server. Winehq and bugzilla are quite snappy but the AppDB is a pig now. I have know idea what is wrong -- Tony Lambregst From chmorgan at gmail.com Sun Feb 11 21:20:40 2007 From: chmorgan at gmail.com (Chris Morgan) Date: Sun Feb 11 21:20:48 2007 Subject: AppDB performance issue In-Reply-To: <45CFDC62.6020009@gmail.com> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> Message-ID: Are particular pages slow? I'm not seeing slow page loads to the main page or to an application version page from here, a few seconds for each. Chris On 2/11/07, Tony Lambregts wrote: > Nick Law wrote: > > Hi Tony, > > Just lately, I've noticed that AppDB seems to be very slow, i.e it can > > take15 seconds or more for a page to come up or simply to login. Is > > there a bandwidth problem or is the server getting overwhelmed or is > > it a problem at my end (UK). 30 seconds later it's back to being very > > responsive as if the server was a bit overloaded for 30 seconds or so. > > Other websites I try at the time work fine including winehq. Is winehq > > on a different server ? > > > I have noticed this too and it is very annoying. Yes www.winehq.org > qpdb.winehq.or and bugs.winehq.org are all on the same server. > > Winehq and bugzilla are quite snappy but the AppDB is a pig now. > > I have know idea what is wrong > > -- > > Tony Lambregst > > > From tony.lambregts at gmail.com Sun Feb 11 21:36:24 2007 From: tony.lambregts at gmail.com (Tony Lambregts) Date: Sun Feb 11 21:35:35 2007 Subject: AppDB performance issue In-Reply-To: References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> Message-ID: <45CFE0B8.6000501@gmail.com> Chris Morgan wrote: > On 2/11/07, Tony Lambregts wrote: >> Nick Law wrote: >> > Hi Tony, >> > Just lately, I've noticed that AppDB seems to be very slow, i.e it can >> > take15 seconds or more for a page to come up or simply to login. Is >> > there a bandwidth problem or is the server getting overwhelmed or is >> > it a problem at my end (UK). 30 seconds later it's back to being very >> > responsive as if the server was a bit overloaded for 30 seconds or so. >> > Other websites I try at the time work fine including winehq. Is winehq >> > on a different server ? >> > >> I have noticed this too and it is very annoying. Yes www.winehq.org >> qpdb.winehq.or and bugs.winehq.org are all on the same server. >> >> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >> >> I have know idea what is wrong >> >> -- >> >> Tony Lambregst >> >> >> > > Are particular pages slow? I'm not seeing slow page loads to the main > page or to an application version page from here, a few seconds for > each. > > Chris > > I see it when doing administration ie accepting or rejectiong applications and versions (maybe its the way we send emails). -- Tony Lambregts From mk144210 at bcm.tmc.edu Sun Feb 11 21:47:29 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Sun Feb 11 21:48:07 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <45CFDB85.4030609@holycrap.org> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <45CFDB85.4030609@holycrap.org> Message-ID: <1171252049.6269.17.camel@misha-laptop> Ok, I sent out a patch with this fix to wine-patches. Now the HKEY_CURRENT_USER\Software\Wine\StartupItems key can be set to "always" which will make all items always run. Otherwise, previous behavior with asking/keys for each individual items will occur. Misha On Mon, 2007-02-12 at 04:14 +0100, Felix Nawothnig wrote: > richardvoigt@gmail.com wrote: > > This sounds almost perfect. I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > Since we want winecfg to be gone in the long-term a registry key alone > would probably do fine. > > Felix -------------- next part -------------- From 7465a6f5e695a33670343cd959fca3fbf763899a Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 11 Feb 2007 21:41:51 -0600 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. --- programs/wineboot/En.rc | 36 +++++++ programs/wineboot/Makefile.in | 5 + programs/wineboot/wineboot.c | 222 +++++++++++++++++++++++++++++++++++++++++ programs/wineboot/wineboot.h | 21 ++++ programs/wineboot/wineboot.rc | 26 +++++ 5 files changed, 307 insertions(+), 3 deletions(-) diff --git a/programs/wineboot/En.rc b/programs/wineboot/En.rc new file mode 100644 index 0000000..286b03c --- /dev/null +++ b/programs/wineboot/En.rc @@ -0,0 +1,36 @@ +/* + * Wine Boot + * English Language Support + * + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT + +Run_Confirmation_Dialog DIALOG 100, 200, 300, 70 +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION +CAPTION "Simulating Windows Boot" +FONT 8, "MS Shell Dlg" +{ + LTEXT "The following program would like to be run:", -1, 20, 10, 260, 12 + LTEXT "Program name here", ID_PROGRAM, 20, 22, 260, 12 + LTEXT "Would you like to run the program?", -1, 20, 34, 260, 12 + PUSHBUTTON "Always", ID_ALWAYS, 40, 50, 50, 14, WS_GROUP | WS_TABSTOP + PUSHBUTTON "Yes", IDYES, 100, 50, 50, 14, WS_GROUP | WS_TABSTOP + DEFPUSHBUTTON "No", IDNO, 160, 50, 50, 14, BS_DEFPUSHBUTTON | WS_GROUP | WS_TABSTOP + PUSHBUTTON "Never", ID_NEVER, 220, 50, 50, 14, WS_GROUP | WS_TABSTOP +} diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in index 08c27a5..7437cab 100644 --- a/programs/wineboot/Makefile.in +++ b/programs/wineboot/Makefile.in @@ -4,12 +4,15 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = wineboot.exe APPMODE = -mconsole -IMPORTS = version user32 advapi32 kernel32 +IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi +EXTRALIBS = -luuid C_SRCS = \ shutdown.c \ wineboot.c +RC_SRCS = wineboot.rc + @MAKE_PROG_RULES@ @DEPENDENCIES@ # everything below this line is overwritten by make depend diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c index 1434003..ba973cf 100644 --- a/programs/wineboot/wineboot.c +++ b/programs/wineboot/wineboot.c @@ -37,7 +37,7 @@ * - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, synch) * - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch) * - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch) - * - Startup folders (all, ?asynch?, no imp) + * - Startup folders (all, ?asynch?) * - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, asynch) * * Somewhere in there is processing the RunOnceEx entries (also no imp) @@ -63,6 +63,14 @@ #endif #include #include +#define COBJMACROS +#include +#include +#include +#include + +#include "wineboot.h" + WINE_DEFAULT_DEBUG_CHANNEL(wineboot); #define MAX_LINE_LENGTH (2*MAX_PATH+2) @@ -616,6 +624,214 @@ static int ProcessWindowsFileProtection( return 1; } +/* A dialog box handler for the run confirmation dialog box. */ +static INT_PTR rcd_Setup(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) +{ + HWND hWndDesktop; + RECT rcDesktop, rc; + LPCWSTR wProgram; + + switch(uMsg) + { + case WM_INITDIALOG: + /* Center the dialog box */ + hWndDesktop = GetDesktopWindow(); + GetWindowRect(hWndDesktop, &rcDesktop); + GetWindowRect(hWnd, &rc); + SetWindowPos(hWnd, HWND_TOP, (rcDesktop.right/2)-((rc.right-rc.left)/2), + (rcDesktop.bottom/2)-((rc.bottom-rc.top)/2), + 0, 0, SWP_NOSIZE); + + /* Set the program name. */ + wProgram = (LPCWSTR)lParam; + SetDlgItemTextW(hWnd, ID_PROGRAM, wProgram); + return TRUE; + + case WM_COMMAND: + if (wParam == ID_ALWAYS || wParam == IDYES || wParam == IDNO || wParam == ID_NEVER) + EndDialog(hWnd, wParam); + return TRUE; + + default: + return FALSE; /* since I don't process this particular message */ + } +} + +/* Process items in the StartUp group of the user's Programs under the Start Menu. Some installers put + * shell links here to restart themselves after boot. User input is solicited to prevent malware by + * default. The following registry keys are used: + * + * HKEY_CURRENT_USER\Software\Wine\StartupItems - if set to "always" always runs, otherwise asks user + * (determines run behavior for all items) + * HKEY_CURRENT_USER\Software\Wine\StartupItems\FullPathOfFile - set to always or never + * (determines run behavior for item) + * */ +static BOOL ProcessStartupItems() +{ + static const WCHAR AlwaysW[] = { 'a','l','w','a','y','s',0 }; + static const WCHAR NeverW[] = { 'n','e','v','e','r',0 }; + static const WCHAR StartupItemsW[] = { 'S','o','f','t','w','a','r','e','\\', + 'W','i','n','e','\\', + 'S','t','a','r','t','u','p','I','t','e','m','s',0 }; + + BOOL ret = FALSE; + HRESULT hr; + int iRet; + IMalloc *ppM = NULL; + IShellFolder *psfDesktop = NULL, *psfStartup = NULL; + LPITEMIDLIST pidlStartup = NULL, pidlItem; + ULONG NumPIDLs; + IEnumIDList *iEnumList = NULL; + STRRET strret; + WCHAR wszCommand[MAX_PATH], wszBuffer[MAX_PATH]; + HINSTANCE hInst = GetModuleHandle(NULL); + DWORD res, bufLength; + HKEY hKeyStartupItems = NULL; + BOOL bAskUser = TRUE; /* Change this default value to change the default behavior */ + + WINE_TRACE("Processing items in the StartUp folder.\n"); + + /* Get the startup items registry key and record our default ask behavior */ + RegOpenKeyExW( HKEY_CURRENT_USER, StartupItemsW, 0, KEY_ALL_ACCESS, &hKeyStartupItems ); + bufLength = MAX_PATH; + res = RegQueryValueExW(hKeyStartupItems, NULL, NULL, NULL, (LPBYTE)wszBuffer, &bufLength); + if (res == ERROR_SUCCESS) { + if (!StrCmpW(wszBuffer, AlwaysW)) bAskUser = FALSE; /* Always run means never ask */ + else if (!StrCmpW(wszBuffer, NeverW)) bAskUser = TRUE; /* Never ask means always run */ + else + WINE_ERR("Startup Item Ask Behavior has undefined value %s.\n", wine_dbgstr_w(wszBuffer)); + } + + hr = SHGetMalloc(&ppM); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get IMalloc object.\n"); + goto done; + } + + hr = SHGetDesktopFolder(&psfDesktop); + if (FAILED(hr)) + { + WINE_ERR("Couldn't get desktop folder.\n"); + goto done; + } + + hr = SHGetSpecialFolderLocation(NULL, CSIDL_STARTUP, &pidlStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't get StartUp folder location.\n"); + goto done; + } + + hr = IShellFolder_BindToObject(psfDesktop, pidlStartup, NULL, &IID_IShellFolder, (LPVOID*)&psfStartup); + if (FAILED(hr)) + { + WINE_TRACE("Couldn't bind IShellFolder to StartUp folder.\n"); + goto done; + } + + hr = IShellFolder_EnumObjects(psfStartup, NULL, SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &iEnumList); + if (FAILED(hr)) + { + WINE_TRACE("Unable to enumerate StartUp objects.\n"); + goto done; + } + + while (IEnumIDList_Next(iEnumList, 1, &pidlItem, &NumPIDLs) == S_OK && + (NumPIDLs) == 1) + { + hr = IShellFolder_GetDisplayNameOf(psfStartup, pidlItem, SHGDN_FORPARSING, &strret); + if (FAILED(hr)) + WINE_TRACE("Unable to get display name of enumeration item.\n"); + else + { + hr = StrRetToBufW(&strret, pidlItem, wszCommand, MAX_PATH); + if (FAILED(hr)) + WINE_TRACE("Unable to parse display name.\n"); + else { + /* Set the default value based on our ask behavior */ + if (bAskUser) + iRet = IDNO; + else + iRet = IDYES; + + /* If the current behavior is not to start, check the registry for the default behavior for + * this item. */ + if (iRet == IDNO && hKeyStartupItems) { + bufLength = MAX_PATH; + res = RegQueryValueExW(hKeyStartupItems, wszCommand, NULL, NULL, (LPBYTE)wszBuffer, &bufLength); + if (res == ERROR_SUCCESS) { + /* Two possibilities here, always or never */ + if (!StrCmpW(wszBuffer, AlwaysW)) iRet = ID_ALWAYS; + else if (!StrCmpW(wszBuffer, NeverW)) iRet = ID_NEVER; + else + WINE_ERR("StartupItem %s has undefined registry action %s.\n", wine_dbgstr_w(wszCommand), wine_dbgstr_w(wszBuffer)); + } + } + + /* If our behavior is still no, ask the user */ + if (iRet == IDNO) + iRet = DialogBoxParam(hInst, "Run_Confirmation_Dialog", NULL, (DLGPROC)rcd_Setup, (LPARAM)wszCommand); + + /* Now do what we determined either from the registry or from the user */ + switch (iRet) { + case ID_ALWAYS: + /* Set the appropriate registry key */ + if (!hKeyStartupItems && + (res = RegCreateKeyExW(HKEY_CURRENT_USER, StartupItemsW, 0, NULL, + REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, + &hKeyStartupItems, NULL)) != ERROR_SUCCESS) + WINE_ERR("Error %d creating registry key %s.\n", res, wine_dbgstr_w(StartupItemsW)); + else if ((res = RegSetValueExW(hKeyStartupItems, wszCommand, 0, REG_SZ, + (LPBYTE) AlwaysW, + (lstrlenW(AlwaysW)+1)*sizeof(WCHAR))) != ERROR_SUCCESS) + WINE_ERR("Error %d setting registry key %s value to %s.\n", res, + wine_dbgstr_w(wszCommand), wine_dbgstr_w(AlwaysW)); + + /* Go from always to running the command, no break needed here. */ + + case IDYES: + if ((iRet = (int)ShellExecuteW(NULL, NULL, wszCommand, NULL, NULL, SW_SHOWNORMAL)) <= 32) + WINE_ERR("Error %d executing command %s.\n", iRet, wine_dbgstr_w(wszCommand)); + break; + + case IDNO: /* don't run, but leave file intact. */ + break; + + case ID_NEVER: /* don't run, set registry key. */ + if (!hKeyStartupItems && + (res = RegCreateKeyExW(HKEY_CURRENT_USER, StartupItemsW, 0, NULL, + REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, + &hKeyStartupItems, NULL)) != ERROR_SUCCESS) + WINE_ERR("Error %d creating registry key %s.\n", res, wine_dbgstr_w(StartupItemsW)); + else if ((res = RegSetValueExW(hKeyStartupItems, wszCommand, 0, REG_SZ, + (LPBYTE) NeverW, + (lstrlenW(NeverW)+1)*sizeof(WCHAR))) != ERROR_SUCCESS) + WINE_ERR("Error %d setting registry key %s value to %s.\n", res, + wine_dbgstr_w(wszCommand), wine_dbgstr_w(NeverW)); + break; + + default: /* Unknown return value */ + WINE_ERR("DialogBoxParam returned an unknown value %d.\n", iRet); + } + } + } + + IMalloc_Free(ppM, pidlItem); + } + + /* Return success */ + ret = TRUE; + +done: + if (iEnumList) IEnumIDList_Release(iEnumList); + if (psfStartup) IShellFolder_Release(psfStartup); + if (pidlStartup) IMalloc_Free(ppM, pidlStartup); + if (hKeyStartupItems) RegCloseKey(hKeyStartupItems); + + return ret; +} + static void usage(void) { WINE_MESSAGE( "Usage: wineboot [options]\n" ); @@ -732,7 +948,9 @@ int main( int argc, char *argv[] ) FALSE, FALSE )) && (!ops.postlogin || !ops.startup || ProcessRunKeys( HKEY_CURRENT_USER, runkeys_names[RUNKEY_RUN], - FALSE, FALSE )); + FALSE, FALSE )) && + (!ops.postlogin || !ops.startup || + ProcessStartupItems( )); WINE_TRACE("Operation done\n"); diff --git a/programs/wineboot/wineboot.h b/programs/wineboot/wineboot.h new file mode 100644 index 0000000..5c838b4 --- /dev/null +++ b/programs/wineboot/wineboot.h @@ -0,0 +1,21 @@ +/* + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define ID_PROGRAM 997 +#define ID_ALWAYS 998 +#define ID_NEVER 999 diff --git a/programs/wineboot/wineboot.rc b/programs/wineboot/wineboot.rc new file mode 100644 index 0000000..0abd583 --- /dev/null +++ b/programs/wineboot/wineboot.rc @@ -0,0 +1,26 @@ +/* + * WINEBOOT.RC + * + * Copyright (c) 2007 Misha Koshelev. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include +#include "wineboot.h" + +#include "En.rc" + +LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL -- 1.4.1 From wine-devel at kievinfo.com Sun Feb 11 22:23:19 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 11 22:24:23 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <45CFDB85.4030609@holycrap.org> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <45CFDB85.4030609@holycrap.org> Message-ID: <45CFEBB7.2060103@kievinfo.com> Felix Nawothnig wrote: > richardvoigt@gmail.com wrote: >> This sounds almost perfect. I think the counterpoint raised by James >> Hawkins would be adequately addressed by adding a winecfg option as >> follows: > > Since we want winecfg to be gone in the long-term a registry key alone Who said that? Or you planning on implementing a winecfg replacement yet again? Vitaliy. From wine-devel at kievinfo.com Sun Feb 11 22:27:06 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 11 22:27:36 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <22821af30702111409o5247f02ay430b9165011eb8ed@mail.gmail.com> References: <1171229496.9224.6.camel@misha-laptop> <22821af30702111409o5247f02ay430b9165011eb8ed@mail.gmail.com> Message-ID: <45CFEC9A.5060906@kievinfo.com> James Hawkins wrote: > On 2/11/07, Misha Koshelev wrote: >> Ok, thanks to everybody's responses on the wine-devel list. Here is my >> new version of this patch. It starts the items in the StartUp folder >> like Windows does (again, if anybody who knows about IShellFolder will >> look over my code that would be great :) I tested it and it works for >> the Vector NTI installer, but I would really like to have an expert's >> opinion on whether it is missing osmething). There were a lot of >> comments on wine-devel about malware using this system to start itself >> so here is what I added: >> >> To me it seems like this would be enough to prevent malware from using >> this system because the user could just click no or never. Also, someone >> pointed out that wineboot already runs quite a lot of other RUN registry >> keys that can be used for malware, and currently there is no system for >> these keys like the one I made for startup. Any comments will be >> appreciated. Thanks. >> > > These anti-malware changes are unnecessary. We implement Wine to be > bug-for-bug compatible with Windows. Windows doesn't ask this Then you will have to implement all the required functionality to allow anti-malware programs to function properly. Until then, Wine have to have some solutions to prevent nasty things to run on Wine. The excuse "bug-for-bug" will not cut it here! If you want that - you should not have ever switched to Linux in the first place. Vitaliy. From dmitry at codeweavers.com Sun Feb 11 22:27:49 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sun Feb 11 22:27:48 2007 Subject: 1/4 NtCreateMailslotFile tests References: <45CEF57E.3010101@yless4u.com.au> Message-ID: <00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> "Jeff Latimer" wrote: > + rc = pNtCreateMailslotFile(&hslot, DesiredAccess, > + &attr, &IoStatusBlock, CreateOptions, MailslotQuota, MaxMessageSize, > + &TimeOut); > + ok( rc == S_OK, "Create MailslotFile failed rc = %x %u\n", rc, GetLastError()); NT APIs return STATUS_xxx error codes, S_OK is an OLE error value. > + ok( hslot != INVALID_HANDLE_VALUE, "Handle is invalid\n"); INVALID_HANDLE_VALUE is a kernel32 thing, NT APIs don't use it. Most likely you need to test returned value against 0. > + ok( CloseHandle(hslot), "CloseHandle failed\n"); To close the handle returned by an NT API you have you use an NT API as well. -- Dmitry. From chris.kcat at gmail.com Sun Feb 11 23:17:31 2007 From: chris.kcat at gmail.com (Chris Robinson) Date: Sun Feb 11 23:18:09 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> Message-ID: <200702112117.32083.chris.kcat@gmail.com> On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com wrote: > This sounds almost perfect. What would stop the program from adding the registry key itself when placing the item in the startup folder, or wherever else? > I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Sounds like it's just asking if it should ask. I'm not really sure what you could do as a user that a program couldn't just override and do itself. Besides, users might not know whether what's being installed into an auto-start key/folder is necessary, deny it for "safety concerns", and have a broken installation. From xixsimplicityxix at gmail.com Sun Feb 11 23:49:18 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Sun Feb 11 23:49:23 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <200702112117.32083.chris.kcat@gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <200702112117.32083.chris.kcat@gmail.com> Message-ID: <78a7dad00702112149h7d577845md067c2cec4f2b8f@mail.gmail.com> What prevents malicious programs from writing this registry key on their own? On 2/11/07, Chris Robinson wrote: > > On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key itself when > placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program couldn't > just > override and do itself. Besides, users might not know whether what's being > installed into an auto-start key/folder is necessary, deny it for "safety > concerns", and have a broken installation. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070211/1cb718df/attachment.htm From dmitry at codeweavers.com Mon Feb 12 00:01:42 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 12 00:01:50 2007 Subject: user32: add test cases for update rects affected by ShowWindow References: <45C96E6D.8040507@utwire.net> Message-ID: <01b501c74e6b$4e0c3ac0$0100a8c0@DMITRY> "Clinton Stimpson" wrote: > This patch adds a test to check the results of GetUpdateRect when a > child window is hidden. > See bug #7360. Wine incorrectly makes an update rect for the > grandparent window which has a todo_wine around it. > > Thanks, > Clinton Stimpson > > ChangeLog: > Add test for GetUpdateRect and ShowWindow interaction. After looking at this test once more, I think we need another test with windows without CS_PARENTDC style set in order to understand better what the proper behaviour is. -- Dmitry. From dank06 at kegel.com Mon Feb 12 00:23:52 2007 From: dank06 at kegel.com (Dan Kegel) Date: Mon Feb 12 00:24:01 2007 Subject: comtctl32 : updown : Getter and Setter Tests for Updown control In-Reply-To: References: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> Message-ID: I haven't looked at what James was talking about, but I noticed three things: You have a typo 'sohuld'. You should use the same filename as before, but increment the number in the filename. You might consider using the expect() macro I've been encouraging the other cs130 students to use, it makes the repeated ok() calls a bit more readable (IMHO, we'll see if others agree). - Dan On 2/11/07, Leslie Choong wrote: > Hey there, I've made the changes so that the return value is not > stored unnecessarily. I've also added comments explaining why. Let me > know what you think. > -Leslie > > On 2/11/07, Leslie Choong wrote: > > Thanks for the input. UDM_SETRANGE has no return value according to > > MSDN so I'll remove those assignments. > > > > On 2/11/07, James Hawkins wrote: > > > On 2/10/07, Leslie Choong wrote: > > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > > under graduate work at UCLA. This patch is being sent as part of the > > > > coursework for CS 130 : Software Engineering. Please take a look and > > > > let me know if you have any suggestions or comments for change. > > > > Thanks! > > > > -Leslie Choong > > > > > > > > > > + /* Set Range from 0 to 100 */ > > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > > > If you're not going to check the first return value, then take out the > > > 'r =', else it seems like you're missing a test. On the other hand, > > > why don't you test the return value? > > > > > > -- > > > James Hawkins > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv From damjan.jov at gmail.com Mon Feb 12 01:24:36 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Mon Feb 12 01:24:40 2007 Subject: DIB Engine, some summarization In-Reply-To: <003901c74e29$d44955b0$4001a8c0@glis> References: <003901c74e29$d44955b0$4001a8c0@glis> Message-ID: <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> On 2/12/07, Rolf Kalbermatter wrote: > The issue about network transparency for the display driver would not be an > issue IMO. > Once complete the DIB engine would handle all DIB operations locally and so > no need for > translating direct memory access into remote calls to some display server > would be > necessary. And the blitting of DIBs to the display when necessary would > still be done > through the driver of course so everything would be transparent as far as > the capabilities > of the used display device itself allow for that. What about the case where you draw with GDI, then render with OpenGL on top of that, then draw on top of that with GDI, then swap buffers? If you draw only client-side, you have to copy to the server, then copy back, then copy to the server *again*. You have to upload or download the image *every time* you go between OpenGL and GDI drawing, whereas when you draw with X11, there is no uploads/downloads unless you use DIB sections and draw directly. X11 drawing has some more advantages, like being able to use forms of hardware acceleration (XAA/EXA) that client-side drawing can't. A pure client-side drawing strategy is IMO inferior to a strategy where you can draw client-side or server-side, as the need arises. > Rolf Kalbermatter Damjan Jovanovic From julliard at winehq.org Mon Feb 12 06:07:31 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 12 06:07:46 2007 Subject: ntdll: Fix compilation on systems that don't support nameless structs. In-Reply-To: (Francois Gouget's message of "Mon\, 12 Feb 2007 12\:38\:19 +0100 \(CET\)") References: Message-ID: <878xf3efzw.fsf@wine.dyndns.org> Francois Gouget writes: > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 34a05b7..4d5c41d 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -40,6 +40,12 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > > +#ifdef NONAMELESSSTRUCT > +# define S(x) (x).s > +#else > +# define S(x) (x) > +#endif > + You shouldn't need that sort of macro in the Wine code. Simply define NONAMELESSSTRUCT unconditionally. -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Mon Feb 12 06:49:51 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 12 06:49:57 2007 Subject: [3/9] WineD3D: Add a per context structure for context management In-Reply-To: <200702082248.04615.stefan@codeweavers.com> (Stefan =?utf-8?Q?D=C3=B6singer's?= message of "Thu\, 8 Feb 2007 22\:48\:04 +0100") References: <200702082248.04615.stefan@codeweavers.com> Message-ID: <87y7n3czgw.fsf@wine.dyndns.org> Stefan D?singer writes: > This patch adds a new context management structure which will keep a dirty > state list, state optimization members, a glx context and drawable, ... [2. application/x-zip; 0003-WineD3D-Add-a-per-context-structure-for-context-management.txt.zip]... Please don't send patches in zip format, that's a pain to extract. If you really have to compress please use gzip or bzip2. -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Mon Feb 12 07:23:32 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 12 07:23:44 2007 Subject: user32: WM_NCACTIVATE sent by set_active_window() should never deactivate In-Reply-To: <45CE2F09.8020309@holycrap.org> (Felix Nawothnig's message of "Sat\, 10 Feb 2007 21\:46\:01 +0100") References: <45CE2F09.8020309@holycrap.org> Message-ID: <87tzxrcxwr.fsf@wine.dyndns.org> Felix Nawothnig writes: > This fixes #7198. Problem is that GetForegroundWindow() sometimes > returns NULL (MSDN says: "in certain circumstances, such as when a > window is losing activation"). I didn't bother to check why this > happens for some apps (winemine works fine for me, winecfg doesn't - I > suspect timing issues) here as I saw no point in this check anyway: The point is that the window should not be painted active if it's not the foreground window too. There is one active window per queue, but only one foreground window. -- Alexandre Julliard julliard@winehq.org From mk144210 at bcm.tmc.edu Mon Feb 12 08:18:15 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 12 08:18:50 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <78a7dad00702112149h7d577845md067c2cec4f2b8f@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <200702112117.32083.chris.kcat@gmail.com> <78a7dad00702112149h7d577845md067c2cec4f2b8f@mail.gmail.com> Message-ID: <1171289895.31155.10.camel@misha-laptop> On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson wrote: > On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > > Yes, I will admit a program can just write this registry key and have itself run. My assumption is that most malware is currently written for Windows and not specifically for Wine, and thus such programs generally would not have any reason to write such a key. I think if malware really wanted to run _specifically_ on Wine it would be pretty easy to do with or without my patch, for example, overwrite a key system DLL and then just set the appropriate registry key so Wine uses the "native DLL" that the malware program has put. I think the "security" of my patch is based on the fact that most malware programs are written for Windows and I think if we start seeing Wine-specific malware we are going to have to develop a lot more security in a lot of places. Misha From stefan.munz at itomig.de Mon Feb 12 09:18:00 2007 From: stefan.munz at itomig.de (Stefan Munz) Date: Mon Feb 12 09:18:03 2007 Subject: Linuxtag 2007 Message-ID: <200702121618.00879.stefan.munz@itomig.de> Hi, mentioned a few days ago I try to register "Wine" for participating at the Linuxtag 2007. They want some information that I can only guess. Maybe someone can provide me a better estimation for: Developers in 1. Germany 2. Europe (incl. Germany) 3. Worldwide (incl. Europe) How many developers work for Codeweavers (as they are for sure the biggest contributor)? -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz@itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 T?bingen . . . . . . . . . . . . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/38022528/attachment.pgp From frick at sc-networks.de Mon Feb 12 09:32:30 2007 From: frick at sc-networks.de (Christoph Frick) Date: Mon Feb 12 09:32:28 2007 Subject: Linuxtag 2007 In-Reply-To: <200702121618.00879.stefan.munz@itomig.de> References: <200702121618.00879.stefan.munz@itomig.de> Message-ID: <20070212153230.GS1252@byleth.sc-networks.de> On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > Developers in > 1. Germany > 2. Europe (incl. Germany) > 3. Worldwide (incl. Europe) > How many developers work for Codeweavers (as they are for sure the > biggest contributor)? isn't finding this number hard for OSS? what makes contributor a devloper? for worldwide then the 873 lines from the AUTHORS file would be start. -- cu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/a34bf56b/attachment.pgp From mk144210 at bcm.tmc.edu Mon Feb 12 09:35:14 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 12 09:35:50 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <78a7dad00702112149h7d577845md067c2cec4f2b8f@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <200702112117.32083.chris.kcat@gmail.com> <78a7dad00702112149h7d577845md067c2cec4f2b8f@mail.gmail.com> Message-ID: <1171294514.9123.1.camel@misha-laptop> On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson wrote: > On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > I think the bigger security issue to be made is that until wine default behavior is not to set up the user's home directory in a writeable way as the Z: drive there is really no way to store any settings in any user-writable file without having malware being able to change if it wanted to and was written specifically for wine (please correct me if I am wrong). So I believe that, given this state, securing Wine from malware written for Windows (which most is) and not specifically for Wine is the best we can do. Misha > From meissner at suse.de Mon Feb 12 09:37:54 2007 From: meissner at suse.de (Marcus Meissner) Date: Mon Feb 12 09:38:00 2007 Subject: Linuxtag 2007 In-Reply-To: <200702121618.00879.stefan.munz@itomig.de> References: <200702121618.00879.stefan.munz@itomig.de> Message-ID: <20070212153754.GB13457@suse.de> On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > Hi, > > mentioned a few days ago I try to register "Wine" for participating at the > Linuxtag 2007. > They want some information that I can only guess. Maybe someone can provide me > a better estimation for: > > Developers in > 1. Germany I briefly reviewed the Changelog for the last 9 months and found around 10 active developers. > 2. Europe (incl. Germany) More difficult to find out, but lets just say 20 active developers. > 3. Worldwide (incl. Europe) I guess around 35-40 active developers. > How many developers work for Codeweavers (as they are for sure the biggest > contributor)? $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l 15 Ciao, Marcus From stefan.munz at itomig.de Mon Feb 12 09:40:34 2007 From: stefan.munz at itomig.de (Stefan Munz) Date: Mon Feb 12 09:41:05 2007 Subject: Linuxtag 2007 In-Reply-To: <20070212153754.GB13457@suse.de> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153754.GB13457@suse.de> Message-ID: <200702121640.34676.stefan.munz@itomig.de> Hi Markus, thanks for the detailed answer :-) cu, Stefan Am Montag, 12. Februar 2007 16:37 schrieben Sie: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > > Hi, > > > > mentioned a few days ago I try to register "Wine" for participating at > > the Linuxtag 2007. > > They want some information that I can only guess. Maybe someone can > > provide me a better estimation for: > > > > Developers in > > 1. Germany > > I briefly reviewed the Changelog for the last 9 months > and found around 10 active developers. > > > 2. Europe (incl. Germany) > > More difficult to find out, but lets just say 20 active developers. > > > 3. Worldwide (incl. Europe) > > I guess around 35-40 active developers. > > > How many developers work for Codeweavers (as they are for sure the > > biggest contributor)? > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 > > Ciao, Marcus -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz@itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 T?bingen . . . . . . . . . . . . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/9f88446a/attachment.pgp From stefan.munz at itomig.de Mon Feb 12 09:44:45 2007 From: stefan.munz at itomig.de (Stefan Munz) Date: Mon Feb 12 09:45:01 2007 Subject: Linuxtag 2007 In-Reply-To: <20070212153230.GS1252@byleth.sc-networks.de> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153230.GS1252@byleth.sc-networks.de> Message-ID: <200702121644.45876.stefan.munz@itomig.de> Am Montag, 12. Februar 2007 16:32 schrieb Christoph Frick: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > > Developers in > > 1. Germany > > 2. Europe (incl. Germany) > > 3. Worldwide (incl. Europe) > > How many developers work for Codeweavers (as they are for sure the > > biggest contributor)? > > isn't finding this number hard for OSS? what makes contributor a > devloper? this isn't specified, though I think a rough estimate is ok. > > for worldwide then the 873 lines from the AUTHORS file would be start. I think they mean active developers in, so the authors file seems a bit too much. Markus approach using the changelog file is ok, I think. thanks && cu, Stefan -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz@itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 T?bingen . . . . . . . . . . . . . . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/26224759/attachment.pgp From truiken at gmail.com Mon Feb 12 10:33:28 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 12 10:33:41 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> Message-ID: <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> On 2/11/07, richardvoigt@gmail.com wrote: > On 2/11/07, Misha Koshelev wrote: > > Hi everybody, > > > > Thanks for your suggestions. I just posted a new patch on wine-patches > > where I tried to incorporate these and now it does the following (in > > addition to my previous patch which just started items in the StartUp > > folder): > > > > - When wineboot finds a file that it wants to start in the StartUp > > folder, it asks the user whether he wants to run the program. His > > options are: Always, Yes, No (default), and Never. > > - If he selects Yes the program is run, if he select No it is not. > > - If he selects Always or Never, I create a registry key in: > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > of the program and the value "always" or "never." When wineboot sees > > this program in the StartUp folder it checks this key, and if it is > > set it performs the appropriate action. > > > > What do you guys think? If you like the system, it would be pretty easy > > to incorporate this into the run key running as well (which are > > currently just run without any user confirmation)? > > This sounds almost perfect. I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: > > Startup items behavior: > (*) Silently allow <-- This is "bug-for-bug compatibility" > ( ) Ask <-- Most computer-savvy folks would want this > ( ) Silently block > ( ) Block and notify me > This is unnecessarily complicated, and i really doubt anything like this would ever make it into the Wine tree. > Perhaps this should be independently set for each kind of startup item > (startmenu\programs\startup, registry run key, profile settings, etc), > but I think that's not really necessary. > > Also, I would suggest that the list of approved start items be stored > outside of winespace, so that malware can't bypass the protection by > setting the key. Of course, really nasty stuff could still call into > Linux, but that would require some hybrid system that was aware of the > ELF dynamic loader in order to not fall afoul of address space > randomization. > > Ultimately I think wine is about more than just running > Windows-compatible programs without the Microsoft tax. It's about > running those programs without ceding control of your computer to an > untrustworthy party. We don't want the limitations that Windows > imposes... true bug-for-bug compatibility would mean only being able > to access files on a FAT or NTFS partition, but I don't hear anyone > advocating for that kind of crippling behavior. > What? Wine has nothing to do with which file system your files reside on. Asking if you want to run every file set for startup in wineboot every single time is crippling behavior, not to mention annoying. UAC anyone? If you're so worried about this "malware", create a reduced privileges account just for Wine. > > > > Thanks > > Misha > > > > p.s. please please please anyone who is familiar with IShellFolder if > > you could look over those parts and just say yes it looks good that > > would make me feel better. I think it is correct but really an expert's > > opinion would be great. > > > > > > > > > -- James Hawkins From wine.dev at web.de Mon Feb 12 10:58:41 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Mon Feb 12 11:03:34 2007 Subject: Linuxtag 2007 In-Reply-To: <20070212153754.GB13457@suse.de> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153754.GB13457@suse.de> Message-ID: <1171299521.6923.18.camel@p4> On Mo, 2007-02-12 at 16:37 +0100, Marcus Meissner wrote: Whith your help, what can be done, I found 54 contributors for 2007 in the changelog . $ grep "^2007.*>" ChangeLog | sort -t "<" +1 -u | wc -l 56 (Stefan and Francois are twice in the list) > > How many developers work for Codeweavers (as they are for sure the biggest > > contributor)? > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 Alexandre is missing here, as he use @winehq.org -- By by ... Detlef From hverbeet at gmail.com Mon Feb 12 12:13:33 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 12 12:13:48 2007 Subject: DirectX related question In-Reply-To: <2c97fe9d0702111221x1a80ec47o7293815aa54002c@mail.gmail.com> References: <2c97fe9d0702110001h735e4b78ocefe4e532b123aa4@mail.gmail.com> <53e3a9930702110322h27e075dar4c13a79998e382eb@mail.gmail.com> <2c97fe9d0702111221x1a80ec47o7293815aa54002c@mail.gmail.com> Message-ID: On 11/02/07, Tim Schmidt wrote: > I'll purchase crossover, but it looks like SupComm wants pixel shader > 2.0, so I was thinking more along the lines of someone who wants to > hack on DirectX 10, but has no DirectX 10 capable hardware. Or no > DirectX 10 games to test against, etc. Anyone? > PS 2.0 is DX9. As mentioned in bug 6570, using GLSL for the shader backend should help a bit for shader support. The current plan is to make GLSL the default relatively soon. I see a demo was released not too long ago, so I might give a try one of these days. From stefan at codeweavers.com Mon Feb 12 12:18:56 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Mon Feb 12 12:23:17 2007 Subject: [7/10] WineD3D: Make the context array dynamic Message-ID: <200702121918.57000.stefan@codeweavers.com> -------------- next part -------------- From dd3ad62a7ed0206ddb7031551b3844d3595eced5 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger Date: Fri, 26 Jan 2007 18:06:51 +0100 Subject: [PATCH] WineD3D: Make the context array dynamic --- dlls/wined3d/context.c | 2 +- dlls/wined3d/device.c | 13 +++++++++---- dlls/wined3d/directx.c | 6 ++++++ dlls/wined3d/wined3d_private.h | 2 +- 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c index 1f6d693..6dc88fb 100644 --- a/dlls/wined3d/context.c +++ b/dlls/wined3d/context.c @@ -207,7 +207,7 @@ void ActivateContext(IWineD3DDeviceImpl *This, IWineD3DSurface *target, ContextU /* TODO: Thread selection */ /* TODO: Activate the opengl context */ - context = &This->contexts[This->activeContext]; + context = This->contexts[This->activeContext]; switch(usage) { case CTXUSAGE_RESOURCELOAD: diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index 1f27916..1771e63 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -350,10 +350,16 @@ static ULONG WINAPI IWineD3DDeviceImpl_Release(IWineD3DDevice *iface) { TRACE("(%p) : Releasing from %d\n", This, refCount + 1); if (!refCount) { + UINT i; if (This->fbo) { GL_EXTCALL(glDeleteFramebuffersEXT(1, &This->fbo)); } + for(i = 0; i < This->numContexts; i++) { + HeapFree(GetProcessHeap(), 0, This->contexts[i]); + } + HeapFree(GetProcessHeap(), 0, This->contexts); + HeapFree(GetProcessHeap(), 0, This->render_targets); HeapFree(GetProcessHeap(), 0, This->draw_buffers); @@ -2007,8 +2013,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Init3D(IWineD3DDevice *iface, WINED3DPR /* Initialize the current view state */ This->view_ident = 1; - This->numContexts = 1; - This->contexts[0].last_was_rhw = 0; + This->contexts[0]->last_was_rhw = 0; glGetIntegerv(GL_MAX_LIGHTS, &This->maxConcurrentLights); TRACE("(%p) All defaults now set up, leaving Init3D with %p\n", This, This); @@ -5948,7 +5953,7 @@ static void device_render_to_texture(IWineD3DDeviceImpl* This, BOOL isTexture) { if (This->depth_copy_state != WINED3D_DCS_NO_COPY) { This->depth_copy_state = WINED3D_DCS_COPY; } - This->contexts[0].last_was_rhw = FALSE; + This->contexts[0]->last_was_rhw = FALSE; /* Viewport state will reapply the projection matrix for now */ IWineD3DDeviceImpl_MarkStateDirty(This, WINED3DRS_CULLMODE); @@ -6985,7 +6990,7 @@ void IWineD3DDeviceImpl_MarkStateDirty(IWineD3DDeviceImpl *This, DWORD state) { if(!rep) return; for(i = 0; i < This->numContexts; i++) { - context = &This->contexts[i]; + context = This->contexts[i]; if(isStateDirty(context, rep)) continue; context->dirtyArray[context->numDirtyEntries++] = rep; diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 7bd04bb..e711b10 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -2444,6 +2444,12 @@ static HRESULT WINAPI IWineD3DImpl_CreateDevice(IWineD3D *iface, UINT Adapter, object->ddraw_format = pixelformat_for_depth(GetDeviceCaps(hDC, BITSPIXEL) * GetDeviceCaps(hDC, PLANES)); ReleaseDC(0, hDC); + /* Allocate one context for now */ + object->contexts = HeapAlloc(GetProcessHeap(), 0, sizeof(WineD3DContext *)); + object->contexts[0] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(WineD3DContext)); + object->numContexts = 1; + object->activeContext = 0; + return WINED3D_OK; create_device_error: diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 03d5759..7be34ac 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -695,7 +695,7 @@ struct IWineD3DDeviceImpl BOOL useDrawStridedSlow; /* Context management */ - WineD3DContext contexts[1]; /* Dynamic array later */ + WineD3DContext **contexts; /* Dynamic array containing pointers to context structures */ UINT activeContext; /* Only 0 for now */ UINT numContexts; /* Always 1 for now */ }; -- 1.4.4.3 From dtremenak at gmail.com Mon Feb 12 12:54:29 2007 From: dtremenak at gmail.com (Daniel Remenak) Date: Mon Feb 12 12:54:43 2007 Subject: DIB Engine, some summarization In-Reply-To: <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> References: <003901c74e29$d44955b0$4001a8c0@glis> <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> Message-ID: On 2/11/07, Damjan Jovanovic wrote: > What about the case where you draw with GDI, then render with OpenGL > on top of that, then draw on top of that with GDI, then swap buffers? > If you draw only client-side, you have to copy to the server, then > copy back, then copy to the server *again*. You have to upload or > download the image *every time* you go between OpenGL and GDI drawing, > whereas when you draw with X11, there is no uploads/downloads unless > you use DIB sections and draw directly. Not that it's relevant to this conversation (since wine needs to support legacy apps), but just so you know, even Microsoft no longer supports this sample scenario. Drawing with GDI over OpenGL (or DX), and reading from the GDI buffer on a hardware-accelerated window, are both undefined (officially "not supported") operations on Windows Vista. Caused a ton of problems for my company's product. I can't directly quote what our nVidia rep sent to us (for legal reasons), but this link might be helpful: http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx --Daniel Remenak From septikus at gmail.com Sun Feb 11 22:49:42 2007 From: septikus at gmail.com (Leslie Choong) Date: Mon Feb 12 12:59:56 2007 Subject: comtctl32 : updown : Getter and Setter Tests for Updown control In-Reply-To: References: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> Message-ID: Hey there, I've made the changes so that the return value is not stored unnecessarily. I've also added comments explaining why. Let me know what you think. -Leslie On 2/11/07, Leslie Choong wrote: > Thanks for the input. UDM_SETRANGE has no return value according to > MSDN so I'll remove those assignments. > > On 2/11/07, James Hawkins wrote: > > On 2/10/07, Leslie Choong wrote: > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > under graduate work at UCLA. This patch is being sent as part of the > > > coursework for CS 130 : Software Engineering. Please take a look and > > > let me know if you have any suggestions or comments for change. > > > Thanks! > > > -Leslie Choong > > > > > > > + /* Set Range from 0 to 100 */ > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > If you're not going to check the first return value, then take out the > > 'r =', else it seems like you're missing a test. On the other hand, > > why don't you test the return value? > > > > -- > > James Hawkins > > > -------------- next part -------------- From bd8ea4f6278e4b3164ad7bb310525026faa93325 Mon Sep 17 00:00:00 2001 From: U-SEPTIKUS\Leslie Date: Sun, 11 Feb 2007 20:45:29 -0800 Subject: [PATCH] Added getter setter tests --- dlls/comctl32/tests/updown.c | 175 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 175 insertions(+), 0 deletions(-) diff --git a/dlls/comctl32/tests/updown.c b/dlls/comctl32/tests/updown.c index e0b8131..76ff59a 100644 --- a/dlls/comctl32/tests/updown.c +++ b/dlls/comctl32/tests/updown.c @@ -2,6 +2,7 @@ * * Copyright 2005 C. Scott Ananian * Copyright (C) 2007 James Hawkins + * Copyright (C) 2007 Leslie Choong * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -500,6 +501,174 @@ static HWND create_updown_control() return updown; } +static void test_updown_pos(void) +{ + int r; + + /* Set Range from 0 to 100 */ + /* No need to check first return as UDM_SETRANGE does not use it */ + SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); + r= SendMessage(updown, UDM_GETRANGE, 0,0); + ok(LOWORD(r) == 100, "Expected 100, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 0, "Expected 0, got %d\n", HIWORD(r)); + + /* Set the position to 5, return is not checked as it was set before func call */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(5,0) ); + /* Since UDM_SETBUDDYINT was not set at creation HIWORD(r) will always be 1 as a return from UDM_GETPOS */ + /* Get the position, which should be 5 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + ok(LOWORD(r) == 5, "Expected 5, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 1, "Expected 1, got %d\n", HIWORD(r)); + + /* Set the position to 0, return should be 5 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(0,0) ); + ok(r == 5, "Expected 5, got %d\n", r); + /* Get the position, which should be 0 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + ok(LOWORD(r) == 0, "Expected 0, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 1, "Expected 1, got %d\n", HIWORD(r)); + + /* Set the position to -1, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(-1,0) ); + ok(r == 0, "Expected 0, got %d\n", r); + /* Get the position, which should be 0 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + ok(LOWORD(r) == 0, "Expected 0, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 1, "Expected 1, got %d\n", HIWORD(r)); + + /* Set the position to 100, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(100,0) ); + ok(r == 0, "Expected 0, got %d\n", r); + /* Get the position, which should be 100 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + ok(LOWORD(r) == 100, "Expected 100, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 1, "Expected 1, got %d\n", HIWORD(r)); + + /* Set the position to 101, return should be 100 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(101,0) ); + ok(r == 100, "Expected 100, got %d\n", r); + /* Get the position, which should be 100 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + ok(LOWORD(r) == 100, "Expected 100, got %d\n", LOWORD(r)); + ok(HIWORD(r) == 1, "Expected 1, got %d\n", HIWORD(r)); +} + +static void test_updown_pos32(void) +{ + int r; + int low, high; + + /* Set the position to 0 to 1000 */ + /* No need to check first return as UDM_SETRANGE32 does not use it */ + SendMessage(updown, UDM_SETRANGE32, 0 , 1000 ); + + r = SendMessage(updown, UDM_GETRANGE32, (WPARAM) &low , (LPARAM) &high ); + ok(low == 0, "Expected 0, got %d\n", low); + ok(high == 1000, "Expected 1000, got %d\n", high); + + /* Set position to 500, don't check return since it is unset*/ + r = SendMessage(updown, UDM_SETPOS32, 0 , 500 ); + + /* Since UDM_SETBUDDYINT was not set at creation bRet will always be true as a return from UDM_GETPOS32 */ + + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + ok(r == 500, "Expected 500, got %d\n", r); + ok(high == 1 , "Expected 0, got %d\n", high); + + /* Set position to 0, return should be 500 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 0 ); + ok(r == 500, "Expected 500, got %d\n", r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + ok(r == 0, "Expected 0, got %d\n", r); + ok(high == 1 , "Expected 0, got %d\n", high); + + /* Set position to -1 which sohuld become 0, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , -1 ); + ok(r == 0, "Expected 0, got %d\n", r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + ok(r == 0, "Expected 0, got %d\n", r); + ok(high == 1 , "Expected 0, got %d\n", high); + + /* Set position to 1000, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 1000 ); + ok(r == 0, "Expected 0, got %d\n", r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + ok(r == 1000, "Expected 1000, got %d\n", r); + ok(high == 1 , "Expected 0, got %d\n", high); + + /* Set position to 1001 which sohuld become 1000, return should be 1000 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 1001 ); + ok(r == 1000, "Expected 1000, got %d\n", r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + ok(r == 1000, "Expected 0, got %d\n", r); + ok(high == 1 , "Expected 0, got %d\n", high); +} + +static void test_updown_buddy(void) +{ + HWND buddyReturn; + + buddyReturn = (HWND)SendMessage(updown, UDM_GETBUDDY, 0 , 0 ); + ok(buddyReturn == edit, "Expected edit handle\n"); +} + +static void test_updown_base(void) +{ + int r; + + /* return not checked since previous value is not known at start */ + SendMessage(updown, UDM_SETBASE, 10 , 0); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + ok(r == 10, "Expected 10, got %d\n", r); + + /* Set base to an invalid value, should return 0 and stay at 10 */ + r = SendMessage(updown, UDM_SETBASE, 80 , 0); + ok(r == 0, "Expected 0, got %d\n", r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + ok(r == 10, "Expected 10, got %d\n", r); + + /* Set base to 16 now, should get 16 as the return */ + r = SendMessage(updown, UDM_SETBASE, 16 , 0); + ok(r == 10, "Expected 10, got %d\n", r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + ok(r == 16, "Expected 16, got %d\n", r); + + /* Set base to an invalid value, should return 0 and stay at 16 */ + r = SendMessage(updown, UDM_SETBASE, 80 , 0); + ok(r == 0, "Expected 0, got %d\n", r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + ok(r == 16, "Expected 16, got %d\n", r); + + /* Set base back to 10, return should be 16 */ + r = SendMessage(updown, UDM_SETBASE, 10 , 0); + ok(r == 16, "Expected 16, got %d\n", r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + ok(r == 10, "Expected 10, got %d\n", r); +} + +static void test_updown_unicode(void) +{ + int r; + + /* Set it to ANSI, don't check return as we don't know previous state */ + SendMessage(updown, UDM_SETUNICODEFORMAT, 0 , 0); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + ok(r == 0, "Expected 0, got %d\n", r); + + /* Now set it to Unicode format */ + r = SendMessage(updown, UDM_SETUNICODEFORMAT, 1 , 0); + ok(r == 0, "Expected 0, got %d\n", r); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + ok(r == 1, "Expected 1, got %d\n", r); + + /* And now set it back to ANSI */ + r = SendMessage(updown, UDM_SETUNICODEFORMAT, 0 , 0); + ok(r == 1, "Expected 1, got %d\n", r); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + ok(r == 0, "Expected 0, got %d\n", r); +} + + static void test_create_updown_control(void) { CHAR text[MAX_PATH]; @@ -528,6 +697,12 @@ static void test_create_updown_control(void) ok_sequence(EDIT_SEQ_INDEX, get_edit_text_seq, "get edit text", FALSE); flush_sequences(); + + test_updown_pos(); + test_updown_pos32(); + test_updown_buddy(); + test_updown_base(); + test_updown_unicode(); } START_TEST(updown) -- 1.4.4.4 From septikus at gmail.com Mon Feb 12 02:43:26 2007 From: septikus at gmail.com (Leslie Choong) Date: Mon Feb 12 12:59:57 2007 Subject: comtctl32 : updown : Getter and Setter Tests for Updown control In-Reply-To: References: <22821af30702110953v698f3dc1r4ac15294621508a2@mail.gmail.com> Message-ID: Thanks for the input, I've added the expect() macro, corrected some spelling mistakes. Let me know what else I can do. -Leslie On 2/11/07, Dan Kegel wrote: > I haven't looked at what James was talking about, but I noticed three things: > > You have a typo 'sohuld'. > > You should use the same filename as before, but increment the number > in the filename. > > You might consider using the expect() macro I've been encouraging > the other cs130 students to use, it makes the repeated ok() calls a bit > more readable (IMHO, we'll see if others agree). > - Dan > > On 2/11/07, Leslie Choong wrote: > > Hey there, I've made the changes so that the return value is not > > stored unnecessarily. I've also added comments explaining why. Let me > > know what you think. > > -Leslie > > > > On 2/11/07, Leslie Choong wrote: > > > Thanks for the input. UDM_SETRANGE has no return value according to > > > MSDN so I'll remove those assignments. > > > > > > On 2/11/07, James Hawkins wrote: > > > > On 2/10/07, Leslie Choong wrote: > > > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > > > under graduate work at UCLA. This patch is being sent as part of the > > > > > coursework for CS 130 : Software Engineering. Please take a look and > > > > > let me know if you have any suggestions or comments for change. > > > > > Thanks! > > > > > -Leslie Choong > > > > > > > > > > > > > + /* Set Range from 0 to 100 */ > > > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > > > > > If you're not going to check the first return value, then take out the > > > > 'r =', else it seems like you're missing a test. On the other hand, > > > > why don't you test the return value? > > > > > > > > -- > > > > James Hawkins > > > > > > > > > > > > > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > -------------- next part -------------- From 538f7ffdac284ff15daafa72c4209a24221768e8 Mon Sep 17 00:00:00 2001 From: U-SEPTIKUS\Leslie Date: Sun, 11 Feb 2007 20:42:03 -0800 Subject: [PATCH] Added Getter/Setter Tests for Updown Common Control --- dlls/comctl32/tests/updown.c | 177 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 177 insertions(+), 0 deletions(-) diff --git a/dlls/comctl32/tests/updown.c b/dlls/comctl32/tests/updown.c diff --git a/dlls/comctl32/tests/updown.c b/dlls/comctl32/tests/updown.c index e0b8131..f93e840 100644 --- a/dlls/comctl32/tests/updown.c +++ b/dlls/comctl32/tests/updown.c @@ -2,6 +2,7 @@ * * Copyright 2005 C. Scott Ananian * Copyright (C) 2007 James Hawkins + * Copyright (C) 2007 Leslie Choong * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -51,6 +52,8 @@ #include "wine/test.h" +#define expect(expected,got) ok(got == expected, "Expected %d, got %d\n", expected, got) + #define NUM_MSG_SEQUENCES 3 #define PARENT_SEQ_INDEX 0 #define EDIT_SEQ_INDEX 1 @@ -500,6 +503,174 @@ static HWND create_updown_control() return updown; } +static void test_updown_pos(void) +{ + int r; + + /* Set Range from 0 to 100 */ + /* No need to check first return as UDM_SETRANGE does not use it */ + SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); + r= SendMessage(updown, UDM_GETRANGE, 0,0); + expect(100,LOWORD(r)); + expect(0,HIWORD(r)); + + /* Set the position to 5, return is not checked as it was set before func call */ + SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(5,0) ); + /* Since UDM_SETBUDDYINT was not set at creation HIWORD(r) will always be 1 as a return from UDM_GETPOS */ + /* Get the position, which should be 5 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + expect(5,LOWORD(r)); + expect(1,HIWORD(r)); + + /* Set the position to 0, return should be 5 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(0,0) ); + expect(5,r); + /* Get the position, which should be 0 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + expect(0,LOWORD(r)); + expect(1,HIWORD(r)); + + /* Set the position to -1, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(-1,0) ); + expect(0,r); + /* Get the position, which should be 0 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + expect(0,LOWORD(r)); + expect(1,HIWORD(r)); + + /* Set the position to 100, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(100,0) ); + expect(0,r); + /* Get the position, which should be 100 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + expect(100,LOWORD(r)); + expect(1,HIWORD(r)); + + /* Set the position to 101, return should be 100 */ + r = SendMessage(updown, UDM_SETPOS, 0 , MAKELONG(101,0) ); + expect(100,r); + /* Get the position, which should be 100 */ + r = SendMessage(updown, UDM_GETPOS, 0 , 0 ); + expect(100,LOWORD(r)); + expect(1,HIWORD(r)); +} + +static void test_updown_pos32(void) +{ + int r; + int low, high; + + /* Set the position to 0 to 1000 */ + /* No need to check first return as UDM_SETRANGE32 does not use it */ + SendMessage(updown, UDM_SETRANGE32, 0 , 1000 ); + + r = SendMessage(updown, UDM_GETRANGE32, (WPARAM) &low , (LPARAM) &high ); + expect(0,low); + expect(1000,high); + + /* Set position to 500, don't check return since it is unset*/ + SendMessage(updown, UDM_SETPOS32, 0 , 500 ); + + /* Since UDM_SETBUDDYINT was not set at creation bRet will always be true as a return from UDM_GETPOS32 */ + + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + expect(500,r); + ok(high == 1 , "Expected 0, got %d\n", high); + + /* Set position to 0, return should be 500 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 0 ); + expect(500,r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + expect(0,r); + expect(1,high); + + /* Set position to -1 which should become 0, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , -1 ); + expect(0,r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + expect(0,r); + expect(1,high); + + /* Set position to 1000, return should be 0 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 1000 ); + expect(0,r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + expect(1000,r); + expect(1,high); + + /* Set position to 1001 which should become 1000, return should be 1000 */ + r = SendMessage(updown, UDM_SETPOS32, 0 , 1001 ); + expect(1000,r); + r = SendMessage(updown, UDM_GETPOS32, 0 , (LPARAM) &high ); + expect(1000,r); + expect(1,high); +} + +static void test_updown_buddy(void) +{ + HWND buddyReturn; + + buddyReturn = (HWND)SendMessage(updown, UDM_GETBUDDY, 0 , 0 ); + expect((int)edit,(int)buddyReturn); +} + +static void test_updown_base(void) +{ + int r; + + /* return not checked since previous value is not known at start */ + SendMessage(updown, UDM_SETBASE, 10 , 0); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + expect(10,r); + + /* Set base to an invalid value, should return 0 and stay at 10 */ + r = SendMessage(updown, UDM_SETBASE, 80 , 0); + expect(0,r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + expect(10,r); + + /* Set base to 16 now, should get 16 as the return */ + r = SendMessage(updown, UDM_SETBASE, 16 , 0); + expect(10,r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + expect(16,r); + + /* Set base to an invalid value, should return 0 and stay at 16 */ + r = SendMessage(updown, UDM_SETBASE, 80 , 0); + expect(0,r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + expect(16,r); + + /* Set base back to 10, return should be 16 */ + r = SendMessage(updown, UDM_SETBASE, 10 , 0); + expect(16,r); + r = SendMessage(updown, UDM_GETBASE, 0 , 0); + expect(10,r); +} + +static void test_updown_unicode(void) +{ + int r; + + /* Set it to ANSI, don't check return as we don't know previous state */ + SendMessage(updown, UDM_SETUNICODEFORMAT, 0 , 0); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + expect(0,r); + + /* Now set it to Unicode format */ + r = SendMessage(updown, UDM_SETUNICODEFORMAT, 1 , 0); + expect(0,r); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + expect(1,r); + + /* And now set it back to ANSI */ + r = SendMessage(updown, UDM_SETUNICODEFORMAT, 0 , 0); + expect(1,r); + r = SendMessage(updown, UDM_GETUNICODEFORMAT, 0 , 0); + expect(0,r); +} + + static void test_create_updown_control(void) { CHAR text[MAX_PATH]; @@ -528,6 +699,12 @@ static void test_create_updown_control(void) ok_sequence(EDIT_SEQ_INDEX, get_edit_text_seq, "get edit text", FALSE); flush_sequences(); + + test_updown_pos(); + test_updown_pos32(); + test_updown_buddy(); + test_updown_base(); + test_updown_unicode(); } START_TEST(updown) -- 1.4.4.4 From paul.vriens.wine at gmail.com Mon Feb 12 13:20:37 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Mon Feb 12 13:21:07 2007 Subject: extract DLL calls from exe file (i.e. from portable executable) In-Reply-To: <45D0AA3A.3020203@ilidium.com> References: <45D0AA3A.3020203@ilidium.com> Message-ID: <45D0BE05.4040603@gmail.com> Luis C. Busquets P?rez wrote: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. > > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. > > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. > > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. > > Please let me know if you put it in the winehq. I look forward to have > the opportunity to contribute to the wine project. > > Luis C. Busquets P?rez > T. +32 473 353 128 > > > > ------------------------------------------------------------------------ > > Hi, excuse me if got it wrong, but what's the difference with winedump? Cheers, Paul. From stefandoesinger at gmx.at Mon Feb 12 14:02:34 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Mon Feb 12 14:03:29 2007 Subject: extract DLL calls from exe file (i.e. from portable executable) In-Reply-To: <45D0AA3A.3020203@ilidium.com> References: <45D0AA3A.3020203@ilidium.com> Message-ID: <200702122102.40353.stefandoesinger@gmx.at> Am Montag 12 Februar 2007 18:56 schrieb Luis C. Busquets P?rez: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. I think wine-devel is the better list for that. For inclusion in wine please send diffs against the wine code rather than some zipped sources. And I am not sure if pascal is allowed in wine. C or bash scripts are better. > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. I think winedump does that, but I could be mistaken > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. Well, not really. That a function is implemented in wine does not necessarily mean that it is free of bugs. In most cases applications do not run because of bugs in the implementation rather than missing functions. > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. There are some other issues too: I don't speak pascall, but can your program deal with lazy linking, i.e. functions loaded after startup with LoadDLL? And I think you will not be able to read COM interfaces. For example for Direct3D9 you will see only one call, CreateDirect3D9, although d3d9 has numerous interfaces with a few hundred methods. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/5d3d9f9f/attachment.pgp From stefandoesinger at gmx.at Mon Feb 12 14:10:45 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Mon Feb 12 14:11:29 2007 Subject: DIB Engine, some summarization In-Reply-To: References: <003901c74e29$d44955b0$4001a8c0@glis> <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> Message-ID: <200702122110.50394.stefandoesinger@gmx.at> Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > On 2/11/07, Damjan Jovanovic wrote: > > What about the case where you draw with GDI, then render with OpenGL > > on top of that, then draw on top of that with GDI, then swap buffers? > > If you draw only client-side, you have to copy to the server, then > > copy back, then copy to the server *again*. You have to upload or > > download the image *every time* you go between OpenGL and GDI drawing, > > whereas when you draw with X11, there is no uploads/downloads unless > > you use DIB sections and draw directly. > > Not that it's relevant to this conversation (since wine needs to > support legacy apps), but just so you know, even Microsoft no longer > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > and reading from the GDI buffer on a hardware-accelerated window, are > both undefined (officially "not supported") operations on Windows > Vista. Caused a ton of problems for my company's product. So IDirect3DSurface9::GetDC does not work any longer? (Or IDirectDrawSurface7::GetDC) /me parties! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/42a7cb60/attachment.pgp From kumbayo84 at arcor.de Mon Feb 12 14:22:37 2007 From: kumbayo84 at arcor.de (Peter Oberndorfer) Date: Mon Feb 12 14:22:48 2007 Subject: ntdll: test that shows RtlRaiseException with EXCEPTION_BREAKPOINT mangles Eip of context Message-ID: <200702122122.38467.kumbayo84@arcor.de> This test is supposed to show that the Eip field in the context is fixed up somewhere inside RtlRaiseException or NtRaiseException (test for NtRaiseException not included) for (only) EXCEPTION_BREAKPOINT exception For others context.Eip is not changed. Since real exceptions on wine also take that path i guess it is best to implement context modifing in there. The next patches will show what is the value of context.Eip in a Vectored exception handler (I still have some problems with this patch) After that i plan to wrap a debugger around the test to show that the debugger gets a unmodified context The ultimate goal is to fix the "Handling of EXCEPTION_BREAKPOINT" problem Vitaliy Margolen reported ( http://bugs.winehq.org/show_bug.cgi?id=7063 ) Patch tested on XP/2k Comments, suggestions? Greetings Peter --- dlls/ntdll/tests/exception.c | 85 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 85 insertions(+), 0 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 3e7771e012532dd76f4bb316e43b04df36bed338.diff Type: text/x-patch Size: 4676 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/f56d0a02/3e7771e012532dd76f4bb316e43b04df36bed338.bin From dtremenak at gmail.com Mon Feb 12 14:28:18 2007 From: dtremenak at gmail.com (Daniel Remenak) Date: Mon Feb 12 14:28:27 2007 Subject: DIB Engine, some summarization In-Reply-To: <200702122110.50394.stefandoesinger@gmx.at> References: <003901c74e29$d44955b0$4001a8c0@glis> <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> <200702122110.50394.stefandoesinger@gmx.at> Message-ID: On 2/12/07, Stefan D?singer wrote: > Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > > On 2/11/07, Damjan Jovanovic wrote: > > > What about the case where you draw with GDI, then render with OpenGL > > > on top of that, then draw on top of that with GDI, then swap buffers? > > > If you draw only client-side, you have to copy to the server, then > > > copy back, then copy to the server *again*. You have to upload or > > > download the image *every time* you go between OpenGL and GDI drawing, > > > whereas when you draw with X11, there is no uploads/downloads unless > > > you use DIB sections and draw directly. > > > > Not that it's relevant to this conversation (since wine needs to > > support legacy apps), but just so you know, even Microsoft no longer > > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > > and reading from the GDI buffer on a hardware-accelerated window, are > > both undefined (officially "not supported") operations on Windows > > Vista. Caused a ton of problems for my company's product > > So IDirect3DSurface9::GetDC does not work any longer? (Or > IDirectDrawSurface7::GetDC) > > /me parties! > > Unfortunately, no; it looks like you can still render GDI onto a DX surface, just not directly onto a window which is also being rendered to by DX. >From the linked blog article: "Note that there is an alternative that can often work for an application -- DirectX is capable of handing back a DC to a DirectX surface, and applications can perform GDI rendering to that DC. From the DWM's perspective, that DirectX surface remains purely rendered by DirectX, and all is well." --Daniel Remenak From lists at michael-amorose.com Mon Feb 12 14:34:54 2007 From: lists at michael-amorose.com (Mike) Date: Mon Feb 12 14:35:41 2007 Subject: Unsubscribe? In-Reply-To: <20070212153754.GB13457@suse.de> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153754.GB13457@suse.de> Message-ID: <45D0CF6E.9030709@michael-amorose.com> How does one unsubscribe from this list? -m ============ Marcus Meissner wrote: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > >> Hi, >> >> mentioned a few days ago I try to register "Wine" for participating at the >> Linuxtag 2007. >> They want some information that I can only guess. Maybe someone can provide me >> a better estimation for: >> >> Developers in >> 1. Germany >> > > I briefly reviewed the Changelog for the last 9 months > and found around 10 active developers. > > >> 2. Europe (incl. Germany) >> > > More difficult to find out, but lets just say 20 active developers. > > >> 3. Worldwide (incl. Europe) >> > > I guess around 35-40 active developers. > > >> How many developers work for Codeweavers (as they are for sure the biggest >> contributor)? >> > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 > > Ciao, Marcus > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070212/e92f54c4/attachment.htm From kevin.krammer at gmx.at Mon Feb 12 14:46:03 2007 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Mon Feb 12 14:46:55 2007 Subject: Unsubscribe? In-Reply-To: <45D0CF6E.9030709@michael-amorose.com> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153754.GB13457@suse.de> <45D0CF6E.9030709@michael-amorose.com> Message-ID: <200702122146.11311.kevin.krammer@gmx.at> On Monday 12 February 2007 21:34, Mike wrote: > How does one unsubscribe from this list? http://www.winehq.org/mailman/options/wine-devel Cheers, Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070212/7dfe9ead/attachment-0001.pgp From thestig at google.com Mon Feb 12 16:03:25 2007 From: thestig at google.com (Lei Zhang) Date: Mon Feb 12 16:04:07 2007 Subject: compiling out debugging messages? Message-ID: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> Hi, Is it still possible to compile out debugging messages? According to http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass --disable-debug, but the Changelog says that option was removed about 10 month ago. - Lei From thestig at google.com Mon Feb 12 16:19:55 2007 From: thestig at google.com (Lei Zhang) Date: Mon Feb 12 16:20:16 2007 Subject: compiling out debugging messages? In-Reply-To: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> References: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> Message-ID: <558b2f5c0702121419y33321a82xbd9091a17eb4559e@mail.gmail.com> Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / -DWINE_NO_TRACE_MSGS from configure, but not from include/wine/debug.h. On 2/12/07, Lei Zhang wrote: > Hi, > > Is it still possible to compile out debugging messages? According to > http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass > --disable-debug, but the Changelog says that option was removed about > 10 month ago. > > - Lei > From mstefani at redhat.com Mon Feb 12 16:47:13 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Mon Feb 12 16:47:42 2007 Subject: compiling out debugging messages? In-Reply-To: <558b2f5c0702121419y33321a82xbd9091a17eb4559e@mail.gmail.com> References: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> <558b2f5c0702121419y33321a82xbd9091a17eb4559e@mail.gmail.com> Message-ID: <45D0EE71.7040308@redhat.com> Lei Zhang wrote: > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / > -DWINE_NO_TRACE_MSGS from configure, but not from > include/wine/debug.h. Right, it was a problem with a lot of people turning debug messages off and sending in useless problem reports. So that option got removed from configure. There is one valid reason to turn debugging off and that is to cross check that there are no side effects hidden in some debug message. > On 2/12/07, Lei Zhang wrote: >> Hi, >> >> Is it still possible to compile out debugging messages? According to >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass >> --disable-debug, but the Changelog says that option was removed about >> 10 month ago. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From nlaw at nildram.co.uk Mon Feb 12 19:32:31 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Mon Feb 12 19:33:11 2007 Subject: AppDB performance issue In-Reply-To: <45CFE0B8.6000501@gmail.com> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> Message-ID: <45D1152F.601@nildram.co.uk> Tony Lambregts wrote: > Chris Morgan wrote: > >> On 2/11/07, Tony Lambregts wrote: >> >>> Nick Law wrote: >>> >>>> Hi Tony, >>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it can >>>> take15 seconds or more for a page to come up or simply to login. Is >>>> there a bandwidth problem or is the server getting overwhelmed or is >>>> it a problem at my end (UK). 30 seconds later it's back to being very >>>> responsive as if the server was a bit overloaded for 30 seconds or so. >>>> Other websites I try at the time work fine including winehq. Is winehq >>>> on a different server ? >>>> >>>> >>> I have noticed this too and it is very annoying. Yes www.winehq.org >>> qpdb.winehq.or and bugs.winehq.org are all on the same server. >>> >>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >>> >>> I have know idea what is wrong >>> >>> -- >>> >>> Tony Lambregst >>> >>> >>> >>> >> Are particular pages slow? I'm not seeing slow page loads to the main >> page or to an application version page from here, a few seconds for >> each. >> >> Chris >> >> >> > > I see it when doing administration ie accepting or rejectiong applications and > versions (maybe its the way we send emails). > > > -- > > Tony Lambregts > . Yes, ditto. Logging in to do admin tasks, but not only that, if I click on the link in an email from somebody that has posted to the WoW 2.0.x page it will take 30 seconds for the page to appear. I just posted some replies to the wow page and then clicked on the link in the email and it took 84 seconds for the page to appear. It find it seems to be more frequent now, maybe every other page or 1 in three pages are very slow. Nick From nlaw at nildram.co.uk Mon Feb 12 19:40:54 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Mon Feb 12 19:41:25 2007 Subject: AppDB performance issue In-Reply-To: <45D1152F.601@nildram.co.uk> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> Message-ID: <45D11726.4020608@nildram.co.uk> Nick Law wrote: > Tony Lambregts wrote: >> Chris Morgan wrote: >> >>> On 2/11/07, Tony Lambregts wrote: >>> >>>> Nick Law wrote: >>>> >>>>> Hi Tony, >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it >>>>> can >>>>> take15 seconds or more for a page to come up or simply to login. Is >>>>> there a bandwidth problem or is the server getting overwhelmed or is >>>>> it a problem at my end (UK). 30 seconds later it's back to being very >>>>> responsive as if the server was a bit overloaded for 30 seconds or >>>>> so. >>>>> Other websites I try at the time work fine including winehq. Is >>>>> winehq >>>>> on a different server ? >>>>> >>>>> >>>> I have noticed this too and it is very annoying. Yes www.winehq.org >>>> qpdb.winehq.or and bugs.winehq.org are all on the same server. >>>> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >>>> >>>> I have know idea what is wrong >>>> >>>> -- >>>> >>>> Tony Lambregst >>>> >>>> >>>> >>>> >>> Are particular pages slow? I'm not seeing slow page loads to the main >>> page or to an application version page from here, a few seconds for >>> each. >>> >>> Chris >>> >>> >>> >> >> I see it when doing administration ie accepting or rejectiong >> applications and >> versions (maybe its the way we send emails). >> >> >> -- >> >> Tony Lambregts >> . > > Yes, ditto. Logging in to do admin tasks, but not only that, if I > click on the link in an email from somebody that has posted to the > WoW 2.0.x page it will take 30 seconds for the page to appear. > > I just posted some replies to the wow page and then clicked on the > link in the email and it took 84 seconds for the page to appear. It > find it seems to be more frequent now, maybe every other page or 1 in > three pages are very slow. > > Nick > > Correction it seems to be bad at the moment, the last 4 pages are slow, 60-90 secs before they display, and now it's back to < 2seconds to display a page again, it's like some process on the server hogs the CPU for 60 secs intermittently. Nick From nathan.andrew.williams at gmail.com Mon Feb 12 19:43:26 2007 From: nathan.andrew.williams at gmail.com (Nathan Williams) Date: Mon Feb 12 19:43:43 2007 Subject: Starting work on wine (Direct X Help) Message-ID: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> I want to get my hands dirty in the wine source code but I need a little guidance, hopefully from someone working on the DirectX sections of wine. I've decided I want to get Carmageddon working properly. I have already added it to the appdb (http://appdb.winehq.org/appview.php?iVersionId=6993) for the windows version. My main question is, how can I go about linking the visual bugs that I see with the area of code that needs work? I have worked with DirectX before and I am capable of coding tests and hooking directx on windows if needed. -- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070213/463acc6e/attachment.html From richardvoigt at gmail.com Mon Feb 12 20:02:05 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Mon Feb 12 20:02:12 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> Message-ID: <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> On 2/12/07, James Hawkins wrote: > On 2/11/07, richardvoigt@gmail.com wrote: > > On 2/11/07, Misha Koshelev wrote: > > > Hi everybody, > > > > > > Thanks for your suggestions. I just posted a new patch on wine-patches > > > where I tried to incorporate these and now it does the following (in > > > addition to my previous patch which just started items in the StartUp > > > folder): > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > folder, it asks the user whether he wants to run the program. His > > > options are: Always, Yes, No (default), and Never. > > > - If he selects Yes the program is run, if he select No it is not. > > > - If he selects Always or Never, I create a registry key in: > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > > of the program and the value "always" or "never." When wineboot sees > > > this program in the StartUp folder it checks this key, and if it is > > > set it performs the appropriate action. > > > > > > What do you guys think? If you like the system, it would be pretty easy > > > to incorporate this into the run key running as well (which are > > > currently just run without any user confirmation)? > > > > This sounds almost perfect. I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > > > Startup items behavior: > > (*) Silently allow <-- This is "bug-for-bug compatibility" > > ( ) Ask <-- Most computer-savvy folks would want this > > ( ) Silently block > > ( ) Block and notify me > > > > This is unnecessarily complicated, and i really doubt anything like > this would ever make it into the Wine tree. > > > Perhaps this should be independently set for each kind of startup item > > (startmenu\programs\startup, registry run key, profile settings, etc), > > but I think that's not really necessary. > > > > Also, I would suggest that the list of approved start items be stored > > outside of winespace, so that malware can't bypass the protection by > > setting the key. Of course, really nasty stuff could still call into > > Linux, but that would require some hybrid system that was aware of the > > ELF dynamic loader in order to not fall afoul of address space > > randomization. > > > > Ultimately I think wine is about more than just running > > Windows-compatible programs without the Microsoft tax. It's about > > running those programs without ceding control of your computer to an > > untrustworthy party. We don't want the limitations that Windows > > imposes... true bug-for-bug compatibility would mean only being able > > to access files on a FAT or NTFS partition, but I don't hear anyone > > advocating for that kind of crippling behavior. > > > > What? Wine has nothing to do with which file system your files reside > on. You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com? That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not! There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware. > Asking if you want to run every file set for startup in wineboot > every single time is crippling behavior, not to mention annoying. UAC > anyone? If you're so worried about this "malware", create a reduced > privileges account just for Wine. That's the point of a "remember my choice" or "Yes/No/Always/Never" option on the prompt which appears when the winecfg option is ask... Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like). > > > > > > > Thanks > > > Misha > > > > > > p.s. please please please anyone who is familiar with IShellFolder if > > > you could look over those parts and just say yes it looks good that > > > would make me feel better. I think it is correct but really an expert's > > > opinion would be great. > > > > > > > > > > > > > > > > > > -- > James Hawkins > From kingofallhearts999 at gmail.com Mon Feb 12 20:12:14 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Mon Feb 12 20:12:23 2007 Subject: AppDB performance issue In-Reply-To: <45D11726.4020608@nildram.co.uk> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> Message-ID: Weird I'm on dial-up even and goto the same pages, and all around the wine sites, all the time, and they load surprisingly fast. On 2/12/07, Nick Law wrote: > > Nick Law wrote: > > Tony Lambregts wrote: > >> Chris Morgan wrote: > >> > >>> On 2/11/07, Tony Lambregts wrote: > >>> > >>>> Nick Law wrote: > >>>> > >>>>> Hi Tony, > >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it > >>>>> can > >>>>> take15 seconds or more for a page to come up or simply to login. Is > >>>>> there a bandwidth problem or is the server getting overwhelmed or is > >>>>> it a problem at my end (UK). 30 seconds later it's back to being > very > >>>>> responsive as if the server was a bit overloaded for 30 seconds or > >>>>> so. > >>>>> Other websites I try at the time work fine including winehq. Is > >>>>> winehq > >>>>> on a different server ? > >>>>> > >>>>> > >>>> I have noticed this too and it is very annoying. Yes www.winehq.org > >>>> qpdb.winehq.or and bugs.winehq.org are all on the same server. > >>>> > >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. > >>>> > >>>> I have know idea what is wrong > >>>> > >>>> -- > >>>> > >>>> Tony Lambregst > >>>> > >>>> > >>>> > >>>> > >>> Are particular pages slow? I'm not seeing slow page loads to the main > >>> page or to an application version page from here, a few seconds for > >>> each. > >>> > >>> Chris > >>> > >>> > >>> > >> > >> I see it when doing administration ie accepting or rejectiong > >> applications and > >> versions (maybe its the way we send emails). > >> > >> > >> -- > >> > >> Tony Lambregts > >> . > > > > Yes, ditto. Logging in to do admin tasks, but not only that, if I > > click on the link in an email from somebody that has posted to the > > WoW 2.0.x page it will take 30 seconds for the page to appear. > > > > I just posted some replies to the wow page and then clicked on the > > link in the email and it took 84 seconds for the page to appear. It > > find it seems to be more frequent now, maybe every other page or 1 in > > three pages are very slow. > > > > Nick > > > > > Correction it seems to be bad at the moment, the last 4 pages are slow, > 60-90 secs before they display, and now it's back to < 2seconds to > display a page again, it's like some process on the server hogs the CPU > for 60 secs intermittently. > > Nick > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070212/0ee96b8a/attachment.htm From xixsimplicityxix at gmail.com Mon Feb 12 20:13:58 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Mon Feb 12 20:14:06 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> Message-ID: <78a7dad00702121813r539416acydaa7254099392432@mail.gmail.com> Part of my confusion what usage pattern is contracting malware on wine in the first place On 2/12/07, richardvoigt@gmail.com wrote: > > On 2/12/07, James Hawkins wrote: > > On 2/11/07, richardvoigt@gmail.com wrote: > > > On 2/11/07, Misha Koshelev wrote: > > > > Hi everybody, > > > > > > > > Thanks for your suggestions. I just posted a new patch on > wine-patches > > > > where I tried to incorporate these and now it does the following (in > > > > addition to my previous patch which just started items in the > StartUp > > > > folder): > > > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > > folder, it asks the user whether he wants to run the program. His > > > > options are: Always, Yes, No (default), and Never. > > > > - If he selects Yes the program is run, if he select No it is not. > > > > - If he selects Always or Never, I create a registry key in: > > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > > > of the program and the value "always" or "never." When wineboot sees > > > > this program in the StartUp folder it checks this key, and if it is > > > > set it performs the appropriate action. > > > > > > > > What do you guys think? If you like the system, it would be pretty > easy > > > > to incorporate this into the run key running as well (which are > > > > currently just run without any user confirmation)? > > > > > > This sounds almost perfect. I think the counterpoint raised by James > > > Hawkins would be adequately addressed by adding a winecfg option as > > > follows: > > > > > > Startup items behavior: > > > (*) Silently allow <-- This is "bug-for-bug compatibility" > > > ( ) Ask <-- Most computer-savvy folks would > want this > > > ( ) Silently block > > > ( ) Block and notify me > > > > > > > This is unnecessarily complicated, and i really doubt anything like > > this would ever make it into the Wine tree. > > > > > Perhaps this should be independently set for each kind of startup item > > > (startmenu\programs\startup, registry run key, profile settings, etc), > > > but I think that's not really necessary. > > > > > > Also, I would suggest that the list of approved start items be stored > > > outside of winespace, so that malware can't bypass the protection by > > > setting the key. Of course, really nasty stuff could still call into > > > Linux, but that would require some hybrid system that was aware of the > > > ELF dynamic loader in order to not fall afoul of address space > > > randomization. > > > > > > Ultimately I think wine is about more than just running > > > Windows-compatible programs without the Microsoft tax. It's about > > > running those programs without ceding control of your computer to an > > > untrustworthy party. We don't want the limitations that Windows > > > imposes... true bug-for-bug compatibility would mean only being able > > > to access files on a FAT or NTFS partition, but I don't hear anyone > > > advocating for that kind of crippling behavior. > > > > > > > What? Wine has nothing to do with which file system your files reside > > on. > You advocated that wine aim for working exactly like Windows, no less > and no more, rather than deviating in user-configurable ways to > enhance the user's control over his own system. Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. No, I think defeating DRM to enable fair use is > perfectly reasonable, and there are some bugs which should be fixed. > Should wine try to patch remote exploits at the exact same rate as > windowsupdate.com? That would be also be required for true > bug-for-bug compatibility. After all, someone properly authorized > might be using that backdoor to reboot their webfarm remotely -- not! > > There are things that are wrong in a theoretical sense (i.e. the > Pentium floating-point bug), or misclassification of Unicode > characters, which some programs might reasonably depend on. And then > there are things that are wrong from a practical engineering > perspective, like software taking away the user's choice to not run > it, which the mere fact that a program depends on it makes it malware. > > > Asking if you want to run every file set for startup in wineboot > > every single time is crippling behavior, not to mention annoying. UAC > > anyone? If you're so worried about this "malware", create a reduced > > privileges account just for Wine. > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > option on the prompt which appears when the winecfg option is ask... > > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > > > > > > > > > > > Thanks > > > > Misha > > > > > > > > p.s. please please please anyone who is familiar with IShellFolder > if > > > > you could look over those parts and just say yes it looks good that > > > > would make me feel better. I think it is correct but really an > expert's > > > > opinion would be great. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > James Hawkins > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070212/26dd3987/attachment.html From stefandoesinger at gmx.at Mon Feb 12 20:27:00 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Mon Feb 12 20:27:44 2007 Subject: Starting work on wine (Direct X Help) In-Reply-To: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> References: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> Message-ID: <200702130327.08778.stefandoesinger@gmx.at> Am Dienstag 13 Februar 2007 02:43 schrieb Nathan Williams: > I want to get my hands dirty in the wine source code but I need a > little guidance, hopefully from someone working on the DirectX > sections of wine. > > I've decided I want to get Carmageddon working properly. > I have already added it to the appdb > (http://appdb.winehq.org/appview.php?iVersionId=6993) > for the windows version. > My main question is, how can I go about linking the visual bugs that I > see with the area of code that needs work? > I have worked with DirectX before and I am capable of coding tests and > hooking directx on windows if needed. I am working on Direct3D and DirectDraw, and I wrote the new DirectDraw over WineD3D implementation. From looking at the (tiny) description in the appdb it seems that there are 3 different issues. The "lenght not multiple" messages are sound related - I hardly know about that. The "managed" issue, do you mean it only runs in a virtual desktop, or when you allow the window to be controlled by the linux window manager? Last, the flawky menus and cutscenes could be because of the lack of a proper GDI engine. You can test that by enabling the ddraw debug channel and searching for GetDC calls. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070213/3bb6a9b6/attachment.pgp From kingofallhearts999 at gmail.com Mon Feb 12 20:32:39 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Mon Feb 12 20:32:52 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <78a7dad00702121813r539416acydaa7254099392432@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> <78a7dad00702121813r539416acydaa7254099392432@mail.gmail.com> Message-ID: If you've read the recent mailing list posts dating up to a few weeks back I think, there have been some cases. But like everyone said, the fact the malware would even run in itself is almost bittersweet. It is bug-for-bug though so you can't just do that. Possibly an 'msconfig' like thing would be more realistic you know where you control (in a poor poor pooooooor way,) what runs at startup. yo ucould even go as far as to show the programs in the gnome-sessions program or the kde equivilent, thought that would be a pain (though cool.) On 2/12/07, John Smith wrote: > > Part of my confusion what usage pattern is contracting malware on wine in > the first place > > On 2/12/07, richardvoigt@gmail.com wrote: > > > > On 2/12/07, James Hawkins wrote: > > > On 2/11/07, richardvoigt@gmail.com < richardvoigt@gmail.com> wrote: > > > > On 2/11/07, Misha Koshelev wrote: > > > > > Hi everybody, > > > > > > > > > > Thanks for your suggestions. I just posted a new patch on > > wine-patches > > > > > where I tried to incorporate these and now it does the following > > (in > > > > > addition to my previous patch which just started items in the > > StartUp > > > > > folder): > > > > > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > > > folder, it asks the user whether he wants to run the program. His > > > > > options are: Always, Yes, No (default), and Never. > > > > > - If he selects Yes the program is run, if he select No it is not. > > > > > - If he selects Always or Never, I create a registry key in: > > > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full > > pathname > > > > > of the program and the value "always" or "never." When wineboot > > sees > > > > > this program in the StartUp folder it checks this key, and if it > > is > > > > > set it performs the appropriate action. > > > > > > > > > > What do you guys think? If you like the system, it would be pretty > > easy > > > > > to incorporate this into the run key running as well (which are > > > > > currently just run without any user confirmation)? > > > > > > > > This sounds almost perfect. I think the counterpoint raised by > > James > > > > Hawkins would be adequately addressed by adding a winecfg option as > > > > follows: > > > > > > > > Startup items behavior: > > > > (*) Silently allow <-- This is "bug-for-bug > > compatibility" > > > > ( ) Ask <-- Most computer-savvy folks > > would want this > > > > ( ) Silently block > > > > ( ) Block and notify me > > > > > > > > > > This is unnecessarily complicated, and i really doubt anything like > > > this would ever make it into the Wine tree. > > > > > > > Perhaps this should be independently set for each kind of startup > > item > > > > (startmenu\programs\startup, registry run key, profile settings, > > etc), > > > > but I think that's not really necessary. > > > > > > > > Also, I would suggest that the list of approved start items be > > stored > > > > outside of winespace, so that malware can't bypass the protection by > > > > setting the key. Of course, really nasty stuff could still call > > into > > > > Linux, but that would require some hybrid system that was aware of > > the > > > > ELF dynamic loader in order to not fall afoul of address space > > > > randomization. > > > > > > > > Ultimately I think wine is about more than just running > > > > Windows-compatible programs without the Microsoft tax. It's about > > > > running those programs without ceding control of your computer to an > > > > untrustworthy party. We don't want the limitations that Windows > > > > imposes... true bug-for-bug compatibility would mean only being able > > > > > > to access files on a FAT or NTFS partition, but I don't hear anyone > > > > advocating for that kind of crippling behavior. > > > > > > > > > > What? Wine has nothing to do with which file system your files reside > > > > > on. > > You advocated that wine aim for working exactly like Windows, no less > > and no more, rather than deviating in user-configurable ways to > > enhance the user's control over his own system. Maybe while we're at > > it, wine should have the bug which allows certain software to prevent > > screen grabs. No, I think defeating DRM to enable fair use is > > perfectly reasonable, and there are some bugs which should be fixed. > > Should wine try to patch remote exploits at the exact same rate as > > windowsupdate.com? That would be also be required for true > > bug-for-bug compatibility. After all, someone properly authorized > > might be using that backdoor to reboot their webfarm remotely -- not! > > > > There are things that are wrong in a theoretical sense (i.e. the > > Pentium floating-point bug), or misclassification of Unicode > > characters, which some programs might reasonably depend on. And then > > there are things that are wrong from a practical engineering > > perspective, like software taking away the user's choice to not run > > it, which the mere fact that a program depends on it makes it malware. > > > > > Asking if you want to run every file set for startup in wineboot > > > every single time is crippling behavior, not to mention annoying. UAC > > > anyone? If you're so worried about this "malware", create a reduced > > > privileges account just for Wine. > > > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > > option on the prompt which appears when the winecfg option is ask... > > > > Reduced privileges do little or nothing to prevent network abuse (open > > spam relay and the like). > > > > > > > > > > > > > > > Thanks > > > > > Misha > > > > > > > > > > p.s. please please please anyone who is familiar with IShellFolder > > if > > > > > you could look over those parts and just say yes it looks good > > that > > > > > would make me feel better. I think it is correct but really an > > expert's > > > > > opinion would be great. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > James Hawkins > > > > > > > > > > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070212/531570cb/attachment.html From nathan.andrew.williams at gmail.com Mon Feb 12 20:39:30 2007 From: nathan.andrew.williams at gmail.com (Nathan Williams) Date: Mon Feb 12 20:39:48 2007 Subject: Starting work on wine (Direct X Help) In-Reply-To: <200702130327.08778.stefandoesinger@gmx.at> References: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> <200702130327.08778.stefandoesinger@gmx.at> Message-ID: <5989a080702121839w5796755tb9488e813990a074@mail.gmail.com> Yeah, I'm not too interested in the sound right now, but I aim to work on that eventually. As for managed mode, unless I'm mangling the wine terminology, what i mean is that it will only show up if I use a command such as: wine explorer /desktop=foo,640x480 CARM95.EXE I'll do some looking into the GetDC calls now. Thank you! On 2/13/07, Stefan D?singer wrote: > > Am Dienstag 13 Februar 2007 02:43 schrieb Nathan Williams: > > I want to get my hands dirty in the wine source code but I need a > > little guidance, hopefully from someone working on the DirectX > > sections of wine. > > > > I've decided I want to get Carmageddon working properly. > > I have already added it to the appdb > > (http://appdb.winehq.org/appview.php?iVersionId=6993) > > for the windows version. > > My main question is, how can I go about linking the visual bugs that I > > see with the area of code that needs work? > > I have worked with DirectX before and I am capable of coding tests and > > hooking directx on windows if needed. > I am working on Direct3D and DirectDraw, and I wrote the new DirectDraw > over > WineD3D implementation. > > From looking at the (tiny) description in the appdb it seems that there > are 3 > different issues. The "lenght not multiple" messages are sound related - I > hardly know about that. The "managed" issue, do you mean it only runs in a > > virtual desktop, or when you allow the window to be controlled by the > linux > window manager? Last, the flawky menus and cutscenes could be because of > the > lack of a proper GDI engine. You can test that by enabling the ddraw debug > > channel and searching for GetDC calls. > > -- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070213/5b372a85/attachment.htm From truiken at gmail.com Mon Feb 12 22:46:23 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 12 22:46:32 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> Message-ID: <22821af30702122046h5d8844a2y4354c1adaf112342@mail.gmail.com> On 2/12/07, richardvoigt@gmail.com wrote: > > You advocated that wine aim for working exactly like Windows, no less > and no more, rather than deviating in user-configurable ways to > enhance the user's control over his own system. > Right. That's the purpose of Wine. You'd know that if you were a developer on this project. > Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. > I don't know of any apps that depend on this behavior, so that's not likely to happen. > No, I think defeating DRM to enable fair use is > perfectly reasonable, and there are some bugs which should be fixed. > Should wine try to patch remote exploits at the exact same rate as > windowsupdate.com? > Since we have completely different code bases, I don't see how we can fix their code in our tree. > That would be also be required for true > bug-for-bug compatibility. After all, someone properly authorized > might be using that backdoor to reboot their webfarm remotely -- not! > > There are things that are wrong in a theoretical sense (i.e. the > Pentium floating-point bug), or misclassification of Unicode > characters, which some programs might reasonably depend on. And then > there are things that are wrong from a practical engineering > perspective, like software taking away the user's choice to not run > it, which the mere fact that a program depends on it makes it malware. > Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This "malware" that you're so afraid of can just write over that registry entry. > > Asking if you want to run every file set for startup in wineboot > > every single time is crippling behavior, not to mention annoying. UAC > > anyone? If you're so worried about this "malware", create a reduced > > privileges account just for Wine. > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > option on the prompt which appears when the winecfg option is ask... > If this entry defaults to "Always" or "Never", then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about. > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns. -- James Hawkins From r.kalbermatter at hccnet.nl Tue Feb 13 01:39:20 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Tue Feb 13 01:40:17 2007 Subject: DIB Engine, some summarization Message-ID: <009401c74f42$12f91ca0$4001a8c0@glis> Damjan Jovanovic [mailto:damjan.jov@gmail.com] well: >What about the case where you draw with GDI, then render with OpenGL on >top of that, then draw on top of that with GDI, then swap buffers? >If you draw only client-side, you have to copy to the server, then copy >back, then copy to the server *again*. You have to upload or download >the image *every time* you go between OpenGL and GDI drawing, whereas >when you draw with X11, there is no uploads/downloads unless you use >DIB sections and draw directly. Well, I have to admit I don't understand the whole complexity with DirectX, OpenGL and GDI. But the DIB engine is mostly for DIB sections I would think. It could be used for most device dependant bitmap surfaces too as long as the driver puts them in the surface structure of course, since that are just bitmaps too, but if that would be wise is another question. I would think that to start with the handling of DIBs would be most important. Or is it the idea to use the DIB engine for device dependant bitmaps attached to the device context too? Because that would make at least this case probably indeed more complicated. As far as X11 is concerend device dependant bitmaps should not pose a problem other than possibly performance if an application also wants to draw directly in the bitmap. But this works now and could be left in. And the bit depth will be alright since the ddb should be in the same bit depth as what the X11 server uses. DIBs however have the additional problem of using any possible bit depth with X11 only really supporting the currently used bit depth. So here you want to get X11 out of the loop if possible. >X11 drawing has some more advantages, like being able to use forms of >hardware acceleration (XAA/EXA) that client-side drawing can't. That might be but arbitrary bit depth support for hardware related acceleration is probably not very common among chip sets. >A pure client-side drawing strategy is IMO inferior to a strategy where >you can draw client-side or server-side, as the need arises. I think DIB drawing should be if possible kept on the client side. That solves the problems with X11 not supporting arbitrary bit depths and also synchronisation of the bitmaps if the application uses direct bitmap access too. And it wouldn't be pure client side at all. A driver can hook functions even for DIBs if he wants. If he does he would of course have to make sure all bit depths are supported and synchronisation is taken care off. Support of all bit depts would be quite easy as it could decide to do whatever modes it can do and otherwise pass it on to the GDI engine anyhow. If the driver doesn't hook or fails that function somehow then the GDI engine is used to do the operation for the DIB. And at least for drivers having their device bitmap in the device context too (under Windows a driver doesn't need to do that, for instance always drawing directly to the shared video memory), it might be possible to use the DIB engine too, but that would be the drivers decision and as said I'm not yet sure that is how it's done under Windows nor if it should be done this way. Rolf Kalbermatter From mike at codeweavers.com Tue Feb 13 02:28:52 2007 From: mike at codeweavers.com (Mike McCormack) Date: Tue Feb 13 02:28:56 2007 Subject: [PATCH] switch stat and fopen Message-ID: <45D176C4.8050200@codeweavers.com> Marcus Meissner wrote: > - if (!(fin = fopen(input_file_name, "r"))) return 0; > if (stat(input_file_name, &st) < 0) return 0; > + if (!(fin = fopen(input_file_name, "r"))) return 0; Wouldn't it be better to use fstat here to avoid a race condition? Mike From nlaw at nildram.co.uk Tue Feb 13 04:06:24 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Tue Feb 13 04:07:19 2007 Subject: AppDB performance issue In-Reply-To: References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> Message-ID: <45D18DA0.4090709@nildram.co.uk> Bryan Haskins wrote: > Weird I'm on dial-up even and goto the same pages, and all around the > wine sites, all the time, and they load surprisingly fast. > > On 2/12/07, *Nick Law* > wrote: >> Nick Law wrote: >> > Tony Lambregts wrote: >> >> Chris Morgan wrote: >> >> >> >>> On 2/11/07, Tony Lambregts > > wrote: >> >>> >> >>>> Nick Law wrote: >> >>>> >> >>>>> Hi Tony, >> >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it >> >>>>> can >> >>>>> take15 seconds or more for a page to come up or simply to >> login. Is >> >>>>> there a bandwidth problem or is the server getting overwhelmed >> or is >> >>>>> it a problem at my end (UK). 30 seconds later it's back to >> being very >> >>>>> responsive as if the server was a bit overloaded for 30 seconds or >> >>>>> so. >> >>>>> Other websites I try at the time work fine including winehq. Is >> >>>>> winehq >> >>>>> on a different server ? >> >>>>> >> >>>>> >> >>>> I have noticed this too and it is very annoying. Yes >> www.winehq.org >> >>>> qpdb.winehq.or and bugs.winehq.org are >> all on the same server. >> >>>> >> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >> >>>> >> >>>> I have know idea what is wrong >> >>>> >> >>>> -- >> >>>> >> >>>> Tony Lambregst >> >>>> >> >>>> >> >>>> >> >>>> >> >>> Are particular pages slow? I'm not seeing slow page loads to the >> main >> >>> page or to an application version page from here, a few seconds for >> >>> each. >> >>> >> >>> Chris >> >>> >> >>> >> >>> >> >> >> >> I see it when doing administration ie accepting or rejectiong >> >> applications and >> >> versions (maybe its the way we send emails). >> >> >> >> >> >> -- >> >> >> >> Tony Lambregts >> >> . >> > >> > Yes, ditto. Logging in to do admin tasks, but not only that, if I >> > click on the link in an email from somebody that has posted to the >> > WoW 2.0.x page it will take 30 seconds for the page to appear. >> > >> > I just posted some replies to the wow page and then clicked on the >> > link in the email and it took 84 seconds for the page to appear. It >> > find it seems to be more frequent now, maybe every other page or 1 in >> > three pages are very slow. >> > >> > Nick >> > >> > >> Correction it seems to be bad at the moment, the last 4 pages are slow, >> 60-90 secs before they display, and now it's back to < 2seconds to >> display a page again, it's like some process on the server hogs the CPU >> for 60 secs intermittently. >> >> Nick >> >> >> >> -- >> Cheers, >> Bryan >> ------------------------------------------------------------------------ >> >> >> Do you click on the links in the emails received from appdb@winehq.org to take you to the posts on the WoW AppDB page ? That's where I often see the problem. For instance this is a link to your recent post http://appdb.winehq.org/appview.php?iVersionId=6482&mode=nested#Comment-18117 which takes over a minute to load, then 5 minutes later I try again and it loads in < 2secs. Nick From julliard at winehq.org Tue Feb 13 04:35:35 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 13 04:35:42 2007 Subject: avifil32: sign-compare fixes In-Reply-To: <159828.264.qm@web52714.mail.yahoo.com> (Joris Huizer's message of "Mon\, 12 Feb 2007 16\:16\:28 -0800 \(PST\)") References: <159828.264.qm@web52714.mail.yahoo.com> Message-ID: <87lkj2cpl4.fsf@wine.dyndns.org> Joris Huizer writes: > diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c > index f989c79..e7b22b1 100644 > --- a/dlls/avifil32/avifile.c > +++ b/dlls/avifil32/avifile.c > @@ -835,7 +835,7 @@ static LONG WINAPI IAVIStream_fnFindSamp > ULONG n; > > for (n = 0; n < This->sInfo.dwFormatChangeCount; n++) > - if (This->idxFmtChanges[n].ckid >= pos) { > + if (This->idxFmtChanges[n].ckid >= (ULONG)pos) { Please don't add typecasts all over the place. If things can be fixed by changing variable types then that's fine, but otherwise we can just as well live with the warnings. -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Tue Feb 13 05:34:51 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 13 05:35:00 2007 Subject: mshtml #10: Added SchemeIs implementation. In-Reply-To: <45CE083A.1010803@codeweavers.com> (Jacek Caban's message of "Sat\, 10 Feb 2007 19\:00\:26 +0100") References: <45CE083A.1010803@codeweavers.com> Message-ID: <87d54ecmuc.fsf@wine.dyndns.org> Jacek Caban writes: > --- > dlls/mshtml/nsio.c | 12 +++++++++++- > 1 files changed, 11 insertions(+), 1 deletions(-) This one causes make test to hang in the htmldoc.c test, somewhere in test_download(). -- Alexandre Julliard julliard@winehq.org From meissner at suse.de Tue Feb 13 06:26:13 2007 From: meissner at suse.de (Marcus Meissner) Date: Tue Feb 13 06:26:17 2007 Subject: [PATCH] switch stat and fopen In-Reply-To: <45D176C4.8050200@codeweavers.com> References: <45D176C4.8050200@codeweavers.com> Message-ID: <20070213122613.GA22295@suse.de> On Tue, Feb 13, 2007 at 05:28:52PM +0900, Mike McCormack wrote: > > Marcus Meissner wrote: > > >- if (!(fin = fopen(input_file_name, "r"))) return 0; > > if (stat(input_file_name, &st) < 0) return 0; > >+ if (!(fin = fopen(input_file_name, "r"))) return 0; > > Wouldn't it be better to use fstat here to avoid a race condition? Done. Ciao, Marcus From stefandoesinger at gmx.at Tue Feb 13 06:31:18 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Tue Feb 13 06:31:59 2007 Subject: Starting work on wine (Direct X Help) In-Reply-To: <5989a080702121839w5796755tb9488e813990a074@mail.gmail.com> References: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> <200702130327.08778.stefandoesinger@gmx.at> <5989a080702121839w5796755tb9488e813990a074@mail.gmail.com> Message-ID: <200702131331.22782.stefandoesinger@gmx.at> Am Dienstag 13 Februar 2007 03:39 schrieb Nathan Williams: > Yeah, I'm not too interested in the sound right now, but I aim to work on > that eventually. > > As for managed mode, unless I'm mangling the wine terminology, what i mean > is that it will only show up if I use a command such as: > > wine explorer /desktop=foo,640x480 CARM95.EXE Yes, you're mangling the terminology here. What you do here is a virtual desktop. Managed mode means that the windows are managed by the X11 window manager(so they have the window decorations like Linux apps and can be minimized as normal), while unmanaged mode means that wine manages them, they have windows 95-style decos and stay on top of all Linux apps. Managed mode is the default, I think you can enable unmanaged mode with a registry switch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070213/0d9e033c/attachment.pgp From wine.dev at web.de Tue Feb 13 10:29:34 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Tue Feb 13 10:30:07 2007 Subject: Linuxtag 2007 In-Reply-To: <1171299521.6923.18.camel@p4> References: <200702121618.00879.stefan.munz@itomig.de> <20070212153754.GB13457@suse.de> <1171299521.6923.18.camel@p4> Message-ID: <1171384174.6995.11.camel@p4> On Mo, 2007-02-12 at 17:58 +0100, Detlef Riekenberg wrote: > On Mo, 2007-02-12 at 16:37 +0100, Marcus Meissner wrote: > > Whith your help, what can be done, I found 54 contributors for > 2007 in the changelog . > > $ grep "^2007.*>" ChangeLog | sort -t "<" +1 -u | wc -l > 56 > (Stefan and Francois are twice in the list) "+1" works with "sort (GNU coreutils) 5.93" here, but is not documented in "man sort" and did not work on newer versions: "sort (GNU coreutils) 6.4" as example: file "+1" not found. "-k 2" works on 5.93 and is documented: $ grep "^2007.*>" ChangeLog | sort -t "<" -k 2 -u | wc -l 56 -- By by ... Detlef From julliard at winehq.org Tue Feb 13 10:30:57 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 13 10:31:02 2007 Subject: winecfg: Add check for device access to Drives tab. In-Reply-To: <45CD04B9.7080600@kievinfo.com> (Vitaliy Margolen's message of "Fri\, 09 Feb 2007 16\:33\:13 -0700") References: <45CD04B9.7080600@kievinfo.com> Message-ID: <873b5ac94u.fsf@wine.dyndns.org> Vitaliy Margolen writes: > Any reasons why this patch is not applied? > http://www.winehq.org/pipermail/wine-patches/2007-January/035264.html > > This is one of the major headaches for users trying to get programs > requiring direct CD-ROM drive access to work. And it's nearly impossible > to get required information from users to find if the direct access > actually works or not. I think you should distinguish the case of no device at all from the case of a SCSI ioctl failing, for instance loop mounts wouldn't support the ioctl but would still work fine for many things. Also the no device case needs to be less scary, there's nothing wrong with it for most devices. And the strings need to be in resources. -- Alexandre Julliard julliard@winehq.org From gs at crosslight.com.cn Tue Feb 13 03:13:11 2007 From: gs at crosslight.com.cn (gaosheng) Date: Tue Feb 13 10:55:22 2007 Subject: opengl Message-ID: Hi: I want to use opengl with wine. //----Here is my glxinfo. server glx vendor string:SGI server glx version string:1.2 client glx vendor string:SGI client glx version string:1.2 OpengGL vendor string:Mesa project:www.mesa3d.org OpengGL renderer string:Mesa GLX Indirect OpengGL version string:1.3 Mesa 4.0.4 //------ I can't init opengl. when ChoosePixel(), it failed. Can you tell me the reason. Best regards gao sheng From flexo at holycrap.org Tue Feb 13 11:39:00 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 13 11:32:09 2007 Subject: version: Constify a formal parameter of VerQueryValue{A|W}() In-Reply-To: <200702131646.56969.Andrew.Talbot@talbotville.com> References: <200702131646.56969.Andrew.Talbot@talbotville.com> Message-ID: <45D1F7B4.3000700@holycrap.org> Andrew Talbot wrote: > -BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock, > +BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, This is wrong - in the PSDK headers it's LPSTR (the first parameter should be const though). Felix From kingofallhearts999 at gmail.com Tue Feb 13 11:34:06 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Tue Feb 13 11:34:06 2007 Subject: opengl In-Reply-To: References: Message-ID: Well you don't have Direct rendering... if you dont have support from the ATI OSS drivers ( if you use ATi) then you should download the ATI or nvidia proprietary drivers. Should be in your Distros Repos, or you can set them up yourself from their sties. On 2/13/07, gaosheng wrote: > > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. > > Best regards > gao sheng > > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070213/43df1f43/attachment.htm From kingofallhearts999 at gmail.com Tue Feb 13 11:39:25 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Tue Feb 13 11:39:43 2007 Subject: AppDB performance issue In-Reply-To: <45D18DA0.4090709@nildram.co.uk> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> Message-ID: I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. On 2/13/07, Nick Law wrote: > > Bryan Haskins wrote: > > Weird I'm on dial-up even and goto the same pages, and all around the > > wine sites, all the time, and they load surprisingly fast. > > > > On 2/12/07, *Nick Law* > > wrote: > >> Nick Law wrote: > >> > Tony Lambregts wrote: > >> >> Chris Morgan wrote: > >> >> > >> >>> On 2/11/07, Tony Lambregts >> > wrote: > >> >>> > >> >>>> Nick Law wrote: > >> >>>> > >> >>>>> Hi Tony, > >> >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.eit > >> >>>>> can > >> >>>>> take15 seconds or more for a page to come up or simply to > >> login. Is > >> >>>>> there a bandwidth problem or is the server getting overwhelmed > >> or is > >> >>>>> it a problem at my end (UK). 30 seconds later it's back to > >> being very > >> >>>>> responsive as if the server was a bit overloaded for 30 seconds > or > >> >>>>> so. > >> >>>>> Other websites I try at the time work fine including winehq. Is > >> >>>>> winehq > >> >>>>> on a different server ? > >> >>>>> > >> >>>>> > >> >>>> I have noticed this too and it is very annoying. Yes > >> www.winehq.org > >> >>>> qpdb.winehq.or and bugs.winehq.org are > >> all on the same server. > >> >>>> > >> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. > >> >>>> > >> >>>> I have know idea what is wrong > >> >>>> > >> >>>> -- > >> >>>> > >> >>>> Tony Lambregst > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>> Are particular pages slow? I'm not seeing slow page loads to the > >> main > >> >>> page or to an application version page from here, a few seconds for > >> >>> each. > >> >>> > >> >>> Chris > >> >>> > >> >>> > >> >>> > >> >> > >> >> I see it when doing administration ie accepting or rejectiong > >> >> applications and > >> >> versions (maybe its the way we send emails). > >> >> > >> >> > >> >> -- > >> >> > >> >> Tony Lambregts > >> >> . > >> > > >> > Yes, ditto. Logging in to do admin tasks, but not only that, if I > >> > click on the link in an email from somebody that has posted to the > >> > WoW 2.0.x page it will take 30 seconds for the page to appear. > >> > > >> > I just posted some replies to the wow page and then clicked on the > >> > link in the email and it took 84 seconds for the page to appear. It > >> > find it seems to be more frequent now, maybe every other page or 1 in > >> > three pages are very slow. > >> > > >> > Nick > >> > > >> > > >> Correction it seems to be bad at the moment, the last 4 pages are slow, > >> 60-90 secs before they display, and now it's back to < 2seconds to > >> display a page again, it's like some process on the server hogs the CPU > >> for 60 secs intermittently. > >> > >> Nick > >> > >> > >> > >> -- > >> Cheers, > >> Bryan > >> > ------------------------------------------------------------------------ > >> > >> > >> > Do you click on the links in the emails received from appdb@winehq.org > to take you to the posts on the WoW AppDB page ? That's where I often > see the problem. For instance this is a link to your recent post > > http://appdb.winehq.org/appview.php?iVersionId=6482&mode=nested#Comment-18117 > which takes over a minute to load, then 5 minutes later I try again and > it loads in < 2secs. > > Nick > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070213/2da9862b/attachment.htm From stefandoesinger at gmx.at Tue Feb 13 11:53:17 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 13 11:53:49 2007 Subject: opengl In-Reply-To: References: Message-ID: <200702131853.20291.stefandoesinger@gmx.at> Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > OpengGL renderer string:Mesa GLX Indirect is your reason. You do not have a 3D driver installed or properly set up -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070213/b26d064a/attachment-0001.pgp From Andrew.Talbot at talbotville.com Tue Feb 13 12:35:06 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Tue Feb 13 12:36:02 2007 Subject: version: Constify a formal parameter of VerQueryValue{A|W}() References: <200702131646.56969.Andrew.Talbot@talbotville.com> <45D1F7B4.3000700@holycrap.org> Message-ID: Felix Nawothnig wrote: > Andrew Talbot wrote: >> -BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock, >> +BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, > > This is wrong - in the PSDK headers it's LPSTR (the first parameter > should be const though). > > Felix I've seen this function represented with the first two parameters constified. Is anyone aware of a more const-correct version in the field than the one Felix mentions? -- Andy. From thestig at google.com Tue Feb 13 12:38:20 2007 From: thestig at google.com (Lei Zhang) Date: Tue Feb 13 12:38:47 2007 Subject: compiling out debugging messages? In-Reply-To: <45D0EE71.7040308@redhat.com> References: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> <558b2f5c0702121419y33321a82xbd9091a17eb4559e@mail.gmail.com> <45D0EE71.7040308@redhat.com> Message-ID: <558b2f5c0702131038k4d6bc72aq520158571d90211c@mail.gmail.com> On 2/12/07, Michael Stefaniuc wrote: > Lei Zhang wrote: > > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / > > -DWINE_NO_TRACE_MSGS from configure, but not from > > include/wine/debug.h. > Right, it was a problem with a lot of people turning debug messages off > and sending in useless problem reports. So that option got removed from > configure. There is one valid reason to turn debugging off and that is > to cross check that there are no side effects hidden in some debug message. > > > On 2/12/07, Lei Zhang wrote: > >> Hi, > >> > >> Is it still possible to compile out debugging messages? According to > >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass > >> --disable-debug, but the Changelog says that option was removed about > >> 10 month ago. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani@redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > Well, we should update the documentation either by removing section 2.6 or mention passing -DWINE_NO_{DEBUG/TRACE}_MSGS instead. From lav at etersoft.ru Tue Feb 13 12:39:58 2007 From: lav at etersoft.ru (Vitaly Lipatov) Date: Tue Feb 13 12:40:46 2007 Subject: opengl In-Reply-To: <200702131853.20291.stefandoesinger@gmx.at> References: <200702131853.20291.stefandoesinger@gmx.at> Message-ID: <200702132139.58205.lav@etersoft.ru> ? ????????? ?? 13 ??????? 2007 20:53 Stefan D?singer ???????(a): > Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > > OpengGL renderer string:Mesa GLX Indirect > > is your reason. You do not have a 3D driver installed or properly set up Why we can't use software rendering? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru From truiken at gmail.com Tue Feb 13 12:46:27 2007 From: truiken at gmail.com (James Hawkins) Date: Tue Feb 13 12:46:55 2007 Subject: comctl32: move up-down msg seq tests into new 'msg' test In-Reply-To: <45D1FDF8.9060007@holycrap.org> References: <45D1FDF8.9060007@holycrap.org> Message-ID: <22821af30702131046s44194779i4a2a4dda6a280df@mail.gmail.com> On 2/13/07, Felix Nawothnig wrote: > Figured you might want a test for my listview patch - so first this. > > Didn't really change anything, still passed on XP SP2. > --- > dlls/comctl32/tests/Makefile.in | 1 + > dlls/comctl32/tests/msg.c | 523 > +++++++++++++++++++++++++++++++++++++++ > dlls/comctl32/tests/updown.c | 435 +-------------------------------- > 3 files changed, 532 insertions(+), 427 deletions(-) > This is not what needs to happen. The generic message sequence testing code needs to be factored into msg.c, but the specific tests need to stay in each control's test file. -- James Hawkins From flexo at holycrap.org Tue Feb 13 12:59:34 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 13 12:52:45 2007 Subject: comctl32: move up-down msg seq tests into new 'msg' test In-Reply-To: <22821af30702131046s44194779i4a2a4dda6a280df@mail.gmail.com> References: <45D1FDF8.9060007@holycrap.org> <22821af30702131046s44194779i4a2a4dda6a280df@mail.gmail.com> Message-ID: <45D20A96.2060202@holycrap.org> James Hawkins wrote: > This is not what needs to happen. The generic message sequence > testing code needs to be factored into msg.c, but the specific tests > need to stay in each control's test file. Guessed so... How about putting it into include/wine/test.h to share the code with user32/msg? Wouldn't help object size but I don't think a shared lib would be worth it... Felix From truiken at gmail.com Tue Feb 13 12:54:09 2007 From: truiken at gmail.com (James Hawkins) Date: Tue Feb 13 12:55:07 2007 Subject: comctl32: move up-down msg seq tests into new 'msg' test In-Reply-To: <45D20A96.2060202@holycrap.org> References: <45D1FDF8.9060007@holycrap.org> <22821af30702131046s44194779i4a2a4dda6a280df@mail.gmail.com> <45D20A96.2060202@holycrap.org> Message-ID: <22821af30702131054k3f5e60c5y89e2e2e9fb6dc1a1@mail.gmail.com> On 2/13/07, Felix Nawothnig wrote: > James Hawkins wrote: > > This is not what needs to happen. The generic message sequence > > testing code needs to be factored into msg.c, but the specific tests > > need to stay in each control's test file. > > Guessed so... How about putting it into include/wine/test.h to share the > code with user32/msg? Wouldn't help object size but I don't think a > shared lib would be worth it... > No, comctl32's message sequence testing code is different than user32's, and will be even more different when I add in WM_NOTIFY testing support. -- James Hawkins From flexo at holycrap.org Tue Feb 13 13:11:35 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 13 13:05:05 2007 Subject: version: Constify a formal parameter of VerQueryValue{A|W}() In-Reply-To: References: <200702131646.56969.Andrew.Talbot@talbotville.com> <45D1F7B4.3000700@holycrap.org> Message-ID: <45D20D67.20007@holycrap.org> Andrew Talbot wrote: > I've seen this function represented with the first two parameters > constified. Is anyone aware of a more const-correct version in the field > than the one Felix mentions? Sorry about that, seems they changed the declaration in the new headers - I misinterpreted your comment about the first parameter. What's the problem with it anyway? Just keep adding "const" to internal functions until the warnings disappear. :) Felix From inckie at gmail.com Tue Feb 13 13:06:21 2007 From: inckie at gmail.com (Pedro Araujo Chaves Jr.) Date: Tue Feb 13 13:06:40 2007 Subject: Bug 50 In-Reply-To: <954071.53888.qm@web51507.mail.yahoo.com> References: <954071.53888.qm@web51507.mail.yahoo.com> Message-ID: Hi all, I'm writing just to ask why my patch and test case for Bug 50 (the text justification issue) weren't committed yet, so that I can take the proper measures in order that they can be. Regards, Pedro. From stefandoesinger at gmx.at Tue Feb 13 13:31:52 2007 From: stefandoesinger at gmx.at (Stefan =?utf-8?q?D=C3=B6singer?=) Date: Tue Feb 13 13:32:33 2007 Subject: opengl In-Reply-To: <200702132139.58205.lav@etersoft.ru> References: <200702131853.20291.stefandoesinger@gmx.at> <200702132139.58205.lav@etersoft.ru> Message-ID: <200702132031.53518.stefandoesinger@gmx.at> Am Dienstag 13 Februar 2007 19:39 schrieb Vitaly Lipatov: > ? ????????? ?? 13 ??????? 2007 20:53 Stefan D?singer ???????(a): > > Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > > > OpengGL renderer string:Mesa GLX Indirect > > > > is your reason. You do not have a 3D driver installed or properly set up > > Why we can't use software rendering? Actually it does work, but the other thing with this glxinfo is that its way too short(like he has no glx at all). And mesa indirect won't give satisfying results, even though it should work good enought to give some output. From nathan.andrew.williams at gmail.com Tue Feb 13 14:45:23 2007 From: nathan.andrew.williams at gmail.com (Nathan Williams) Date: Tue Feb 13 14:45:32 2007 Subject: Starting work on wine (Direct X Help) In-Reply-To: <200702131331.22782.stefandoesinger@gmx.at> References: <5989a080702121743l49989268r120fadbe2a2fb70f@mail.gmail.com> <200702130327.08778.stefandoesinger@gmx.at> <5989a080702121839w5796755tb9488e813990a074@mail.gmail.com> <200702131331.22782.stefandoesinger@gmx.at> Message-ID: <5989a080702131245h6dd98a13s34eed9ac88048a96@mail.gmail.com> Oh, my apologies, i thought i had the terminology down pat, but i guess not! I added a comment correcting myself on the appdb. On the actual code, i think the bug lies somewhere in: IWineD3DPaletteImpl_SetEntries During the menus this is called repeatedly. Which looking at the source (wined3d/palette.c) there is a comment about problems with depth conversion (which Carmageddon runs in 8 bit) so I'm working on the assumption thats where the problem lies. Tonight I plan to do some testing on that to see what i can find. On 2/13/07, Stefan D?singer wrote: > > wine explorer /desktop=foo,640x480 CARM95.EXE > Yes, you're mangling the terminology here. What you do here is a virtual > desktop. Managed mode means that the windows are managed by the X11 window > manager(so they have the window decorations like Linux apps and can be > minimized as normal), while unmanaged mode means that wine manages them, > they > have windows 95-style decos and stay on top of all Linux apps. Managed > mode > is the default, I think you can enable unmanaged mode with a registry > switch. > > -- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070214/28041a77/attachment-0001.htm From flexo at holycrap.org Tue Feb 13 15:16:58 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 13 15:10:09 2007 Subject: Add RegisterRawInputDevices stub implementation In-Reply-To: <200702132153.56714.andras@csevego.net> References: <200702132153.56714.andras@csevego.net> Message-ID: <45D22ACA.2070108@holycrap.org> Kov?cs Andr?s wrote: > +BOOL WINAPI RegisterRawInputDevices(PRAWINPUTDEVICE pRawInputDevices, UINT uiNumDevices, UINT cbSize) > +{ > +int i; Please keep the indentation style of the original file. From mstefani at redhat.com Tue Feb 13 17:03:53 2007 From: mstefani at redhat.com (Michael Stefaniuc) Date: Tue Feb 13 17:04:07 2007 Subject: compiling out debugging messages? In-Reply-To: <558b2f5c0702131038k4d6bc72aq520158571d90211c@mail.gmail.com> References: <558b2f5c0702121403v541ca588j15338dd3f6418d3f@mail.gmail.com> <558b2f5c0702121419y33321a82xbd9091a17eb4559e@mail.gmail.com> <45D0EE71.7040308@redhat.com> <558b2f5c0702131038k4d6bc72aq520158571d90211c@mail.gmail.com> Message-ID: <45D243D9.1080208@redhat.com> Lei Zhang wrote: > On 2/12/07, Michael Stefaniuc wrote: >> Lei Zhang wrote: >> > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / >> > -DWINE_NO_TRACE_MSGS from configure, but not from >> > include/wine/debug.h. >> Right, it was a problem with a lot of people turning debug messages off >> and sending in useless problem reports. So that option got removed from >> configure. There is one valid reason to turn debugging off and that is >> to cross check that there are no side effects hidden in some debug >> message. >> >> > On 2/12/07, Lei Zhang wrote: >> >> Hi, >> >> >> >> Is it still possible to compile out debugging messages? According to >> >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass >> >> --disable-debug, but the Changelog says that option was removed about >> >> 10 month ago. >> > > Well, we should update the documentation either by removing section > 2.6 or mention passing -DWINE_NO_{DEBUG/TRACE}_MSGS instead. Removing that part of the documentation is probably best. Somebody really wanting to disable that will figure it out for himself. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani@redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart From ivg231 at gmail.com Tue Feb 13 19:18:16 2007 From: ivg231 at gmail.com (Ivan Gyurdiev) Date: Tue Feb 13 19:14:41 2007 Subject: [4/9] d3d8: Add an IDirect3DVertexDeclaration8 class to hold the wined3d vertex declaration In-Reply-To: References: Message-ID: <45D26358.6000001@gmail.com> > > The idea of this patch and the next few is to create an internal d3d8 > object to hold the wined3d declaration and give the d3d8 vertex shader > a field to hold the d3d8 vertex declaration object. Setting the d3d8 > vertex shader will then set both the wined3d shader and the wined3d > vertex declaration. Excellent. I don't know if the implementation works, but the idea is certainly on the right track. This was done incorrectly to begin with, and also made it difficult to remove the dependency on d3d8/d3d9 includes (which I see you're on track to complete). Ivan From stefandoesinger at gmx.at Tue Feb 13 19:17:38 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 13 19:18:22 2007 Subject: GPU performance counters, agp usage Message-ID: <200702140217.42434.stefandoesinger@gmx.at> Hi, I've had a look at various performance counters of my nvidia card with nvperfkit and nvperfgraph while running half-life 2. The first thing I noticed was that the gpu was approximately 75% to 90% idle, while one cpu core was 100% busy and the other completely idle. More to that later. The other interesting thing was that "OGL driver waiting" was at 100% and agp usage was beyond what nvperfgraph could show. This seems to happen with any application that uses opengl in wine, including very simple d3d apps(Moto racer 2, Direct3D1) and opengl apps(Jedi academy). when the application quits the counters fall back to 0 immediately. On the other hand, a native Linux application(ut2004, 64 bit) does not cause any change in the driver waiting and the agp usage stays at zero. (makes me wonder a bit how useful those counters are). For wine it is enough to successfully create a d3d device or opengl context. Just a IDirect3D9::CreateDevice does it. Regarding the 75% idle, I think that is comparably ok. Native ut2004 shows the same behavior. So either the games are broken, or I have a way to overpowered gpu(geforce 7600) for my cpu(athlon 64 X2 dual core 3800+). Any ideas regarding the agp usage? Could a badly chosen pixel format cause the trouble? Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070214/412c2069/attachment.pgp From twickline at gmail.com Tue Feb 13 19:52:14 2007 From: twickline at gmail.com (Tom Wickline) Date: Tue Feb 13 19:52:24 2007 Subject: opengl In-Reply-To: References: Message-ID: <53e3a9930702131752g5a10ae18t8a0b3e56515aeef5@mail.gmail.com> On 2/13/07, gaosheng wrote: > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. You will need to have direct rendering, and to see if its currently activated (status) you can grep glxinfo : $ glxinfo | grep direct You will want to make sure it says Yes tom@prostar ~ $ glxinfo | grep direct direct rendering: Yes tom@prostar ~ $ You may also need to update your module section in your X.org conf file You will want to turn off dri and turn glx on. # Load "dri" Load "glx" You may also want to grep the vendor tom@prostar ~ $ glxinfo | grep vendor server glx vendor string: NVIDIA Corporation client glx vendor string: NVIDIA Corporation OpenGL vendor string: NVIDIA Corporation tom@prostar ~ $ You can run 'glxgears' before and after also, here it makes a huge difference. tom@prostar ~ $ glxgears 54378 frames in 5.0 seconds = 10875.471 FPS 54802 frames in 5.0 seconds = 10960.384 FPS 54775 frames in 5.0 seconds = 10954.939 FPS tom@prostar ~ $ Cheers, Tom > > Best regards > gao sheng > From thestig at google.com Tue Feb 13 19:56:13 2007 From: thestig at google.com (Lei Zhang) Date: Tue Feb 13 19:56:30 2007 Subject: test.winehq.com status In-Reply-To: <45C0DD39.3090509@gmail.com> References: <45BF6D97.3060908@holycrap.org> <45C0DD39.3090509@gmail.com> Message-ID: <558b2f5c0702131756g5786a655u3437735dd541ca0e@mail.gmail.com> On 1/31/07, Paul Vriens wrote: > Felix Nawothnig wrote: > > Hi. Anyone knows what happened to test.winehq.com/data? There has been > > no new crossbuilds for quite some time now... > > > > Felix > > > > > > > Hi, > > I did sent an email to Paul Millar, but no reply yet. You can see what goes > wrong with the build btw.: > > http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ > > Cheers, > > Paul. > > > > Any news? It's been a couple weeks... From alex.pigna at inventati.org Tue Feb 13 20:36:51 2007 From: alex.pigna at inventati.org (Alessandro Pignotti) Date: Tue Feb 13 20:36:29 2007 Subject: wined3d: The sims regression Message-ID: <200702140336.56791.alex.pigna@inventati.org> Hi, I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps Bye Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070214/eefb12ad/attachment.pgp From dmitry at codeweavers.com Tue Feb 13 21:01:20 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 13 21:01:53 2007 Subject: Declare some WinXP related structures References: <200702132151.44811.andras@csevego.net> Message-ID: <00d901c74fe4$80df8ae0$0100a8c0@DMITRY> "Kov?cs Andr?s" wrote: > --- a/include/winuser.h > +++ b/include/winuser.h > @@ -1055,6 +1055,51 @@ BOOL WINAPI SetSysColors(INT,const INT*,const COLORREF*); > #define WM_GETICON 0x007f > #define WM_SETICON 0x0080 > > + /* Windows XP messages */ > +#define WM_INPUT 0x00FF Please don't add this kind of a comment, even if it's true for this particular message, it may not belong to all messages below this one. > + /* Windows XP related raw input structures */ > +typedef struct tagRAWINPUTDEVICE { You have added a bunch of structures in the middle of the message definitions, please find a better place. -- Dmitry. From paul.vriens.wine at gmail.com Wed Feb 14 00:36:29 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Wed Feb 14 00:36:47 2007 Subject: test.winehq.com status In-Reply-To: <558b2f5c0702131756g5786a655u3437735dd541ca0e@mail.gmail.com> References: <45BF6D97.3060908@holycrap.org> <45C0DD39.3090509@gmail.com> <558b2f5c0702131756g5786a655u3437735dd541ca0e@mail.gmail.com> Message-ID: <45D2ADED.7000107@gmail.com> Lei Zhang wrote: > On 1/31/07, Paul Vriens wrote: >> Felix Nawothnig wrote: >> > Hi. Anyone knows what happened to test.winehq.com/data? There has been >> > no new crossbuilds for quite some time now... >> > >> > Felix >> > >> > >> > >> Hi, >> >> I did sent an email to Paul Millar, but no reply yet. You can see what >> goes >> wrong with the build btw.: >> >> http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ >> >> Cheers, >> >> Paul. >> >> >> >> > > Any news? It's been a couple weeks... > > > Hi, Maybe we should start thinking (again) of having several sources for the winetest executable. The only issue I'm seeing there is that the builds could be different (if build by different people at an unknown time of the day/state of GIT) hence test.winehq.org should make a distinction as well (to not compare apples with pears). Cheers, Paul. From fgouget at free.fr Wed Feb 14 03:16:42 2007 From: fgouget at free.fr (Francois Gouget) Date: Wed Feb 14 03:16:47 2007 Subject: GPU performance counters, agp usage In-Reply-To: <200702140217.42434.stefandoesinger@gmx.at> References: <200702140217.42434.stefandoesinger@gmx.at> Message-ID: On Wed, 14 Feb 2007, Stefan D?singer wrote: [...] > Regarding the 75% idle, I think that is comparably ok. Native ut2004 shows the > same behavior. So either the games are broken, or I have a way to overpowered > gpu(geforce 7600) for my cpu(athlon 64 X2 dual core 3800+). You really need to compare that to what you get on Windows (but maybe this is what you mean by 'native ut2004' having the same problem?). Otherwise it could also mean that our some part of Wine is taking way too much CPU compared to Windows. Maybe Direct3D or too much ping pong between Wine and the Wine server, or something else. -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science. From hans at it.vu.nl Wed Feb 14 03:17:27 2007 From: hans at it.vu.nl (Hans Leidekker) Date: Wed Feb 14 03:17:52 2007 Subject: test.winehq.com status In-Reply-To: <45D2ADED.7000107@gmail.com> References: <45BF6D97.3060908@holycrap.org> <558b2f5c0702131756g5786a655u3437735dd541ca0e@mail.gmail.com> <45D2ADED.7000107@gmail.com> Message-ID: <200702141017.27524.hans@it.vu.nl> On Wednesday 14 February 2007, Paul Vriens wrote: > Maybe we should start thinking (again) of having several sources for the > winetest executable. The only issue I'm seeing there is that the builds could be > different (if build by different people at an unknown time of the day/state of > GIT) hence test.winehq.org should make a distinction as well (to not compare > apples with pears). Many if not most failures are due to missing imports on MinGW. Using Wine's import libraries should make the service more robust, at the cost of somewhat reduced testing exposure. -Hans From stefan at codeweavers.com Wed Feb 14 06:15:31 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Wed Feb 14 06:15:53 2007 Subject: wined3d: The sims regression In-Reply-To: <200702140336.56791.alex.pigna@inventati.org> References: <200702140336.56791.alex.pigna@inventati.org> Message-ID: <200702141315.35375.stefan@codeweavers.com> Am Mittwoch 14 Februar 2007 03:36 schrieb Alessandro Pignotti: > Hi, > I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the > git tree causes a regression in the sims, making characters flipped upside > down. It's seems to me that the y axis is flipped. > I hope this helps Oops :-( Is there a demo for this game I could use to debug this? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070214/4d99feb7/attachment.pgp From stefan at codeweavers.com Wed Feb 14 06:22:31 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Wed Feb 14 06:22:41 2007 Subject: GPU performance counters, agp usage In-Reply-To: References: <200702140217.42434.stefandoesinger@gmx.at> Message-ID: <200702141322.35995.stefan@codeweavers.com> Am Mittwoch 14 Februar 2007 10:16 schrieb Francois Gouget: > On Wed, 14 Feb 2007, Stefan D?singer wrote: > [...] > > > Regarding the 75% idle, I think that is comparably ok. Native ut2004 > > shows the same behavior. So either the games are broken, or I have a way > > to overpowered gpu(geforce 7600) for my cpu(athlon 64 X2 dual core > > 3800+). > > You really need to compare that to what you get on Windows (but maybe > this is what you mean by 'native ut2004' having the same problem?). > Otherwise it could also mean that our some part of Wine is > taking way too much CPU compared to Windows. Maybe Direct3D or too much > ping pong between Wine and the Wine server, or something else. Yes, I thought about that. Though atm I am more interested about the reported agp usage, which behaves differently in linux apps. Actually, wined3d usually takes only 5% cpu time in nice games, the rest is split up on the game and 3d driver(usually 60% driver, 35% game). I think that windows uses some marshalling to move the driver to another thread, which will help on dual core machines. I think its time to get a windows license for my other machine :-/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070214/b7e17999/attachment.pgp From lav at etersoft.ru Wed Feb 14 08:51:11 2007 From: lav at etersoft.ru (Vitaly Lipatov) Date: Wed Feb 14 08:51:44 2007 Subject: WINSPOOL: search for a printer driver Message-ID: <200702141751.11462.lav@etersoft.ru> When wine is loading, CUPS_LoadPrinters function get printer list from CUPS and add printer and their printer drivers to registry. If printer is already exist, we do not override nor printer driver, nor printer entry. It all works fine. Note, we place printer driver in "Windows 4.0" registry entry if Wine version is win9x and use "Windows NT x86" registry entry if Wine version is win2000 and above. If we will change wine version after printer loaded, Wine printing is got failed. Wine search in empty registry entry. For example, I get such configuration after run wine in win98 mode: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\hp] 1171461136 "Configuration File"="wineps16" "Data File"="" "Datatype"="RAW" "Dependent Files"=str(7):"\0" "Driver"="wineps16" "Help File"="" "Monitor"="" "Version"=dword:00000000 [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows NT x86\\Drivers\\Version-3] 1171461821 [System\\CurrentControlSet\\Control\\Print\\Printers\\hp] 1171461818 "Attributes"=dword:00000000 "Datatype"="RAW" "Default DevMode"=hex:68,70,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ ... "Description"="WINEPS Printer using CUPS" "Location"="" "Name"="hp" "Parameters"="" "Port"="LPR:hp" "Print Processor"="WinPrint" "Printer Driver"="hp" ... I try to find a better way to resolve this problem. Some ideas: 1. Check if Wine version is changed and reset printer drivers. 2. Search in both registry entry in any way. 3. ... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru From thunder.m at czela.net Wed Feb 14 13:11:49 2007 From: thunder.m at czela.net (Mirek) Date: Wed Feb 14 13:12:08 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: <200702141757.07934.stefan@codeweavers.com> References: <200702141757.07934.stefan@codeweavers.com> Message-ID: <45D35EF5.9000908@czela.net> Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some Nvidia SDK demos are completly fixed! Mirek Stefan D?singer napsal(a): > > ------------------------------------------------------------------------ > > From c59f7c4eea148cfb9a1321bbbbc587ef52194bc9 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Fri, 2 Feb 2007 15:30:34 +0100 > Subject: [PATCH] WineD3D: Properly release the converted vertex declaration > > --- > dlls/d3d9/d3d9_private.h | 5 +++++ > dlls/d3d9/device.c | 3 +++ > dlls/d3d9/vertexdeclaration.c | 5 +++++ > 3 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index 435a37e..972945d 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -179,6 +179,11 @@ typedef struct IDirect3DDevice9Impl > /* Avoids recursion with nested ReleaseRef to 0 */ > BOOL inDestruction; > > + /* A vertex declaration was converted from setFVF. > + * Keep track of it, so it can be properly freed > + */ > + IDirect3DVertexDeclaration9 *convertedDecl; > + > } IDirect3DDevice9Impl; > > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index 4eff550..e6ecd96 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -62,6 +62,8 @@ static ULONG WINAPI IDirect3DDevice9Impl_Release(LPDIRECT3DDEVICE9 iface) { > > if (ref == 0) { > This->inDestruction = TRUE; > + if (This->convertedDecl != NULL) > + IUnknown_Release(This->convertedDecl); > IWineD3DDevice_Uninit3D(This->WineD3DDevice, D3D9CB_DestroyDepthStencilSurface, D3D9CB_DestroySwapChain); > IWineD3DDevice_Release(This->WineD3DDevice); > HeapFree(GetProcessHeap(), 0, This); > @@ -766,6 +768,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetFVF(LPDIRECT3DDEVICE9 iface, DWORD FVF) > > hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); > if (hr != S_OK) goto exit; > + This->convertedDecl = pDecl; > pDecl = NULL; > > exit: > diff --git a/dlls/d3d9/vertexdeclaration.c b/dlls/d3d9/vertexdeclaration.c > index a7f5486..c3f462e 100644 > --- a/dlls/d3d9/vertexdeclaration.c > +++ b/dlls/d3d9/vertexdeclaration.c > @@ -360,6 +360,11 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetVertexDeclaration(LPDIRECT3DDEVICE9 ifa > > TRACE("(%p) : Relay\n", iface); > > + if (This->convertedDecl && This->convertedDecl != pDecl) { > + IUnknown_Release(This->convertedDecl); > + This->convertedDecl = NULL; > + } > + > hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); > > return hr; > > > ------------------------------------------------------------------------ > > From eric.pouech at wanadoo.fr Wed Feb 14 13:14:39 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Wed Feb 14 13:15:33 2007 Subject: [Janitorial] snmpapi: Remove the last-but-one %ll printf format In-Reply-To: References: Message-ID: <45D35F9F.1090209@wanadoo.fr> Pedro Araujo Chaves Jr. a ?crit : > case ASN_COUNTER64: > { > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > it should read %s\n"... A+ From stefan at codeweavers.com Wed Feb 14 13:33:17 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Wed Feb 14 13:33:37 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: <45D35EF5.9000908@czela.net> References: <200702141757.07934.stefan@codeweavers.com> <45D35EF5.9000908@czela.net> Message-ID: <200702142033.20718.stefan@codeweavers.com> Am Mittwoch 14 Februar 2007 20:11 schrieb Mirek: > Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some > Nvidia SDK demos are completly fixed! Though I doubt that patch fixed it. You can do a regression test to find the patch that fixed it if you want, but last I tried to look for a fix I had to revert the sense of good and bad > Mirek > > Stefan D?singer napsal(a): > > ------------------------------------------------------------------------ > > > > From c59f7c4eea148cfb9a1321bbbbc587ef52194bc9 Mon Sep 17 00:00:00 2001 > > From: Stefan Doesinger > > Date: Fri, 2 Feb 2007 15:30:34 +0100 > > Subject: [PATCH] WineD3D: Properly release the converted vertex > > declaration > > > > --- > > dlls/d3d9/d3d9_private.h | 5 +++++ > > dlls/d3d9/device.c | 3 +++ > > dlls/d3d9/vertexdeclaration.c | 5 +++++ > > 3 files changed, 13 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > > index 435a37e..972945d 100644 > > --- a/dlls/d3d9/d3d9_private.h > > +++ b/dlls/d3d9/d3d9_private.h > > @@ -179,6 +179,11 @@ typedef struct IDirect3DDevice9Impl > > /* Avoids recursion with nested ReleaseRef to 0 */ > > BOOL inDestruction; > > > > + /* A vertex declaration was converted from setFVF. > > + * Keep track of it, so it can be properly freed > > + */ > > + IDirect3DVertexDeclaration9 *convertedDecl; > > + > > } IDirect3DDevice9Impl; > > > > > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > > index 4eff550..e6ecd96 100644 > > --- a/dlls/d3d9/device.c > > +++ b/dlls/d3d9/device.c > > @@ -62,6 +62,8 @@ static ULONG WINAPI > > IDirect3DDevice9Impl_Release(LPDIRECT3DDEVICE9 iface) { > > > > if (ref == 0) { > > This->inDestruction = TRUE; > > + if (This->convertedDecl != NULL) > > + IUnknown_Release(This->convertedDecl); > > IWineD3DDevice_Uninit3D(This->WineD3DDevice, > > D3D9CB_DestroyDepthStencilSurface, D3D9CB_DestroySwapChain); > > IWineD3DDevice_Release(This->WineD3DDevice); > > HeapFree(GetProcessHeap(), 0, This); > > @@ -766,6 +768,7 @@ HRESULT WINAPI > > IDirect3DDevice9Impl_SetFVF(LPDIRECT3DDEVICE9 iface, DWORD FVF) > > > > hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); > > if (hr != S_OK) goto exit; > > + This->convertedDecl = pDecl; > > pDecl = NULL; > > > > exit: > > diff --git a/dlls/d3d9/vertexdeclaration.c > > b/dlls/d3d9/vertexdeclaration.c index a7f5486..c3f462e 100644 > > --- a/dlls/d3d9/vertexdeclaration.c > > +++ b/dlls/d3d9/vertexdeclaration.c > > @@ -360,6 +360,11 @@ HRESULT WINAPI > > IDirect3DDevice9Impl_SetVertexDeclaration(LPDIRECT3DDEVICE9 ifa > > > > TRACE("(%p) : Relay\n", iface); > > > > + if (This->convertedDecl && This->convertedDecl != pDecl) { > > + IUnknown_Release(This->convertedDecl); > > + This->convertedDecl = NULL; > > + } > > + > > hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, > > pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); > > > > return hr; > > > > > > ------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070214/bb0a6be0/attachment.pgp From xerox_xerox2000 at yahoo.co.uk Wed Feb 14 14:51:15 2007 From: xerox_xerox2000 at yahoo.co.uk (Louis Lenders) Date: Wed Feb 14 14:51:57 2007 Subject: AppDB performance issue References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> Message-ID: Bryan Haskins gmail.com> writes: > > > I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. > For your info, Appdb, is complete unusable for me ... Loading a page, or adding a test result to an application takes several minutes. Please fix, as this is really annoying :( From thunder.m at czela.net Wed Feb 14 16:05:17 2007 From: thunder.m at czela.net (Mirek) Date: Wed Feb 14 16:05:52 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: <915194.91418.qm@web26008.mail.ukl.yahoo.com> References: <915194.91418.qm@web26008.mail.ukl.yahoo.com> Message-ID: <45D3879D.8050506@czela.net> Luke Bratch napsal(a): >> Wow, great work!!!!! 3DMark 2006 with fbo looks > realy coool!! And some >> Nvidia SDK demos are completly fixed! > > How did you test 3DMark2006? When I try and run it, > it tells me I need Pixel Shader 2.0 support. > > I have UseGLSL set to enabled and OffscreenRenderMode > set to fbo, and the Pixel Shader 2 test in 3DMark03 > works fine. Yes, but after accept this error message i can select some test and run benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 and GT2 tests are almost perfect, but very slow (fbo is slower than backbuffer, so I am not using it in other applications), you should also disable post procesing (very very slow) in 3DMark. Here are some screenshots with latest wine and latest Stefan patches: http://62.240.181.87/Mirek/3DMark2006/ PS: I have GF 6800GS, Core 2 Duo X6800@3700MHz and about 2 FPS, but it works! :) Mirek From xixsimplicityxix at gmail.com Wed Feb 14 16:35:29 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Wed Feb 14 16:35:40 2007 Subject: AppDB performance issue In-Reply-To: References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> Message-ID: <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> Humm very strange it works well for me, I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on windows 2000, on gentoo x86 with firefox 2.0.0.1, and on gentoo amd64 firefox 2.0.0.1. I added, then removed, then edited a test result. Speed seemed normal. Hope this helps the investigation. Regards, John Klehm On 2/14/07, Louis Lenders wrote: > > Bryan Haskins gmail.com> writes: > > > > > > > I was just replying, and reading now, no slow down at all. It loads a > little > slow running through all that text, but no where near the minutes everyone > says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading a page, or > adding a test result to an application takes several minutes. Please fix, > as > this is really annoying :( > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070214/0ba6c23f/attachment.htm From nathan.andrew.williams at gmail.com Wed Feb 14 16:51:17 2007 From: nathan.andrew.williams at gmail.com (Nathan Williams) Date: Wed Feb 14 16:51:34 2007 Subject: Direct Draw "palette_convert" Message-ID: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> I'm working on some direct draw code to get Carmageddon working. I think I have found my issue in IWineD3DPaletteImpl_SetEntries Carmageddon runs in 8 bit mode, my x windows is set at 24bit. If I drop xorg to 8bit, wine refuses to load. If i set it to 16bit, the Carmageddon menus are still bad, but noticeably better then running in 24bit. In SetEntries there is a bit of code idef'd out: #if 0 /* Now, if we are in 'depth conversion mode', update the screen palette */ /* FIXME: we need to update the image or we won't get palette fading. */ if (This->ddraw->d->palette_convert != NULL) This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); #endif Uncommenting the above only leads to compile errors. Dredging through the wine archives, I see that the palette convert functions haven't been there since 2000. Can anyone give me an idea on why they were removed & what might be the best way to reimplement some form of palette conversion? (Even just in a hacky way right now, so i can test my assumptions) -- Nathan From wine.dev at web.de Wed Feb 14 17:12:35 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Wed Feb 14 17:13:15 2007 Subject: [cmd][try3] Update Russian translate (edited) [Really sorry!!] In-Reply-To: <45D2FD96.1050207@etersoft.ru> References: <45D2FD96.1050207@etersoft.ru> Message-ID: <1171494755.1753.9.camel@p4> On Mi, 2007-02-14 at 15:16 +0300, Anatoly Lyutin wrote: > - HELP <> .\n" > + HELP <> .\n\ > + DOS http://www.citforum.ru/operating_systems/msdos/\n" > } That link is wrong in wine. Please remove from your Patch -- By by ... Detlef From wine.dev at web.de Wed Feb 14 17:15:38 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Wed Feb 14 17:16:21 2007 Subject: [Janitorial] snmpapi: Remove the last-but-one %ll printf format In-Reply-To: References: Message-ID: <1171494938.1753.11.camel@p4> On Mi, 2007-02-14 at 15:27 -0200, Pedro Araujo Chaves Jr. wrote: > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", > wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > return; Did you mean "%s" ? (used "%su") -- By by ... Detlef From richardvoigt at gmail.com Wed Feb 14 21:46:37 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Wed Feb 14 21:46:43 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <22821af30702122046h5d8844a2y4354c1adaf112342@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> <22821af30702122046h5d8844a2y4354c1adaf112342@mail.gmail.com> Message-ID: <2e59e6970702141946h6cf1c8cbu581ff007cb54de8f@mail.gmail.com> On 2/12/07, James Hawkins wrote: > On 2/12/07, richardvoigt@gmail.com wrote: > > > > You advocated that wine aim for working exactly like Windows, no less > > and no more, rather than deviating in user-configurable ways to > > enhance the user's control over his own system. > > > > Right. That's the purpose of Wine. You'd know that if you were a > developer on this project. You'll get there a lot faster by contributing to colinux (www.colinux.org) instead. > > > Maybe while we're at > > it, wine should have the bug which allows certain software to prevent > > screen grabs. > > > > I don't know of any apps that depend on this behavior, so that's not > likely to happen. Any DRM-enabled media player... which you would have understood if you looked at my next comment! > > > No, I think defeating DRM to enable fair use is > > perfectly reasonable, and there are some bugs which should be fixed. > > Should wine try to patch remote exploits at the exact same rate as > > windowsupdate.com? > > > > Since we have completely different code bases, I don't see how we can > fix their code in our tree. You misunderstood me completely, I'm beginning to wonder if you're doing so intentionally. To maintain "bug for bug compatibility", then when an exploit is discovered, wine won't be able to release a patch until after Microsoft has done so, because to do so earlier would be to implement functionality that doesn't match WIndows, breaking compatibility. > > > That would be also be required for true > > bug-for-bug compatibility. After all, someone properly authorized > > might be using that backdoor to reboot their webfarm remotely -- not! > > > > There are things that are wrong in a theoretical sense (i.e. the > > Pentium floating-point bug), or misclassification of Unicode > > characters, which some programs might reasonably depend on. And then > > there are things that are wrong from a practical engineering > > perspective, like software taking away the user's choice to not run > > it, which the mere fact that a program depends on it makes it malware. > > > > Are you a software engineer? From a practical engineering > perspective, adding this option adds unnecessary complication to the > code base and increases the chances for bugs. This is exactly what I consider this sort of thing quite necessary, I would implement that function on Windows if it was possible without totally replacing all the security code (processing of Start menu/Programs/Startup and HKLM/Software/.../Run can be turned off, but group policy start items can't be disabled in any way that I'm aware of). > UAC does, and no competent engineer thinks UAC is a good thing, or > that it adds any amount of security. This "malware" that you're so UAC does add security, but the interface is horrid. It's really the same idea as Linux's don't-login-as-root, except that with linux you don't necessarily have to use sudo and type a password for every process you want to run elevated, there's suid, sudo remembers your credentials for a short while, you can open an elevated shell, etc. I think UAC has some of the same capability between signed manifests in place of suid and you can probably run an elevated shell there as well. > afraid of can just write over that registry entry. > I don't run Vista, but my understanding is that you can't permanently approve a particular program to run elevated, the question reappears every single time. Giving the user a per-program "Remember my answer" option improves the user experience so much it's not even comparable. And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API. > If this entry defaults to "Always" or "Never", then the users won't > even know that the option exists, and that's one more piece of > information that we'll have to broadcast and answer questions about. So the best thing would be to set "Ask" as the installation default, and in addition to the "Yes/No/Always/Never" buttons on the prompt, provide a link to the winecfg page where the default is configured. > > > Reduced privileges do little or nothing to prevent network abuse (open > > spam relay and the like). > > > > If you're running executables that are going to add themselves to > AutoStart, the fact that they might run again is the least of your > concerns. While I agree 100%, stopping the malware from running itself after a reboot is still a very good thing. How useful would chroot be if the chrooted programs could set up autostart items or cron jobs without the admin's approval? Not nearly as much as it is now. From dmitry at codeweavers.com Wed Feb 14 23:09:49 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Wed Feb 14 23:09:53 2007 Subject: [cmd][try3] Update Russian translate (edited) [Really sorry!!] References: <45D2FD96.1050207@etersoft.ru> <1171494755.1753.9.camel@p4> Message-ID: <014601c750bf$8e2bcfc0$0100a8c0@DMITRY> ----- Original Message ----- From: "Detlef Riekenberg" To: Sent: Thursday, February 15, 2007 7:12 AM Subject: Re: [cmd][try3] Update Russian translate (edited) [Really sorry!!] > On Mi, 2007-02-14 at 15:16 +0300, Anatoly Lyutin wrote: >> - HELP <> .\n" >> + HELP <> .\n\ >> + DOS http://www.citforum.ru/operating_systems/msdos/\n" >> } > > > That link is wrong in wine. Please remove from your Patch Moreover it doesn't match an original english wording in En.rc: "Enter HELP for further information on any of the above commands\n" -- Dmitry. From flexo at holycrap.org Thu Feb 15 00:06:17 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 14 23:59:27 2007 Subject: wineboot: Start items in StartUp folder on boot, includes security measures. In-Reply-To: <2e59e6970702141946h6cf1c8cbu581ff007cb54de8f@mail.gmail.com> References: <1171229662.9224.10.camel@misha-laptop> <2e59e6970702111849h5330f92dm68445054e87a6b7e@mail.gmail.com> <22821af30702120833w148ccca6rd5579119a56bf018@mail.gmail.com> <2e59e6970702121802u9443e0cme8b70e21c48ca3b8@mail.gmail.com> <22821af30702122046h5d8844a2y4354c1adaf112342@mail.gmail.com> <2e59e6970702141946h6cf1c8cbu581ff007cb54de8f@mail.gmail.com> Message-ID: <45D3F859.5020502@holycrap.org> richardvoigt@gmail.com wrote: > And I have never advocated for putting this in the registry, my > suggestion has always been to store these settings in a file outside > the .wine/drive_c jail area that is accessbile via wine's Win32 API. Wine is *not* a sandbox. Any .exe run can make use of native (Linux) syscalls as it wants. Felix From patrol at sinus.cz Thu Feb 15 00:00:09 2007 From: patrol at sinus.cz (Pavel Troller) Date: Thu Feb 15 00:00:22 2007 Subject: Regression in comctl32 Message-ID: <20070215060009.GA7730@tangens.sinus.cz> Hi! I just found a regression in comctl32 and bisected it successfully. The following commit 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit commit 369749dcb2ba12ce8481503543afd18ad99805d1 Author: Dmitry Timoshkov Date: Mon Feb 12 16:47:56 2007 +0800 comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls causes that IDA Pro shows black squares instead of its toolbar icons. With regards, Pavel Troller From thunder.m at czela.net Thu Feb 15 01:44:36 2007 From: thunder.m at czela.net (Mirek) Date: Thu Feb 15 01:44:39 2007 Subject: [07/10] wined3d: Add WINED3DPBLENDCAPS flags and use them In-Reply-To: References: Message-ID: <45D40F64.3070901@czela.net> Hi, this patch has bad attachment, it has same attachment as "[08/10] wined3d: Add WINED3DPMISCCAPS flags and use them". Mirek Slugen H. Verbeet napsal(a): > Changelog: > - Add WINED3DPBLENDCAPS flags and use them > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/directx.c | 34 +++++++++++++++++----------------- > include/wine/wined3d_caps.h | 19 +++++++++++++++++++ > 2 files changed, 36 insertions(+), 17 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 1753ef9..cc1e0f6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1872,29 +1872,29 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINED3DDEVCAPS_DRAWPRIMITIVES2 | > WINED3DDEVCAPS_DRAWPRIMITIVES2EX; > > - *pCaps->PrimitiveMiscCaps = D3DPMISCCAPS_CULLNONE | > - D3DPMISCCAPS_CULLCCW | > - D3DPMISCCAPS_CULLCW | > - D3DPMISCCAPS_COLORWRITEENABLE | > - D3DPMISCCAPS_CLIPTLVERTS | > - D3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > - D3DPMISCCAPS_MASKZ | > - D3DPMISCCAPS_BLENDOP; > + *pCaps->PrimitiveMiscCaps = WINED3DPMISCCAPS_CULLNONE | > + WINED3DPMISCCAPS_CULLCCW | > + WINED3DPMISCCAPS_CULLCW | > + WINED3DPMISCCAPS_COLORWRITEENABLE | > + WINED3DPMISCCAPS_CLIPTLVERTS | > + WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > + WINED3DPMISCCAPS_MASKZ | > + WINED3DPMISCCAPS_BLENDOP; > /* TODO: > - D3DPMISCCAPS_NULLREFERENCE > - D3DPMISCCAPS_INDEPENDENTWRITEMASKS > - D3DPMISCCAPS_FOGANDSPECULARALPHA > - D3DPMISCCAPS_SEPARATEALPHABLEND > - D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > - D3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > - D3DPMISCCAPS_FOGVERTEXCLAMPED */ > + WINED3DPMISCCAPS_NULLREFERENCE > + WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS > + WINED3DPMISCCAPS_FOGANDSPECULARALPHA > + WINED3DPMISCCAPS_SEPARATEALPHABLEND > + WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > + WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > + WINED3DPMISCCAPS_FOGVERTEXCLAMPED */ > > /* The caps below can be supported but aren't handled yet in utils.c 'd3dta_to_combiner_input', disable them until support is fixed */ > #if 0 > if (GL_SUPPORT(NV_REGISTER_COMBINERS)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_TSSARGTEMP; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_TSSARGTEMP; > if (GL_SUPPORT(NV_REGISTER_COMBINERS2)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_PERSTAGECONSTANT; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_PERSTAGECONSTANT; > #endif > > *pCaps->RasterCaps = WINED3DPRASTERCAPS_DITHER | > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > index 1cedae7..98a655d 100644 > --- a/include/wine/wined3d_caps.h > +++ b/include/wine/wined3d_caps.h > @@ -34,6 +34,25 @@ > #define WINED3DPBLENDCAPS_BOTHINVSRCALPHA 0x00001000 > #define WINED3DPBLENDCAPS_BLENDFACTOR 0x00002000 > > +#define WINED3DPMISCCAPS_MASKZ 0x00000002 > +#define WINED3DPMISCCAPS_LINEPATTERNREP 0x00000004 > +#define WINED3DPMISCCAPS_CULLNONE 0x00000010 > +#define WINED3DPMISCCAPS_CULLCW 0x00000020 > +#define WINED3DPMISCCAPS_CULLCCW 0x00000040 > +#define WINED3DPMISCCAPS_COLORWRITEENABLE 0x00000080 > +#define WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS 0x00000100 > +#define WINED3DPMISCCAPS_CLIPTLVERTS 0x00000200 > +#define WINED3DPMISCCAPS_TSSARGTEMP 0x00000400 > +#define WINED3DPMISCCAPS_BLENDOP 0x00000800 > +#define WINED3DPMISCCAPS_NULLREFERENCE 0x00001000 > +#define WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS 0x00004000 > +#define WINED3DPMISCCAPS_PERSTAGECONSTANT 0x00008000 > +#define WINED3DPMISCCAPS_FOGANDSPECULARALPHA 0x00010000 > +#define WINED3DPMISCCAPS_SEPARATEALPHABLEND 0x00020000 > +#define WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS 0x00040000 > +#define WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING 0x00080000 > +#define WINED3DPMISCCAPS_FOGVERTEXCLAMPED 0x00100000 > + > #define WINED3DSTENCILCAPS_KEEP 0x00000001 > #define WINED3DSTENCILCAPS_ZERO 0x00000002 > #define WINED3DSTENCILCAPS_REPLACE 0x00000004 > > > ------------------------------------------------------------------------ > > From thunderbird2k at gmx.net Thu Feb 15 01:52:06 2007 From: thunderbird2k at gmx.net (Roderick Colenbrander) Date: Thu Feb 15 01:52:47 2007 Subject: Direct Draw "palette_convert" In-Reply-To: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> References: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> Message-ID: <20070215075206.159880@gmx.net> Use this patch which I made a while ago. I still need to fix some things in it but it handles the conversion using fragment shaders. You need to set the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I hope to clean it up soon. Roderick > I'm working on some direct draw code to get Carmageddon working. > > I think I have found my issue in IWineD3DPaletteImpl_SetEntries > > Carmageddon runs in 8 bit mode, my x windows is set at 24bit. > > If I drop xorg to 8bit, wine refuses to load. > If i set it to 16bit, the Carmageddon menus are still bad, but > noticeably better then running in 24bit. > > In SetEntries there is a bit of code idef'd out: > > #if 0 > /* Now, if we are in 'depth conversion mode', update the screen > palette */ > /* FIXME: we need to update the image or we won't get palette fading. > */ > if (This->ddraw->d->palette_convert != NULL) > > This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); > #endif > > Uncommenting the above only leads to compile errors. > Dredging through the wine archives, I see that the palette convert > functions haven't been there since 2000. > > Can anyone give me an idea on why they were removed & what might be > the best way to reimplement some form of palette conversion? > (Even just in a hacky way right now, so i can test my assumptions) > > -- > Nathan > -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out From dmitry at codeweavers.com Thu Feb 15 02:10:50 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Thu Feb 15 02:10:54 2007 Subject: Regression in comctl32 References: <20070215060009.GA7730@tangens.sinus.cz> Message-ID: <002e01c750d8$dabb8970$0100a8c0@DMITRY> "Pavel Troller" wrote: > I just found a regression in comctl32 and bisected it successfully. > The following commit > > 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit > commit 369749dcb2ba12ce8481503543afd18ad99805d1 > Author: Dmitry Timoshkov > Date: Mon Feb 12 16:47:56 2007 +0800 > > comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. > > :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls > > causes that IDA Pro shows black squares instead of its toolbar icons. The regrssion was reported already and the the bug #7405 tracks its status. I'm working on it. -- Dmitry. From stefan at codeweavers.com Thu Feb 15 03:18:25 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 15 03:18:29 2007 Subject: Direct Draw "palette_convert" In-Reply-To: <20070215075206.159880@gmx.net> References: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> <20070215075206.159880@gmx.net> Message-ID: <200702151018.30629.stefan@codeweavers.com> Am Donnerstag 15 Februar 2007 08:52 schrieb Roderick Colenbrander: > Use this patch which I made a while ago. I still need to fix some things in > it but it handles the conversion using fragment shaders. You need to set > the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I > hope to clean it up soon. Forgot the patch? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070215/13ed4604/attachment-0001.pgp From stefan at codeweavers.com Thu Feb 15 03:21:42 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 15 03:21:49 2007 Subject: [10/10] DDraw: Forward D3DRS_TEXTUREADDRESS* and D3DTSS_ADDRESS* to sampler states In-Reply-To: References: <200702150305.06308.stefan@codeweavers.com> Message-ID: <200702151021.47302.stefan@codeweavers.com> Am Donnerstag 15 Februar 2007 09:51 schrieb H. Verbeet: > On 15/02/07, Stefan D?singer wrote: > >+ case D3DTSS_ADDRESS: > >+ return IWineD3DDevice_GetSamplerState(This->wineD3DDevice, > >+ Stage, > >+ WINED3DSAMP_ADDRESSW, > >+ State); > > Is that correct? Hm. No, it isn't. I thought I fixed that sort of things. Maybe an old version of the patch got sent NULL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070215/c06c1075/attachment.pgp From stefan at codeweavers.com Thu Feb 15 03:24:34 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 15 03:24:34 2007 Subject: [4/10] WineD3D: Convert and load U8V8 surfaces as rgb In-Reply-To: References: <200702150301.45239.stefan@codeweavers.com> Message-ID: <200702151024.35659.stefan@codeweavers.com> Am Donnerstag 15 Februar 2007 09:50 schrieb H. Verbeet: > On 15/02/07, Stefan D?singer wrote: > > GL_INDEX is definitly not the way to load U8V8 surfaces > > I think you should be using something like GL_DU8DV8_ATI or GL_DSDT_NV > instead. Thats my plan, but I think we should handle it in some way if none of the extensions is available. We can later use the extension-specific formats if they are available. From julliard at winehq.org Thu Feb 15 04:19:11 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Thu Feb 15 04:19:21 2007 Subject: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them In-Reply-To: (H. Verbeet's message of "Wed\, 14 Feb 2007 23\:30\:46 +0100") References: Message-ID: <87ire37mg0.fsf@wine.dyndns.org> "H. Verbeet" writes: > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > new file mode 100644 > index 0000000..4bf474b > --- /dev/null > +++ b/include/wine/wined3d_caps.h > @@ -0,0 +1,49 @@ > +/* > + * Copyright 2007 Henri Verbeet > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#ifndef __WINE_WINED3D_CAPS_H > +#define __WINE_WINED3D_CAPS_H > + > +#define WINED3DTEXOPCAPS_DISABLE 0x00000001 > +#define WINED3DTEXOPCAPS_SELECTARG1 0x00000002 > +#define WINED3DTEXOPCAPS_SELECTARG2 0x00000004 > +#define WINED3DTEXOPCAPS_MODULATE 0x00000008 > +#define WINED3DTEXOPCAPS_MODULATE2X 0x00000010 > +#define WINED3DTEXOPCAPS_MODULATE4X 0x00000020 > +#define WINED3DTEXOPCAPS_ADD 0x00000040 > +#define WINED3DTEXOPCAPS_ADDSIGNED 0x00000080 > +#define WINED3DTEXOPCAPS_ADDSIGNED2X 0x00000100 > +#define WINED3DTEXOPCAPS_SUBTRACT 0x00000200 > +#define WINED3DTEXOPCAPS_ADDSMOOTH 0x00000400 > +#define WINED3DTEXOPCAPS_BLENDDIFFUSEALPHA 0x00000800 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHA 0x00001000 > +#define WINED3DTEXOPCAPS_BLENDFACTORALPHA 0x00002000 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHAPM 0x00004000 > +#define WINED3DTEXOPCAPS_BLENDCURRENTALPHA 0x00008000 > +#define WINED3DTEXOPCAPS_PREMODULATE 0x00010000 > +#define WINED3DTEXOPCAPS_MODULATEALPHA_ADDCOLOR 0x00020000 > +#define WINED3DTEXOPCAPS_MODULATECOLOR_ADDALPHA 0x00040000 > +#define WINED3DTEXOPCAPS_MODULATEINVALPHA_ADDCOLOR 0x00080000 > +#define WINED3DTEXOPCAPS_MODULATEINVCOLOR_ADDALPHA 0x00100000 > +#define WINED3DTEXOPCAPS_BUMPENVMAP 0x00200000 > +#define WINED3DTEXOPCAPS_BUMPENVMAPLUMINANCE 0x00400000 > +#define WINED3DTEXOPCAPS_DOTPRODUCT3 0x00800000 > +#define WINED3DTEXOPCAPS_MULTIPLYADD 0x01000000 > +#define WINED3DTEXOPCAPS_LERP 0x02000000 > + > +#endif /* __WINE_WINED3D_CAPS_H */ I think this could just as well go into an existing file like wined3d_types.h. We should try to keep the number of Wine-specific global includes to a minimum. -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Thu Feb 15 04:38:09 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Thu Feb 15 04:38:11 2007 Subject: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them In-Reply-To: <87ire37mg0.fsf@wine.dyndns.org> References: <87ire37mg0.fsf@wine.dyndns.org> Message-ID: On 15/02/07, Alexandre Julliard wrote: > I think this could just as well go into an existing file like > wined3d_types.h. It could, but the idea was to keep things similar to d3d8 and d3d9 where the corresponding defines are in d3d8caps.h and d3d9caps.h From julliard at winehq.org Thu Feb 15 04:43:04 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Thu Feb 15 04:43:11 2007 Subject: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them In-Reply-To: (H. Verbeet's message of "Thu\, 15 Feb 2007 11\:38\:09 +0100") References: <87ire37mg0.fsf@wine.dyndns.org> Message-ID: <87ejor7lc7.fsf@wine.dyndns.org> "H. Verbeet" writes: > On 15/02/07, Alexandre Julliard wrote: >> I think this could just as well go into an existing file like >> wined3d_types.h. > It could, but the idea was to keep things similar to d3d8 and d3d9 > where the corresponding defines are in d3d8caps.h and d3d9caps.h OK, that makes sense. -- Alexandre Julliard julliard@winehq.org From nathan.andrew.williams at gmail.com Thu Feb 15 05:48:48 2007 From: nathan.andrew.williams at gmail.com (Nathan Williams) Date: Thu Feb 15 05:48:58 2007 Subject: Direct Draw "palette_convert" In-Reply-To: <200702151018.30629.stefan@codeweavers.com> References: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> <20070215075206.159880@gmx.net> <200702151018.30629.stefan@codeweavers.com> Message-ID: <5989a080702150348w7043490buddf6d102c14c671@mail.gmail.com> Google to the rescue! (I googled Roderick's name, i was lead right to the patches!) http://www.kernel-traffic.org/wine/wn20051211_301.html#2 I believe this is the patch he was talking about, I'll give it a try in the morning & see how it goes. On 2/15/07, Stefan D?singer wrote: > Am Donnerstag 15 Februar 2007 08:52 schrieb Roderick Colenbrander: > > Use this patch which I made a while ago. I still need to fix some things in > > it but it handles the conversion using fragment shaders. You need to set > > the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I > > hope to clean it up soon. > Forgot the patch? > > -- Nathan From joris_huizer at yahoo.com Thu Feb 15 06:04:06 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Thu Feb 15 06:04:44 2007 Subject: avifil32: sign-compare fixes Message-ID: <172032.9827.qm@web52713.mail.yahoo.com> Hello As the previous time I was inserting too many casts, I want to ask whether this approach is better (introducing an ULONG version if it fixes compare warnings, and casting away remaining problems) If this is not alright, could you tell what's the best way to fix? regards, Joris ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-avifil32-sign-compare-fixes.txt Type: text/x-patch Size: 2464 bytes Desc: 2845674572-0008-avifil32-sign-compare-fixes.txt Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070215/13c4c85f/0008-avifil32-sign-compare-fixes.bin From hverbeet at gmail.com Thu Feb 15 06:05:02 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Thu Feb 15 06:05:15 2007 Subject: Direct Draw "palette_convert" In-Reply-To: <5989a080702150348w7043490buddf6d102c14c671@mail.gmail.com> References: <5989a080702141451i1202de52je0de84a3302c100@mail.gmail.com> <20070215075206.159880@gmx.net> <200702151018.30629.stefan@codeweavers.com> <5989a080702150348w7043490buddf6d102c14c671@mail.gmail.com> Message-ID: On 15/02/07, Nathan Williams wrote: > Google to the rescue! (I googled Roderick's name, i was lead right to > the patches!) > http://www.kernel-traffic.org/wine/wn20051211_301.html#2 > > I believe this is the patch he was talking about, I'll give it a try > in the morning & see how it goes. > I think there was a more recent version of those patches, I'm not sure if the ones linked there still apply. From wine.dev at web.de Thu Feb 15 07:59:00 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Thu Feb 15 08:02:20 2007 Subject: WINSPOOL: search for a printer driver In-Reply-To: <200702141751.11462.lav@etersoft.ru> References: <200702141751.11462.lav@etersoft.ru> Message-ID: <1171547940.6922.9.camel@p4> On Mi, 2007-02-14 at 17:51 +0300, Vitaly Lipatov wrote: > When wine is loading, CUPS_LoadPrinters function get printer list from CUPS > and add printer and their printer drivers to registry. > Note, we place printer driver in "Windows 4.0" registry entry if Wine version > is win9x and use "Windows NT x86" registry entry if Wine version is win2000 > and above. > > If we will change wine version after printer loaded, Wine printing is got > failed. Wine search in empty registry entry. Thanks for mention this. Just a short first note: There is a move/update for that Area in progress, but that needs a working "IniFileMapping" first. (Away for some days.) -- By by ... Detlef From dmitry at codeweavers.com Thu Feb 15 08:42:01 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Thu Feb 15 08:41:44 2007 Subject: gdi32: Symbol encoding should be always selectable References: Message-ID: <005501c7510f$78d3e360$0100a8c0@DMITRY> "Dmitry Timoshkov" wrote: > this patch fixes a failure in the font charset test in the case when > only Arial is installed. As the test shows the symbol encoding should be > always selectable. Please do not commit this patch, it's wrong. According to GetTextFace XP selects Wingdings if SYMBOL_CHARSET was requested. I'm not sure how to make the test pass: probably SYMBOL_CHARSET should be skipped if Symbol or Wingdings are not installed. -- Dmitry. From mike at plan99.net Thu Feb 15 10:02:28 2007 From: mike at plan99.net (Mike Hearn) Date: Thu Feb 15 10:02:31 2007 Subject: Wine and menu integration In-Reply-To: <45D4230D.8010606@ols.es> References: <45D4230D.8010606@ols.es> Message-ID: Hi David, Sounds great! To submit those files, you need to make a patch ... git can do this but I don't remember the exact command to use (depends on your setup also). Or you can do it the old fashioned way using diff directly. Feel free to ask if you'd like more guidance with this. Once you have a patch, email it to wine-patches@winehq.org so Alexandre and the others can review it, suggest improvements etc. Good luck! On 2/15/07, David Saez Padros wrote: > Hi !! > > I saw your post at http://wiki.winehq.org/GnomeMenusIntegration > and i made some freedesktop compliant files which: > > - add a global Wine menu item in the Aplications menu (seen > by all users) with WineFile and WineMine, which also merge > all user specific wine installed programs. > > - add a global menu item for winecfg in System -> Preferences > (seen by all users) > > I also have what should be add to installation so .exe files > are executed with wine when double-clicked (tested in ubuntu) > > How could i submit those files ?? I cannot din anything > related to this in the bugzilla :( > > -- > Best regards ... > > I am Homer of Borg. Prepare to be assim... mmmm, donuts. > > ---------------------------------------------------------------- > David Saez Padros http://www.ols.es > On-Line Services 2000 S.L. e-mail david@ols.es > Pintor Vayreda 1 telf +34 902 50 29 75 > 08184 Palau-Solita i Plegamans movil +34 670 35 27 53 > ---------------------------------------------------------------- > > > From julliard at winehq.org Thu Feb 15 11:45:13 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Thu Feb 15 11:45:15 2007 Subject: [PATCH 6/6] kernel32: Fix the GetComputerName* functions to not write to the buffer at all if there is not enough space. In-Reply-To: <45D48A04.2090101@codeweavers.com> (Robert Shearman's message of "Thu\, 15 Feb 2007 16\:27\:48 +0000") References: <45D48A04.2090101@codeweavers.com> Message-ID: <878xez71sm.fsf@wine.dyndns.org> Robert Shearman writes: > Remove the exception handlers, since testing on XP SP2 shows that > access violations are not caught. Yes, but they are caught on Win9x, and the handler was added because an app needed it. I'd suggest to keep it at least in the A function. -- Alexandre Julliard julliard@winehq.org From juan_lang at yahoo.com Thu Feb 15 12:13:07 2007 From: juan_lang at yahoo.com (Juan Lang) Date: Thu Feb 15 12:13:48 2007 Subject: [7/10] WineD3D: Test for supported queries Message-ID: <115115.30204.qm@web39703.mail.mud.yahoo.com> Hi Stefan, + hr = IDirect3D9_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, + D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pDevice ); + ok(SUCCEEDED(hr), "Failed to create IDirect3D9Device (%s)\n", DXGetErrorString9(hr)); + if (FAILED(hr)) goto cleanup; (snip) + cleanup: + if(pDevice) IDirect3DDevice9_Release(pDevice); The label cleanup isn't used anywhere except in the failure to create the device. In this case, wouldn't: if (FAILED(hr)) return; be clearer, and omit the unneeded label? There's no reason to release pDevice in creating it failed. --Juan ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From l_bratch at yahoo.co.uk Wed Feb 14 15:20:59 2007 From: l_bratch at yahoo.co.uk (Luke Bratch) Date: Thu Feb 15 12:13:52 2007 Subject: [1/10] - [10/10] WineD3D Message-ID: <915194.91418.qm@web26008.mail.ukl.yahoo.com> > Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some > Nvidia SDK demos are completly fixed! How did you test 3DMark2006? When I try and run it, it tells me I need Pixel Shader 2.0 support. I have UseGLSL set to enabled and OffscreenRenderMode set to fbo, and the Pixel Shader 2 test in 3DMark03 works fine. ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk From pgr at arcelectronicsinc.com Thu Feb 15 01:14:00 2007 From: pgr at arcelectronicsinc.com (Paul Romanyszyn) Date: Thu Feb 15 12:13:53 2007 Subject: Regression in comctl32 In-Reply-To: <20070215060009.GA7730@tangens.sinus.cz> References: <20070215060009.GA7730@tangens.sinus.cz> Message-ID: Pavel Troller wrote: > Hi! > I just found a regression in comctl32 and bisected it successfully. > The following commit > > 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit > commit 369749dcb2ba12ce8481503543afd18ad99805d1 > Author: Dmitry Timoshkov > Date: Mon Feb 12 16:47:56 2007 +0800 > > comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. > > :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls > > causes that IDA Pro shows black squares instead of its toolbar icons. > > With regards, Pavel Troller > > > See bug 7405 for 2 additional programs. > http://bugs.winehq.org/show_bug.cgi?id=7405 Paul R. From workingonwise at gmail.com Thu Feb 15 11:43:12 2007 From: workingonwise at gmail.com (Keith H. Pratt) Date: Thu Feb 15 12:13:54 2007 Subject: Office 2007 help wine Message-ID: <1171561392.29999.10.camel@lordkeiden-lappy> Hi, I went to a Microsoft Launch for their enterprise and business products this past tuesday, and they gave me a full version of Office 2007 Professional. Nice of them huh. Well, I am a linux user, and an avid evangelist for open source, and for anything that lets thw linux and windows world work together. I also have spent a considerable amount of time testing and bug reporting beta software. With all that said, here's my point. What can I do with this software to help you in the testing and development of wine? I run a dual-boot system with winxp and ubuntu linux. linux is where i work, and windows is there to make it easier to support my clients in their windows machines. If theres nothing now that applies to wine and office 2007, maybe keep this message for when the need does arise. Thanks Keith From rob at codeweavers.com Thu Feb 15 12:35:19 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 15 12:36:09 2007 Subject: Office 2007 help wine In-Reply-To: <1171561392.29999.10.camel@lordkeiden-lappy> References: <1171561392.29999.10.camel@lordkeiden-lappy> Message-ID: <45D4A7E7.3020906@codeweavers.com> Keith H. Pratt wrote: > Hi, > I went to a Microsoft Launch for their enterprise and business products > this past tuesday, and they gave me a full version of Office 2007 > Professional. Nice of them huh. Well, I am a linux user, and an avid > evangelist for open source, and for anything that lets thw linux and > windows world work together. I also have spent a considerable amount of > time testing and bug reporting beta software. > With all that said, here's my point. > What can I do with this software to help you in the testing and > development of wine? I run a dual-boot system with winxp and ubuntu > linux. linux is where i work, and windows is there to make it easier to > support my clients in their windows machines. > If theres nothing now that applies to wine and office 2007, maybe keep > this message for when the need does arise. Hi Keith, It would help if you could try to install it with Wine and report any problems that arise in bugzilla. If I can help you get past any issues, I will. -- Rob Shearman From fpga at pacbell.net Thu Feb 15 17:09:09 2007 From: fpga at pacbell.net (Duane Clark) Date: Thu Feb 15 17:10:08 2007 Subject: [1/4] wined3d: Fix WINED3DPRESENT_PARAMETERS and use it instead of D3DPRESENT_PARAMETERS In-Reply-To: References: Message-ID: <45D4E815.3000909@pacbell.net> H. Verbeet wrote: > It looks like the patch might be a bit large for the list, here's a > compressed version instead. > Anything over 80K just gets caught in the mail queue. It should get through eventually. From dimi at lattica.com Thu Feb 15 17:32:35 2007 From: dimi at lattica.com (Dimi Paun) Date: Thu Feb 15 17:33:38 2007 Subject: ANN: Wiki upgrade Message-ID: <3035.207.245.37.34.1171582355.squirrel@lattica.com> Folks, We finished upgrading the wiki to MoinMoin 1.5.7. Please let me know if you encounter any problems. -- Dimi Paun Lattica, Inc. From richardvoigt at gmail.com Thu Feb 15 18:11:14 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Thu Feb 15 18:11:26 2007 Subject: DIB Engine, some summarization In-Reply-To: References: <003901c74e29$d44955b0$4001a8c0@glis> <9e89675b0702112324qa40fa2es675ddf58bc11eb47@mail.gmail.com> <200702122110.50394.stefandoesinger@gmx.at> Message-ID: <2e59e6970702151611t212462a4jeda707da5b7327d6@mail.gmail.com> On 2/12/07, Daniel Remenak wrote: > On 2/12/07, Stefan D?singer wrote: > > Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > > > On 2/11/07, Damjan Jovanovic wrote: > > > > What about the case where you draw with GDI, then render with OpenGL > > > > on top of that, then draw on top of that with GDI, then swap buffers? > > > > If you draw only client-side, you have to copy to the server, then > > > > copy back, then copy to the server *again*. You have to upload or > > > > download the image *every time* you go between OpenGL and GDI drawing, > > > > whereas when you draw with X11, there is no uploads/downloads unless > > > > you use DIB sections and draw directly. > > > > > > Not that it's relevant to this conversation (since wine needs to > > > support legacy apps), but just so you know, even Microsoft no longer > > > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > > > and reading from the GDI buffer on a hardware-accelerated window, are > > > both undefined (officially "not supported") operations on Windows > > > Vista. Caused a ton of problems for my company's product > > > > So IDirect3DSurface9::GetDC does not work any longer? (Or > > IDirectDrawSurface7::GetDC) > > > > /me parties! > > > > > > Unfortunately, no; it looks like you can still render GDI onto a DX > surface, just not directly onto a window which is also being rendered > to by DX. > > >From the linked blog article: > "Note that there is an alternative that can often work for an > application -- DirectX is capable of handing back a DC to a DirectX > surface, and applications can perform GDI rendering to that DC. From > the DWM's perspective, that DirectX surface remains purely rendered by > DirectX, and all is well." > > --Daniel Remenak This sounds like a really simple way to support client-side and server-side drawing without the mixing that causes repeated network transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would all be done client-size, while IDirectWhatever::GetDC would return a device context that is strictly server-side. Does that seem reasonable? From scott at open-vote.org Thu Feb 15 21:48:24 2007 From: scott at open-vote.org (Scott Ritchie) Date: Thu Feb 15 21:46:56 2007 Subject: Wine and menu integration In-Reply-To: References: <45D4230D.8010606@ols.es> Message-ID: <1171597704.17168.84.camel@scott-desktop> > On 2/15/07, David Saez Padros wrote: > > I also have what should be add to installation so .exe files > > are executed with wine when double-clicked (tested in ubuntu) When did this break? I thought this worked in Ubuntu just fine. Thanks, Scott Ritchie From scott at open-vote.org Thu Feb 15 23:53:56 2007 From: scott at open-vote.org (Scott Ritchie) Date: Thu Feb 15 23:52:33 2007 Subject: We need a new version numbering scheme Message-ID: <1171605236.17168.94.camel@scott-desktop> On several occasions I have received emails referring to Wine version 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. Presumably, this version is being confused with Wine 0.9.30 in these letters, however I have been unable to tell whether people were ACTUALLY using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive way of chopping off the last 0. Either way, version numbers should be completely clear, and they're not currently. I'm not quite sure what to do at this point. Thanks, Scott Ritchie From research at science.su Fri Feb 16 01:03:07 2007 From: research at science.su (L. Rahyen) Date: Fri Feb 16 01:22:10 2007 Subject: We need a new version numbering scheme In-Reply-To: <1171605236.17168.94.camel@scott-desktop> References: <1171605236.17168.94.camel@scott-desktop> Message-ID: <200702160703.08878.research@science.su> Friday February 16 2007 05:53?Scott Ritchie ????????: > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie I think there is no problem. Most people do understand that 0.9.30 and 0.9.3 different things. Chopping off the last 0 isn't intuitive at all. This is the same as replacing amount of something with value of 10 times smaller: 3 apples instead of 30 for example! So my opinion that there is no problem at all. This is mostly problem of some people that don't understand simple things. I think it is very clear that if we have "0" in version number then it is important. And also - it actually have very intuitive meaning! BTW, 90% of versions doesn't contain zeros in the version number. From nemes.sorin at gmail.com Fri Feb 16 01:48:20 2007 From: nemes.sorin at gmail.com (SorinN) Date: Fri Feb 16 01:48:27 2007 Subject: We need a new version numbering scheme In-Reply-To: <1171605236.17168.94.camel@scott-desktop> References: <1171605236.17168.94.camel@scott-desktop> Message-ID: mr. Scott, I am a wine user for long time - I understand from start that actual system is not a decimal system - but a numbering one - so for me the difference between 0.9.3. and 0.9.30 is the difference between 3 and 30. If I presume correct, instead of changing numbering system - maybe is better to explain this system to users - somewhere on first page - first paragraph - on Wine HQ - and on Synaptic ( or other package managers where Details appear ). At least, it's true - the position of the last point on right can make this confusion - this point make the difference - so here is to be explained ( 0.9.3. < 0.9.30. ; 03.9.3.1 < 0.9.30.1 ...etc ). SorinN 2007/2/16, Scott Ritchie : > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie > > > > -- Nemes Ioan Sorin From marcus at jet.franken.de Fri Feb 16 02:02:34 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Fri Feb 16 02:02:39 2007 Subject: regression in 613998d4f6ff953a22a4455a28f77d2126642c7d Message-ID: <20070216080234.GA23825@galeere> Hi Shanren, your commit 613998d4f6ff953a22a4455a28f77d2126642c7d Author: Shanren Zhou Date: Mon Feb 12 19:53:51 2007 -0800 comctl32: Add header tests. generates a Coverity Warning in this code: ... HIMAGELIST hImageList; HIMAGELIST hImageListRetVal; hImageListRetVal = (HIMAGELIST) SendMessage(hWndHeader, HDM_SETIMAGELIST, 0, (LPARAM) &hImageList); HDM_SETIMAGELISTs parameter is used and stored, so hImageList should be: - initialized to something (likely 0 is ok, didnt check) - and not a pointer (did you add the & just to kill the warning?) Ciao, Marcus From scott at open-vote.org Fri Feb 16 04:27:18 2007 From: scott at open-vote.org (Scott Ritchie) Date: Fri Feb 16 04:25:43 2007 Subject: We need a new version numbering scheme In-Reply-To: References: <1171605236.17168.94.camel@scott-desktop> Message-ID: <1171621638.17168.99.camel@scott-desktop> On Fri, 2007-02-16 at 09:48 +0200, SorinN wrote: > If I presume correct, instead of changing numbering system - maybe is > better to explain this system to users - somewhere on first page - > first paragraph - on Wine HQ - and on Synaptic ( or other package > managers where Details appear ). > If we have to teach them, something is not obvious. And that's the source of the confusion - better to avoid it entirely. Thanks, Scott Ritchie From dmitry at codeweavers.com Fri Feb 16 04:39:09 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Fri Feb 16 04:39:15 2007 Subject: We need a new version numbering scheme References: <1171605236.17168.94.camel@scott-desktop> <1171621638.17168.99.camel@scott-desktop> Message-ID: <000801c751b6$b5e63850$0100a8c0@DMITRY> "Scott Ritchie" wrote: > On Fri, 2007-02-16 at 09:48 +0200, SorinN wrote: >> If I presume correct, instead of changing numbering system - maybe is >> better to explain this system to users - somewhere on first page - >> first paragraph - on Wine HQ - and on Synaptic ( or other package >> managers where Details appear ). >> > > If we have to teach them, something is not obvious. And that's the > source of the confusion - better to avoid it entirely. I'd say that if you have to explain something then something is wrong. How many open source projects versioning schemes do you know? Wine is using what is commonly accepted, we don't invent something new. -- Dmitry. From Andrew.Talbot at talbotville.com Fri Feb 16 09:11:20 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Fri Feb 16 09:11:49 2007 Subject: We need a new version numbering scheme References: <1171605236.17168.94.camel@scott-desktop> Message-ID: Scott Ritchie wrote: > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie The problem arises when version control programs sort the release "tags" alphanumerically, presenting them in the following order, since the digits are just treated as members of an extended alphabet, not as real numbers. Wine-0_9 Wine-0_9_1 Wine-0_9_10 ... Wine-0_9_19 Wine-0_9_2 Wine-0_9_20 ... Wine-0_9_29 Wine-0_9_3 Wine-0_9_30 I think it's probably only a trap for people who download from a source repository - and it is not a problem peculiar to Wine. Packaged versions are unlikely to be presented in this bizarre order. -- Andy. From twickline at gmail.com Fri Feb 16 09:21:12 2007 From: twickline at gmail.com (Tom Wickline) Date: Fri Feb 16 09:21:15 2007 Subject: Google Summer of Code 2007 Message-ID: <53e3a9930702160721h41a9bb44t828b2c007650463b@mail.gmail.com> Hello, I see Google is going to do there summer of code again this year :-) They plan to start accepting applications in March, so now would be the time for us to propose new projects and review the ones we have already listed on the Wiki for interested applicants? As well as line up mentors for the accepted applicants? http://wiki.winehq.org/SummerOfCode http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Tom From xixsimplicityxix at gmail.com Fri Feb 16 09:40:09 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Fri Feb 16 09:40:29 2007 Subject: We need a new version numbering scheme In-Reply-To: References: <1171605236.17168.94.camel@scott-desktop> Message-ID: <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> Maybe this would be unworkable in git or whatnot but perhaps always making the minor version field double digit would do the trick? 0.9.03 0.9.09 0.9.10 ... 0.9.30 etc this would fix the sorting problems that arise from going from single to double digit names in most programs too. As long as the major and minor fields always have the same number of digits it will sort correctly even with alphanumeric names. Of course they would have to update the older versions to double digits but that isn't impossible. Of course if you break 99 minor revisions you'd run into the problem again but I think 99 minor revisions is a lot harder to over run than 9. Plus, maybe if we have 99 minor versions it would be time for an increase in the major version number =) I'd be willing to implement this for a summer of code project. Just kidding. =) Hopefully I'll come up with something more exciting that you guys will like. Just a thought, John Klehm On 2/16/07, Andrew Talbot wrote: > > Scott Ritchie wrote: > > > On several occasions I have received emails referring to Wine version > > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > > > Presumably, this version is being confused with Wine 0.9.30 in these > > letters, however I have been unable to tell whether people were ACTUALLY > > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > > way of chopping off the last 0. > > > > Either way, version numbers should be completely clear, and they're not > > currently. I'm not quite sure what to do at this point. > > > > Thanks, > > Scott Ritchie > > The problem arises when version control programs sort the release "tags" > alphanumerically, presenting them in the following order, since the digits > are just treated as members of an extended alphabet, not as real numbers. > > Wine-0_9 > Wine-0_9_1 > Wine-0_9_10 > ... > Wine-0_9_19 > Wine-0_9_2 > Wine-0_9_20 > ... > Wine-0_9_29 > Wine-0_9_3 > Wine-0_9_30 > > I think it's probably only a trap for people who download from a source > repository - and it is not a problem peculiar to Wine. Packaged versions > are unlikely to be presented in this bizarre order. > > -- Andy. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070216/54e6195b/attachment.htm From xixsimplicityxix at gmail.com Fri Feb 16 09:43:44 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Fri Feb 16 09:45:33 2007 Subject: We need a new version numbering scheme In-Reply-To: <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> References: <1171605236.17168.94.camel@scott-desktop> <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> Message-ID: <78a7dad00702160743m93fdc74ib3a59bc6dcabd74@mail.gmail.com> Ack in my previous message I was speaking of 99 minor versions not revisions, sorry for the typo! John On 2/16/07, John Smith wrote: > > Maybe this would be unworkable in git or whatnot but perhaps always making > the minor version field double digit would do the trick? > > 0.9.03 > 0.9.09 > 0.9.10 > ... > 0.9.30 > etc > > this would fix the sorting problems that arise from going from single to > double digit names in most programs too. As long as the major and minor > fields always have the same number of digits it will sort correctly even > with alphanumeric names. Of course they would have to update the older > versions to double digits but that isn't impossible. > > Of course if you break 99 minor revisions you'd run into the problem again > but I think 99 minor revisions is a lot harder to over run than 9. Plus, > maybe if we have 99 minor versions it would be time for an increase in the > major version number =) > > I'd be willing to implement this for a summer of code project. > > Just kidding. =) Hopefully I'll come up with something more exciting that > you guys will like. > > Just a thought, > John Klehm > > On 2/16/07, Andrew Talbot wrote: > > > > Scott Ritchie wrote: > > > > > On several occasions I have received emails referring to Wine version > > > 0.9.3. One person even told me about a regression from 0.9.28 to > > 0.9.3. > > > > > > Presumably, this version is being confused with Wine 0.9.30 in these > > > letters, however I have been unable to tell whether people were > > ACTUALLY > > > using 0.9.3 or were instead simply referring to 0.9.30 in the > > intuitive > > > way of chopping off the last 0. > > > > > > Either way, version numbers should be completely clear, and they're > > not > > > currently. I'm not quite sure what to do at this point. > > > > > > Thanks, > > > Scott Ritchie > > > > The problem arises when version control programs sort the release "tags" > > > > alphanumerically, presenting them in the following order, since the > > digits > > are just treated as members of an extended alphabet, not as real > > numbers. > > > > Wine-0_9 > > Wine-0_9_1 > > Wine-0_9_10 > > ... > > Wine-0_9_19 > > Wine-0_9_2 > > Wine-0_9_20 > > ... > > Wine-0_9_29 > > Wine-0_9_3 > > Wine-0_9_30 > > > > I think it's probably only a trap for people who download from a source > > repository - and it is not a problem peculiar to Wine. Packaged versions > > > > are unlikely to be presented in this bizarre order. > > > > -- Andy. > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070216/f4cf4e55/attachment.html From joris_huizer at yahoo.com Fri Feb 16 10:32:15 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Fri Feb 16 10:32:54 2007 Subject: git question Message-ID: <186469.7450.qm@web52710.mail.yahoo.com> Hello, As a new wine is released I'm trying to get updated. Before I had used git for generating patches, I could do: git fetch; git rebase origin however, now this doesn't seem to pickup anything. How should I tell git to actually update to the files on the server? Thanks, Joris ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From stefandoesinger at gmx.at Fri Feb 16 10:36:13 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Fri Feb 16 10:36:53 2007 Subject: DIB Engine, some summarization In-Reply-To: <2e59e6970702151611t212462a4jeda707da5b7327d6@mail.gmail.com> References: <003901c74e29$d44955b0$4001a8c0@glis> <2e59e6970702151611t212462a4jeda707da5b7327d6@mail.gmail.com> Message-ID: <200702161736.14239.stefandoesinger@gmx.at> > This sounds like a really simple way to support client-side and > server-side drawing without the mixing that causes repeated network > transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would > all be done client-size, while IDirectWhatever::GetDC would return a > device context that is strictly server-side. Not necessarily a good idea. DirectDraw (software emulation) would profit a lot from client side DCs. On the other hand, for GetDC on a Direct3D rendertarget(aka opengl frame buffer), a server side context may help together with the GLX_texture_from_pixmap extension(maybe, the extension does not match exactly what we need). My other(crazy) idea is to implement GDI calls in opengl, or at least a part of them, and fall back to downloading the framebuffer, drawing in software and uploading again otherwise. Would we call that client side or server side rendering? From stefandoesinger at gmx.at Fri Feb 16 10:38:01 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Fri Feb 16 10:38:41 2007 Subject: [7/10] WineD3D: Test for supported queries In-Reply-To: <115115.30204.qm@web39703.mail.mud.yahoo.com> References: <115115.30204.qm@web39703.mail.mud.yahoo.com> Message-ID: <200702161738.05169.stefandoesinger@gmx.at> Am Donnerstag 15 Februar 2007 19:13 schrieb Juan Lang: > The label cleanup isn't used anywhere except in the failure to create the > device. In this case, wouldn't: > if (FAILED(hr)) return; > be clearer, and omit the unneeded label? There's no reason to release > pDevice in creating it failed. You're right. Its just copypasted from the other tests :-/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070216/d5795feb/attachment.pgp From jnewman at codeweavers.com Fri Feb 16 10:48:45 2007 From: jnewman at codeweavers.com (Jeremy Newman) Date: Fri Feb 16 10:48:51 2007 Subject: AppDB performance issue In-Reply-To: <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> Message-ID: <1171644525.20723.6.camel@localhost.localdomain> I made some tweaks to the server on Wednesday. Hopefully everything is running fine now. Let me know if it is still running slow. On Wed, 2007-02-14 at 16:35 -0600, John Smith wrote: > Humm very strange it works well for me, > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on > windows 2000, on gentoo x86 with firefox 2.0.0.1 , and on gentoo amd64 > firefox 2.0.0.1. > > I added, then removed, then edited a test result. Speed seemed > normal. > > Hope this helps the investigation. > > Regards, > John Klehm > > On 2/14/07, Louis Lenders wrote: > Bryan Haskins gmail.com> writes: > > > > > > > I was just replying, and reading now, no slow down at all. > It loads a little > slow running through all that text, but no where near the > minutes everyone says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading > a page, or > adding a test result to an application takes several minutes. > Please fix, as > this is really annoying :( > > > > From scott at open-vote.org Fri Feb 16 12:53:51 2007 From: scott at open-vote.org (Scott Ritchie) Date: Fri Feb 16 12:52:30 2007 Subject: We need a new version numbering scheme In-Reply-To: <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> References: <1171605236.17168.94.camel@scott-desktop> <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> Message-ID: <1171652031.17168.103.camel@scott-desktop> On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > Maybe this would be unworkable in git or whatnot but perhaps always > making the minor version field double digit would do the trick? How about we make the next version Wine 0.9.99.01? Or how about we make the next version 1.0 ;) Thanks, Scott Ritchie From marcus at jet.franken.de Fri Feb 16 13:13:42 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Fri Feb 16 13:14:00 2007 Subject: We need a new version numbering scheme In-Reply-To: <1171652031.17168.103.camel@scott-desktop> References: <1171605236.17168.94.camel@scott-desktop> <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> <1171652031.17168.103.camel@scott-desktop> Message-ID: <20070216191342.GA21416@galeere> On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > Maybe this would be unworkable in git or whatnot but perhaps always > > making the minor version field double digit would do the trick? > > How about we make the next version Wine 0.9.99.01? > > Or how about we make the next version 1.0 ;) I think 0.9.31 will have removed this confusion again. Ciao, Marcus From paul.vriens.wine at gmail.com Fri Feb 16 13:18:23 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Fri Feb 16 13:18:38 2007 Subject: wininet: Improve FtpOpenFile()'s parameter checking and remove the corresponding todo_wines. In-Reply-To: References: Message-ID: <45D6037F.3060007@gmail.com> Francois Gouget wrote: > Also make test_getfile_no_open() succeed on Windows 98. > --- > > I have had some strange results with these tests. One of them was > actually succeeding in a todo_wine for a good while. > > dlls/wininet/ftp.c | 12 +++++++++++- > dlls/wininet/tests/ftp.c | 12 +++--------- > 2 files changed, 14 insertions(+), 10 deletions(-) > This was the last one for now on my list, you beat me to it. We do have some conflicting patches now in wine-patches. > diff --git a/dlls/wininet/ftp.c b/dlls/wininet/ftp.c > index 5b073cf..2bd29fd 100644 > --- a/dlls/wininet/ftp.c > +++ b/dlls/wininet/ftp.c > @@ -1011,11 +1011,21 @@ HINTERNET WINAPI FtpOpenFileW(HINTERNET hFtpSession, > debugstr_w(lpszFileName), fdwAccess, dwFlags, dwContext); > > lpwfs = (LPWININETFTPSESSIONW) WININET_GetObject( hFtpSession ); > - if (NULL == lpwfs || WH_HFTPSESSION != lpwfs->hdr.htype) > + if (NULL == lpwfs) > + { > + INTERNET_SetLastError(ERROR_INTERNET_NOT_INITIALIZED); > + goto lend; Why do a 'goto lend' you could just 'return FALSE' like I did in the other ftp functions. No need do another check for lpwfs being NULL. If you do a 'return FALSE' you could also get rid of the check for lpwfs being NULL right after lend:. > + } > + if (WH_HFTPSESSION != lpwfs->hdr.htype) > { > INTERNET_SetLastError(ERROR_INTERNET_INCORRECT_HANDLE_TYPE); > goto lend; > } > + if (dwFlags & ~(INTERNET_FLAGS_MASK|FTP_TRANSFER_TYPE_MASK)) > + { > + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > + goto lend; > + } I think this covers the 5 in the test but not all possible combinations. I did some (loop) testing with dwFlags (also used in FtpGetFile and FtpPutFile) and it appears all boils down to the last 3 bits (see FtpGetFile). Cheers, Paul. From lats at yless4u.com.au Fri Feb 16 13:08:36 2007 From: lats at yless4u.com.au (Jeff L) Date: Fri Feb 16 13:21:59 2007 Subject: git question In-Reply-To: <186469.7450.qm@web52710.mail.yahoo.com> References: <186469.7450.qm@web52710.mail.yahoo.com> Message-ID: <45D60134.7040101@yless4u.com.au> Joris Huizer wrote: > git fetch; git rebase origin Have you committed all updates before you git rebase origin? git commit -a -m "all"; git rebase origin; git reset HEAD^ Jeff Latimer From scott at open-vote.org Fri Feb 16 13:34:24 2007 From: scott at open-vote.org (Scott Ritchie) Date: Fri Feb 16 13:33:08 2007 Subject: We need a new version numbering scheme In-Reply-To: <20070216191342.GA21416@galeere> References: <1171605236.17168.94.camel@scott-desktop> <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> <1171652031.17168.103.camel@scott-desktop> <20070216191342.GA21416@galeere> Message-ID: <1171654465.17168.110.camel@scott-desktop> On Fri, 2007-02-16 at 20:13 +0100, Marcus Meissner wrote: > On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > > Maybe this would be unworkable in git or whatnot but perhaps always > > > making the minor version field double digit would do the trick? > > > > How about we make the next version Wine 0.9.99.01? > > > > Or how about we make the next version 1.0 ;) > > I think 0.9.31 will have removed this confusion again. > > Ciao, Marcus Except maybe that 0.9.4 might be thought of as higher than 0.9.31 Thanks, Scott Ritchie From stefandoesinger at gmx.at Fri Feb 16 13:44:36 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Fri Feb 16 13:45:18 2007 Subject: git question In-Reply-To: <186469.7450.qm@web52710.mail.yahoo.com> References: <186469.7450.qm@web52710.mail.yahoo.com> Message-ID: <200702162044.39906.stefandoesinger@gmx.at> Am Freitag 16 Februar 2007 17:32 schrieb Joris Huizer: > Hello, > > As a new wine is released I'm trying to get updated. > Before I had used git for generating patches, I could > do: > > git fetch; git rebase origin > > however, now this doesn't seem to pickup anything. > How should I tell git to actually update to the files > on the server? That should still work. Does it give any error message? Most likely some of the patches in your tree conflict with some newly commited patches on the server. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070216/41cb0b84/attachment.pgp From kingofallhearts999 at gmail.com Fri Feb 16 14:14:12 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Fri Feb 16 14:14:28 2007 Subject: We need a new version numbering scheme In-Reply-To: <1171654465.17168.110.camel@scott-desktop> References: <1171605236.17168.94.camel@scott-desktop> <78a7dad00702160740x34bce9d5of2a4f4ca49029599@mail.gmail.com> <1171652031.17168.103.camel@scott-desktop> <20070216191342.GA21416@galeere> <1171654465.17168.110.camel@scott-desktop> Message-ID: 90 percent of statistics don't contain a 0 either! Whoops... Jokes aside, I was answering some wine related question on Ubuntuforums.org and came across this, many light users tend to do it. I even thought of it that way when I first learned about the common linux versioning system. I don't think there is anything we can do about it but educate users. And correct them when they do this, maybe on the main download info page for repos and such say outright it's important. Thinks like that. Maybe on some kind of getting support page or the future wine help talk about how it's important. even after 1.0 we'll be hitting this again too unless you do major revisions and reworking it will always be 1.XX.XX so... they need to get with it somehow. Just a users POV. On 2/16/07, Scott Ritchie wrote: > > On Fri, 2007-02-16 at 20:13 +0100, Marcus Meissner wrote: > > On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > > > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > > > Maybe this would be unworkable in git or whatnot but perhaps always > > > > making the minor version field double digit would do the trick? > > > > > > How about we make the next version Wine 0.9.99.01? > > > > > > Or how about we make the next version 1.0 ;) > > > > I think 0.9.31 will have removed this confusion again. > > > > Ciao, Marcus > > Except maybe that 0.9.4 might be thought of as higher than 0.9.31 > > Thanks, > Scott Ritchie > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070216/74c11acf/attachment.htm From kingofallhearts999 at gmail.com Fri Feb 16 14:27:17 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Fri Feb 16 14:27:26 2007 Subject: Wine and menu integration In-Reply-To: <1171597704.17168.84.camel@scott-desktop> References: <45D4230D.8010606@ols.es> <1171597704.17168.84.camel@scott-desktop> Message-ID: It does work in Ubuntu fine, which should conversely mean it works with any other gnome menu standard desktop. *should should should*. And in Feisty when you say always open this type of program (exe in this case) to use wine, it sticks and now I can just double-click and I'm in. Any Distro using the latest dev release of Gnome should be able to do this (don't know about pre this.) On 2/15/07, Scott Ritchie wrote: > > > On 2/15/07, David Saez Padros wrote: > > > I also have what should be add to installation so .exe files > > > are executed with wine when double-clicked (tested in ubuntu) > > When did this break? I thought this worked in Ubuntu just fine. > > Thanks, > Scott Ritchie > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070216/f73a1545/attachment.html From kingofallhearts999 at gmail.com Fri Feb 16 14:28:22 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Fri Feb 16 14:28:38 2007 Subject: AppDB performance issue In-Reply-To: <1171644525.20723.6.camel@localhost.localdomain> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> <1171644525.20723.6.camel@localhost.localdomain> Message-ID: Out of complete curiosity, what kind of problem caused only some people to slow down, while me, on dial-up sped right along? Lol. On 2/16/07, Jeremy Newman wrote: > > I made some tweaks to the server on Wednesday. Hopefully everything is > running fine now. > > Let me know if it is still running slow. > > On Wed, 2007-02-14 at 16:35 -0600, John Smith wrote: > > Humm very strange it works well for me, > > > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on > > windows 2000, on gentoo x86 with firefox 2.0.0.1 , and on gentoo amd64 > > firefox 2.0.0.1. > > > > I added, then removed, then edited a test result. Speed seemed > > normal. > > > > Hope this helps the investigation. > > > > Regards, > > John Klehm > > > > On 2/14/07, Louis Lenders wrote: > > Bryan Haskins gmail.com> writes: > > > > > > > > > > > I was just replying, and reading now, no slow down at all. > > It loads a little > > slow running through all that text, but no where near the > > minutes everyone says > > it takes them, even on dialup. > > > > > > > > > For your info, Appdb, is complete unusable for me ... Loading > > a page, or > > adding a test result to an application takes several minutes. > > Please fix, as > > this is really annoying :( > > > > > > > > > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070216/c30daf78/attachment-0001.htm From jnewman at codeweavers.com Fri Feb 16 14:32:30 2007 From: jnewman at codeweavers.com (Jeremy Newman) Date: Fri Feb 16 14:32:39 2007 Subject: AppDB performance issue In-Reply-To: References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> <1171644525.20723.6.camel@localhost.localdomain> Message-ID: <1171657950.20723.11.camel@localhost.localdomain> A few problems. First off, the web server and smtp server for winehq.org are all on the same box. WineHQ just gets hammered with spam some days. All that spam load takes I/O away from mysql. I've updated the mail daemon to go into a queue only mode when the load average gets to high. Secondly, for those who admin the appdb. Some pages send out email. The default settings for PHP when sending mail are very slow. I changed a setting in PHP to speed that up. On Fri, 2007-02-16 at 15:28 -0500, Bryan Haskins wrote: > Out of complete curiosity, what kind of problem caused only some > people to slow down, while me, on dial-up sped right along? Lol. > > On 2/16/07, Jeremy Newman wrote: > I made some tweaks to the server on Wednesday. Hopefully > everything is > running fine now. From hverbeet at gmail.com Fri Feb 16 14:28:31 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Fri Feb 16 14:35:56 2007 Subject: [5/10] DDraw: Fix a leak in a test In-Reply-To: <200702161908.13796.stefan@codeweavers.com> References: <200702161908.13796.stefan@codeweavers.com> Message-ID: Does this really matter? From ns03ja at brocku.ca Fri Feb 16 14:37:25 2007 From: ns03ja at brocku.ca (Neil Skrypuch) Date: Fri Feb 16 14:37:03 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: <45D3879D.8050506@czela.net> References: <915194.91418.qm@web26008.mail.ukl.yahoo.com> <45D3879D.8050506@czela.net> Message-ID: <200702161537.25569.ns03ja@brocku.ca> On Wednesday 14 February 2007, Mirek wrote: > Luke Bratch napsal(a): > >> Wow, great work!!!!! 3DMark 2006 with fbo looks > > > > realy coool!! And some > > > >> Nvidia SDK demos are completly fixed! > > > > How did you test 3DMark2006? When I try and run it, > > it tells me I need Pixel Shader 2.0 support. > > > > I have UseGLSL set to enabled and OffscreenRenderMode > > set to fbo, and the Pixel Shader 2 test in 3DMark03 > > works fine. > > Yes, but after accept this error message i can select some test and run > benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 > and GT2 tests are almost perfect, but very slow (fbo is slower than > backbuffer, so I am not using it in other applications), you should also > disable post procesing (very very slow) in 3DMark. Here are some > screenshots with latest wine and latest Stefan patches: > http://62.240.181.87/Mirek/3DMark2006/ > > PS: I have GF 6800GS, Core 2 Duo X6800@3700MHz and about 2 FPS, but it > works! :) > > Mirek 3DMark 05 and 06 are quite picky about caps, there's a few that are slightly off and it refuses to run, you can apply this hack to make it work: http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch This may also be of interest: http://bugs.winehq.org/show_bug.cgi?id=7434 - Neil From swhetzel at gmail.com Fri Feb 16 14:33:59 2007 From: swhetzel at gmail.com (Scot Hetzel) Date: Fri Feb 16 14:56:31 2007 Subject: We need a new version numbering scheme Message-ID: <790a9fff0702161233p51241898he72b09f76d15ba96@mail.gmail.com> I read about users confusion with wine version numbering scheme. Personally, I would redirect these confused users to the wiki page at wikipedia where it discusses what the numbers mean in a software version numbering scheme. http://en.wikipedia.org/wiki/Software_version The MAME project had the same user confusion when it went from 0.99 to 0.100. Several of the users of MAME had expected the next version to be 1.00. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From hverbeet at gmail.com Fri Feb 16 15:00:05 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Fri Feb 16 15:00:21 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: <200702161537.25569.ns03ja@brocku.ca> References: <915194.91418.qm@web26008.mail.ukl.yahoo.com> <45D3879D.8050506@czela.net> <200702161537.25569.ns03ja@brocku.ca> Message-ID: On 16/02/07, Neil Skrypuch wrote: > http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch > That won't apply/compile anymore, use the attached patch instead. -------------- next part -------------- --- dlls/wined3d/directx.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 841e16f..ca3eaaf 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -585,7 +585,7 @@ BOOL IWineD3DImpl_FillGLCaps(IWineD3D *iface, Display* display) { glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max); TRACE_(d3d_caps)(" FOUND: ARB Multitexture support - GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max); gl_info->supported[ARB_MULTITEXTURE] = TRUE; - gl_info->max_textures = min(MAX_TEXTURES, gl_max); + gl_info->max_textures = 8; gl_info->max_texture_stages = min(MAX_TEXTURES, gl_max); gl_info->max_samplers = max(gl_info->max_samplers, gl_max); } else if (strcmp(ThisExtn, "GL_ARB_texture_cube_map") == 0) { @@ -2196,7 +2196,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->MaxVertexBlendMatrixIndex = 1; *pCaps->MaxAnisotropy = GL_LIMITS(anisotropy); - *pCaps->MaxPointSize = GL_LIMITS(pointsize); + *pCaps->MaxPointSize = 64.0f; *pCaps->VertexProcessingCaps = WINED3DVTXPCAPS_DIRECTIONALLIGHTS | @@ -2294,7 +2294,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->NumSimultaneousRTs = GL_LIMITS(buffers); - *pCaps->StretchRectFilterCaps = 0; + *pCaps->StretchRectFilterCaps = WINED3DPTFILTERCAPS_MINFLINEAR | + WINED3DPTFILTERCAPS_MAGFLINEAR; *pCaps->VertexTextureFilterCaps = 0; if(*pCaps->VertexShaderVersion == WINED3DVS_VERSION(3,0)) { From ns03ja at brocku.ca Fri Feb 16 15:09:22 2007 From: ns03ja at brocku.ca (Neil Skrypuch) Date: Fri Feb 16 15:09:42 2007 Subject: [1/10] - [10/10] WineD3D In-Reply-To: References: <915194.91418.qm@web26008.mail.ukl.yahoo.com> <200702161537.25569.ns03ja@brocku.ca> Message-ID: <200702161609.22279.ns03ja@brocku.ca> On Friday 16 February 2007, H. Verbeet wrote: > On 16/02/07, Neil Skrypuch wrote: > > http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch > > That won't apply/compile anymore, use the attached patch instead. Ah, thanks, I didn't notice that. It applied just a few days ago. I updated my link as well. - Neil From stefandoesinger at gmx.at Fri Feb 16 15:59:42 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Fri Feb 16 16:00:39 2007 Subject: [5/10] DDraw: Fix a leak in a test In-Reply-To: References: <200702161908.13796.stefan@codeweavers.com> Message-ID: <200702162259.47228.stefandoesinger@gmx.at> Am Freitag 16 Februar 2007 21:28 schrieb H. Verbeet: > Does this really matter? Not really, but it avoids a few FIXMEs about unreleased surfaces and textures. We could downgrade the FIXMEs to warnings, but not releasing the objects in the test is wrong :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070216/d54febb7/attachment.pgp From kai.blin at gmail.com Fri Feb 16 17:07:40 2007 From: kai.blin at gmail.com (Kai Blin) Date: Fri Feb 16 17:08:24 2007 Subject: Google Summer of Code 2007 In-Reply-To: <53e3a9930702160721h41a9bb44t828b2c007650463b@mail.gmail.com> References: <53e3a9930702160721h41a9bb44t828b2c007650463b@mail.gmail.com> Message-ID: <200702170007.44083.kai.blin@gmail.com> On Friday 16 February 2007 16:21, Tom Wickline wrote: > I see Google is going to do there summer of code again this year :-) Yup, let's see what it will bring this year. > They plan to start accepting applications in March, so now would be > the time for us to propose new projects and review the ones we have > already listed on the Wiki for interested applicants? I'm not at all convinced anymore that DirectPlay is a SoC scope. I _might_ consider giving that a dash myself, but only if I manage to get some more groundwork covered on the wire protocol side of things. I've updated the Wiki page and removed the proposals that were successful last year. Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070217/6d6f8ac9/attachment.pgp From us at edmeades.me.uk Fri Feb 16 18:18:00 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Fri Feb 16 18:18:17 2007 Subject: calling _splitpath from cmd.exe, and 64 bit decimal formatting Message-ID: <000001c75229$15caaf90$1001a8c0@JasonsPC> Hello, Its been a while since I did any wine work so thought I'd fix some bugs in the cmd shell. I have come across a call which fails at compile time which I was interested in knowing the 'right' way to solve _splitpath appears to exist in ntdll, but none of the #includes I have tried pick it up. Stblib, for example, is just using the standard compiler one. Additionally looking at winefile it has just copied the implementation in, so why did it do that? Also, I wanted to sprintf using %I64d but again I believe we are ending up using the standard sprintf gcc library function which does not support it. Is there any easy way around this (its trivial functionality which can be left as a fixme if not). Jason From thestig at google.com Fri Feb 16 18:19:22 2007 From: thestig at google.com (Lei Zhang) Date: Fri Feb 16 18:19:43 2007 Subject: comctl32: move up-down msg seq tests into new 'msg' test In-Reply-To: <22821af30702131054k3f5e60c5y89e2e2e9fb6dc1a1@mail.gmail.com> References: <45D1FDF8.9060007@holycrap.org> <22821af30702131046s44194779i4a2a4dda6a280df@mail.gmail.com> <45D20A96.2060202@holycrap.org> <22821af30702131054k3f5e60c5y89e2e2e9fb6dc1a1@mail.gmail.com> Message-ID: <558b2f5c0702161619t636ce80bl7a47f7a2728b2d81@mail.gmail.com> On 2/13/07, James Hawkins wrote: > On 2/13/07, Felix Nawothnig wrote: > > James Hawkins wrote: > > > This is not what needs to happen. The generic message sequence > > > testing code needs to be factored into msg.c, but the specific tests > > > need to stay in each control's test file. > > > > Guessed so... How about putting it into include/wine/test.h to share the > > code with user32/msg? Wouldn't help object size but I don't think a > > shared lib would be worth it... > > > > No, comctl32's message sequence testing code is different than > user32's, and will be even more different when I add in WM_NOTIFY > testing support. > > -- > James Hawkins > I sent a couple of new patches for this: http://www.winehq.org/pipermail/wine-patches/2007-February/035992.html http://www.winehq.org/pipermail/wine-patches/2007-February/035993.html - Lei From dank at kegel.com Fri Feb 16 21:28:28 2007 From: dank at kegel.com (Dan Kegel) Date: Fri Feb 16 21:28:39 2007 Subject: VB, Access based program on Linux In-Reply-To: References: Message-ID: [-wine-users, +wine-devel] On 2/6/07, Dan Kegel wrote: > Neelesh wrote: > >I work in one public charitable trust. Here we are using one > >Accounting+Inventory+Report management Program. Two developers have > >developed in VB, Access and Crystal Reports. > > > >Now I am trying to use it through wine on linux.... > ... > If you want to help us get Wine ready for > VB/Access applications, you could send a Wine > developer a copy of your application so he could > look at the problems locally. Thanks for sending the app to me. Of the many problems it seems to present, I'm starting with the first one: an error dialog during install. When it tries to run a couple subinstallers, it fails, and puts up a dialog box saying the directory is invalid. After a bit of looking, I am starting to suspect that ShellExecuteEx is being called by the installer with a quoted directory name, and Wine isn't handling that right. Here's a bit of log: dank@krunch:/C:/foo/bar_Installation$ grep -i Shell.*Execute log7.c 000e:Call shell32.ShellExecuteExA(0035f40c) ret=0041e5a4 000e:trace:exec:SHELL_execute mask=0x00000640 hwnd=0x1002c verb=L"open" file=L"C:\\foo\\bar_Installation\\InstMsiA.EXE" parm=L"" dir=L"\"C:\\foo\\bar_Installation" show=0x00000001 class=not used 000e:fixme:exec:SHELL_execute flags ignored: 0x00000400 000e:trace:exec:ShellExecute_FromContextMenu L"C:\\foo\\bar_Installation\\InstMsiA.EXE" 000e:trace:exec:ShellExecute_GetClassKey ext = L".EXE" 000e:trace:exec:ShellExecute_GetClassKey class = L"exefile" 000e:trace:exec:SHELL_execute execute:L"C:\\foo\\bar_Installation\\InstMsiA.EXE",L"",L"\"C:\\foo\\bar_Installation" 000e:trace:exec:SHELL_ExecuteW Execute L"C:\\foo\\bar_Installation\\InstMsiA.EXE" from directory L"\"C:\\foo\\bar_Installation" 000e:err:exec:SHELL_ExecuteW cannot set directory L"\"C:\\foo\\bar_Installation" 000e:trace:exec:SHELL_ExecuteW CreateProcess returned error 267 000e:trace:exec:SHELL_ExecuteW returning 11 The directory only has a quote mark at the beginning; this may be a bug in your installer, but if Windows' ShellExecute can handle that, Wine should be able to, too. My computer time is limited, or I'd add a testcase in shell32/tests/shlexec.c to check this. Maybe someone else can have a look. - Dan From dank at kegel.com Fri Feb 16 23:08:06 2007 From: dank at kegel.com (Dan Kegel) Date: Fri Feb 16 23:08:11 2007 Subject: 32 bpp cursors? Message-ID: http://bugs.winehq.org/show_bug.cgi?id=4273 points to a patch set that implements 32 bit per pixel cursors and a bunch of other cursor stuff. Looks like the patch got dropped by the author, though, and since it makes server changes, it's going to be hard to get past Alexandre. Is anyone interested in picking this up? - Dan From dmitry at codeweavers.com Sat Feb 17 00:12:23 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 17 00:12:27 2007 Subject: comctl32: rebar: New conformance test for CCS_NORESIZE style.[PATCH 1/2] References: <1171690635.26775.1.camel@misha-laptop> Message-ID: <01d001c7525a$9ab44c30$0100a8c0@DMITRY> "Misha Koshelev" wrote: > +/* MSDN 672579: "CCS_NORESIZE: Prevents the control from using the default width and height when setting its > + * initial size or a new size. Instead, the control uses the width and height specified in the request for > + * creation or sizing." This test checks both creation and sizing dimensions. */ You can't quote MSDN in the Wine code, but you can explain the problem using your own wording. -- Dmitry. From lats at yless4u.com.au Sat Feb 17 03:15:03 2007 From: lats at yless4u.com.au (Jeff L) Date: Sat Feb 17 03:15:19 2007 Subject: 1/4 NtCreateMailslotFile tests In-Reply-To: <00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> References: <45CEF57E.3010101@yless4u.com.au> <00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> Message-ID: <45D6C797.2000505@yless4u.com.au> Dmitry Timoshkov wrote: > "Jeff Latimer" wrote: >> + ok( CloseHandle(hslot), "CloseHandle failed\n"); > To close the handle returned by an NT API you have you use an NT API > as well. Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems that NtClose has been superseded by CloseHandle. So I suppose that CloseHandle is the one to use. Have fixed the other points. Jeff From dmitry at codeweavers.com Sat Feb 17 03:51:19 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 17 03:51:29 2007 Subject: 1/4 NtCreateMailslotFile tests References: <45CEF57E.3010101@yless4u.com.au><00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> <45D6C797.2000505@yless4u.com.au> Message-ID: <002001c75279$3081ec90$0100a8c0@DMITRY> "Jeff L" wrote: >> To close the handle returned by an NT API you have you use an NT API >> as well. What is not apparent in the explanation above? > Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx > and it seems that NtClose has been superseded by CloseHandle. So I > suppose that CloseHandle is the one to use. The information in MSDN is misleading in this case, CloseHandle is a kernel32 API, not an NT (native) one. -- Dmitry. From lats at yless4u.com.au Sat Feb 17 03:58:03 2007 From: lats at yless4u.com.au (Jeff L) Date: Sat Feb 17 03:58:06 2007 Subject: 1/4 NtCreateMailslotFile tests In-Reply-To: <002001c75279$3081ec90$0100a8c0@DMITRY> References: <45CEF57E.3010101@yless4u.com.au><00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> <45D6C797.2000505@yless4u.com.au> <002001c75279$3081ec90$0100a8c0@DMITRY> Message-ID: <45D6D1AB.1030007@yless4u.com.au> Dmitry Timoshkov wrote: > "Jeff L" wrote: > >>> To close the handle returned by an NT API you have you use an NT API >>> as well. > > What is not apparent in the explanation above? I have no problem with what you have said though I did have a bit of difficulty marrying to the sentence below. > >> Have reread MSDN >> http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems >> that NtClose has been superseded by CloseHandle. So I suppose that >> CloseHandle is the one to use. > > The information in MSDN is misleading in this case, CloseHandle is a > kernel32 > API, not an NT (native) one. > So the correct move is to use the depreciated function? Microsoft appears to be pushing people away from NtClose. Is the it that they are reserving NtClose etc for their ntdll use? Jeff From thunderbird2k at gmx.net Sat Feb 17 03:57:52 2007 From: thunderbird2k at gmx.net (Roderick Colenbrander) Date: Sat Feb 17 03:58:26 2007 Subject: 32 bpp cursors? In-Reply-To: References: Message-ID: <20070217095752.47510@gmx.net> > http://bugs.winehq.org/show_bug.cgi?id=4273 points to a > patch set that implements 32 bit per pixel cursors > and a bunch of other cursor stuff. > > Looks like the patch got dropped by the author, though, > and since it makes server changes, it's going to be hard > to get past Alexandre. > > Is anyone interested in picking this up? > - Dan > I believe the problem is not that Henri has dropped the patches. The problem was that Alexandre didn't have time for reviewing the patches. The patches are very, very, very big and chance big parts of Wine. For this reason Alexandre is reluctant in applying it. Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out From eric.pouech at wanadoo.fr Sat Feb 17 04:00:55 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Sat Feb 17 04:01:28 2007 Subject: Resend 1/4 NtCreateMailslotFile tests In-Reply-To: <45D6C93F.2060303@yless4u.com.au> References: <45D6C93F.2060303@yless4u.com.au> Message-ID: <45D6D257.8030507@wanadoo.fr> Jeff Latimer a ?crit : > Establish the framework for testing NtCreateMailslotFile. Have fixed > issues with NTSTATUS return codes etc. those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle A+ From lats at yless4u.com.au Sat Feb 17 04:14:21 2007 From: lats at yless4u.com.au (Jeff L) Date: Sat Feb 17 04:14:25 2007 Subject: Resend 1/4 NtCreateMailslotFile tests In-Reply-To: <45D6D257.8030507@wanadoo.fr> References: <45D6C93F.2060303@yless4u.com.au> <45D6D257.8030507@wanadoo.fr> Message-ID: <45D6D57D.4010009@yless4u.com.au> Eric Pouech wrote: > Jeff Latimer a ?crit : >> Establish the framework for testing NtCreateMailslotFile. Have fixed >> issues with NTSTATUS return codes etc. > those tests belong to dlls/ntdll, not dlls/kernel32 > also, if the test is for ntdll functions, it shouldn't use kernel32 > ones... hence, NtClose should be used instead of CloseHandle I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case? Jeff From joris_huizer at yahoo.com Sat Feb 17 07:08:53 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Sat Feb 17 07:16:19 2007 Subject: -ansi, -pedantic warnings and errors on Message-ID: <20070217130853.35154.qmail@web52707.mail.yahoo.com> Hello, I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far; At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions. As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-pedantic-fix-make-unicode-functions-static.txt Type: text/x-patch Size: 13298 bytes Desc: 3217175606-0008-pedantic-fix-make-unicode-functions-static.txt Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070217/dc3fd09d/0008-pedantic-fix-make-unicode-functions-static-0001.bin From dmitry at codeweavers.com Sat Feb 17 08:29:01 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 17 08:29:19 2007 Subject: 1/4 NtCreateMailslotFile tests References: <45CEF57E.3010101@yless4u.com.au><00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY><45D6C797.2000505@yless4u.com.au><002001c75279$3081ec90$0100a8c0@DMITRY> <45D6D1AB.1030007@yless4u.com.au> Message-ID: <000601c752a0$002a84e0$0100a8c0@DMITRY> "Jeff L" wrote: >>> Have reread MSDN >>> http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems >>> that NtClose has been superseded by CloseHandle. So I suppose that >>> CloseHandle is the one to use. >> >> The information in MSDN is misleading in this case, CloseHandle is a >> kernel32 >> API, not an NT (native) one. >> > So the correct move is to use the depreciated function? It's not deprecated, even Microsof tries to create an impression it is. > Microsoft > appears to be pushing people away from NtClose. I'd suggest you to find a reason why. > Is the it that they are > reserving NtClose etc for their ntdll use? Also I'd suggest to learn about a difference between Native and Win32 API before writing the tests that mix them. -- Dmitry. From eric.pouech at wanadoo.fr Sat Feb 17 12:16:46 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Sat Feb 17 12:17:25 2007 Subject: Resend 1/4 NtCreateMailslotFile tests In-Reply-To: <45D6D57D.4010009@yless4u.com.au> References: <45D6C93F.2060303@yless4u.com.au> <45D6D257.8030507@wanadoo.fr> <45D6D57D.4010009@yless4u.com.au> Message-ID: <45D7468E.2000904@wanadoo.fr> Jeff L a ?crit : > Eric Pouech wrote: >> Jeff Latimer a ?crit : >>> Establish the framework for testing NtCreateMailslotFile. Have >>> fixed issues with NTSTATUS return codes etc. >> those tests belong to dlls/ntdll, not dlls/kernel32 >> also, if the test is for ntdll functions, it shouldn't use kernel32 >> ones... hence, NtClose should be used instead of CloseHandle > I put the proposition a while ago about putting the tests in kernel32 > as, although they are ntdll functions, they related to mailslot > functions and relating the tests would be easier on the tester. I > take it that that is not the case? my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test rationale behind this: - that's what is the most logical - when someone changes DLL X, he/she doesn't want (at first) to rerun the tests from every DLL note: there's currently only one case of this (in kernel32/tests) for virtual memory, and it should be moved to ntdll A+ From fgouget at free.fr Sat Feb 17 13:23:02 2007 From: fgouget at free.fr (Francois Gouget) Date: Sat Feb 17 13:23:13 2007 Subject: lostwages/ news/2006081001.xml news/2007021602 ... In-Reply-To: References: Message-ID: On Fri, 16 Feb 2007, WineHQ wrote: > ChangeSet ID: 30931 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: wineowner@winehq.org 2007/02/16 18:13:29 Could we get rid of wineowner account? It makes it impossible to know who's doing the changes. Each user having access to the WineHQ box should have his own login. Welcome back Brian (if I read the wwn right). -- Francois Gouget http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U From chrivers at iversen-net.dk Sat Feb 17 11:13:57 2007 From: chrivers at iversen-net.dk (Christian Iversen) Date: Sat Feb 17 13:46:21 2007 Subject: Error in ntdll/module.c? Message-ID: <45D737D5.5090501@iversen-net.dk> (Please CC me, I'm not on the list) According to: http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Executable%20Images/LdrGetProcedureAddress.html The parameter order for LdrGetProcedureAddress is (Handle, Function, Ordinal, Address) The file dlls/ntdll/module.c has the order as (Handle, Ordinal, Function, Address) This of course works well because kernel32.dll is the only caller (and it indeed uses, if not the correct, then at least the same order). I haven't attached a patch, because I'm not actually sure which version is right. Anyone? -- Mvh Christian Iversen From rob at codeweavers.com Sat Feb 17 14:23:50 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sat Feb 17 14:24:30 2007 Subject: patches and more In-Reply-To: <45D573F6.2080008@ols.es> References: <45D573F6.2080008@ols.es> Message-ID: <45D76456.3060809@codeweavers.com> David Saez Padros wrote: > This line should be added to commctrl.h: > > #define ListView_GetOrigin(hwndLV, ppt) \ > (BOOL)SNDMSG((hwndLV), LVM_GETORIGIN, (WPARAM)0, (LPARAM)ppt) I've submitted a patch for this. > this one should be added to windows.h (maybe it's not the best > place for it, but it works): > > #define stricmp strcasecmp This define is not present in the Platform SDK. It is a by-product of using glibc instead of msvcrt as your C library. If you used the headers in include/msvcrt and added -lmsvcrt to the linker command line then it should have worked out of the box. If you want to link against glibc, then think of changing stricmp to strcasecmp as part of porting the program. -- Rob Shearman From rob at codeweavers.com Sat Feb 17 14:27:07 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sat Feb 17 14:27:46 2007 Subject: -ansi, -pedantic warnings and errors on In-Reply-To: <20070217130853.35154.qmail@web52707.mail.yahoo.com> References: <20070217130853.35154.qmail@web52707.mail.yahoo.com> Message-ID: <45D7651B.3030809@codeweavers.com> Joris Huizer wrote: > Hello, > > I was looking at the result of configuring with -ansi, > -pedantic flags. It gives loads of warnings (not all > relevant - also complaining about 'long long' not > being ansi) and indicates unnamed unions, among other > things. > Could someone confirm my idea that unnamed unions must > all be dealt with? Am hoping to fix those if I get it > to compile thus far; > > At this point, it complains about > include/wine/unicode.h which has the combination > 'extern' and 'inline', which it doesn't like. > Getting rid of that, with -Dinline=__inline__, helps > it get a bit further > > Next it complains about is libs/wine/string.c, which > implements several functions that are also implemented > in include/wine/unicode.h. These are again the 'extern > inline' functions. > > As most headers have 'static inline' instead of > 'extern inline', with the advantage of not having to > duplicate the functions. I'm hoping this is an allowed > fix, it gets compiling further anyway > On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions. -- Rob Shearman From joris_huizer at yahoo.com Sat Feb 17 14:41:14 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Sat Feb 17 14:41:53 2007 Subject: -ansi, -pedantic warnings and errors on In-Reply-To: <45D7651B.3030809@codeweavers.com> Message-ID: <650848.70612.qm@web52706.mail.yahoo.com> Robert Shearman wrote: Joris Huizer wrote: > Hello, > > I was looking at the result of configuring with -ansi, > -pedantic flags. It gives loads of warnings (not all > relevant - also complaining about 'long long' not > being ansi) and indicates unnamed unions, among other > things. > Could someone confirm my idea that unnamed unions must > all be dealt with? Am hoping to fix those if I get it > to compile thus far; > > At this point, it complains about > include/wine/unicode.h which has the combination > 'extern' and 'inline', which it doesn't like. > Getting rid of that, with -Dinline=__inline__, helps > it get a bit further > > Next it complains about is libs/wine/string.c, which > implements several functions that are also implemented > in include/wine/unicode.h. These are again the 'extern > inline' functions. > > As most headers have 'static inline' instead of > 'extern inline', with the advantage of not having to > duplicate the functions. I'm hoping this is an allowed > fix, it gets compiling further anyway > On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions. -- Rob Shearman Well if it isn't applied (btw how could I see what is/isn't applied?) will try to look at that. Though the keyword "inline" implies the code should get inlined, and if it shouldn't, the implementation copy should be removed from the unicode.h file Joris --------------------------------- Have a burning question? Go to Yahoo! Answers and get answers from real people who know. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070217/f50c25de/attachment.html From dank at kegel.com Sat Feb 17 14:55:37 2007 From: dank at kegel.com (Dan Kegel) Date: Sat Feb 17 14:55:46 2007 Subject: 32 bpp cursors? In-Reply-To: References: Message-ID: On 2/16/07, H. Verbeet wrote: >> http://bugs.winehq.org/show_bug.cgi?id=4273 points to a >> patch set that implements 32 bit per pixel cursors >> and a bunch of other cursor stuff. [What's up with it?] > >I believe the problem is not that Henri has dropped the patches. >The problem was that Alexandre didn't have time for reviewing the patches. >The patches are very, very, very big and change big parts of Wine. >For this reason Alexandre is reluctant in applying it. Is it neccessary to move cursors into the server first? Could you break off some of the features and do them first, e.g. 32 bpp cursors? - Dan From dclark at akamail.com Sat Feb 17 15:02:28 2007 From: dclark at akamail.com (Duane Clark) Date: Sat Feb 17 15:03:12 2007 Subject: 32 bpp cursors? In-Reply-To: References: Message-ID: Dan Kegel wrote: > http://bugs.winehq.org/show_bug.cgi?id=4273 points to a > patch set that implements 32 bit per pixel cursors > and a bunch of other cursor stuff. > > Looks like the patch got dropped by the author, though, > and since it makes server changes, it's going to be hard > to get past Alexandre. > > Is anyone interested in picking this up? Well, no server changes are needed just to implement 32 bits per pixel. There are rather simple changes needed in the file dlls/winex11.drv/mouse.c in create_cursor(), and the places that need to be changed are cleverly marked by "switch (ptr->bBitsPerPixel)" ;) I tried installing Google Sketchup, but could not get that to install. That said, it looks like 32 bit pixels use 8 bits each of RGB, plus an extra 8 bits of "alpha" (which apparently controls transparency). So probably you could duplicate the 24 bit case, read out the extra 8 bits and just throw them away for now. Standard X cursors don't support alpha, AFAIK. From hverbeet at gmail.com Sat Feb 17 15:15:31 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Sat Feb 17 15:16:11 2007 Subject: 32 bpp cursors? In-Reply-To: References: Message-ID: On 17/02/07, Dan Kegel wrote: > Could you break off some of the features and > do them first, e.g. 32 bpp cursors? > - Dan > My plan was to redo the set for local cursors only, but there's also wined3d that needs attention :-) From hverbeet at gmail.com Sat Feb 17 15:19:02 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Sat Feb 17 15:19:13 2007 Subject: 32 bpp cursors? In-Reply-To: References: Message-ID: On 17/02/07, Duane Clark wrote: > Well, no server changes are needed just to implement 32 bits per pixel. > There are rather simple changes needed in the file > dlls/winex11.drv/mouse.c in create_cursor(), and the places that need to > be changed are cleverly marked by "switch (ptr->bBitsPerPixel)" ;) > > I tried installing Google Sketchup, but could not get that to install. > That said, it looks like 32 bit pixels use 8 bits each of RGB, plus an > extra 8 bits of "alpha" (which apparently controls transparency). So > probably you could duplicate the 24 bit case, read out the extra 8 bits > and just throw them away for now. Standard X cursors don't support > alpha, AFAIK. > The only thing that really needs cursors to be in the server is passing cursor/icon handles around between processes. From ploujj at gmail.com Sat Feb 17 17:08:45 2007 From: ploujj at gmail.com (Michael [Plouj] Ploujnikov) Date: Sat Feb 17 17:08:57 2007 Subject: generic.ppd does not appear in the build dir - cannot print Message-ID: <18e575130702171508p3af94ee6h3a7779a54ed2d4c1@mail.gmail.com> With a recent update to Wine 0.9.31, my printing issue [1] has changed in some way that actually generated some meaningful error messages being printed. I don't know if this is indeed the same issue or not. However, here are the messages that I started getting: $ wine notepad Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Note: my Wine source is checked out from git into ~/apps/wine-git . However, I execute ./configure && make inside ~/apps/build_dir to separate the source from the build files. I also run Wine by executing ~/apps/build_dir/wine . After some playing around I realized that generic.pdd resides in my Wine source checkout directory: $ file ~/apps/wine-git/dlls/wineps.drv/generic.ppd /home/plouj/apps/wine-git/dlls/wineps.drv/generic.ppd: PPD file, ve but not inside the build directory: ls ~/apps/build_dir/dlls/wineps.drv/*.ppd ls: cannot access /home/plouj/apps/build_dir/dlls/wineps.drv/*.ppd: No such file or directory After simply copying generic.pdd to my build directory I was able to print without (absolutely any) errors or warning messages. After finding a quick solution I'm wondering what, a person like me, who builds (and runs) wine in a directory parallel to the source, should do in this case? Should I just live with this hack-ish copying of the .ppd file? Is my usage case not 'popular' enough to warrant a fix? Is this how Autotools is supposed to be used to install generic.ppd? Why didn't the older versions of Wine [2] have this issue? The Makefile doesn't look promising to me: install install-lib:: $(DESTDIR)$(datadir)/wine $(INSTALL_DATA) $(SRCDIR)/generic.ppd $(DESTDIR)$(datadir)/wine/generic.ppd The way I understand this is that generic.ppd is meant to reside in the source directory and the install directory only. This probably means that Autotools won't put it in the build directory. References [1] - http://www.winehq.org/pipermail/wine-devel/2007-January/053606.html [2] - As you can see I've been successfully printing with a non-free application running under Wine since around 0.9.9: http://appdb.winehq.org/appview.php?iVersionId=4498 -- Libre Software: http://www.gnu.org/philosophy/free-sw.html From dank at kegel.com Sat Feb 17 21:56:01 2007 From: dank at kegel.com (Dan Kegel) Date: Sat Feb 17 21:56:06 2007 Subject: generic.ppd does not appear in the build dir - cannot print Message-ID: > [I keep my source and object in different directories, and generic.ppd isn't found during build] That method of building is great, and is supported, but not too many people build that way, so bugs do creep in. You can either keep living with the workaround you found, or submit a patch to fix the build. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv From dmitry at codeweavers.com Sat Feb 17 23:37:33 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 17 23:37:41 2007 Subject: Font issue - workaround found References: <87r6ytb1f0.fsf@elstar.ursus.kosmos> Message-ID: <005801c7531e$e7e187b0$0100a8c0@DMITRY> "Timm" wrote: > My one win app that makes me a devotee of WINE is TablEdit > (demo at www.tabledit.com/download/tabled32.exe) > has a custom font , tef260.ttf, that has failed to display since > somewhere after ver 9.6. The program installs the font into > c:\windows\font, but can not display it within the program, instead > displaying for the most part, empty squares. After reading WWN with this problem raised again, I think that it sounds like the same bug as reported in http://bugs.winehq.org/show_bug.cgi?id=7379 Could you please re-test with Wine 0.9.31 and report if the problem still persists? -- Dmitry. From dmitry at codeweavers.com Sat Feb 17 23:47:25 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sat Feb 17 23:47:30 2007 Subject: patches and more References: <45D573F6.2080008@ols.es> <45D76456.3060809@codeweavers.com> Message-ID: <006a01c75320$47a78bd0$0100a8c0@DMITRY> "Robert Shearman" wrote: >> this one should be added to windows.h (maybe it's not the best >> place for it, but it works): >> >> #define stricmp strcasecmp > > This define is not present in the Platform SDK. It is a by-product of > using glibc instead of msvcrt as your C library. If you used the headers > in include/msvcrt and added -lmsvcrt to the linker command line then it > should have worked out of the box. If you want to link against glibc, > then think of changing stricmp to strcasecmp as part of porting the program. Rob is right, but I'd like to point out to a caveat caused by using strcasecmp instead of a Win32 API: since Unix and Wine internal (Win32) *are* different, that could lead to subtle bugs in many locales. -- Dmitry. From bon at elektron.ikp.physik.tu-darmstadt.de Sun Feb 18 05:53:12 2007 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Sun Feb 18 05:53:47 2007 Subject: Error in ntdll/module.c? In-Reply-To: <45D737D5.5090501@iversen-net.dk> References: <45D737D5.5090501@iversen-net.dk> Message-ID: <17880.15912.784479.266195@hertz.ikp.physik.tu-darmstadt.de> >>>>> "Christian" == Christian Iversen writes: Christian> (Please CC me, I'm not on the list) Christian> According to: Christian> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Executable%20Images/LdrGetProcedureAddress.html Christian> The parameter order for LdrGetProcedureAddress is (Handle, Christian> Function, Ordinal, Address) Christian> The file dlls/ntdll/module.c has the order as (Handle, Christian> Ordinal, Function, Address) Christian> This of course works well because kernel32.dll is the only Christian> caller (and it indeed uses, if not the correct, then at least Christian> the same order). Christian> I haven't attached a patch, because I'm not actually sure Christian> which version is right. Anyone? Write a test for our test suite and run the test on wine and a windows machine. Send at least the test. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From eric.pouech at wanadoo.fr Sun Feb 18 06:40:12 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Sun Feb 18 06:40:46 2007 Subject: [PATCH] return when not finding the name Message-ID: <45D8492C.5040705@wanadoo.fr> Marcus Meissner a ?crit : > --- > dlls/dbghelp/dwarf.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > index 4f74b6a..f51a948 100644 > --- a/dlls/dbghelp/dwarf.c > +++ b/dlls/dbghelp/dwarf.c > @@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar > > TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); > > - if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string = NULL; > + if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; > if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) value.u.svalue = 0; > symt_add_enum_element(ctx->module, parent, name.u.string, value.u.svalue); > > Hi Marcus, can you send me the ELF file(s) which is/are causing this? A+ From rob at codeweavers.com Sun Feb 18 06:42:15 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 18 06:45:18 2007 Subject: -ansi, -pedantic warnings and errors on In-Reply-To: <650848.70612.qm@web52706.mail.yahoo.com> References: <650848.70612.qm@web52706.mail.yahoo.com> Message-ID: <45D849A7.4080206@codeweavers.com> Joris Huizer wrote: > Though the keyword "inline" implies the code should get inlined, and > if it shouldn't, the implementation copy should be removed from the > unicode.h file No, it's a hint to the compiler. "static inline" says to the compiler try to inline this function if it is worth it, or otherwise include a copy of this function in the object file. "extern inline" says to the compiler try to inline this function if it is worth it, or otherwise link to shared copy of this function (in our case, implemented in the libwine shared object). -- Rob Shearman From r.kalbermatter at hccnet.nl Sun Feb 18 07:18:42 2007 From: r.kalbermatter at hccnet.nl (Rolf Kalbermatter) Date: Sun Feb 18 07:19:35 2007 Subject: Error in ntdll/module.c? Message-ID: <003801c7535f$4f9ebc70$4001a8c0@glis> Christian Iversen [mailto:chrivers@iversen-net.dk] wrote: >According to: > >http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/ >Executable%20Images/LdrGetProcedureAddress.html > >The parameter order for LdrGetProcedureAddress is (Handle, Function, >Ordinal, Address) > >The file dlls/ntdll/module.c has the order as (Handle, Ordinal, >Function, Address) Ok. I took a look at the call sequence of this function in a native kernel32.dll and the second parameter is initialized with RtlInitString. So I guess the parameter order as on that web site would be correct. Having looked at the particular assembly code obviously excludes me from doing any work on this part anymore. As to the current implemenation I'm not sure that makes any difference since most undocumented APIs are unlikely to be used by applications. And since ntdll and kernel32 are both also Wine specific and therefore can't be replaced by Windows ones this won't matter either it would seem. You can try to post a proper patch to both kernel32 and ntdll to wine-patches and then let Alexandre decide if he wants to apply it. Rolf Kalbermatter From marcus at jet.franken.de Sun Feb 18 07:39:21 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Sun Feb 18 07:39:27 2007 Subject: [PATCH] return when not finding the name In-Reply-To: <45D8492C.5040705@wanadoo.fr> References: <45D8492C.5040705@wanadoo.fr> Message-ID: <20070218133921.GA26052@galeere> On Sun, Feb 18, 2007 at 01:40:12PM +0100, Eric Pouech wrote: > Marcus Meissner a ?crit : > >--- > > dlls/dbghelp/dwarf.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > >diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > >index 4f74b6a..f51a948 100644 > >--- a/dlls/dbghelp/dwarf.c > >+++ b/dlls/dbghelp/dwarf.c > >@@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar > > > > TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); > > > >- if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string > >= NULL; > >+ if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; > > if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) > > value.u.svalue = 0; > > symt_add_enum_element(ctx->module, parent, name.u.string, > > value.u.svalue); > > > > > Hi Marcus, > > can you send me the ELF file(s) which is/are causing this? There is no ELF file. Coverity spotted this as error, since name.u.string can be NULL in the flow and symt_add_enum_element() would crash in pool_strdup. It is CID 461. 462 and 463 are related issues. Ciao, Marcus From eric.pouech at wanadoo.fr Sun Feb 18 07:41:43 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Sun Feb 18 07:42:15 2007 Subject: Error in ntdll/module.c? In-Reply-To: <003801c7535f$4f9ebc70$4001a8c0@glis> References: <003801c7535f$4f9ebc70$4001a8c0@glis> Message-ID: <45D85797.5010409@wanadoo.fr> Rolf Kalbermatter a ?crit : > Christian Iversen [mailto:chrivers@iversen-net.dk] wrote: > > >> According to: >> >> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/ >> Executable%20Images/LdrGetProcedureAddress.html >> >> The parameter order for LdrGetProcedureAddress is (Handle, Function, >> Ordinal, Address) >> >> The file dlls/ntdll/module.c has the order as (Handle, Ordinal, >> Function, Address) >> > > Ok. I took a look at the call sequence of this function in a native > kernel32.dll and the second parameter is initialized with RtlInitString. > So I guess the parameter order as on that web site would be correct. > > Having looked at the particular assembly code obviously excludes me > from doing any work on this part anymore. > > As to the current implemenation I'm not sure that makes any difference > since most undocumented APIs are unlikely to be used by applications. > And since ntdll and kernel32 are both also Wine specific and therefore > can't be replaced by Windows ones this won't matter either it would seem. > > You can try to post a proper patch to both kernel32 and ntdll to > wine-patches and then let Alexandre decide if he wants to apply it. > googling LdrGetProcedureAddress gives the same conclusion It's always a good idea to have APIs behaving like on windows A+ From wine.dev at web.de Sun Feb 18 08:53:47 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Sun Feb 18 08:54:23 2007 Subject: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627 In-Reply-To: References: Message-ID: <1171810428.7289.12.camel@p4> On Sa, 2007-02-17 at 13:32 -0800, Dan Kegel wrote: > +++ b/tools/wine.inf > @@ -2149,6 +2149,7 @@ HKLM,%CurrentVersion%\Telephony\Country > > [FakeDllsSection] > +10,..\Program Files\Windows NT\Accessories,wordpad.exe > +++ b/tools/wineprefixcreate.in > + "$CROOT/Program Files" \ > + "$CROOT/Program Files/Windows NT" \ > + "$CROOT/Program Files/Windows NT/Accessories" The Idea sounds good, but your Patch is wrong for every system in the World, that does not use English as locale: My XP has wordpad.exe here: "C:\Programme\Windows NT\Zubeh?r\wordpad.exe" -- By by ... Detlef From jnewman at codeweavers.com Sun Feb 18 09:24:50 2007 From: jnewman at codeweavers.com (Jeremy Newman) Date: Sun Feb 18 09:24:51 2007 Subject: lostwages/ news/2006081001.xml news/2007021602 ... In-Reply-To: References: Message-ID: <1171812290.7720.7.camel@localhost.localdomain> Yes, that is on my todo list. First, I need each of the wineowner users to contact me so I can get them setup. On Sat, 2007-02-17 at 20:23 +0100, Francois Gouget wrote: > On Fri, 16 Feb 2007, WineHQ wrote: > > > ChangeSet ID: 30931 > > CVSROOT: /opt/cvs-commit > > Module name: lostwages > > Changes by: wineowner@winehq.org 2007/02/16 18:13:29 > > Could we get rid of wineowner account? It makes it impossible to know > who's doing the changes. Each user having access to the WineHQ box > should have his own login. > > Welcome back Brian (if I read the wwn right). > From vostok at etersoft.ru Sun Feb 18 07:06:04 2007 From: vostok at etersoft.ru (Anatoly Lyutin) Date: Sun Feb 18 09:28:16 2007 Subject: Lost KOI8-U. Message-ID: <45D84F3C.5050205@etersoft.ru> -------------- next part -------------- An embedded message was scrubbed... From: Anatoly Lyutin Subject: Lost KOI8-U. Date: Wed, 14 Feb 2007 11:49:33 +0300 Size: 775 Url: http://www.winehq.org/pipermail/wine-devel/attachments/20070218/77fbfd19/LostKOI8-U.mht From wine-devel at kievinfo.com Sun Feb 18 10:18:33 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 18 10:19:06 2007 Subject: [start][start] Output with console encoding Message-ID: <45D87C59.8070708@kievinfo.com> > Changelog: > Fix output console to output with console encoding. > static void output(const char *message) > Index: programs/start/start.c > =================================================================== > RCS file: /home/wine/wine/programs/start/start.c,v > retrieving revision 1.5 > diff -u -p -u -r1.5 start.c > --- programs/start/start.c 23 May 2006 12:49:22 -0000 1.5 > +++ programs/start/start.c 30 Jan 2007 09:47:52 -0000 > @@ -33,7 +33,20 @@ > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); > + > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; > + > + WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), bufC, len, &count, NULL); > + > + free(bufW); > + free(bufC); > } This is not correct. This function and everything else, using it should be rewritten as unicode, not ansi. Also you should use HeapAlloc/HeapFree. Vitaliy. From wine.dev at web.de Sun Feb 18 11:12:32 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Sun Feb 18 11:13:16 2007 Subject: generic.ppd does not appear in the build dir - cannot print In-Reply-To: <18e575130702171508p3af94ee6h3a7779a54ed2d4c1@mail.gmail.com> References: <18e575130702171508p3af94ee6h3a7779a54ed2d4c1@mail.gmail.com> Message-ID: <1171818752.7289.49.camel@p4> On Sa, 2007-02-17 at 18:08 -0500, Michael [Plouj] Ploujnikov wrote: > However, here are the messages that I started getting: > > $ wine notepad > Couldn't find PPD file This can only happen, when wine is unable to receive a ppd-File from CUPS and no ppd-file is configured in the registry. See my previous message : http://www.winehq.org/pipermail/wine-devel/2007-January/053617.html ("trace:winspool:CUPS_LoadPrinters loaded libcups.so.2") What do you get from: $ grep -i cups include/config.h Where is the library located, that is used in "#define SONAME_LIBCUPS" from above $ find /usr/l* -name libcups.* What do you get from: $ file $ file /usr/lib/libcups.* $ file /usr/lib64/libcups.* > After some playing around I realized that generic.pdd resides in my > Wine source checkout directory: > but not inside the build directory: That is an issue, that must be fixed in wine. > After finding a quick solution I'm wondering what, a person like me, > who builds (and runs) wine in a directory parallel to the source, I do the same here, but my wine is using CUPS -- By by ... Detlef From claudio.fontana at gmail.com Sun Feb 18 09:58:10 2007 From: claudio.fontana at gmail.com (Claudio Fontana) Date: Sun Feb 18 11:18:17 2007 Subject: kernel32 (profile.c): allow profile section and key names of zero length patch Message-ID: <2c04dc350702180758v4dc3fffdle775da4feccf5c07@mail.gmail.com> Hello all, I was wondering if there's anything wrong with my patch to kernel32/profile.c and its tests: http://www.winehq.org/pipermail/wine-patches/2007-February/035468.html It fixes a problem that causes applications built with Multimedia Fusion to fail under wine, since the "INI object" of MF relies on zero length section and key names to store and retrieve values. The changes in tests/profile.c contain new testcases, and a generally useful fix to the tests, where some values are currently passed directly to the functions instead of using the values in the testcases table. If there's anything unclear or wrong about this patch, please tell me so that I will be able to fix it. Thanks, Claudio From wine-devel at kievinfo.com Sun Feb 18 12:59:50 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 18 13:00:36 2007 Subject: winecfg: Add check for device access to Drives tab. In-Reply-To: <873b5ac94u.fsf@wine.dyndns.org> References: <45CD04B9.7080600@kievinfo.com> <873b5ac94u.fsf@wine.dyndns.org> Message-ID: <45D8A226.3040907@kievinfo.com> Alexandre Julliard wrote: > Vitaliy Margolen writes: > >> Any reasons why this patch is not applied? >> http://www.winehq.org/pipermail/wine-patches/2007-January/035264.html >> >> This is one of the major headaches for users trying to get programs >> requiring direct CD-ROM drive access to work. And it's nearly impossible >> to get required information from users to find if the direct access >> actually works or not. > > I think you should distinguish the case of no device at all from the > case of a SCSI ioctl failing, for instance loop mounts wouldn't > support the ioctl but would still work fine for many things. Also the That is exactly the point! Some "smart" users use iso images and complain that cd-checks fail. This is a more generic ioctl that will fail on a loop device. And that's a reason I used it. > no device case needs to be less scary, there's nothing wrong with it I disagree. It have to be scary! It have to tell user that they do not have direct access to the device. And that enything that will try doing that will fail! In most cases users will get some obscure error messages that will tell them nothing about the actual cause. I want to have at least one place where we can point users to go look if they have or properly configured system or not. > for most devices. And the strings need to be in resources. Will do that. Vitaliy. From truiken at gmail.com Sun Feb 18 13:17:31 2007 From: truiken at gmail.com (James Hawkins) Date: Sun Feb 18 13:17:41 2007 Subject: resend : gdi32:WidenPath partial implementation In-Reply-To: <45D8A3D8.9070609@vromman.org> References: <45D8A3D8.9070609@vromman.org> Message-ID: <22821af30702181117u55b68a05i2650f4dc1054dee2@mail.gmail.com> On 2/18/07, Laurent Vromman wrote: > Changelog : > - Add a partial implementation for the function gd32:WidenPath > > It is the second time I send this patch. It seems it was forgotten the > previous time. I am sorry for that. > > > If this patch needs to be improved, please let me know, I'll try to do it. > > Laurent Vromman > > > > > diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c > index 306ed37..d9ccbb3 100644 > --- a/dlls/gdi32/path.c > +++ b/dlls/gdi32/path.c > @@ -1823,6 +1823,14 @@ BOOL WINAPI StrokePath(HDC hdc) > /******************************************************************* > * WidenPath [GDI32.@] > * > + * Redefines the current path as the area that would be painted if the path were stroked using the pen currently selected into the given device context. > + * > + * PARAMS > + * hdc [I] Handle to a device context that contains a closed path. > + * > + * RETURNS > + * Success: TRUE. The path is updated with the new computed path. > + * Failure: FALSE. > * You copied this documentation word-for-word from msdn, which is not allowed. -- James Hawkins From nick at pu.if.ua Sun Feb 18 13:59:13 2007 From: nick at pu.if.ua (Oleh R. Nykyforchyn) Date: Sun Feb 18 13:52:47 2007 Subject: Lost KOI8-U. In-Reply-To: <45D84F3C.5050205@etersoft.ru> References: <45D84F3C.5050205@etersoft.ru> Message-ID: <20070218215913.825c1122.nick@pu.if.ua> On Sun, 18 Feb 2007 16:06:04 +0300 Anatoly Lyutin wrote: > For generate collation table The cpmap.pl (/libs/wine) takes data from > www.unicode.org and I find some bugs in it. > Cpmap.pl uses for generate KOI8-U but in www.unicode.org this file absences! > I can not understand it... =( Some time ago I proposed a patch to support KOI8-U, and it was committed. I submitted an extra function to cpmap.pl to build KOI8-U file from KOI8-R.TXT from unicode.org, but afterwards I found out that cpmap.pl is left almost intact, except for a reference to KOI8-U.TXT that is absent at unicode.org. I guess that there is KOI8-U.TXT added to the local copy of ftp.unicode.org at winehq.org. It is quite reasonable because KOI8-U is an approved RFC**** and there cannot be a confusion because of distinct versions of this file. I hope that Wine team will not abandon KOI8-U support, at least I depend on it. Oleh R. Nykyforchyn From m_demontis at tiscali.it Sun Feb 18 12:14:41 2007 From: m_demontis at tiscali.it (Mario Demontis) Date: Sun Feb 18 14:37:10 2007 Subject: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1 In-Reply-To: <1373421286.20060727230855@kievinfo.com> References: <1373421286.20060727230855@kievinfo.com> Message-ID: <1171822482.16004.4.camel@localhost.localdomain> Hello Vitaliy May you please send out the patches for ntoskrnl? Is there any reason why ntoskrnl doesn't get integrated into official wine? Regards Mario Il giorno gio, 27/07/2006 alle 23.08 -0600, Vitaliy Margolen ha scritto: > Same as before. Just recompiled with new version. > http://www.kievinfo.com/wine-0.9.18-1.2.i586.rpm > http://www.kievinfo.com/wine-0.9.18-1.2.src.rpm > From wine-devel at kievinfo.com Sun Feb 18 15:08:12 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 18 15:08:56 2007 Subject: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1 In-Reply-To: <1171822482.16004.4.camel@localhost.localdomain> References: <1373421286.20060727230855@kievinfo.com> <1171822482.16004.4.camel@localhost.localdomain> Message-ID: <45D8C03C.10203@kievinfo.com> Sorry but I'm not longer interested in working on something that will never be included in Wine. Why? I have no clue! If anyone can explain that it would be helpfull to know for whomever next will try this. I have removed all the related patches from my tree so that for sure won't be me. Vitaliy. Mario Demontis wrote: > Hello Vitaliy > May you please send out the patches for ntoskrnl? > > Is there any reason why ntoskrnl doesn't get integrated into official > wine? > > Regards > Mario > > Il giorno gio, 27/07/2006 alle 23.08 -0600, Vitaliy Margolen ha scritto: >> Same as before. Just recompiled with new version. >> http://www.kievinfo.com/wine-0.9.18-1.2.i586.rpm >> http://www.kievinfo.com/wine-0.9.18-1.2.src.rpm >> From rafgeens at gmail.com Sun Feb 18 16:03:58 2007 From: rafgeens at gmail.com (Raf Geens) Date: Sun Feb 18 16:04:06 2007 Subject: Mouse not warping properly in full screen mode Message-ID: <41341d460702181403w20105597wb627a0ec6d893a0c@mail.gmail.com> Hi, I'm new to Wine and DirectX development, but I've dug around a bit in the Wine source code to get Determinance, a sword-fighting game to work. I've submitted an entry for it to the application database. The main problem I had was with strange mouse behaviour in full screen mode. The player can rotate his character by holding down the right mouse button and moving the mouse. In Windows, this allows you to turn as much as you want. In Wine, the rotation stops at a certain point. You can't see the cursor, but I'm fairly certain the point at which movement stops is when the cursor hits the edge of the screen. When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour. I've isolated the problem to the following line in dlls/dinput/mouse.c : This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; Changing it to This->need_warp = TRUE; as a quick test makes the mouse behave correctly. I've read about the mouse warping hack over here: http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a TRACE statement displaying the variables in that line of code revealed that: - it is only executed in full screen mode, and not in windowed mode - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false. So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading about the meanings of the dwCoop values at msdn ( http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers might not have entirely been following the rules. However, it works properly on Windows. Would it be acceptable to drop the DISCL_EXCLUSIVE constraint? Raf Geens From thunder.m at czela.net Sun Feb 18 16:15:21 2007 From: thunder.m at czela.net (Mirek) Date: Sun Feb 18 16:15:40 2007 Subject: Mouse not warping properly in full screen mode In-Reply-To: <41341d460702181403w20105597wb627a0ec6d893a0c@mail.gmail.com> References: <41341d460702181403w20105597wb627a0ec6d893a0c@mail.gmail.com> Message-ID: <45D8CFF9.8040801@czela.net> Hi similar bug with mouse in TES IV: Oblivion was introduced in wine 0.9.31 Mirek Raf Geens napsal(a): > Hi, > > I'm new to Wine and DirectX development, but I've dug around a bit in > the Wine source code to get Determinance, a sword-fighting game to > work. I've submitted an entry for it to the application database. > > The main problem I had was with strange mouse behaviour in full screen > mode. The player can rotate his character by holding down the right > mouse button and moving the mouse. In Windows, this allows you to turn > as much as you want. In Wine, the rotation stops at a certain point. > You can't see the cursor, but I'm fairly certain the point at which > movement stops is when the cursor hits the edge of the screen. > > When this has happened and you return to the main menu, it can occur > that for example the cursor can't reach the top part of the screen > anymore. It's as if an invisible rectangle that keeps the cursor > inside the screen has moved. In such a case, moving the cursor all the > way to the bottom and back up again restores normal behaviour. > > I've isolated the problem to the following line in dlls/dinput/mouse.c : > > This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; > > Changing it to This->need_warp = TRUE; as a quick test makes the mouse > behave correctly. > > I've read about the mouse warping hack over here: > http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a > TRACE statement displaying the variables in that line of code revealed > that: > > - it is only executed in full screen mode, and not in windowed mode > - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false. > > So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading > about the meanings of the dwCoop values at msdn ( > http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers > might not have entirely been following the rules. However, it works > properly on Windows. Would it be acceptable to drop the > DISCL_EXCLUSIVE constraint? > > Raf Geens > > > From wine-devel at kievinfo.com Sun Feb 18 16:19:07 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 18 16:19:45 2007 Subject: Mouse not warping properly in full screen mode In-Reply-To: <41341d460702181403w20105597wb627a0ec6d893a0c@mail.gmail.com> References: <41341d460702181403w20105597wb627a0ec6d893a0c@mail.gmail.com> Message-ID: <45D8D0DB.8020404@kievinfo.com> Raf Geens wrote: > When this has happened and you return to the main menu, it can occur > that for example the cursor can't reach the top part of the screen > anymore. It's as if an invisible rectangle that keeps the cursor > inside the screen has moved. In such a case, moving the cursor all the > way to the bottom and back up again restores normal behaviour. > > I've isolated the problem to the following line in dlls/dinput/mouse.c : That's the consequence and not the real place where the problem is. > > This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; Wine'd dinput warps mouse in some cases (much lesser number then it was before) while it shouldn't do that at all! The real issue is in x11drv which should warp mouse and report "relative" mouse moves while it doesn't. I've sent two patches that haven't been applied yet. See bug 6971 for more info. Vitaliy. From wine-devel at kievinfo.com Sun Feb 18 16:58:11 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 18 16:58:51 2007 Subject: ANN: Wiki upgrade In-Reply-To: <3035.207.245.37.34.1171582355.squirrel@lattica.com> References: <3035.207.245.37.34.1171582355.squirrel@lattica.com> Message-ID: <45D8DA03.4030101@kievinfo.com> Dimi Paun wrote: > Folks, > > We finished upgrading the wiki to MoinMoin 1.5.7. > Please let me know if you encounter any problems. > Something hapaned to all tables. Ex: http://wiki.winehq.org/KnownIssues All cells have extra space in them. I don't see anything wrong with the text and it worked fine before. Vitaliy. From richardvoigt at gmail.com Sun Feb 18 19:30:47 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sun Feb 18 19:30:52 2007 Subject: -ansi, -pedantic warnings and errors on In-Reply-To: <45D849A7.4080206@codeweavers.com> References: <650848.70612.qm@web52706.mail.yahoo.com> <45D849A7.4080206@codeweavers.com> Message-ID: <2e59e6970702181730p4b2c38b6x9422c7c98bd6aa8e@mail.gmail.com> On 2/18/07, Robert Shearman wrote: > Joris Huizer wrote: > > Though the keyword "inline" implies the code should get inlined, and > > if it shouldn't, the implementation copy should be removed from the > > unicode.h file > > No, it's a hint to the compiler. "static inline" says to the compiler > try to inline this function if it is worth it, or otherwise include a > copy of this function in the object file. "extern inline" says to the > compiler try to inline this function if it is worth it, or otherwise > link to shared copy of this function (in our case, implemented in the > libwine shared object). I believe just "inline" by itself has that effect. One doesn't ordinarily put "extern" on the function definition (unless it's 'extern "C"'). > > -- > Rob Shearman > > > > From richardvoigt at gmail.com Sun Feb 18 19:37:52 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sun Feb 18 19:37:58 2007 Subject: 1/4 NtCreateMailslotFile tests In-Reply-To: <000601c752a0$002a84e0$0100a8c0@DMITRY> References: <45CEF57E.3010101@yless4u.com.au> <00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> <45D6C797.2000505@yless4u.com.au> <002001c75279$3081ec90$0100a8c0@DMITRY> <45D6D1AB.1030007@yless4u.com.au> <000601c752a0$002a84e0$0100a8c0@DMITRY> Message-ID: <2e59e6970702181737s7bd68099h990911e9214802ed@mail.gmail.com> > > Microsoft > > appears to be pushing people away from NtClose. > > I'd suggest you to find a reason why. That particular documentation happens to be part of the API released under court order. They didn't want to give it out to begin with, and they don't want people using it now. Perhaps someone should determine if there are any applications statically linking to any of those functions, which would disprove the claim "There is no import library, you must use GetProcAddress" and leave MS in violation of said order. From richardvoigt at gmail.com Sun Feb 18 19:40:09 2007 From: richardvoigt at gmail.com (richardvoigt@gmail.com) Date: Sun Feb 18 19:40:24 2007 Subject: Resend 1/4 NtCreateMailslotFile tests In-Reply-To: <45D7468E.2000904@wanadoo.fr> References: <45D6C93F.2060303@yless4u.com.au> <45D6D257.8030507@wanadoo.fr> <45D6D57D.4010009@yless4u.com.au> <45D7468E.2000904@wanadoo.fr> Message-ID: <2e59e6970702181740v41708fb6u9214c24c12476e25@mail.gmail.com> On 2/17/07, Eric Pouech wrote: > Jeff L a ?crit : > > Eric Pouech wrote: > >> Jeff Latimer a ?crit : > >>> Establish the framework for testing NtCreateMailslotFile. Have > >>> fixed issues with NTSTATUS return codes etc. > >> those tests belong to dlls/ntdll, not dlls/kernel32 > >> also, if the test is for ntdll functions, it shouldn't use kernel32 > >> ones... hence, NtClose should be used instead of CloseHandle > > I put the proposition a while ago about putting the tests in kernel32 > > as, although they are ntdll functions, they related to mailslot > > functions and relating the tests would be easier on the tester. I > > take it that that is not the case? > my call would be to put the tests for functions sitting in DLL X in the > directory X/tests, even if we need to rewrite some code (or bother some > code from some other tests) > but as the API are different, we need in the end the both sets of test > perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ? From scott at open-vote.org Sun Feb 18 21:10:16 2007 From: scott at open-vote.org (Scott Ritchie) Date: Sun Feb 18 21:08:36 2007 Subject: Let's get rid of the FAQ and move it into the wiki Message-ID: <1171854616.16510.4.camel@scott-desktop> Updating the FAQ is a bit of a pain, as is maintaining it. There is, after all, still a lot of ancient stuff in it. Why not just move it into the wiki and point the link on the web page there? I promise I'll watch it a bit closer. Thanks, Scott Ritchie From dank at kegel.com Sun Feb 18 22:11:46 2007 From: dank at kegel.com (Dan Kegel) Date: Sun Feb 18 22:11:54 2007 Subject: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627 In-Reply-To: References: Message-ID: [reposting to right list. Maybe I should break down and subscribe to wine-devel so I can just hit 'reply'...] Detlef wrote: >The Idea sounds good, but your Patch is wrong for every >system in the World, that does not use English as locale: Oh, right. Well, at least I'm enthusiastic, if not wise :-) I guess the way to fix this right would be to create IDS_PROGRAM_FILES_ACCESSORIES analogous to IDS_PROGRAM_FILES; that would let us localize the path in shell32.dll, and setupapi.dll could handle it just like it does IDS_PROGRAM_FILES already (it translates the %16422% into the localized Program Files directory name). Then maybe get rid of the need to create the directores in wineprefixcreate by modifying create_fake_dll in setupapi/fakedll.c to create the directories if they don't exist. Lotta trouble to go through just to support broken-ish apps that need to know where wordpad is, but maybe I'll see about doing it if nobody else fixes this. From dmitry at codeweavers.com Sun Feb 18 22:34:30 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sun Feb 18 22:34:48 2007 Subject: [start][start] Output with console encoding References: <45D86DB3.1010803@etersoft.ru> Message-ID: <007d01c753df$4341b2e0$0100a8c0@DMITRY> "Anatoly Lyutin" wrote: > @@ -33,7 +33,20 @@ > static void output(const char *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); Please do not use calloc/malloc calls in the Wine code, use win32 API HeapAlloc instead. > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; Please refer to other parts of Wine code how to properly allocate space for this kind of a conversion. -- Dmitry. From dmitry at codeweavers.com Sun Feb 18 22:39:03 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sun Feb 18 22:39:08 2007 Subject: [wineconsole][dialog] Fix inversion in work Up-down control (Option Dialog) References: <45D86BDF.20803@etersoft.ru> Message-ID: <009101c753df$e530edf0$0100a8c0@DMITRY> "Anatoly Lyutin" wrote: > struct dialog_info* di; > unsigned idc; > + unsigned nMaxHistUD = 500; > > switch (msg) > { > @@ -66,6 +67,8 @@ static INT_PTR WINAPI WCUSER_OptionDlgPr > di = (struct dialog_info*)((PROPSHEETPAGEA*)lParam)->lParam; > di->hDlg = hDlg; > SetWindowLongPtr(hDlg, DWLP_USER, (LONG_PTR)di); > + > + SendMessage(GetDlgItem(hDlg,IDC_OPT_HIST_SIZE_UD), UDM_SETRANGE, (WPARAM) 0, MAKELONG (nMaxHistUD, 0)); There is no need for (WPARAM) cast. Better use MAKELPARAM to construct an lParam instead of MAKELONG. Simple MAKELPARAM(500, 0) works just fine without introducing a new variable. -- Dmitry. From mk144210 at bcm.tmc.edu Mon Feb 19 00:00:26 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 19 00:02:05 2007 Subject: What does it mean if doing WINEDEBUG=+relay fixes a bug? Message-ID: <1171864826.18418.1.camel@misha-laptop> Hi, I am trying to debug bug #7484 but am having some problems as simply doing a WINEDEBUG=+relay causes this bug to be fixed, thus making it difficult for me to track it down (WINEDEBUG=+listview or WINEDEBUG= +snoop do not have this effect of fixing it). If there is something that the fact that this bug is fixed by +relay suggests, I would love to know. Thanks a lot Misha From marcus at jet.franken.de Mon Feb 19 00:48:10 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Mon Feb 19 00:48:15 2007 Subject: What does it mean if doing WINEDEBUG=+relay fixes a bug? In-Reply-To: <1171864826.18418.1.camel@misha-laptop> References: <1171864826.18418.1.camel@misha-laptop> Message-ID: <20070219064810.GA8827@galeere> On Mon, Feb 19, 2007 at 12:00:26AM -0600, Misha Koshelev wrote: > Hi, I am trying to debug bug #7484 but am having some problems as simply > doing a WINEDEBUG=+relay causes this bug to be fixed, thus making it > difficult for me to track it down (WINEDEBUG=+listview or WINEDEBUG= > +snoop do not have this effect of fixing it). If there is something that > the fact that this bug is fixed by +relay suggests, I would love to > know. This usually points to uninitialized variables or uninitialized memory on the stack, or timing issues or similar.. Ciao, Marcus From dmitry at codeweavers.com Mon Feb 19 02:37:05 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 19 02:37:13 2007 Subject: [PATCH 3/3] ntdll: fix up instruction pointer in context insideraise_exception References: <200702182232.44927.kumbayo84@arcor.de> Message-ID: <006301c75401$28b9bc70$0100a8c0@DMITRY> "Peter Oberndorfer" wrote: > I'm not fully sure if the fixup also happens for other architectures > (i guess not) > so this patch is more a RFC > @@ -336,6 +336,10 @@ static NTSTATUS raise_exception( EXCEPTION_RECORD *rec, CONTEXT *context, BOOL f > if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) > return STATUS_SUCCESS; > > + /* fix up instruction pointer in context for EXCEPTION_BREAKPOINT */ > + if (rec->ExceptionCode == EXCEPTION_BREAKPOINT) > + GET_IP(context) = (DWORD_PTR)GET_IP(context) - 1; Gary Nebbett's book "Windows Nt/2000 Native API Reference" in the section C "Exceptions and Debugging" provides a pseudocode for KiDispatchException (page 439, Example C.1), and it does exactly the same thing as the patch above. *But* it does it as a very first thing after getting the context and before sending the debugger event. -- Dmitry. From thestig at google.com Mon Feb 19 02:56:44 2007 From: thestig at google.com (Lei Zhang) Date: Mon Feb 19 02:56:59 2007 Subject: Let's get rid of the FAQ and move it into the wiki In-Reply-To: <1171854616.16510.4.camel@scott-desktop> References: <1171854616.16510.4.camel@scott-desktop> Message-ID: <558b2f5c0702190056g6769dd81x20e5cd917a3fb726@mail.gmail.com> On 2/18/07, Scott Ritchie wrote: > Updating the FAQ is a bit of a pain, as is maintaining it. There is, > after all, still a lot of ancient stuff in it. > > Why not just move it into the wiki and point the link on the web page > there? I promise I'll watch it a bit closer. > > Thanks, > Scott Ritchie > Sounds like a good idea to me. From meissner at suse.de Mon Feb 19 03:07:07 2007 From: meissner at suse.de (Marcus Meissner) Date: Mon Feb 19 03:07:11 2007 Subject: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1 In-Reply-To: <45D8C03C.10203@kievinfo.com> References: <1373421286.20060727230855@kievinfo.com> <1171822482.16004.4.camel@localhost.localdomain> <45D8C03C.10203@kievinfo.com> Message-ID: <20070219090707.GA8763@suse.de> On Sun, Feb 18, 2007 at 02:08:12PM -0700, Vitaliy Margolen wrote: > Sorry but I'm not longer interested in working on something that will > never be included in Wine. Why? I have no clue! If anyone can explain > that it would be helpfull to know for whomever next will try this. I > have removed all the related patches from my tree so that for sure won't > be me. > > Vitaliy. > > Mario Demontis wrote: > > Hello Vitaliy > > May you please send out the patches for ntoskrnl? > > > > Is there any reason why ntoskrnl doesn't get integrated into official > > wine? It needs major design work, as seen above. WINE will get there at some point in time, but its not foreseeable. Ciao, Marcus From lats at yless4u.com.au Mon Feb 19 05:40:12 2007 From: lats at yless4u.com.au (Jeff L) Date: Mon Feb 19 05:40:23 2007 Subject: 1/4 NtCreateMailslotFile tests In-Reply-To: <2e59e6970702181737s7bd68099h990911e9214802ed@mail.gmail.com> References: <45CEF57E.3010101@yless4u.com.au> <00bd01c74e5e$2bb51ad0$0100a8c0@DMITRY> <45D6C797.2000505@yless4u.com.au> <002001c75279$3081ec90$0100a8c0@DMITRY> <45D6D1AB.1030007@yless4u.com.au> <000601c752a0$002a84e0$0100a8c0@DMITRY> <2e59e6970702181737s7bd68099h990911e9214802ed@mail.gmail.com> Message-ID: <45D98C9C.9010401@yless4u.com.au> richardvoigt@gmail.com wrote: >> > Microsoft >> > appears to be pushing people away from NtClose. >> >> I'd suggest you to find a reason why. > That particular documentation happens to be part of the API released > under court order. They didn't want to give it out to begin with, and > they don't want people using it now. Ok I am happy with this as an explanation and will move the tests. Another case of MSDN telling fibs to the gullible. Jeff From julliard at winehq.org Mon Feb 19 06:30:24 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 19 06:30:28 2007 Subject: comctl32: rebar[1/4]: rewrite the layouting code In-Reply-To: <45D76F5B.5010809@zalewski.pl> (=?utf-8?Q?Miko=C5=82aj?= Zalewski's message of "Sat\, 17 Feb 2007 22\:10\:51 +0100") References: <45D76F5B.5010809@zalewski.pl> Message-ID: <87mz3a49en.fsf@wine.dyndns.org> Miko?aj Zalewski writes: > From 2b42e9b97b443ced2531a445b531fddc5db2dcad Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= > Date: Sat, 17 Feb 2007 19:24:25 +0100 > Subject: [PATCH] comctl32: rebar: rewrite the layouting code This crashes in make test: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so rebar.c && touch rebar.ok wine: Unhandled page fault on read access to 0xffff001a at address 0x601bb75b (thread 0024), starting debugger... WineDbg starting on pid 0023 Unhandled exception: page fault on read access to 0xffff001a in 32-bit code (0x601bb75b). err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got 1ef14dcf while expecting 31f52e76) Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:601bb75b ESP:0033e50c EBP:0033e548 EFLAGS:00010202( - 00 - -RI1) EAX:ffff001a EBX:7b8aa9a0 ECX:00000002 EDX:00000000 ESI:00000000 EDI:ffffffff Stack dump: 0x0033e50c: 7b85b545 ffff001a 00000000 606a0081 0x0033e51c: 605b4fbc 0015df30 00000006 0033e548 0x0033e52c: 6055ddc0 00000040 0000000c 00000006 0x0033e53c: 605e9244 0015e0fc 0033f560 0033e578 0x0033e54c: 6055de30 00000000 00000000 ffff001a 0x0033e55c: ffffffff 00000000 00000000 0033e578 Backtrace: =>1 0x601bb75b strlen+0xb() in libc.so.6 (0x0033e548) 2 0x6055de30 Str_SetPtrAtoW+0x60(lppDest=0x15e10c, lpSrc=0xffff001a) [/home/julliard/wine/wine/dlls/comctl32/comctl32undoc.c:949] in comctl32 (0x0033e578) 3 0x605c06ef TOOLBAR_AddButtonsT+0x14f(hwnd=0x4002c, wParam=0x6, lParam=0x33f53c, fUnicode=0x0) [/home/julliard/wine/wine/dlls/comctl32/toolbar.c:2880] in comctl32 (0x0033e5c8) 4 0x605c2842 ToolbarWindowProc+0x1b52(hwnd=0x4002c, uMsg=, wParam=0x6, lParam=0x33f53c) [/home/julliard/wine/wine/dlls/comctl32/toolbar.c:6622] in comctl32 (0x0033ee58) 5 0x606bb40a WINPROC_wrapper+0x1a() in user32 (0x0033ee88) 6 0x606bbb6b call_window_proc+0x6b(hwnd=, msg=0x414, wp=0x6, lp=0x33f53c, result=0x33f3b8, arg=0x605c0cf0) [/home/julliard/wine/wine/dlls/user32/winproc.c:452] in user32 (0x0033eec8) 7 0x606beae7 WINPROC_CallProcAtoW+0x2c7(callback=0x606bbb00, hwnd=0x4002c, msg=0x414, wParam=0x6, lParam=0x33f53c, result=0x33f3b8, arg=0x605c0cf0) [/home/julliard/wine/wine/dlls/user32/winproc.c:903] in user32 (0x0033f388) 8 0x606bf923 CallWindowProcA+0xc3(func=0xffff0014, hwnd=0x4002c, msg=, wParam=, lParam=0x33f53c) [/home/julliard/wine/wine/dlls/user32/winproc.c:2229] in user32 (0x0033f3c8) 9 0x60688023 call_window_proc+0xe3(hwnd=, msg=0x414, wparam=0x6, lparam=0x33f53c, unicode=0x0, same_thread=0x1) [/home/julliard/wine/wine/dlls/user32/message.c:1547] in user32 (0x0033f438) 10 0x6068bba1 SendMessageTimeoutA+0x201(hwnd=, msg=0x414, wparam=0x6, lparam=0x33f53c, flags=0x0, timeout=0x0, res_ptr=0x33f4e0) [/home/julliard/wine/wine/dlls/user32/message.c:2457] in user32 (0x0033f4a8) 11 0x6068bc5c SendMessageA+0x4c(hwnd=0x4002c, msg=0x414, wparam=0x6, lparam=0x33f53c) [/home/julliard/wine/wine/dlls/user32/message.c:2496] in user32 (0x0033f4e8) 12 0x60507938 build_toolbar+0x2c8(nr=0x1, hParent=) [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:79] in comctl32_test (0x0033f5e8) 13 0x60508011 add_band_w+0x71(hRebar=, lpszText=, cxMinChild=, cx=0x28, cxIdeal=0x64) [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:288] in comctl32_test (0x0033f778) 14 0x6050c205 func_rebar+0x4175() [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:358] in comctl32_test (0x0033fe58) 15 0x60525f20 run_test+0x120(name=0x1103a1) [/home/julliard/wine/wine/dlls/comctl32/tests/../../../include/wine/test.h:389] in comctl32_test (0x0033fea8) 16 0x605265a1 main+0x141(argc=, argv=) [/home/julliard/wine/wine/dlls/comctl32/tests/../../../include/wine/test.h:437] in comctl32_test (0x0033fed8) 17 0x6052666b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in comctl32_test (0x0033ff08) 18 0x7b86fbeb start_process+0xeb() in kernel32 (0x0033ffe8) 19 0x6001f7a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x601bb75b strlen+0xb in libc.so.6: cmpb %ch,0x0(%eax) Wine-dbg> -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Mon Feb 19 09:19:48 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 19 09:19:58 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: <200702191524.48341.stefan@codeweavers.com> References: <200702191524.48341.stefan@codeweavers.com> Message-ID: On 19/02/07, Stefan D?singer wrote: >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { This also checked the sampler state, not just the sampler. From julliard at winehq.org Mon Feb 19 09:24:53 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 19 09:25:26 2007 Subject: winecfg: Add check for device access to Drives tab. In-Reply-To: <45D8A226.3040907@kievinfo.com> (Vitaliy Margolen's message of "Sun\, 18 Feb 2007 11\:59\:50 -0700") References: <45CD04B9.7080600@kievinfo.com> <873b5ac94u.fsf@wine.dyndns.org> <45D8A226.3040907@kievinfo.com> Message-ID: <87irdy41bu.fsf@wine.dyndns.org> Vitaliy Margolen writes: > I disagree. It have to be scary! It have to tell user that they do not > have direct access to the device. And that enything that will try doing > that will fail! CD checks is a specific case, there are many other perfectly valid uses for loop mounts where direct SCSI access is not required. -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Mon Feb 19 09:40:44 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 19 09:41:05 2007 Subject: [9/10] WineD3D: Use VBOs for index buffers In-Reply-To: <200702191525.32934.stefan@codeweavers.com> References: <200702191525.32934.stefan@codeweavers.com> Message-ID: On 19/02/07, Stefan D?singer wrote: >+ GLint vbo; vbo should be a GLuint. From hverbeet at gmail.com Mon Feb 19 09:42:54 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 19 09:42:57 2007 Subject: [10/10] WineD3D: With FVFs only one stream is used In-Reply-To: <200702191526.32045.stefan@codeweavers.com> References: <200702191526.32045.stefan@codeweavers.com> Message-ID: Eventually, the FVF path should be removed from wined3d completely. We should convert the FVF in d3d8 to a vertex declaration, just like in d3d9. From eric.pouech at wanadoo.fr Mon Feb 19 10:24:18 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Mon Feb 19 10:26:54 2007 Subject: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it. In-Reply-To: <45D9BED7.2020204@codeweavers.com> References: <45D9BED7.2020204@codeweavers.com> Message-ID: <45D9CF32.1040100@wanadoo.fr> Robert Shearman a ?crit : > > Keep the debuglink elf_file_map mapped until after > elf_new_public_symbols is called, otherwise we could use unmapped memory. this is still not the full valid solution... what should be done is: when we search for a given section, we should look first in the original .so, then, if not found, in the .gnu_debuglink one... your patch only covers the case where all relevant information is to be found in the .gnu_debuglink file, which is not guaranteed A+ From rob at codeweavers.com Mon Feb 19 10:34:36 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 19 10:35:13 2007 Subject: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it. In-Reply-To: <45D9CF32.1040100@wanadoo.fr> References: <45D9BED7.2020204@codeweavers.com> <45D9CF32.1040100@wanadoo.fr> Message-ID: <45D9D19C.6070701@codeweavers.com> Eric Pouech wrote: > Robert Shearman a ?crit : >> >> Keep the debuglink elf_file_map mapped until after >> elf_new_public_symbols is called, otherwise we could use unmapped >> memory. > > this is still not the full valid solution... what should be done is: > when we search for a given section, we should look first in the > original .so, then, if not found, in the .gnu_debuglink one... > your patch only covers the case where all relevant information is to > be found in the .gnu_debuglink file, which is not guaranteed And that should be easier for an interested person to do after this patch is applied, right? I was just interested in getting rid of bogus crc errors when using winedbg. -- Rob Shearman From kumbayo84 at arcor.de Mon Feb 19 13:14:39 2007 From: kumbayo84 at arcor.de (Peter Oberndorfer) Date: Mon Feb 19 13:19:34 2007 Subject: [PATCH 3/3] ntdll: fix up instruction pointer in context insideraise_exception In-Reply-To: <006301c75401$28b9bc70$0100a8c0@DMITRY> References: <200702182232.44927.kumbayo84@arcor.de> <006301c75401$28b9bc70$0100a8c0@DMITRY> Message-ID: <200702192014.40747.kumbayo84@arcor.de> On Monday 19 February 2007 09:37, Dmitry Timoshkov wrote: > "Peter Oberndorfer" wrote: > > > I'm not fully sure if the fixup also happens for other architectures > > (i guess not) > > so this patch is more a RFC > > > @@ -336,6 +336,10 @@ static NTSTATUS raise_exception( EXCEPTION_RECORD *rec, CONTEXT *context, BOOL f > > if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) > > return STATUS_SUCCESS; > > > > + /* fix up instruction pointer in context for EXCEPTION_BREAKPOINT */ > > + if (rec->ExceptionCode == EXCEPTION_BREAKPOINT) > > + GET_IP(context) = (DWORD_PTR)GET_IP(context) - 1; > > Gary Nebbett's book "Windows Nt/2000 Native API Reference" in the section C > "Exceptions and Debugging" provides a pseudocode for KiDispatchException > (page 439, Example C.1), and it does exactly the same thing as the patch > above. *But* it does it as a very first thing after getting the context and > before sending the debugger event. > The strange thing is my testcase [patch 2/3] shows/(should show) that the debugger gets a unmodified eip for a first chance exception + ? ? ? ? ? ? ? ? ? ?if (de.u.Exception.dwFirstChance) + ? ? ? ? ? ? ? ? ? ?{ + ? ? ? ? ? ? ? ? ? ? ? ?/* debugger gets first chance exception with unmodified ctx.Eip */ + ? ? ? ? ? ? ? ? ? ? ? ?ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xb, "Eip at %x instead of 0x%x\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ?ctx.Eip, (DWORD)code_mem_address + 0xb); and the modified one when the application did not handle the exception + ? ? ? ? ? ? ? ? ? ?else + ? ? ? ? ? ? ? ? ? ?{ + ? ? ? ? ? ? ? ? ? ? ? ?/* debugger gets context after exception handler has played with it */ + ? ? ? ? ? ? ? ? ? ? ? ?/* ctx.Eip is the same value the exception handler got */ + ? ? ? ? ? ? ? ? ? ? ? ?if (de.u.Exception.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT) + ? ? ? ? ? ? ? ? ? ? ? ?{ + ? ? ? ? ? ? ? ? ? ? ? ? ? ?todo_wine{ + ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xa, "Eip at %x instead of 0x%x\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ctx.Eip, (DWORD)code_mem_address + 0xa); + ? ? ? ? ? ? ? ? ? ? ? ? ? ?} i tested this testcase on XP and 2K Unfortunetely i don't own that book :-( Could you please verify in the pseudocode that the modified context gets sent to the debugger, and not some unmodified copy? Or maybe they unfix the context again in the send_to_debugger function ;-) Or the pseudo code is not fully correct. Thanks, Greetings Peter From core5fedora at gmail.com Mon Feb 19 13:21:39 2007 From: core5fedora at gmail.com (Jeffrey Sabarese) Date: Mon Feb 19 13:21:52 2007 Subject: a big fan of your work Message-ID: hi there! I have to wonder if i don't use WinE more than the "average" Fedora Core 5 user. I am forever trying to figure out how to run my old Windows apps here in the linux environment, using your incredible software. If ever you seek a "test subject", or feedback of any kind, please don't hesitate to include me as a candidate for some "volunteer work". If i may be so bold, i wish to address an issue related to WinE and some Web Development software: I have been able to successfully install, and use the Web Dev IDE, HomeSite+ (as in "the homesite which comes w/ dreamweaver nowadays"). previous to this, i was unable to get Bradbury's TopStyle Lite to operate under WinE due to the inability to "find Internet Exlorer", yet it seems as though HomeSite opens TopStyle w/out it's dependecy on IE keeping it from opening (bypassing the "warning" you might say). [can i just say it's sooo cool to finally have TopStyle here in Linux!!! thank you!). I guess you could say then that my question for you is: "How might i go about trying to get IE6 to be "recognized" by such WinE-apps as TopStyle?" I have installed, and use the "ies4linux" ( here for more info if you're unfamiliar with it: http://novicenotes.com/install-internet-explorer-on-linux-under-wine-run-ie-on-linux/ ), but though it works VERY well launching from the Fedora Terminal, i can't seem to get it to be recognized by "Windows" (WinE) as an available Browser. The apps i've tried which seem unable to integrate it are i. EditPlus 2.x (current) ii. TSW WebCoder 5 (as TSW Webcoder 2005 ( Delphi ) will NOT run on WinE, though i wish i did as i have a purchased licence) iii. TopStyle Lite iv. HomeSite Dreamweaver 8 will both run on WinE, and execute "normally", the ies4linux IE6-- yet, obviously there is a primary difference in that IE is NOT integrated into DreamWeaver as "part of the app", as it is in WebCoder and TopStyle. My best guess is that those apps have some security measure preventing a "non-standard" IE to become part of its processes. who knows. anyway-- i thought there was something else, but i suppose that's more than enough b.s. from me from one sitting. good luck in your work! if you have any ideas for my situation, i'd appriciate your input. again, please don't hesitate to inquire if you'd like for me to "test" anything for you and report my findings. i realize you probably have a whole lot of people already out there, but feel free to add me to the list. thanks, --Jeff Sabarese From eric.pouech at wanadoo.fr Mon Feb 19 13:21:47 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Mon Feb 19 13:22:29 2007 Subject: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it. In-Reply-To: <45D9D19C.6070701@codeweavers.com> References: <45D9BED7.2020204@codeweavers.com> <45D9CF32.1040100@wanadoo.fr> <45D9D19C.6070701@codeweavers.com> Message-ID: <45D9F8CB.1030109@wanadoo.fr> Robert Shearman a ?crit : > Eric Pouech wrote: >> Robert Shearman a ?crit : >>> >>> Keep the debuglink elf_file_map mapped until after >>> elf_new_public_symbols is called, otherwise we could use unmapped >>> memory. >> >> this is still not the full valid solution... what should be done is: >> when we search for a given section, we should look first in the >> original .so, then, if not found, in the .gnu_debuglink one... >> your patch only covers the case where all relevant information is to >> be found in the .gnu_debuglink file, which is not guaranteed > > And that should be easier for an interested person to do after this > patch is applied, right? I was just interested in getting rid of bogus > crc errors when using winedbg. > first, it's not exactly what your patch is entirely about... your patch ensures that the newly .gnu_debuglink mapped file is present for symbols resolution... and the bogus CRC errors come from the fact that we have an ERR for that, were it should be a WARN... a user could have different versions of the debug info files secondly, the correct fix will require a rewrite of the mapping algorithm itself, which is rather orthogonal to what you did my reco would simply to downgrade the ERR to a WARN if you don't want to go into the full fix A+ From eric.pouech at wanadoo.fr Mon Feb 19 13:22:17 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Mon Feb 19 13:24:35 2007 Subject: Resend 1/4 NtCreateMailslotFile tests In-Reply-To: <2e59e6970702181740v41708fb6u9214c24c12476e25@mail.gmail.com> References: <45D6C93F.2060303@yless4u.com.au> <45D6D257.8030507@wanadoo.fr> <45D6D57D.4010009@yless4u.com.au> <45D7468E.2000904@wanadoo.fr> <2e59e6970702181740v41708fb6u9214c24c12476e25@mail.gmail.com> Message-ID: <45D9F8E9.5090803@wanadoo.fr> richardvoigt@gmail.com a ?crit : > On 2/17/07, Eric Pouech wrote: >> Jeff L a ?crit : >> > Eric Pouech wrote: >> >> Jeff Latimer a ?crit : >> >>> Establish the framework for testing NtCreateMailslotFile. Have >> >>> fixed issues with NTSTATUS return codes etc. >> >> those tests belong to dlls/ntdll, not dlls/kernel32 >> >> also, if the test is for ntdll functions, it shouldn't use kernel32 >> >> ones... hence, NtClose should be used instead of CloseHandle >> > I put the proposition a while ago about putting the tests in kernel32 >> > as, although they are ntdll functions, they related to mailslot >> > functions and relating the tests would be easier on the tester. I >> > take it that that is not the case? >> my call would be to put the tests for functions sitting in DLL X in the >> directory X/tests, even if we need to rewrite some code (or bother some >> code from some other tests) >> but as the API are different, we need in the end the both sets of test >> > > perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ? > > dlls/ntdll/tests/mailslot.c A+ From eric.pouech at wanadoo.fr Mon Feb 19 13:28:11 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Mon Feb 19 13:28:52 2007 Subject: [PATCH] return when not finding the name In-Reply-To: <20070218133921.GA26052@galeere> References: <45D8492C.5040705@wanadoo.fr> <20070218133921.GA26052@galeere> Message-ID: <45D9FA4B.3070806@wanadoo.fr> Marcus Meissner a ?crit : > On Sun, Feb 18, 2007 at 01:40:12PM +0100, Eric Pouech wrote: > >> Marcus Meissner a ?crit : >> >>> --- >>> dlls/dbghelp/dwarf.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c >>> index 4f74b6a..f51a948 100644 >>> --- a/dlls/dbghelp/dwarf.c >>> +++ b/dlls/dbghelp/dwarf.c >>> @@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar >>> >>> TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); >>> >>> - if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string >>> = NULL; >>> + if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; >>> if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) >>> value.u.svalue = 0; >>> symt_add_enum_element(ctx->module, parent, name.u.string, >>> value.u.svalue); >>> >>> >>> >> Hi Marcus, >> >> can you send me the ELF file(s) which is/are causing this? >> > > There is no ELF file. > > Coverity spotted this as error, since name.u.string can be NULL > in the flow and symt_add_enum_element() would crash in pool_strdup. > > It is CID 461. 462 and 463 are related issues. > > Ciao, Marcus > the point is that the code paths you're trying to fix would only be taken in case of corrupt ELF file (those attributes are mandatory in the dwarf specs) the proposed fix is not correct as we'll still have NULL references (to the objects for enumerators and variables you don't create) and this will crash later on so, I'd rather fix the symbol.c file by allowing to have NULL names for those objects, this will less likely lead to a crash A+ From rob at codeweavers.com Mon Feb 19 13:37:19 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 19 13:38:01 2007 Subject: a big fan of your work In-Reply-To: References: Message-ID: <45D9FC6F.9010006@codeweavers.com> Jeffrey Sabarese wrote: > I guess you could say then that my question for you is: > "How might i go about trying to get IE6 to be "recognized" by such > WinE-apps as TopStyle?" > > I have installed, and use the "ies4linux" I believe ies4linux installs IE in a different WINEPREFIX to the default. Therefore, you either need to install IE without using ies4linux (preferable) or use "WINEPREFIX=~/.ies4linux wine ..." when installing your programs. Given that the author of ies4linux is riding the wave of Wine's success, without giving any contributions back either financial or in code, many people here will be unlikely to help you if you have any difficulties in the former configuration. -- Rob Shearman From rob at codeweavers.com Mon Feb 19 17:16:27 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 19 17:17:08 2007 Subject: [start][start][try2] Output with console encoding In-Reply-To: <45D9B119.1020707@etersoft.ru> References: <45D9B119.1020707@etersoft.ru> Message-ID: <45DA2FCB.307@codeweavers.com> Anatoly Lyutin wrote: > + len = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); > + bufW = HeapAlloc( GetProcessHeap(), 0, len ); > + len is in WCHARs, not bytes so this will cause heap corruption. It really would be a lot easier to make "output" take a Unicode string instead. -- Rob Shearman From mk144210 at bcm.tmc.edu Mon Feb 19 17:42:38 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 19 17:43:19 2007 Subject: Working on JScript/VBScript support for MSI Message-ID: <1171928558.20239.5.camel@misha-laptop> Hi, since MSDN states that any installer that requires JScript/VBScript must make sure to install it, and since some applications require these for install (bug #7353 and another one is there for VBScript for a different installer), I figure there is no reason why builtin MSI cannot use Microsoft Script if it is there (and plus when we have our own JScript/VBScript we will be able to use it off the bat with MSI). I have posted my initial work on this on the bugzilla for bug #7353. The first file (a patch, will attach also) is my patch which updates custom.c to have the appropriate handlers for the custom action types, extracts the script from the appropriate place, writes it to a file, and uses a framework very similar to the current thread framework for DLLs to call my helper call_script function. This first patch, in theory, should not have to change much (if at all), although I have not thoroughly tested it yet so it probably will. The second file (and attached here too) is dlls/msi/script.c, which is where the meat and potatoes of the actual call_script function is/will be. Right now it is pretty barebones, but it does load the script from the file and calls it appropriately. Now I am working on implementing the Session object, although it looks like a wrapper around MSI functions we already have so I think it should be doable. Anyways, any comments on my work so far will be appreciated. Misha -------------- next part -------------- From 027366c3e742f8368522bbc85f1bdf1483c64721 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Mon, 19 Feb 2007 17:29:15 -0600 Subject: msi: Added initial JScript/VBScript support functions. --- dlls/msi/Makefile.in | 1 dlls/msi/custom.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++ dlls/msi/msipriv.h | 1 3 files changed, 219 insertions(+), 0 deletions(-) diff --git a/dlls/msi/Makefile.in b/dlls/msi/Makefile.in index 5fb0941..3f6fd87 100644 --- a/dlls/msi/Makefile.in +++ b/dlls/msi/Makefile.in @@ -37,6 +37,7 @@ C_SRCS = \ record.c \ registry.c \ regsvr.c \ + script.c \ select.c \ source.c \ string.c \ diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index ba5c825..8b5401e 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -58,6 +58,14 @@ static UINT HANDLE_CustomType50(MSIPACKA LPCWSTR target, const INT type, LPCWSTR action); static UINT HANDLE_CustomType34(MSIPACKAGE *package, LPCWSTR source, LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); typedef UINT (WINAPI *MsiCustomActionEntryPoint)( MSIHANDLE ); @@ -266,6 +274,22 @@ UINT ACTION_CustomAction(MSIPACKAGE *pac rc = MSI_SetPropertyW(package,source,deformated); msi_free(deformated); break; + case 37: /* JScript/VBScript text stored in target column. */ + case 38: + rc = HANDLE_CustomType37_38(package,source,target,type,action); + break; + case 5: + case 6: /* JScript/VBScript file stored in a Binary table stream. */ + rc = HANDLE_CustomType5_6(package,source,target,type,action); + break; + case 21: /* JScript/VBScript file installed with the product. */ + case 22: + rc = HANDLE_CustomType21_22(package,source,target,type,action); + break; + case 53: /* JScript/VBScript text specified by a property value. */ + case 54: + rc = HANDLE_CustomType53_54(package,source,target,type,action); + break; default: FIXME("UNHANDLED ACTION TYPE %i (%s %s)\n", type & CUSTOM_ACTION_TYPE_MASK, debugstr_w(source), @@ -855,6 +879,199 @@ static UINT HANDLE_CustomType34(MSIPACKA return wait_process_handle(package, type, info.hProcess, action); } +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + TRACE("%s %s\n", debugstr_w( info->dllname ), debugstr_w( info->function ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + TRACE("calling %s\n", debugstr_w( info->function ) ); + r = call_script( info->package, info->type, info->dllname, info->function, info->action); + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} + +static DWORD WINAPI ScriptThread( LPVOID arg ) +{ + LPGUID guid = arg; + DWORD rc = 0; + + TRACE("custom action (%x) started\n", GetCurrentThreadId() ); + + rc = ACTION_CallScript( guid ); + + TRACE("custom action (%x) returned %i\n", GetCurrentThreadId(), rc ); + + MsiCloseAllHandles(); + return rc; +} + +static msi_custom_action_info *do_msidbCustomActionTypeScript( + MSIPACKAGE *package, INT type, LPCWSTR dllname, LPCWSTR function, LPCWSTR action ) +{ + msi_custom_action_info *info; + + info = msi_alloc( sizeof *info ); + if (!info) + return NULL; + + msiobj_addref( &package->hdr ); + info->package = package; + info->type = type; + info->function = strdupW( function ); + info->dllname = strdupW( dllname ); + info->action = strdupW( action ); + CoCreateGuid( &info->guid ); + + EnterCriticalSection( &msi_custom_action_cs ); + list_add_tail( &msi_pending_custom_actions, &info->entry ); + LeaveCriticalSection( &msi_custom_action_cs ); + + info->handle = CreateThread( NULL, 0, ScriptThread, &info->guid, 0, NULL ); + if (!info->handle) + { + free_custom_action_data( info ); + return NULL; + } + + return info; +} + +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR tmp_file[MAX_PATH]; + WCHAR fmt[MAX_PATH]; + static const WCHAR f1[] = {'m','s','i',0}; + HANDLE file; + DWORD sz, write; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + if (MSI_GetPropertyW(package, cszTempFolder, fmt, &sz) != ERROR_SUCCESS) + GetTempPathW(MAX_PATH, fmt); + + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) + { + TRACE("Unable to create file\n"); + return ERROR_FUNCTION_FAILED; + } + track_tempfile(package, tmp_file); + + /* Write out script from target field to file (a little roundabout but makes script code simpler) */ + file = CreateFileW(tmp_file, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, + FILE_ATTRIBUTE_NORMAL, NULL); + if (file == INVALID_HANDLE_VALUE) + return ERROR_FUNCTION_FAILED; + else + { + WriteFile(file, target, sizeof(WCHAR)*strlenW(target), &write, NULL); + CloseHandle(file); + } + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR tmp_file[MAX_PATH]; + UINT r; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + r = store_binary_to_temp(package, source, tmp_file); + if (r != ERROR_SUCCESS) + return r; + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, target, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + MSIFILE *file; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + file = get_loaded_file(package,source); + if (!file) + { + ERR("invalid file key %s\n", debugstr_w(source)); + return ERROR_FUNCTION_FAILED; + } + + info = do_msidbCustomActionTypeScript( package, type, file->TargetPath, target, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR *prop; + WCHAR tmp_file[MAX_PATH]; + WCHAR fmt[MAX_PATH]; + static const WCHAR f1[] = {'m','s','i',0}; + HANDLE file; + DWORD sz, write; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + prop = msi_dup_property(package,source); + if (!prop) + return ERROR_SUCCESS; + + if (MSI_GetPropertyW(package, cszTempFolder, fmt, &sz) != ERROR_SUCCESS) + GetTempPathW(MAX_PATH, fmt); + + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) + { + TRACE("Unable to create file\n"); + return ERROR_FUNCTION_FAILED; + } + track_tempfile(package, tmp_file); + + /* Write out script from target field to file (a little roundabout but makes script code simpler) */ + file = CreateFileW(tmp_file, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, + FILE_ATTRIBUTE_NORMAL, NULL); + if (file == INVALID_HANDLE_VALUE) + return ERROR_FUNCTION_FAILED; + else + { + WriteFile(file, prop, sizeof(WCHAR)*strlenW(prop), &write, NULL); + CloseHandle(file); + } + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); + + return wait_thread_handle( info ); +} + void ACTION_FinishCustomActions(MSIPACKAGE* package) { struct list *item; diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h index b01bb27..b00dc11 100644 --- a/dlls/msi/msipriv.h +++ b/dlls/msi/msipriv.h @@ -750,6 +750,7 @@ extern UINT ACTION_RegisterMIMEInfo(MSIP extern UINT ACTION_RegisterFonts(MSIPACKAGE *package); /* Helpers */ +extern DWORD call_script(MSIPACKAGE *package, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action); extern DWORD deformat_string(MSIPACKAGE *package, LPCWSTR ptr, WCHAR** data ); extern LPWSTR msi_dup_record_field(MSIRECORD *row, INT index); extern LPWSTR msi_dup_property(MSIPACKAGE *package, LPCWSTR prop); -- 1.4.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: script.c Type: text/x-csrc Size: 10887 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070219/073f522f/script-0001.c From thunder.m at czela.net Mon Feb 19 18:27:23 2007 From: thunder.m at czela.net (Mirek) Date: Mon Feb 19 18:27:33 2007 Subject: [2/2] quartz: Return proper error codes from GraphBuilder_RenderFile In-Reply-To: <200702172355.32928.chris.kcat@gmail.com> References: <200702172355.32928.chris.kcat@gmail.com> Message-ID: <45DA406B.4000703@czela.net> Hi, this patch caused regression in TES IV: Oblivion, now it can't run, here is output: fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found wine: Unhandled page fault on read access to 0xffffffea at address 0x7bfd278f (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0xffffffea in 32-bit code (0x7bfd278f). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7bfd278f ESP:0034f098 EBP:0034f1d0 EFLAGS:00010282( - 00 - RIS1) EAX:00000001 EBX:7bffec00 ECX:0034f198 EDX:ffffffea ESI:80004005 EDI:00000001 Stack dump: 0x0034f098: 115cc680 00000001 0034f198 0034f19c 0x0034f0a8: 00000000 00000001 00000001 0034f150 0x0034f0b8: 00000000 00000000 00000000 00000000 0x0034f0c8: 00000000 00000000 00000000 00000000 0x0034f0d8: 0034f108 7efa09be 7bff527c 0034f19c 0x0034f0e8: 0034f198 0034f1ac 0034f1a8 00000010 Backtrace: =>1 0x7bfd278f GraphBuilder_RenderFile+0x66f(iface=0x115cb968, lpcwstrFile=0x34f3f0, lpcwstrPlayList=0x0) [/usr/src/wine/dlls/q uartz/filtergraph.c:1094] in quartz (0x0034f1d0) 2 0x0069302b in oblivion (+0x29302b) (0x00000008) 3 0x00000000 (0x00000000) 0x7bfd278f GraphBuilder_RenderFile+0x66f [/usr/src/wine/dlls/quartz/filtergraph.c:1094] in quartz: movl 0x0(%edx),%eax 1094 IBaseFilter_Release(psplitter); Modules: Module Address Debug info Name (109 modules) PE 400000-b59000 Export oblivion PE b60000-daf000 Deferred d3dx9_27 PE 18000000-18068000 Deferred binkw32 PE 70000000-700b2000 Deferred dinput8 ELF 7b2de000-7b2f2000 Deferred avicap32 \-PE 7b2e0000-7b2f2000 \ avicap32 ELF 7b2f2000-7b38b000 Deferred oleaut32 \-PE 7b300000-7b38b000 \ oleaut32 ELF 7bf00000-7bf03000 Deferred ELF 7bf81000-7bfa8000 Deferred msvfw32 \-PE 7bf90000-7bfa8000 \ msvfw32 ELF 7bfa8000-7c000000 Dwarf quartz \-PE 7bfb0000-7c000000 \ quartz ELF 7c4b4000-7c4bf000 Deferred libgcc_s.so.1 ELF 7c5a4000-7c634000 Deferred libglu.so.1 ELF 7c634000-7c653000 Deferred devenum \-PE 7c640000-7c653000 \ devenum ELF 7c653000-7c70d000 Deferred wined3d \-PE 7c660000-7c70d000 \ wined3d ELF 7c70d000-7c737000 Deferred d3d9 \-PE 7c710000-7c737000 \ d3d9 ELF 7c857000-7c86b000 Deferred winejoystick \-PE 7c860000-7c86b000 \ winejoystick ELF 7c86b000-7c882000 Deferred cfgmgr32 \-PE 7c870000-7c882000 \ cfgmgr32 ELF 7c882000-7c8de000 Deferred setupapi \-PE 7c890000-7c8de000 \ setupapi ELF 7c8de000-7c8f2000 Deferred hid \-PE 7c8e0000-7c8f2000 \ hid ELF 7c9ed000-7caae000 Deferred libasound.so.2 ELF 7caae000-7cad9000 Deferred winealsa \-PE 7cac0000-7cad9000 \ winealsa ELF 7cad9000-7cb0b000 Deferred uxtheme \-PE 7cae0000-7cb0b000 \ uxtheme ELF 7cd9e000-7cdb3000 Deferred midimap \-PE 7cda0000-7cdb3000 \ midimap ELF 7cdb3000-7cdb8000 Deferred libxfixes.so.3 ELF 7cdbd000-7cdd5000 Deferred msacm32 \-PE 7cdc0000-7cdd5000 \ msacm32 ELF 7cdd7000-7cdda000 Deferred libxinerama.so.1 ELF 7cddd000-7cdf9000 Deferred imm32 \-PE 7cde0000-7cdf9000 \ imm32 ELF 7d7a3000-7d7a5000 Deferred libnvidia-tls.so.1 ELF 7d7a5000-7e116000 Deferred libglcore.so.1 ELF 7e116000-7e1aa000 Deferred libgl.so.1 ELF 7e1aa000-7e1af000 Deferred libxdmcp.so.6 ELF 7e1af000-7e1b2000 Deferred libxau.so.6 ELF 7e1b2000-7e29e000 Deferred libx11.so.6 ELF 7e29e000-7e2ac000 Deferred libxext.so.6 ELF 7e2ac000-7e2b1000 Deferred libxxf86vm.so.1 ELF 7e2b1000-7e2c9000 Deferred libice.so.6 ELF 7e2c9000-7e2d2000 Deferred libsm.so.6 ELF 7e2d3000-7e2dc000 Deferred libxcursor.so.1 ELF 7e2dc000-7e2df000 Deferred libxrandr.so.2 ELF 7e2df000-7e2e7000 Deferred libxrender.so.1 ELF 7e2f1000-7e37f000 Deferred winex11 \-PE 7e300000-7e37f000 \ winex11 ELF 7e3fb000-7e41b000 Deferred libexpat.so.1 ELF 7e41b000-7e446000 Deferred libfontconfig.so.1 ELF 7e446000-7e45a000 Deferred libz.so.1 ELF 7e45a000-7e4c4000 Deferred libfreetype.so.6 ELF 7e4e3000-7e50f000 Deferred ws2_32 \-PE 7e4f0000-7e50f000 \ ws2_32 ELF 7e50f000-7e529000 Deferred wsock32 \-PE 7e520000-7e529000 \ wsock32 ELF 7e529000-7e58d000 Deferred msvcrt \-PE 7e540000-7e58d000 \ msvcrt ELF 7e58d000-7e5a1000 Deferred lz32 \-PE 7e590000-7e5a1000 \ lz32 ELF 7e5a1000-7e5f9000 Deferred shlwapi \-PE 7e5b0000-7e5f9000 \ shlwapi ELF 7e5f9000-7e6ee000 Deferred shell32 \-PE 7e610000-7e6ee000 \ shell32 ELF 7e6ee000-7e701000 Deferred libresolv.so.2 ELF 7e707000-7e720000 Deferred version \-PE 7e710000-7e720000 \ version ELF 7e720000-7e73e000 Deferred iphlpapi \-PE 7e730000-7e73e000 \ iphlpapi ELF 7e73e000-7e793000 Deferred rpcrt4 \-PE 7e750000-7e793000 \ rpcrt4 ELF 7e793000-7e82c000 Deferred ole32 \-PE 7e7a0000-7e82c000 \ ole32 ELF 7e82c000-7e875000 Deferred dsound \-PE 7e830000-7e875000 \ dsound ELF 7e875000-7e903000 Deferred winmm \-PE 7e880000-7e903000 \ winmm ELF 7e903000-7e949000 Deferred advapi32 \-PE 7e910000-7e949000 \ advapi32 ELF 7e949000-7e9dc000 Deferred gdi32 \-PE 7e960000-7e9dc000 \ gdi32 ELF 7e9dc000-7eb16000 Deferred user32 \-PE 7ea00000-7eb16000 \ user32 ELF 7eb16000-7ebd6000 Deferred comctl32 \-PE 7eb20000-7ebd6000 \ comctl32 ELF 7edd6000-7eefc000 Deferred kernel32 \-PE 7edf0000-7eefc000 \ kernel32 ELF 7eefc000-7ef07000 Deferred libnss_files.so.2 ELF 7ef07000-7ef11000 Deferred libnss_nis.so.2 ELF 7ef11000-7ef27000 Deferred libnsl.so.1 ELF 7ef27000-7ef4c000 Deferred libm.so.6 ELF 7ef6b000-7f000000 Deferred ntdll \-PE 7ef80000-7f000000 \ ntdll ELF b7cb6000-b7cba000 Deferred libdl.so.2 ELF b7cba000-b7dec000 Deferred libc.so.6 ELF b7dec000-b7dfe000 Deferred libpthread.so.0 ELF b7e11000-b7e15000 Deferred iso8859-2.so ELF b7e15000-b7e1e000 Deferred libnss_compat.so.2 ELF b7e1e000-b7f2f000 Deferred libwine.so.1 ELF b7f31000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) G:\usr\games\oblivion\Oblivion.exe 00000010 2 0000000f -1 0000000e -1 0000000d 15 00000009 0 <== Mirek Chris Robinson napsal(a): > > ------------------------------------------------------------------------ > > From 427782e216badd48afc917c85682bc5a1954b24b Mon Sep 17 00:00:00 2001 > From: Chris Robinson > Date: Wed, 14 Feb 2007 11:27:26 -0800 > Subject: [PATCH] quartz: Return proper error codes from GraphBuilder_RenderFile > > --- > dlls/quartz/filtergraph.c | 82 +++++++++++++++++++++++---------------------- > 1 files changed, 42 insertions(+), 40 deletions(-) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index 8b38a3b..a3db8dd 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -961,9 +961,9 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > IEnumPins* penumpins; > ULONG pin; > HRESULT hr; > - IEnumMoniker* pEnumMoniker; > + IEnumMoniker* pEnumMoniker = NULL; > GUID tab[2]; > - IPin** ppins; > + IPin** ppins = NULL; > ULONG nb; > IMoniker* pMoniker; > IFileSourceFilter* pfile = NULL; > @@ -972,6 +972,9 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > > TRACE("(%p/%p)->(%s, %s)\n", This, iface, debugstr_w(lpcwstrFile), debugstr_w(lpcwstrPlayList)); > > + if (lpcwstrPlayList != NULL) > + return E_INVALIDARG; > + > hr = IGraphBuilder_AddSourceFilter(iface, lpcwstrFile, string, &preader); > > /* Retrieve file media type */ > @@ -982,6 +985,13 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > IFileSourceFilter_Release(pfile); > } > > + if (SUCCEEDED(hr)) > + hr = IBaseFilter_EnumPins(preader, &penumpins); > + if (SUCCEEDED(hr)) { > + hr = IEnumPins_Next(penumpins, 1, &ppinreader, &pin); > + IEnumPins_Release(penumpins); > + } > + > if (SUCCEEDED(hr)) { > tab[0] = mt.majortype; > tab[1] = mt.subtype; > @@ -990,6 +1000,8 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > > if (FAILED(hr)) > { > + if (pEnumMoniker) > + IEnumMoniker_Release(pEnumMoniker); > if (preader) { > IGraphBuilder_RemoveFilter(iface, preader); > IBaseFilter_Release(preader); > @@ -1019,65 +1031,49 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > hr = IGraphBuilder_AddFilter(iface, psplitter, NULL); > if (FAILED(hr)) { > ERR("Unable add filter (%x)\n", hr); > - return hr; > + IBaseFilter_Release(psplitter); > + continue; > } > > /* Connect file source and splitter filters together */ > /* Make the splitter analyze incoming data */ > - hr = IBaseFilter_EnumPins(preader, &penumpins); > - if (FAILED(hr)) { > - ERR("Enumpins (%x)\n", hr); > - return hr; > - } > - hr = IEnumPins_Next(penumpins, 1, &ppinreader, &pin); > - if (FAILED(hr)) { > - ERR("Next (%x)\n", hr); > - return hr; > - } > - if (pin == 0) { > - ERR("No Pin\n"); > - return E_FAIL; > - } > - IEnumPins_Release(penumpins); > > hr = IBaseFilter_EnumPins(psplitter, &penumpins); > - if (FAILED(hr)) { > - ERR("Splitter Enumpins (%x)\n", hr); > - return hr; > - } > - hr = IEnumPins_Next(penumpins, 1, &ppinsplitter, &pin); > - if (FAILED(hr)) { > - ERR("Next (%x)\n", hr); > - return hr; > - } > - if (pin == 0) { > - ERR("No Pin\n"); > - return E_FAIL; > + if (SUCCEEDED(hr)) { > + hr = IEnumPins_Next(penumpins, 1, &ppinsplitter, &pin); > + IEnumPins_Release(penumpins); > } > - IEnumPins_Release(penumpins); > > - hr = IPin_Connect(ppinreader, ppinsplitter, NULL); > + if (SUCCEEDED(hr)) > + hr = IPin_Connect(ppinreader, ppinsplitter, NULL); > if (SUCCEEDED(hr)) { > /* Make sure there's some output pins in the filter */ > hr = GetInternalConnections(psplitter, ppinsplitter, &ppins, &nb); > - if(SUCCEEDED(hr)) { > + if (SUCCEEDED(hr)) { > if(nb > 0) { > TRACE("Successfully connected to filter\n"); > break; > } > CoTaskMemFree(ppins); > ppins = NULL; > - TRACE("No output pins found in filter\n"); > } > - IBaseFilter_Release(ppinsplitter); > - ppinsplitter = NULL; > + > + TRACE("No output pins found in filter\n"); > + hr = VFW_E_CANNOT_RENDER; > } > + > + IPin_Release(ppinsplitter); > + ppinsplitter = NULL; > + IGraphBuilder_RemoveFilter(iface, psplitter); > + IBaseFilter_Release(psplitter); > + ppinsplitter = NULL; > + > TRACE("Cannot connect to filter (%x), trying next one\n", hr); > - hr = E_FAIL; > } > > /* Render all output pin of the splitter by calling IGraphBuilder_Render on each of them */ > if (SUCCEEDED(hr)) { > + int partial = 0; > int i; > TRACE("pins to consider: %d\n", nb); > for(i = 0; i < nb; i++) { > @@ -1085,13 +1081,19 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > hr = IGraphBuilder_Render(iface, ppins[i]); > if (FAILED(hr)) { > ERR("Cannot render pin %p (%x)\n", ppins[i], hr); > - /* FIXME: We should clean created things properly */ > - break; > + partial = 1; > } > + IPin_Release(ppins[i]); > } > CoTaskMemFree(ppins); > + > + hr = (partial ? VFW_S_PARTIAL_RENDER : S_OK); > } > - > + > + if (psplitter) > + IBaseFilter_Release(psplitter); > + IBaseFilter_Release(preader); > + > return hr; > } > > > > ------------------------------------------------------------------------ > > From us at edmeades.me.uk Mon Feb 19 18:48:09 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Mon Feb 19 18:48:31 2007 Subject: XCOPY support Message-ID: <005201c75488$cac45b60$1001a8c0@JasonsPC> Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of XCOPY support. Does anyone have anything like this in their tree, or should I try to knock something up? I also assume it needs to be a separate program, not part of cmd.exe, to mimic how windows does it? Jason From ploujj at gmail.com Mon Feb 19 18:58:05 2007 From: ploujj at gmail.com (Michael [Plouj] Ploujnikov) Date: Mon Feb 19 18:58:14 2007 Subject: generic.ppd does not appear in the build dir - cannot print In-Reply-To: <18e575130702181051l4e8514fai515411ad28123ed9@mail.gmail.com> References: <18e575130702171508p3af94ee6h3a7779a54ed2d4c1@mail.gmail.com> <1171818752.7289.49.camel@p4> <18e575130702181051l4e8514fai515411ad28123ed9@mail.gmail.com> Message-ID: <18e575130702191658gce742bap8c2b74626c820a27@mail.gmail.com> I have just finished confirming that this problem was indeed caused by some mess up in Gentoo's 32bit filesystem layout (as we discussed on IRC). A solution has been posted: http://wiki.winehq.org/WineOn64bit I am now able to print in Wine using CUPS, not Wine's generic.ppd, again. Thanks for the input. -- Libre Software: http://www.gnu.org/philosophy/free-sw.html From wine-devel at kievinfo.com Mon Feb 19 20:03:35 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Mon Feb 19 20:04:17 2007 Subject: wine-0.9.31 version is absent from bugzilla Message-ID: <45DA56F7.1070003@kievinfo.com> Please whoever has powers to add new versions to bugzilla, can they please do that? Thanks. Vitaliy. From thestig at google.com Mon Feb 19 20:52:39 2007 From: thestig at google.com (Lei Zhang) Date: Mon Feb 19 20:52:52 2007 Subject: wine-0.9.31 version is absent from bugzilla In-Reply-To: <45DA56F7.1070003@kievinfo.com> References: <45DA56F7.1070003@kievinfo.com> Message-ID: <558b2f5c0702191852t7a83c00bs2f9523d7e3b7b5c@mail.gmail.com> Does someone manually add new versions to bugzilla or is it done automatically? On 2/19/07, Vitaliy Margolen wrote: > Please whoever has powers to add new versions to bugzilla, can they > please do that? > > Thanks. > > Vitaliy. > > > From dank at kegel.com Mon Feb 19 21:00:31 2007 From: dank at kegel.com (Dan Kegel) Date: Mon Feb 19 21:00:37 2007 Subject: XCOPY support Message-ID: Jason, >Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of >XCOPY support. I've been wishing for this for other reasons lately. Glad you're looking at it! >Does anyone have anything like this in their tree, or should >I try to knock something up? I'm not aware of anything like it in the wine tree. (It's tempting to borrow code from freedos, but they're GPL... still, you could peek at e.g. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/xcopy/rxcopy/ and maybe ask the author to relicense if you like it.) >I also assume it needs to be a separate program, not part of cmd.exe, to >mimic how windows does it? Yes. BTW, it would be nice if you could include a conformace test of some sort. Maybe a batch file that reports problems by using echo FAIL ...reason... ? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv From wine-devel at kievinfo.com Mon Feb 19 22:49:57 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Mon Feb 19 22:50:32 2007 Subject: [start][start] Output with console encoding In-Reply-To: <45D9B4D7.8040405@etersoft.ru> References: <45D87C59.8070708@kievinfo.com> <45D9B4D7.8040405@etersoft.ru> Message-ID: <45DA7DF5.6020907@kievinfo.com> Anatoly Lyutin wrote: > Vitaliy Margolen wrote: >>> Changelog: >>> Fix output console to output with console encoding. >>> static void output(const char *message) >> >> This is not correct. This function and everything else, using it should >> be rewritten as unicode, not ansi. Also you should use >> HeapAlloc/HeapFree. >> > This program works with 8-bits strings and rewritten all "start" to > unicode is precocious because wineconsole now not yet support unicode in > curses mode (I`m working on it) :) > All you need to do is to convert output() function and all callers into WCHAR. Then you can do whatever magic you need inside of output(). Then you can properly load resources and deal with them properly until the step you need to display them. Vitaliy From wine-devel at kievinfo.com Mon Feb 19 22:55:54 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Mon Feb 19 22:56:35 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: References: <200702191524.48341.stefan@codeweavers.com> Message-ID: <45DA7F5A.3050101@kievinfo.com> H. Verbeet wrote: > On 19/02/07, Stefan D?singer wrote: >> - if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. > > I would also keep some warning messages in there like WARN so we can easily see if game does something wrong. Vitaliy From wine-devel at kievinfo.com Mon Feb 19 22:59:58 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Mon Feb 19 23:00:35 2007 Subject: =?iso-8859-1?q?Re=3A_=5B8/10=5D_WineD3D=3A_Move_the_scissor_rect?= =?iso-8859-1?q?angle_to_the_state_table=2CStefan_D=F6singer_?= Message-ID: <45DA804E.8090206@kievinfo.com> Stefan D?singer wrote: > + if(memcmp(&This->updateStateBlock->scissorRect, pRect, sizeof(*pRect)) == 0) { > + TRACE("App is setting the old scissor rectangle over, nothing to do\n"); > + return WINED3D_OK; > + } > memcpy(&This->updateStateBlock->scissorRect, pRect, sizeof(*pRect)); You should use EqualRect() and CopyRect() instead of memcmp and memcpy for RECTs. Vitaliy From patrol at sinus.cz Mon Feb 19 23:37:31 2007 From: patrol at sinus.cz (Pavel Troller) Date: Mon Feb 19 23:37:36 2007 Subject: 0.9.31 not suitable for gaming Message-ID: <20070220053731.GA28646@tangens.sinus.cz> Hi! I've tried 0.9.31 and it seems that there is a regression in at least two games: - Fallout Tactics (BOS.exe): Shows a dialog stating "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: Could not create display buffers" and then another one about abnormal termination of the program and quits. - Steam based games, mainly HL2: During game load, the screen goes black. Moving the cursor causes sound effects as it hovers across the menus and buttons, so the program runs, but nothing can be seen. Both those games are known to work with wine at about a half between .29 and .30. I tried it with basic .31 as well as with today's git update. Are those regressions known and is it a work in progress, or should I make a bisecting session to find the problem ? With regards, Pavel Troller From wine-devel at kievinfo.com Tue Feb 20 00:04:03 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Tue Feb 20 00:04:41 2007 Subject: AppDB e-mail notifications. Message-ID: <45DA8F53.4070304@kievinfo.com> Can some one fix e-mail notifications sent err. NOT sent from appdb? I have not received a single notification from the apps I am a super maintainer for! Except my own messages! On a side not, thanks to whomever that was who edited steam's howto and erased all the formatting! And they haven't even added themselves to the "laste changed by" entry. Vitaliy From dmitry at codeweavers.com Tue Feb 20 00:15:59 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 20 00:16:02 2007 Subject: [PATCH 3/3] ntdll: fix up instruction pointer in contextinsideraise_exception References: <200702182232.44927.kumbayo84@arcor.de><006301c75401$28b9bc70$0100a8c0@DMITRY> <200702192014.40747.kumbayo84@arcor.de> Message-ID: <01f601c754b6$9b7e8690$0100a8c0@DMITRY> "Peter Oberndorfer" wrote: > The strange thing is my testcase [patch 2/3] shows/(should show) that the debugger > gets a unmodified eip for a first chance exception > + if (de.u.Exception.dwFirstChance) > + { > + /* debugger gets first chance exception with unmodified ctx.Eip */ > + ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xb, "Eip at %x instead of 0x%x\n", > + ctx.Eip, (DWORD)code_mem_address + 0xb); > > and the modified one when the application did not handle the exception Could that be due to an error in your test? > Unfortunetely i don't own that book :-( > Could you please verify in the pseudocode that the modified context gets sent to the debugger, > and not some unmodified copy? The pseudocode of KiDispatchException as the very first thing calls KeContextFromKframes and then unconditionally decrements context.Eip in the case of STATUS_BREAKPOINT. > Or maybe they unfix the context again in the send_to_debugger function ;-) > Or the pseudo code is not fully correct. That's a possibility, yes. -- Dmitry. From thestig at google.com Tue Feb 20 01:47:05 2007 From: thestig at google.com (Lei Zhang) Date: Tue Feb 20 01:47:16 2007 Subject: Comctl32 Status Bar Test In-Reply-To: <45CE9F86.1060507@holycrap.org> References: <45CE9F86.1060507@holycrap.org> Message-ID: <558b2f5c0702192347m2e3559d8g10a6b59e1802bcad@mail.gmail.com> On 2/10/07, Felix Nawothnig wrote: > Alex Arazi wrote: > > - ok(rc.top == 2, "Expected 2, got %d\n", rc.top); > > - ok(rc.bottom == 21, "Expected 21, got %d\n", rc.bottom); > > - ok(rc.left == 0, "Expected 0, got %d\n", rc.left); > > - ok(rc.right == 50, "Expected 50, got %d\n", rc.right); > > I didn't really look at your new tests but the second of those tests you > removed failed ("got 1" IIRC) on Windows (XP) because we don't create a > parent window (and because the 21 is wrong. Should be 22 IIRC) - native > comctl32 sometimes does some strange stuff when a control doesn't have > one - so the test should create it. > > Felix > Hi Felix, Alex removed the incorrect test, it should have been 22. To make native comctl32 behave correctly, Alex tried to create a parent window but that didn't help. What actually needs to happen is to set the WS_VISIBLE style for the status bar. (Dan and I discovered this a few weeks back but it slipped our minds.) Alex and I did some more testing and we noticed the value for rc.bottom isn't consistent on Windows either. On Windows XP, depending on the window style and font size, the size can vary between 22, 23, and 26. So WS_VISIBLE needs to be set, #include is unneeded and should be removed, and (at least for me) a couple tests failed and should be wrapped in todo_wine{ }. - Lei From hverbeet at gmail.com Tue Feb 20 03:31:15 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 20 03:31:22 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070220053731.GA28646@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> Message-ID: On 20/02/07, Pavel Troller wrote: > Hi! > I've tried 0.9.31 and it seems that there is a regression in at least two > games: > - Fallout Tactics (BOS.exe): Shows a dialog stating > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > Could not create display buffers" > and then another one about abnormal termination of the program and quits. > - Steam based games, mainly HL2: During game load, the screen goes black. > Moving the cursor causes sound effects as it hovers across the menus and > buttons, so the program runs, but nothing can be seen. > Both those games are known to work with wine at about a half between .29 > and .30. > I tried it with basic .31 as well as with today's git update. > Are those regressions known and is it a work in progress, or should I make > a bisecting session to find the problem ? > With regards, Pavel Troller > It's a bit unfortunate that right before the release a couple of regressions appear to have crept in. I think that at least the one in HL2/CSS is supposed to be fixed in current git, so if it isn't it probably makes sense to do a regression test. From stefan at codeweavers.com Tue Feb 20 04:05:51 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 20 04:06:27 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070220053731.GA28646@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> Message-ID: <200702201105.56452.stefan@codeweavers.com> Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > - Steam based games, mainly HL2: During game load, the screen goes black. > Moving the cursor causes sound effects as it hovers across the menus and > buttons, so the program runs, but nothing can be seen. This regression is known, and it should be fixed already. It was caused by my patch which made wined3d return an error if an unsupported query is created, like windows does. Wine does not support event queries, but many apps expect them to be supported. I have sent another patch(committed already) that re-enables the fake event queries. > - Fallout Tactics (BOS.exe): Shows a dialog stating > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > Could not create display buffers" > and then another one about abnormal termination of the program and quits. I don't know about this regression. Can you do a bisect? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/9a790d6c/attachment.pgp From julliard at winehq.org Tue Feb 20 04:14:41 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 20 04:14:45 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <45DA8BEE.9030205@kievinfo.com> (Vitaliy Margolen's message of "Mon\, 19 Feb 2007 22\:49\:34 -0700") References: <45DA8BEE.9030205@kievinfo.com> Message-ID: <874pph3zla.fsf@wine.dyndns.org> Vitaliy Margolen writes: > Resend as-is. I need this function to work on global handles when > process is NULL. If you need this you are doing something wrong. Callers are not supposed to know that a handle is global. -- Alexandre Julliard julliard@winehq.org From stefan at codeweavers.com Tue Feb 20 04:17:52 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 20 04:18:25 2007 Subject: [10/10] WineD3D: With FVFs only one stream is used In-Reply-To: References: <200702191526.32045.stefan@codeweavers.com> Message-ID: <200702201117.56240.stefan@codeweavers.com> Am Montag 19 Februar 2007 16:42 schrieb H. Verbeet: > Eventually, the FVF path should be removed from wined3d completely. We > should convert the FVF in d3d8 to a vertex declaration, just like in > d3d9. Agreed. But I think we should keep the FVF->decl conversion at a central place instead of having 3 copies of it(d3d9, d3d8, ddraw). I think we could make a single exported function to convert a fvf->wined3d decl which does not depend on any other code in wined3d -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/9342ff9d/attachment.pgp From hverbeet at gmail.com Tue Feb 20 04:25:29 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 20 04:25:43 2007 Subject: [10/10] WineD3D: With FVFs only one stream is used In-Reply-To: <200702201117.56240.stefan@codeweavers.com> References: <200702191526.32045.stefan@codeweavers.com> <200702201117.56240.stefan@codeweavers.com> Message-ID: On 20/02/07, Stefan D?singer wrote: > But I think we should keep the FVF->decl conversion at a central place instead > of having 3 copies of it(d3d9, d3d8, ddraw). I think we could make a single > exported function to convert a fvf->wined3d decl which does not depend on any > other code in wined3d > Sure. I think it should be easy enough to just add another constructor for the wined3d vertex declaration that takes an FVF instead of an array of WINED3DVERTEXELEMENT's. From stefandoesinger at gmx.at Tue Feb 20 04:34:14 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 20 04:34:49 2007 Subject: [00/16] CMD.exe patches In-Reply-To: <001101c75486$995fed20$1001a8c0@JasonsPC> References: <001101c75486$995fed20$1001a8c0@JasonsPC> Message-ID: <200702201134.20051.stefandoesinger@gmx.at> Am Dienstag 20 Februar 2007 01:32 schrieb Ann & Jason Edmeades: > After being away from active development in wine for a while I wanted to > start somewhere easy, and picked some bugs from the bug database in the > wcmd (cmd.exe) shell. > > I think I got carried away, but the following patches fix some reported > bugs and lots of other issues I found while doing some playing within the > shell. > > All feedback welcome, although I think I need to lean to use git a bit > better! Did patches 1-5 get lost? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/d4ccbf8c/attachment.pgp From stefandoesinger at gmx.at Tue Feb 20 04:55:06 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 20 04:55:54 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: References: <200702191524.48341.stefan@codeweavers.com> Message-ID: <200702201155.21287.stefandoesinger@gmx.at> Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > On 19/02/07, Stefan D?singer wrote: > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. True. I'll extend the test for that and send an updated patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/d2e7d8e5/attachment.pgp From wine-devel at kievinfo.com Tue Feb 20 07:19:14 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Tue Feb 20 07:20:18 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <874pph3zla.fsf@wine.dyndns.org> References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> Message-ID: <45DAF552.2060608@kievinfo.com> Alexandre Julliard wrote: > Vitaliy Margolen writes: > >> Resend as-is. I need this function to work on global handles when >> process is NULL. > > If you need this you are doing something wrong. Callers are not > supposed to know that a handle is global. > http://source.winehq.org/source/server/handle.c#L523 calls duplicate_handle with NULL process. Vitaliy. From julliard at winehq.org Tue Feb 20 07:27:49 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 20 07:27:55 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <45DAF552.2060608@kievinfo.com> (Vitaliy Margolen's message of "Tue\, 20 Feb 2007 06\:19\:14 -0700") References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> <45DAF552.2060608@kievinfo.com> Message-ID: <87sld12c2y.fsf@wine.dyndns.org> Vitaliy Margolen writes: > http://source.winehq.org/source/server/handle.c#L523 calls > duplicate_handle with NULL process. Yes, but duplicate_handle has no reason to call get_handle on the dst process. I see that your 3/3 patch does this, but that's broken. -- Alexandre Julliard julliard@winehq.org From rob at codeweavers.com Tue Feb 20 07:35:36 2007 From: rob at codeweavers.com (Robert Shearman) Date: Tue Feb 20 07:36:19 2007 Subject: [PATCH 3/3] server: Check object's security when creating handles. In-Reply-To: <45DA8CEA.2020707@kievinfo.com> References: <45DA8CEA.2020707@kievinfo.com> Message-ID: <45DAF928.2050200@codeweavers.com> Vitaliy Margolen wrote: > After > checking object's SD against token we fail some tests. > What it seems to me is that some one tried to "optimize" this part in > windows and instead created a security problem. If you already have a valid handle to the object, then it isn't really a security problem to have another one with the same access rights. > @@ -450,25 +453,34 @@ obj_handle_t duplicate_handle( struct pr > unsigned int access, unsigned int attr, unsigned int options ) > { > obj_handle_t res; > + struct handle_entry *entry; > + unsigned int src_access, dst_access; > struct object *obj = get_handle_obj( src, src_handle, 0, NULL ); > > if (!obj) return 0; > - if (options & DUP_HANDLE_SAME_ACCESS) > + if ((entry = get_handle( src, src_handle ))) > + src_access = entry->access; > + else /* pseudo-handle, give it full access */ > { > - struct handle_entry *entry = get_handle( src, src_handle ); > - if (entry) > - access = entry->access; > - else /* pseudo-handle, give it full access */ > - { > - access = obj->ops->map_access( obj, GENERIC_ALL ); > - clear_error(); > - } > + src_access = obj->ops->map_access( obj, GENERIC_ALL ); > + clear_error(); > } > - access &= ~RESERVED_ALL; > + src_access &= ~RESERVED_ALL; > + > + if (options & DUP_HANDLE_SAME_ACCESS) > + dst_access = src_access; > + else > + dst_access = obj->ops->map_access( obj, access ) & ~RESERVED_ALL; > + > + /* asking for more or the same/less access rights */ > + access = ~src_access & dst_access ? dst_access : 0; > + > if (options & DUP_HANDLE_MAKE_GLOBAL) > res = alloc_global_handle( obj, access ); > else > res = alloc_handle( dst, obj, access, attr ); > + if (res) get_handle( dst, res )->access = dst_access; > + > It would seem better to add an extra parameter to alloc_handle and alloc_global_handle to tell them to not check access rather than adding this hack. It should use less processor time and it should make patch 2 not necessary. -- Rob Shearman From nlaw at nildram.co.uk Tue Feb 20 07:49:54 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Tue Feb 20 07:50:12 2007 Subject: AppDB performance issue In-Reply-To: <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFDC62.6020009@gmail.com> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> Message-ID: <45DAFC82.4070302@nildram.co.uk> I still find appdb really slow 60 seconds to view some pages, post on the forums etc.... It's driving me nuts to the point I've gone back to real life for a while as it's less frustrating. BTW this problems exists on systems separated by over 100 miles (but same login account) so it not hardware at my end. I'll check back now and again to see if it's fixed. Apart from that, keep up the good work devs, wine's functionality is improving all the time but appdb needs fixing. Cheers Nick John Smith wrote: > Humm very strange it works well for me, > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 > on windows 2000, on gentoo x86 with firefox 2.0.0.1 > , and on gentoo amd64 firefox 2.0.0.1 . > > I added, then removed, then edited a test result. Speed seemed normal. > > Hope this helps the investigation. > > Regards, > John Klehm > > On 2/14/07, *Louis Lenders* > wrote: > > Bryan Haskins gmail.com > > writes: > > > > > > > I was just replying, and reading now, no slow down at all. It > loads a little > slow running through all that text, but no where near the minutes > everyone says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading a > page, or > adding a test result to an application takes several minutes. > Please fix, as > this is really annoying :( > > > > > ------------------------------------------------------------------------ > > > From thunder.m at czela.net Tue Feb 20 08:03:32 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 20 08:03:33 2007 Subject: [9/10] WineD3D: Use VBOs for index buffers In-Reply-To: <200702191525.32934.stefan@codeweavers.com> References: <200702191525.32934.stefan@codeweavers.com> Message-ID: <45DAFFB4.5060202@czela.net> Hi, this patch caused regression in many Direct3D games. TES IV: Oblivion can't start game (menu works), Flatout II is completly broken, Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried rewrite GLint vbo; to GLuint vbo; but it doesn't help. Mirek Stefan D?singer napsal(a): > > ------------------------------------------------------------------------ > > From 4d52be700666b6b1e853bad296c502b5b0d76189 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Mon, 19 Feb 2007 15:12:39 +0100 > Subject: [PATCH] WineD3D: Use VBOs for index buffers > > This patch uses (if available) gl vertex buffer objects for static d3d index buffers > to store indices in video memory. Therefore a new index buffer state is added which > binds the vbo to GL_ELEMENT_ARRAY_BUFFER. DrawStrided* use the index buffer stride to > tell if indices are used for drawing because a NULL index data pointer is valid now. > DrawStridedSlow has to read the indices from the index buffer if it is used, because > it can't use the data from the vbo(or only very inefficiently). > --- > dlls/wined3d/device.c | 68 ++++++++++++++++++++++++++++++++++++--- > dlls/wined3d/drawprim.c | 14 ++++++-- > dlls/wined3d/indexbuffer.c | 49 +++++++++++++++++++++++++++- > dlls/wined3d/state.c | 12 +++++++ > dlls/wined3d/wined3d_private.h | 8 ++++- > 5 files changed, 139 insertions(+), 12 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 18f3e75..af0e96a 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -443,21 +443,67 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateVertexBuffer(IWineD3DDevice *ifac > return WINED3D_OK; > } > > +static void CreateIndexBufferVBO(IWineD3DDeviceImpl *This, IWineD3DIndexBufferImpl *object) { > + GLenum error, glUsage; > + TRACE("Creating VBO for Index Buffer %p\n", object); > + > + ENTER_GL(); > + while(glGetError()); > + > + GL_EXTCALL(glGenBuffersARB(1, &object->vbo)); > + error = glGetError(); > + if(error != GL_NO_ERROR || object->vbo == 0) { > + ERR("Creating a vbo failed, continueing without vbo for this buffer\n"); > + object->vbo = 0; > + return; > + } > + > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, object->vbo)); > + error = glGetError(); > + if(error != GL_NO_ERROR) { > + ERR("Failed to bind index buffer, continueing without vbo for this buffer\n"); > + goto out; > + } > + > + /* Use static write only usage for now. Dynamic index buffers stay in sysmem, and due to the sysmem > + * copy no readback will be needed > + */ > + glUsage = GL_STATIC_DRAW; > + GL_EXTCALL(glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, object->resource.size, NULL, glUsage)); > + error = glGetError(); > + if(error != GL_NO_ERROR) { > + ERR("Failed to initialize the index buffer\n"); > + goto out; > + } > + LEAVE_GL(); > + TRACE("Successfully created vbo %d for index buffer %p\n", object->vbo, object); > + return; > + > +out: > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + GL_EXTCALL(glDeleteBuffersARB(1, &object->vbo)); > + LEAVE_GL(); > + object->vbo = 0; > +} > + > static HRESULT WINAPI IWineD3DDeviceImpl_CreateIndexBuffer(IWineD3DDevice *iface, UINT Length, DWORD Usage, > WINED3DFORMAT Format, WINED3DPOOL Pool, IWineD3DIndexBuffer** ppIndexBuffer, > HANDLE *sharedHandle, IUnknown *parent) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > IWineD3DIndexBufferImpl *object; > TRACE("(%p) Creating index buffer\n", This); > - > + > /* Allocate the storage for the device */ > D3DCREATERESOURCEOBJECTINSTANCE(object,IndexBuffer,WINED3DRTYPE_INDEXBUFFER, Length) > - > - /*TODO: use VBO's */ > - if (Pool == WINED3DPOOL_DEFAULT ) { /* Allocate some system memory for now */ > + > + if (Pool == WINED3DPOOL_DEFAULT ) { /* We need a local copy for drawStridedSlow */ > object->resource.allocatedMemory = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,object->resource.size); > } > > + if(Pool != WINED3DPOOL_SYSTEMMEM && !(Usage & WINED3DUSAGE_DYNAMIC) && GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT)) { > + CreateIndexBufferVBO(This, object); > + } > + > TRACE("(%p) : Len=%d, Use=%x, Format=(%u,%s), Pool=%d - Memory@%p, Iface@%p\n", This, Length, Usage, Format, > debug_d3dformat(Format), Pool, object, object->resource.allocatedMemory); > *ppIndexBuffer = (IWineD3DIndexBuffer *) object; > @@ -2557,10 +2603,15 @@ static HRESULT WINAPI IWineD3DDeviceImpl_SetIndices(IWineD3DDevice *iface, IWine > return WINED3D_OK; > } > > - /* So far only the base vertex index is tracked */ > + /* The base vertex index affects the stream sources, while > + * The index buffer is a seperate index buffer state > + */ > if(BaseVertexIndex != oldBaseIndex) { > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_STREAMSRC); > } > + if(oldIdxs != pIndexData) { > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > + } > return WINED3D_OK; > } > > @@ -4224,9 +4275,11 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > UINT idxStride = 2; > IWineD3DIndexBuffer *pIB; > WINED3DINDEXBUFFER_DESC IdxBufDsc; > + GLint vbo; > > pIB = This->stateBlock->pIndexData; > This->stateBlock->streamIsUP = FALSE; > + vbo = ((IWineD3DIndexBufferImpl *) pIB)->vbo; > > TRACE("(%p) : Type=(%d,%s), min=%d, CountV=%d, startIdx=%d, countP=%d\n", This, > PrimitiveType, debug_d3dprimitivetype(PrimitiveType), > @@ -4245,7 +4298,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > } > > drawPrimitive(iface, PrimitiveType, primCount, 0, NumVertices, startIndex, > - idxStride, ((IWineD3DIndexBufferImpl *) pIB)->resource.allocatedMemory, minIndex); > + idxStride, vbo ? NULL : ((IWineD3DIndexBufferImpl *) pIB)->resource.allocatedMemory, minIndex); > > return WINED3D_OK; > } > @@ -4310,6 +4363,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitiveUP(IWineD3DDevice * > This->stateBlock->loadBaseVertexIndex = 0; > /* Mark the state dirty until we have nicer tracking of the stream source pointers */ > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_VDECL); > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > > drawPrimitive(iface, PrimitiveType, PrimitiveCount, 0 /* vertexStart */, NumVertices, 0 /* indxStart */, idxStride, pIndexData, MinVertexIndex); > > @@ -4332,8 +4386,10 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawPrimitiveStrided (IWineD3DDevice *i > * that value. > */ > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_VDECL); > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > This->stateBlock->baseVertexIndex = 0; > This->up_strided = DrawPrimStrideData; > + This->stateBlock->streamIsUP = TRUE; > drawPrimitive(iface, PrimitiveType, PrimitiveCount, 0, 0, 0, 0, NULL, 0); > This->up_strided = NULL; > return WINED3D_OK; > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index 2cc3a15..7cf6877 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -571,7 +571,7 @@ static void drawStridedFast(IWineD3DDevice *iface,UINT numberOfVertices, GLenum > const void *idxData, short idxSize, ULONG minIndex, ULONG startIdx, ULONG startVertex) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > > - if (idxData != NULL /* This crashes sometimes!*/) { > + if (idxSize != 0 /* This crashes sometimes!*/) { > TRACE("(%p) : glElements(%x, %d, %d, ...)\n", This, glPrimitiveType, numberOfVertices, minIndex); > idxData = idxData == (void *)-1 ? NULL : idxData; > #if 1 > @@ -629,7 +629,15 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > TRACE("Using slow vertex array code\n"); > > /* Variable Initialization */ > - if (idxData != NULL) { > + if (idxSize != 0) { > + /* Immediate mode drawing can't make use of indices in a vbo - get the data from the index buffer. > + * If the index buffer has no vbo(not supported or other reason), or with user pointer drawing > + * idxData will be != NULL > + */ > + if(idxData == NULL) { > + idxData = ((IWineD3DIndexBufferImpl *) This->stateBlock->pIndexData)->resource.allocatedMemory; > + } > + > if (idxSize == 2) pIdxBufS = (const short *) idxData; > else pIdxBufL = (const long *) idxData; > } > @@ -1165,7 +1173,7 @@ inline void drawStridedInstanced(IWineD3DDevice *iface, WineDirect3DVertexStride > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; > IWineD3DStateBlockImpl *stateblock = This->stateBlock; > > - if (idxData == NULL) { > + if (idxSize == 0) { > /* This is a nasty thing. MSDN says no hardware supports that and apps have to use software vertex processing. > * We don't support this for now > * > diff --git a/dlls/wined3d/indexbuffer.c b/dlls/wined3d/indexbuffer.c > index 39a270d..0f768ac 100644 > --- a/dlls/wined3d/indexbuffer.c > +++ b/dlls/wined3d/indexbuffer.c > @@ -58,6 +58,15 @@ static ULONG WINAPI IWineD3DIndexBufferImpl_Release(IWineD3DIndexBuffer *iface) > ULONG ref = InterlockedDecrement(&This->resource.ref); > TRACE("(%p) : Releasing from %d\n", This, ref + 1); > if (ref == 0) { > + if(This->vbo) { > + ENTER_GL(); > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + checkGLcall("glBindBufferARB"); > + GL_EXTCALL(glDeleteBuffersARB(1, &This->vbo)); > + checkGLcall("glDeleteBuffersARB"); > + LEAVE_GL(); > + } > + > IWineD3DResourceImpl_CleanUp((IWineD3DResource *)iface); > HeapFree(GetProcessHeap(), 0, This); > } > @@ -108,13 +117,49 @@ static HRESULT WINAPI IWineD3DIndexBufferImpl_GetParent(IWineD3DIndexBuffer *ifa > ****************************************************** */ > static HRESULT WINAPI IWineD3DIndexBufferImpl_Lock(IWineD3DIndexBuffer *iface, UINT OffsetToLock, UINT SizeToLock, BYTE** ppbData, DWORD Flags) { > IWineD3DIndexBufferImpl *This = (IWineD3DIndexBufferImpl *)iface; > - TRACE("(%p) : no real locking yet, offset %d, size %d, Flags=%x\n", This, OffsetToLock, SizeToLock, Flags); > + TRACE("(%p) : offset %d, size %d, Flags=%x\n", This, OffsetToLock, SizeToLock, Flags); > + > + InterlockedIncrement(&This->lockcount); > *ppbData = (BYTE *)This->resource.allocatedMemory + OffsetToLock; > + > + if(Flags & (WINED3DLOCK_READONLY | WINED3DLOCK_NO_DIRTY_UPDATE) || This->vbo == 0) { > + return WINED3D_OK; > + } > + > + if(This->dirtystart != This->dirtyend) { > + if(This->dirtystart > OffsetToLock) This->dirtystart = OffsetToLock; > + if(SizeToLock) { > + if(This->dirtyend < OffsetToLock + SizeToLock) This->dirtyend = OffsetToLock + SizeToLock; > + } else { > + This->dirtyend = This->resource.size; > + } > + } else { > + This->dirtystart = OffsetToLock; > + if(SizeToLock) > + This->dirtyend = OffsetToLock + SizeToLock; > + else > + This->dirtyend = This->resource.size; > + } > + > return WINED3D_OK; > } > static HRESULT WINAPI IWineD3DIndexBufferImpl_Unlock(IWineD3DIndexBuffer *iface) { > IWineD3DIndexBufferImpl *This = (IWineD3DIndexBufferImpl *)iface; > - TRACE("(%p) : stub\n", This); > + unsigned long locks = InterlockedDecrement(&This->lockcount);; > + TRACE("(%p)\n", This); > + > + /* For now load in unlock */ > + if(locks == 0 && This->vbo) { > + ENTER_GL(); > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); > + checkGLcall("glBindBufferARB"); > + GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, > + This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); > + checkGLcall("glBufferSubDataARB"); > + LEAVE_GL(); > + This->dirtystart = 0; > + This->dirtyend = 0; > + } > return WINED3D_OK; > } > static HRESULT WINAPI IWineD3DIndexBufferImpl_GetDesc(IWineD3DIndexBuffer *iface, WINED3DINDEXBUFFER_DESC *pDesc) { > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index 0b96e54..f78720a 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -3062,6 +3062,17 @@ static void scissorrect(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3D > checkGLcall("glScissor"); > } > > +static void indexbuffer(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3DContext *context) { > + if(GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT)) { > + if(stateblock->streamIsUP || stateblock->pIndexData == NULL ) { > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + } else { > + IWineD3DIndexBufferImpl *ib = (IWineD3DIndexBufferImpl *) stateblock->pIndexData; > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, ib->vbo)); > + } > + } > +} > + > const struct StateEntry StateTable[] = > { > /* State name representative, apply function */ > @@ -4077,6 +4088,7 @@ const struct StateEntry StateTable[] = > { /*511, WINED3DTS_WORLDMATRIX(255) */ STATE_TRANSFORM(WINED3DTS_WORLDMATRIX(255)), transform_worldex }, > /* Various Vertex states follow */ > { /* , STATE_STREAMSRC */ STATE_VDECL, vertexdeclaration }, > + { /* , STATE_INDEXBUFFER */ STATE_INDEXBUFFER, indexbuffer }, > { /* , STATE_VDECL */ STATE_VDECL, vertexdeclaration }, > { /* , STATE_VSHADER */ STATE_VDECL, vertexdeclaration }, > { /* , STATE_VIEWPORT */ STATE_VIEWPORT, viewport }, > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 3bf0c8e..be8cd6e 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -426,8 +426,10 @@ typedef void (*APPLYSTATEFUNC)(DWORD state, IWineD3DStateBlockImpl *stateblock, > > #define STATE_STREAMSRC (STATE_TRANSFORM(WINED3DTS_WORLDMATRIX(255)) + 1) > #define STATE_IS_STREAMSRC(a) ((a) == STATE_STREAMSRC) > +#define STATE_INDEXBUFFER (STATE_STREAMSRC + 1) > +#define STATE_IS_INDEXBUFFER(a) ((a) == STATE_INDEXBUFFER) > > -#define STATE_VDECL (STATE_STREAMSRC + 1) > +#define STATE_VDECL (STATE_INDEXBUFFER + 1) > #define STATE_IS_VDECL(a) ((a) == STATE_VDECL) > > #define STATE_VSHADER (STATE_VDECL + 1) > @@ -793,6 +795,10 @@ typedef struct IWineD3DIndexBufferImpl > const IWineD3DIndexBufferVtbl *lpVtbl; > IWineD3DResourceClass resource; > > + GLuint vbo; > + UINT dirtystart, dirtyend; > + LONG lockcount; > + > /* WineD3DVertexBuffer specifics */ > } IWineD3DIndexBufferImpl; > > > > ------------------------------------------------------------------------ > > From stefan at codeweavers.com Tue Feb 20 08:43:23 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Tue Feb 20 08:44:03 2007 Subject: [9/10] WineD3D: Use VBOs for index buffers In-Reply-To: <45DAFFB4.5060202@czela.net> References: <200702191525.32934.stefan@codeweavers.com> <45DAFFB4.5060202@czela.net> Message-ID: <200702201543.27338.stefan@codeweavers.com> Am Dienstag 20 Februar 2007 15:03 schrieb Mirek: > Hi, this patch caused regression in many Direct3D games. TES IV: > Oblivion can't start game (menu works), Flatout II is completly broken, > Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried > rewrite GLint vbo; to GLuint vbo; but it doesn't help. Argh, sounds kinda bad :-( . Do the games crash, or display incorrect graphics? Can you try to add the following line in IWineD3DIndexBufferImpl_Unlock(dlls/wined3d/indexbuffer.c),somewhere in the locks == 0 && This->vbo if statement: IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); The bound index buffer is changed there, and it needs to be restored for the next draw. I forgot to add that because originally I planned to make the vbo and state table things 2 patches, but that didn't work out right. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/4ea36cb1/attachment.pgp From stefan at codeweavers.com Tue Feb 20 08:57:17 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 20 09:38:43 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: References: <200702191524.48341.stefan@codeweavers.com> Message-ID: <200702201557.22471.stefan@codeweavers.com> Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > On 19/02/07, Stefan D?singer wrote: > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. I added a test to see if the sampler state is checked too, and neither ddraw, d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not sure if we should commit the test to wine because it could cause invisible memory corruption in the native d3d object which randomly breaks other tests. DirectX is incorrect here, because I have a test for lights where the light type IS checked. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/afd27b65/attachment.pgp From hverbeet at gmail.com Tue Feb 20 09:46:03 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 20 09:46:49 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: <200702201557.22471.stefan@codeweavers.com> References: <200702191524.48341.stefan@codeweavers.com> <200702201557.22471.stefan@codeweavers.com> Message-ID: On 20/02/07, Stefan D?singer wrote: > Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > > On 19/02/07, Stefan D?singer wrote: > > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > > > This also checked the sampler state, not just the sampler. > I added a test to see if the sampler state is checked too, and neither ddraw, > d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not > sure if we should commit the test to wine because it could cause invisible > memory corruption in the native d3d object which randomly breaks other tests. > > DirectX is incorrect here, because I have a test for lights where the light > type IS checked. > Would it make sense to catch out of bounds samplers/sampler states, print a ERR/WARN, and just return WINED3D_OK? Memory corruption is pretty nasty, and we'd at least have some log info that an application is doing something it shouldn't be doing. From hverbeet at gmail.com Tue Feb 20 09:52:35 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 20 09:52:55 2007 Subject: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers In-Reply-To: <200702201557.22471.stefan@codeweavers.com> References: <200702191524.48341.stefan@codeweavers.com> <200702201557.22471.stefan@codeweavers.com> Message-ID: On 20/02/07, Stefan D?singer wrote: > Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > > On 19/02/07, Stefan D?singer wrote: > > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > > > This also checked the sampler state, not just the sampler. > I added a test to see if the sampler state is checked too, and neither ddraw, > d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not > sure if we should commit the test to wine because it could cause invisible > memory corruption in the native d3d object which randomly breaks other tests. > > DirectX is incorrect here, because I have a test for lights where the light > type IS checked. > Would it make sense to catch out of bounds samplers/sampler states, print a ERR/WARN, and just return WINED3D_OK? Memory corruption is pretty nasty, and we'd at least have some log info that an application is doing something it shouldn't be doing. From thunder.m at czela.net Tue Feb 20 09:54:03 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 20 09:54:18 2007 Subject: [9/10] WineD3D: Use VBOs for index buffers In-Reply-To: <200702201543.27338.stefan@codeweavers.com> References: <200702191525.32934.stefan@codeweavers.com> <45DAFFB4.5060202@czela.net> <200702201543.27338.stefan@codeweavers.com> Message-ID: <45DB199B.3020404@czela.net> Stefan D?singer napsal(a): > Am Dienstag 20 Februar 2007 15:03 schrieb Mirek: >> Hi, this patch caused regression in many Direct3D games. TES IV: >> Oblivion can't start game (menu works), Flatout II is completly broken, >> Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried >> rewrite GLint vbo; to GLuint vbo; but it doesn't help. > Argh, sounds kinda bad :-( . > > Do the games crash, or display incorrect graphics? HL 2 EO can't even start to menu, it just hangs TES IV: Oblivion can start, but it hangs while loading game Flatout II can start, but graphic in menu is completly broken and it crash after start of game > > Can you try to add the following line in > IWineD3DIndexBufferImpl_Unlock(dlls/wined3d/indexbuffer.c),somewhere in the > locks == 0 && This->vbo if statement: > > IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, > STATE_INDEXBUFFER); > > The bound index buffer is changed there, and it needs to be restored for the > next draw. I forgot to add that because originally I planned to make the vbo > and state table things 2 patches, but that didn't work out right. I tried it three times in different places, it helped in some games: Flatout II - graphic in menu was without any problems, but game crashed (still regression). HalfLife 2 EO - works, I was in game only about 2 minuts and it look fixed Alpine Sky Racing 2007 - works TES IV: Oblivion - still crashing while loading (it just hang while loading, picture is frozen, and I have to manualy kill it) So it fixed something, but not all regressions. 1. /* For now load in unlock */ if(locks == 0 && This->vbo) { ENTER_GL(); IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; } return WINED3D_OK; 2. /* For now load in unlock */ if(locks == 0 && This->vbo) { IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); ENTER_GL(); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); } return WINED3D_OK; 3. /* For now load in unlock */ if(locks == 0 && This->vbo) { ENTER_GL(); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; } return WINED3D_OK; Mirek From kingofallhearts999 at gmail.com Tue Feb 20 10:14:41 2007 From: kingofallhearts999 at gmail.com (Bryan Haskins) Date: Tue Feb 20 10:14:49 2007 Subject: AppDB performance issue In-Reply-To: <45DAFC82.4070302@nildram.co.uk> References: <45CE4FB4.6040403@mic-nucmed.co.uk> <45CFE0B8.6000501@gmail.com> <45D1152F.601@nildram.co.uk> <45D11726.4020608@nildram.co.uk> <45D18DA0.4090709@nildram.co.uk> <78a7dad00702141435k214e51b9wd623980ccc053933@mail.gmail.com> <45DAFC82.4070302@nildram.co.uk> Message-ID: I'm actually noticing it a little now... about a minute hang sometimes then poof it's up. So it's not a crawl... just a hang. It's weird really. Feels like too many people trying to connect for the server to handle so it throws them to the queue, or similar. On 2/20/07, Nick Law wrote: > > I still find appdb really slow 60 seconds to view some pages, post on > the forums etc.... It's driving me nuts to the point I've gone back to > real life for a while as it's less frustrating. BTW this problems exists > on systems separated by over 100 miles (but same login account) so it > not hardware at my end. > > I'll check back now and again to see if it's fixed. > > Apart from that, keep up the good work devs, wine's functionality is > improving all the time but appdb needs fixing. > > Cheers > Nick > > John Smith wrote: > > Humm very strange it works well for me, > > > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 > > on windows 2000, on gentoo x86 with firefox 2.0.0.1 > > , and on gentoo amd64 firefox 2.0.0.1 . > > > > I added, then removed, then edited a test result. Speed seemed normal. > > > > Hope this helps the investigation. > > > > Regards, > > John Klehm > > > > On 2/14/07, *Louis Lenders* > > wrote: > > > > Bryan Haskins gmail.com > > > writes: > > > > > > > > > > > I was just replying, and reading now, no slow down at all. It > > loads a little > > slow running through all that text, but no where near the minutes > > everyone says > > it takes them, even on dialup. > > > > > > > > > For your info, Appdb, is complete unusable for me ... Loading a > > page, or > > adding a test result to an application takes several minutes. > > Please fix, as > > this is really annoying :( > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > -- Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070220/0fc12328/attachment.htm From wine-patches at kievinfo.com Tue Feb 20 07:46:01 2007 From: wine-patches at kievinfo.com (Vitaliy Margolen) Date: Tue Feb 20 10:55:17 2007 Subject: [PATCH 3/3] server: Check object's security when creating handles. In-Reply-To: <45DAF928.2050200@codeweavers.com> References: <45DA8CEA.2020707@kievinfo.com> <45DAF928.2050200@codeweavers.com> Message-ID: <45DAFB99.8010203@kievinfo.com> Robert Shearman wrote: > Vitaliy Margolen wrote: >> After >> checking object's SD against token we fail some tests. >> What it seems to me is that some one tried to "optimize" this part in >> windows and instead created a security problem. > > If you already have a valid handle to the object, then it isn't really a > security problem to have another one with the same access rights. Actually that's a pseudo-handle from GetCurrentProcess(). Which can be duplicated into say global handle with maximum access. So when an app creates a process and sets any access restrictions on it, it's all useless for the process itself - as it can always gain 100% access to itself, and give that 100% access to anyone who wants. Vitaliy. From joris_huizer at yahoo.com Tue Feb 20 12:37:55 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Tue Feb 20 12:39:04 2007 Subject: a big fan of your work In-Reply-To: Message-ID: <947635.56679.qm@web52701.mail.yahoo.com> --- Jeffrey Sabarese wrote: > I have installed, and use the "ies4linux" > ( here for more info if you're unfamiliar with it: > http://novicenotes.com/install-internet-explorer-on-linux-under-wine-run-ie-on-linux/ > ), but though it works VERY well launching from the > Fedora Terminal I don't think you need ies4linux. At least in the current wine version you could just download ie6 (sp1) from the microsoft site (and I guess have a good look at the terms of use -- though I think you already agreed to them with running ies4linux) and run the installer - it gets the thing installed properly regards, Joris ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html From ben at atomnet.co.uk Tue Feb 20 13:23:52 2007 From: ben at atomnet.co.uk (Ben Hodgetts (Enverex)) Date: Tue Feb 20 13:24:18 2007 Subject: wine-0.9.31 version is absent from bugzilla In-Reply-To: <558b2f5c0702191852t7a83c00bs2f9523d7e3b7b5c@mail.gmail.com> References: <45DA56F7.1070003@kievinfo.com> <558b2f5c0702191852t7a83c00bs2f9523d7e3b7b5c@mail.gmail.com> Message-ID: <45DB4AC8.5080400@atomnet.co.uk> It's done manually by an admin. Lei Zhang wrote: > Does someone manually add new versions to bugzilla or is it done > automatically? > > On 2/19/07, Vitaliy Margolen wrote: >> Please whoever has powers to add new versions to bugzilla, can they >> please do that? >> >> Thanks. >> >> Vitaliy. >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/83b3e3df/signature.pgp From flexo at holycrap.org Tue Feb 20 13:40:43 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Tue Feb 20 13:33:20 2007 Subject: Rediffed patch from Rein Klazes:winex11.drv:Add pointer check in X11DRV_SetDIBits In-Reply-To: <20070218221828.36140.qmail@web23215.mail.ird.yahoo.com> References: <20070218221828.36140.qmail@web23215.mail.ird.yahoo.com> Message-ID: <45DB4EBB.9090701@holycrap.org> Louis. Lenders wrote: > + if( IsBadReadPtr( bits, nrsrcbytes)) return 0; AFAIK you should never use that function since it introduces a race con. Try using an exception handler around the memory access itself. Felix From stefan at codeweavers.com Tue Feb 20 13:48:02 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Tue Feb 20 13:48:51 2007 Subject: [9/10] WineD3D: Use VBOs for index buffers In-Reply-To: <45DB199B.3020404@czela.net> References: <200702191525.32934.stefan@codeweavers.com> <200702201543.27338.stefan@codeweavers.com> <45DB199B.3020404@czela.net> Message-ID: <200702202048.06244.stefan@codeweavers.com> Am Dienstag 20 Februar 2007 16:54 schrieb Mirek: > I tried it three times in different places, it helped in some games: > > Flatout II - graphic in menu was without any problems, but game crashed > (still regression). > HalfLife 2 EO - works, I was in game only about 2 minuts and it look fixed > Alpine Sky Racing 2007 - works > TES IV: Oblivion - still crashing while loading (it just hang while > loading, picture is frozen, and I have to manualy kill it) > > So it fixed something, but not all regressions. Yes, there is another case of that in IWineD3DVertexBufferImpl_Release. Remove the glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER, 0) there too. I will send a patch soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/2a8eb542/attachment.pgp From thunder.m at czela.net Tue Feb 20 14:31:53 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 20 14:32:20 2007 Subject: Progress in implementation of Direct3D Message-ID: <45DB5AB9.8020704@czela.net> Hi, i would like to say "Thanks for your work!" to all wine developers. In past months there was realy big progress in implementation of Direct3D in wine (that part is most important for me) and other parts such Dinput, so I would like to introduce you some more sreenshots from latest Direct3D applications. I will try to post them on official wine website. To run third benchmark in 3DMark 2005 I used wined3d_3dmark05.diff.txt patch (from H. Verbeet) To run Call of Dutty 2 I used cod2.diff patch (my latest modification of patch against current CVS) All screenshots are from today CVS 20.02.2007 without patch "[9/10] WineD3D: Use VBOs for index buffers" which caused some regressions. http://headline.czela.net/Mirek/wine/ or via IP: http://62.240.181.87/Mirek/wine/ -------------- next part -------------- A non-text attachment was scrubbed... Name: cod2.diff Type: text/x-patch Size: 2713 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/abca3f0d/cod2.bin -------------- next part -------------- --- dlls/wined3d/directx.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 841e16f..ca3eaaf 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -585,7 +585,7 @@ BOOL IWineD3DImpl_FillGLCaps(IWineD3D *iface, Display* display) { glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max); TRACE_(d3d_caps)(" FOUND: ARB Multitexture support - GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max); gl_info->supported[ARB_MULTITEXTURE] = TRUE; - gl_info->max_textures = min(MAX_TEXTURES, gl_max); + gl_info->max_textures = 8; gl_info->max_texture_stages = min(MAX_TEXTURES, gl_max); gl_info->max_samplers = max(gl_info->max_samplers, gl_max); } else if (strcmp(ThisExtn, "GL_ARB_texture_cube_map") == 0) { @@ -2196,7 +2196,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->MaxVertexBlendMatrixIndex = 1; *pCaps->MaxAnisotropy = GL_LIMITS(anisotropy); - *pCaps->MaxPointSize = GL_LIMITS(pointsize); + *pCaps->MaxPointSize = 64.0f; *pCaps->VertexProcessingCaps = WINED3DVTXPCAPS_DIRECTIONALLIGHTS | @@ -2294,7 +2294,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->NumSimultaneousRTs = GL_LIMITS(buffers); - *pCaps->StretchRectFilterCaps = 0; + *pCaps->StretchRectFilterCaps = WINED3DPTFILTERCAPS_MINFLINEAR | + WINED3DPTFILTERCAPS_MAGFLINEAR; *pCaps->VertexTextureFilterCaps = 0; if(*pCaps->VertexShaderVersion == WINED3DVS_VERSION(3,0)) { From patrol at sinus.cz Tue Feb 20 14:55:03 2007 From: patrol at sinus.cz (Pavel Troller) Date: Tue Feb 20 14:55:30 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <200702201105.56452.stefan@codeweavers.com> References: <20070220053731.GA28646@tangens.sinus.cz> <200702201105.56452.stefan@codeweavers.com> Message-ID: <20070220205503.GA26428@tangens.sinus.cz> Hi! > Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > > - Steam based games, mainly HL2: During game load, the screen goes black. > > Moving the cursor causes sound effects as it hovers across the menus and > > buttons, so the program runs, but nothing can be seen. > This regression is known, and it should be fixed already. It was caused by my > patch which made wined3d return an error if an unsupported query is created, > like windows does. Wine does not support event queries, but many apps expect > them to be supported. I have sent another patch(committed already) that > re-enables the fake event queries. OK. This bug seems to be really fixed, but the game crashes later (during the startup of the "real" game, after all the selections). It crashes in its own code (called "Engine") but ntdll and kernel32 are visible in the backtrace. I can send it exactly if it helps. I don't know how to bisect this crash because the one initially mentioned is "masking" it. > > > - Fallout Tactics (BOS.exe): Shows a dialog stating > > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > > Could not create display buffers" > > and then another one about abnormal termination of the program and quits. > I don't know about this regression. Can you do a bisect? Yes, done. It's the following commit: commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc Author: Stefan D??singer Date: Wed Feb 14 17:59:08 2007 +0100 wined3d: More fullscreen window fixes. The game is run in a virtual desktop (i.e. it appears in the Linux window, not in full screen). With regards, Pavel Troller From joao.eiras at gmail.com Tue Feb 20 15:24:54 2007 From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=) Date: Tue Feb 20 15:25:04 2007 Subject: Progress in implementation of Direct3D In-Reply-To: <45DB5AB9.8020704@czela.net> References: <45DB5AB9.8020704@czela.net> Message-ID: Na , Mirek escreveu: > Hi, i would like to say "Thanks for your work!" to all wine developers. > In past months there was realy big progress in implementation of > Direct3D in wine (that part is most important for me) and other parts > such Dinput, so I would like to introduce you some more sreenshots from > latest Direct3D applications. I will try to post them on official wine > website. > > To run third benchmark in 3DMark 2005 I used wined3d_3dmark05.diff.txt > patch (from H. Verbeet) > To run Call of Dutty 2 I used cod2.diff patch (my latest modification of > patch against current CVS) > > All screenshots are from today CVS 20.02.2007 without patch "[9/10] > WineD3D: Use VBOs for index buffers" which caused some regressions. > > http://headline.czela.net/Mirek/wine/ > > or via IP: http://62.240.181.87/Mirek/wine/ Indeed excellent ! Damn ! I really want to play COD 2 on my pc :p From rob at codeweavers.com Tue Feb 20 15:44:50 2007 From: rob at codeweavers.com (Robert Shearman) Date: Tue Feb 20 15:45:35 2007 Subject: Working on JScript/VBScript support for MSI In-Reply-To: <1171928558.20239.5.camel@misha-laptop> References: <1171928558.20239.5.camel@misha-laptop> Message-ID: <45DB6BD2.4060900@codeweavers.com> Misha Koshelev wrote: > Hi, since MSDN states that any installer that requires JScript/VBScript > must make sure to install it, and since some applications require these > for install (bug #7353 and another one is there for VBScript for a > different installer), I figure there is no reason why builtin MSI cannot > use Microsoft Script if it is there (and plus when we have our own > JScript/VBScript we will be able to use it off the bat with MSI). > > I have posted my initial work on this on the bugzilla for bug #7353. The > first file (a patch, will attach also) is my patch which updates > custom.c to have the appropriate handlers for the custom action types, > extracts the script from the appropriate place, writes it to a file, and > uses a framework very similar to the current thread framework for DLLs > to call my helper call_script function. This first patch, in theory, > should not have to change much (if at all), although I have not > thoroughly tested it yet so it probably will. > > The second file (and attached here too) is dlls/msi/script.c, which is > where the meat and potatoes of the actual call_script function is/will > be. Right now it is pretty barebones, but it does load the script from > the file and calls it appropriately. > > Now I am working on implementing the Session object, although it looks > like a wrapper around MSI functions we already have so I think it should > be doable. > > Anyways, any comments on my work so far will be appreciated. > Nice work! Does MSI expose any builtin objects to the scripts (a quick Google search indicates there should be a Session object exposed)? -- Rob Shearman From mk144210 at bcm.tmc.edu Tue Feb 20 15:53:03 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Tue Feb 20 15:53:41 2007 Subject: Working on JScript/VBScript support for MSI In-Reply-To: <45DB6BD2.4060900@codeweavers.com> References: <1171928558.20239.5.camel@misha-laptop> <45DB6BD2.4060900@codeweavers.com> Message-ID: <1172008383.6788.5.camel@misha-laptop> On Tue, 2007-02-20 at 21:44 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > Hi, since MSDN states that any installer that requires JScript/VBScript > > must make sure to install it, and since some applications require these > > for install (bug #7353 and another one is there for VBScript for a > > different installer), I figure there is no reason why builtin MSI cannot > > use Microsoft Script if it is there (and plus when we have our own > > JScript/VBScript we will be able to use it off the bat with MSI). > > > > I have posted my initial work on this on the bugzilla for bug #7353. The > > first file (a patch, will attach also) is my patch which updates > > custom.c to have the appropriate handlers for the custom action types, > > extracts the script from the appropriate place, writes it to a file, and > > uses a framework very similar to the current thread framework for DLLs > > to call my helper call_script function. This first patch, in theory, > > should not have to change much (if at all), although I have not > > thoroughly tested it yet so it probably will. > > > > The second file (and attached here too) is dlls/msi/script.c, which is > > where the meat and potatoes of the actual call_script function is/will > > be. Right now it is pretty barebones, but it does load the script from > > the file and calls it appropriately. > > > > Now I am working on implementing the Session object, although it looks > > like a wrapper around MSI functions we already have so I think it should > > be doable. > > > > Anyways, any comments on my work so far will be appreciated. > > > > Nice work! Does MSI expose any builtin objects to the scripts (a quick > Google search indicates there should be a Session object exposed)? > Thanks. It exposes a Session object, which is the next thing I have to work on. Actually the object seems to be a wrapper around all the functions MSI exposes as a Dll, and should not be _too_ much work to implement. I can get an .idl from oleview on the native MSI that has the appropriate objects with a slight bugfix in oleview (tonight I am going to delve a little more into that to figure out if it proper and if so will submit a patch), and then I just have to implement each function as a call to the appropriate Msi... function, which shouldn't be too bad. I do have a dayjob though, so my estimated ETA for this is probably going to be in a bit though (I am thinking couple of weeks). Misha From mk144210 at bcm.tmc.edu Tue Feb 20 16:05:57 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Tue Feb 20 16:06:37 2007 Subject: Working on JScript/VBScript support for MSI In-Reply-To: <45DB6BD2.4060900@codeweavers.com> References: <1171928558.20239.5.camel@misha-laptop> <45DB6BD2.4060900@codeweavers.com> Message-ID: <1172009158.6788.9.camel@misha-laptop> On Tue, 2007-02-20 at 21:44 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > Hi, since MSDN states that any installer that requires JScript/VBScript > > must make sure to install it, and since some applications require these > > for install (bug #7353 and another one is there for VBScript for a > > different installer), I figure there is no reason why builtin MSI cannot > > use Microsoft Script if it is there (and plus when we have our own > > JScript/VBScript we will be able to use it off the bat with MSI). > > > > I have posted my initial work on this on the bugzilla for bug #7353. The > > first file (a patch, will attach also) is my patch which updates > > custom.c to have the appropriate handlers for the custom action types, > > extracts the script from the appropriate place, writes it to a file, and > > uses a framework very similar to the current thread framework for DLLs > > to call my helper call_script function. This first patch, in theory, > > should not have to change much (if at all), although I have not > > thoroughly tested it yet so it probably will. > > > > The second file (and attached here too) is dlls/msi/script.c, which is > > where the meat and potatoes of the actual call_script function is/will > > be. Right now it is pretty barebones, but it does load the script from > > the file and calls it appropriately. > > > > Now I am working on implementing the Session object, although it looks > > like a wrapper around MSI functions we already have so I think it should > > be doable. > > > > Anyways, any comments on my work so far will be appreciated. > > > > Nice work! Does MSI expose any builtin objects to the scripts (a quick > Google search indicates there should be a Session object exposed)? > Btw, I did a little more work on my script.c yesterday, added a Session object. Right now it just does a FIXME for any properties/methods that are looked up, but what I need to do now is implement the Session class (fair amount of work) and then just add an ITypeLib interface to Session and then on to testing. Misha -------------- next part -------------- From 04dd51cf916c6756e410395d1b00db7752c53588 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Mon, 19 Feb 2007 23:19:46 -0600 Subject: msi: Added core classes for JScript/VBScript support. --- dlls/msi/script.c | 540 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 540 insertions(+), 0 deletions(-) diff --git a/dlls/msi/script.c b/dlls/msi/script.c new file mode 100644 index 0000000..d36316a --- /dev/null +++ b/dlls/msi/script.c @@ -0,0 +1,540 @@ +/* + * Implementation of scripting for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +const WCHAR szJScript[] = { 'J','S','c','r','i','p','t',0}; +const WCHAR szVBScript[] = { 'V','B','S','c','r','i','p','t',0}; +const WCHAR szSession[] = {'S','e','s','s','i','o','n',0}; + +/* + * MSISessionDispatch + */ + +typedef struct { + IDispatch lpVtbl; + LONG ref; +} IMSISessionDispatch; + +static const struct IDispatchVtbl MSISessionDispatch_Vtbl; + +static HRESULT MSISessionDispatch_create(IUnknown *pUnkOuter, LPVOID *ppObj) +{ + IMSISessionDispatch* object; + + TRACE("(%p,%p)\n", pUnkOuter, ppObj); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IMSISessionDispatch)); + + object->lpVtbl.lpVtbl = &MSISessionDispatch_Vtbl; + object->ref = 1; + + *ppObj = object; + + return S_OK; +} + +/* + * MSIActiveScriptSite + */ + +typedef struct { + IActiveScriptSite lpVtbl; + IMSISessionDispatch *iMSISessionDispatch; + LONG ref; +} IMSIActiveScriptSite; + +static const struct IActiveScriptSiteVtbl ASS_Vtbl; + +static HRESULT ASS_create(IUnknown *pUnkOuter, LPVOID *ppObj) +{ + IMSIActiveScriptSite* object; + + TRACE("(%p,%p)\n", pUnkOuter, ppObj); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IMSIActiveScriptSite)); + + object->lpVtbl.lpVtbl = &ASS_Vtbl; + object->ref = 1; + + *ppObj = object; + + return S_OK; +} + +/* + * Helper functions to run scripts + */ + +LPCWSTR read_script_from_file(LPCWSTR szFile) +{ + HANDLE hFile; + DWORD sz, szHighWord = 0, read; + WCHAR *script; + + hFile = CreateFileW(szFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); + if (hFile == INVALID_HANDLE_VALUE) + return NULL; + + sz = GetFileSize(hFile, &szHighWord); + if (sz == INVALID_FILE_SIZE || szHighWord != 0) + return NULL; + + script = msi_alloc(sizeof(CHAR)*sz); + if (!script) + return NULL; + + if (!ReadFile(hFile, (LPVOID)script, sz, &read, NULL)) + { + msi_free(script); + return NULL; + } + + return script; +} + +/* JScript or VBScript? */ +LPCWSTR progid_from_type(INT type) +{ + if (type & msidbCustomActionTypeJScript) return szJScript; + else if (type & msidbCustomActionTypeVBScript) return szVBScript; + + ERR("Unknown script type %d\n", type); + return NULL; +} + +/** + * Call a script. This is our meat and potatoes. + */ +DWORD call_script(MSIPACKAGE *package, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) +{ + LPCWSTR script = NULL; + HRESULT hr; + IActiveScript *iActiveScript = NULL; + IActiveScriptParse *iActiveScriptParse = NULL; + IMSIActiveScriptSite *iMSIActiveScriptSite = NULL; + IMSISessionDispatch *iMSISessionDispatch = NULL; + IDispatch *iDispatch = NULL; + DISPPARAMS dispparamsNoArgs = {NULL, NULL, 0, 0}; + DISPID dispid; + CLSID clsid; + VARIANT var; + + /* Return success by default (e.g., if Windows Script not installed) - not native behavior */ + DWORD ret = ERROR_SUCCESS; + + CoInitialize(NULL); + + /* Create IMSIActiveScriptSite object */ + hr = ASS_create(NULL, (void **)&iMSIActiveScriptSite); + if (hr != S_OK) goto done; + + /* Create an IMSISessionDispatch object */ + hr = MSISessionDispatch_create(NULL, (void **)&iMSISessionDispatch); + if (hr != S_OK) goto done; + IUnknown_AddRef((IUnknown *)iMSISessionDispatch); + iMSIActiveScriptSite->iMSISessionDispatch = iMSISessionDispatch; + + /* Create the scripting engine */ + hr = CLSIDFromProgID(progid_from_type(type), &clsid); + if (FAILED(hr)) goto done; + hr = CoCreateInstance(&clsid, NULL, CLSCTX_INPROC_SERVER, &IID_IActiveScript, (void **)&iActiveScript); + if (FAILED(hr)) goto done; + + /* If we got this far, Windows Script is installed, so don't return success by default anymore */ +/* ret = ERROR_INSTALL_FAILURE; */ + + /* Try to load the script file */ + script = read_script_from_file(filename); + if (!script) goto done; + + /* Get the IActiveScriptParse engine interface */ + hr = IActiveScript_QueryInterface(iActiveScript, &IID_IActiveScriptParse, (void **)&iActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Give our host to the engine */ + hr = IActiveScript_SetScriptSite(iActiveScript, (IActiveScriptSite *)iMSIActiveScriptSite); + if (FAILED(hr)) goto done; + + /* Initialize the script engine */ + hr = IActiveScriptParse_InitNew(iActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Add the session object */ + hr = IActiveScript_AddNamedItem(iActiveScript, szSession, SCRIPTITEM_ISSOURCE | SCRIPTITEM_ISVISIBLE); + + /* Pass the script to the engine */ + hr = IActiveScriptParse_ParseScriptText(iActiveScriptParse, script, NULL, NULL, NULL, 0, 0, 0L, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Start processing the script */ + hr = IActiveScript_SetScriptState(iActiveScript, SCRIPTSTATE_CONNECTED); + if (FAILED(hr)) goto done; + + /* Call a function if necessary through the IDispatch interface */ + if (function != NULL && strlenW(function) > 0) { + TRACE("Calling function %s", debugstr_w(function)); + + hr = IActiveScript_GetScriptDispatch(iActiveScript, NULL, &iDispatch); + if (FAILED(hr)) goto done; + + hr = IDispatch_GetIDsOfNames(iDispatch, &IID_NULL, (WCHAR **)&function, 1,LOCALE_USER_DEFAULT, &dispid); + if (FAILED(hr)) goto done; + + hr = IDispatch_Invoke(iDispatch, dispid, &IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD, &dispparamsNoArgs, &var, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Check return value, if it's not IDOK we failed */ + hr = VariantChangeType(&var, &var, 0, VT_I4); + if (FAILED(hr)) goto done; + + if (V_I4(&var) == IDOK) + ret = ERROR_SUCCESS; + else ret = ERROR_INSTALL_FAILURE; + + VariantClear(&var); + } else { + /* If no function to be called, MSI behavior is to succeed */ + ret = ERROR_SUCCESS; + } + +done: + + /* Free everything that needs to be freed */ + if (iDispatch) IDispatch_Release(iDispatch); + if (iActiveScript) IActiveScript_Release(iActiveScript); + if (iMSISessionDispatch) IDispatch_Release((IDispatch *)iMSISessionDispatch); + if (iMSIActiveScriptSite) IActiveScriptSite_Release((IActiveScriptSite *)iMSIActiveScriptSite); + if (script) msi_free((WCHAR *)script); + + CoUninitialize(); /* must call even if CoInitialize failed */ + + return ret; +} + +/* + * IMSIActiveScriptSite + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI IMSIActiveScriptSite_QueryInterface(IActiveScriptSite* iface, REFIID riid, void** ppvObject) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + if (IsEqualGUID(riid, &IID_IUnknown) || + IsEqualGUID(riid, &IID_IActiveScriptSite)) + { + IClassFactory_AddRef(iface); + *ppvObject = This; + return S_OK; + } + + TRACE("(%p)->(%s,%p),not found\n",This,debugstr_guid(riid),ppvObject); + + return E_NOINTERFACE; +} + +static ULONG WINAPI IMSIActiveScriptSite_AddRef(IActiveScriptSite* iface) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI IMSIActiveScriptSite_Release(IActiveScriptSite* iface) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + HeapFree(GetProcessHeap(), 0, This); + + return ref; +} + +/*** IActiveScriptSite methods **/ +static HRESULT WINAPI IMSIActiveScriptSite_GetLCID(IActiveScriptSite* iface, LCID* plcid) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub!\n", This, iface, plcid); + return E_NOTIMPL; +} + +static HRESULT WINAPI IMSIActiveScriptSite_GetItemInfo(IActiveScriptSite* iface, LPCOLESTR pstrName, DWORD dwReturnMask, IUnknown** ppiunkItem, ITypeInfo** ppti) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%d,%p,%p)!\n", This, iface, pstrName, dwReturnMask, ppiunkItem, ppti); + + /* Determine the kind of pointer that is requested, and make sure placeholder is valid */ + if (dwReturnMask & SCRIPTINFO_ITYPEINFO) { + if (!ppti) return E_INVALIDARG; + *ppti = NULL; + } + if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + if (!ppiunkItem) return E_INVALIDARG; + *ppiunkItem = NULL; + } + + /* Are we looking for the session object? */ + if (!strcmpW(szSession, pstrName)) { +/* if (dwReturnMask & SCRIPTINFO_ITYPEINFO) FIXME: Implement ITypeInfo + return ITypeInfo_LoadTypeInfo(This->iMSISessionDispatch, CLSID_iMSISessionDispatch, 0); + else */ if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + IDispatch_QueryInterface((IDispatch *)This->iMSISessionDispatch, &IID_IUnknown, (void **)ppiunkItem); + return S_OK; + } + } + + return TYPE_E_ELEMENTNOTFOUND; +} + +static HRESULT WINAPI IMSIActiveScriptSite_GetDocVersionString(IActiveScriptSite* iface, BSTR* pbstrVersion) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub\n", This, iface, pbstrVersion); + return E_NOTIMPL; +} + +static HRESULT WINAPI IMSIActiveScriptSite_OnScriptTerminate(IActiveScriptSite* iface, const VARIANT* pvarResult, const EXCEPINFO* pexcepinfo) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%p) stub\n", This, iface, pvarResult, pexcepinfo); + return S_OK; +} + +static HRESULT WINAPI IMSIActiveScriptSite_OnStateChange(IActiveScriptSite* iface, SCRIPTSTATE ssScriptState) +{ + switch (ssScriptState) { + case SCRIPTSTATE_UNINITIALIZED: + TRACE("State: Uninitialized.\n"); + break; + + case SCRIPTSTATE_INITIALIZED: + TRACE("State: Initialized.\n"); + break; + + case SCRIPTSTATE_STARTED: + TRACE("State: Started.\n"); + break; + + case SCRIPTSTATE_CONNECTED: + TRACE("State: Connected.\n"); + break; + + case SCRIPTSTATE_DISCONNECTED: + TRACE("State: Disconnected.\n"); + break; + + case SCRIPTSTATE_CLOSED: + TRACE("State: Closed.\n"); + break; + + default: + ERR("Unknown State: %d\n", ssScriptState); + break; + } + + return S_OK; +} + +static HRESULT WINAPI IMSIActiveScriptSite_OnScriptError(IActiveScriptSite* iface, IActiveScriptError* pscripterror) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + EXCEPINFO exception; + HRESULT hr; + + TRACE("(%p/%p)->(%p)\n", This, iface, pscripterror); + hr = IActiveScriptError_GetExceptionInfo(pscripterror, &exception); + if (SUCCEEDED(hr)) + ERR("script error: %s", debugstr_w(exception.bstrDescription)); + + return S_OK; +} + +static HRESULT WINAPI IMSIActiveScriptSite_OnEnterScript(IActiveScriptSite* iface) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static HRESULT WINAPI IMSIActiveScriptSite_OnLeaveScript(IActiveScriptSite* iface) +{ + IMSIActiveScriptSite *This = (IMSIActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static const struct IActiveScriptSiteVtbl ASS_Vtbl = +{ + IMSIActiveScriptSite_QueryInterface, + IMSIActiveScriptSite_AddRef, + IMSIActiveScriptSite_Release, + IMSIActiveScriptSite_GetLCID, + IMSIActiveScriptSite_GetItemInfo, + IMSIActiveScriptSite_GetDocVersionString, + IMSIActiveScriptSite_OnScriptTerminate, + IMSIActiveScriptSite_OnStateChange, + IMSIActiveScriptSite_OnScriptError, + IMSIActiveScriptSite_OnEnterScript, + IMSIActiveScriptSite_OnLeaveScript +}; + +/* + * IMSISessionDispatch + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI IMSISessionDispatch_QueryInterface(IDispatch* iface, REFIID riid, void** ppvObject) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + if (IsEqualGUID(riid, &IID_IUnknown) || + IsEqualGUID(riid, &IID_IDispatch)) + { + IClassFactory_AddRef(iface); + *ppvObject = This; + return S_OK; + } + + TRACE("(%p)->(%s,%p),not found\n",This,debugstr_guid(riid),ppvObject); + + return E_NOINTERFACE; +} + +static ULONG WINAPI IMSISessionDispatch_AddRef(IDispatch* iface) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI IMSISessionDispatch_Release(IDispatch* iface) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + HeapFree(GetProcessHeap(), 0, This); + + return ref; +} + +static HRESULT WINAPI IMSISessionDispatch_GetTypeInfoCount( + IDispatch* iface, + UINT* pctinfo) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + + TRACE("(%p/%p)->(%p)\n", iface, This, pctinfo); + *pctinfo = 0; /* FIXME: We don't support ITypeInfo yet */ + return S_OK; +} + +static HRESULT WINAPI IMSISessionDispatch_GetTypeInfo( + IDispatch* iface, + UINT iTInfo, + LCID lcid, + ITypeInfo** ppTInfo) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + TRACE("(%p/%p)->(%d,%d,%p)\n", iface, This, iTInfo, lcid, ppTInfo); + return E_NOTIMPL; /* FIXME: We don't support ITypeInfo yet */ +} + +static HRESULT WINAPI IMSISessionDispatch_GetIDsOfNames( + IDispatch* iface, + REFIID riid, + LPOLESTR* rgszNames, + UINT cNames, + LCID lcid, + DISPID* rgDispId) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + TRACE("(%p/%p)->(%p,%p,%d,%d,%p)\n", iface, This, riid, rgszNames, cNames, lcid, rgDispId); + + if (!IsEqualGUID(riid, &IID_NULL)) return E_INVALIDARG; + if (cNames > 0) FIXME("%s\n", debugstr_w(rgszNames[0])); + return E_FAIL; +} + +static HRESULT WINAPI IMSISessionDispatch_Invoke( + IDispatch* iface, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + IMSISessionDispatch *This = (IMSISessionDispatch *)iface; + HRESULT hr = E_FAIL; + TRACE("(%p/%p)->(%d,%p,%d,%d,%p,%p,%p,%p)\n", iface, This, dispIdMember, riid, lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); + + if (!IsEqualGUID(riid, &IID_NULL) /* || !(wFlags & DISPATCH_METHOD) */) + return E_INVALIDARG; + + return hr; +} + +static const struct IDispatchVtbl MSISessionDispatch_Vtbl = +{ + IMSISessionDispatch_QueryInterface, + IMSISessionDispatch_AddRef, + IMSISessionDispatch_Release, + IMSISessionDispatch_GetTypeInfoCount, + IMSISessionDispatch_GetTypeInfo, + IMSISessionDispatch_GetIDsOfNames, + IMSISessionDispatch_Invoke +}; -- 1.4.1 From thunder.m at czela.net Tue Feb 20 17:22:13 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 20 17:22:25 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <200702202246.32004.stefan@codeweavers.com> References: <200702202246.32004.stefan@codeweavers.com> Message-ID: <45DB82A5.2030103@czela.net> Some games are still broken with latest 13 patches from your tree. Oblivion still hangs while loading game and Flatout 2 crashed after 2 seconds with this output: athlon64:/usr/games/flatout2# ./flatout2 fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x17fe20) : stub, simulating 256MB for now, returning 256MB left fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded fixme:wave:DBSB_MMAPLoop Can't access sound driver's buffer directly. err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE wine: Unhandled page fault on read access to 0x7c3a4270 at address 0x7c3a4270 (thread 0011), starting debugger... Unhandled exception: page fault on read access to 0x7c3a4270 in 32-bit code (0x7c3a4270). fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x17fe20) : stub Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c3a4270 ESP:7b8cea60 EBP:7b8ceab8 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7c3be764 ECX:00000000 EDX:7b8cea90 ESI:7b8cea90 EDI:00010028 Stack dump: 0x7b8cea60: 00000000 00000000 00000000 00000000 0x7b8cea70: fffffffd 00000000 00000000 00000000 0x7b8cea80: 00000001 7ffd2000 00000018 7ef935ef 0x7b8cea90: 00000000 00000012 00000000 00000000 0x7b8ceaa0: 00002357 00000000 00000000 7efe5368 0x7b8ceab0: 0173fc34 7c3a41b0 7b8ceb58 7efc81bb Backtrace: =>1 0x7c3a4270 (0x7b8ceab8) 2 0x7efc81bb call_thread_func+0x3b(rtl_func=, arg=) [/root/.WineCVS/sources/cvswine/wine/dlls/ntdll/thread.c:371] in ntdll (0x7b8ceb58) 3 0x7efc8461 in ntdll (+0x48461) (0x7b8cf458) err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got aa34a405 while expecting ef5281d2) 4 0xb7df10bd start_thread+0x6d() in libpthread.so.0 (0x7b8cf4c8) err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got 61a1649a while expecting f01d3064) 5 0xb7d859ee __clone+0x5e() in libc.so.6 (0x00000000) 0x7c3a4270: -- no code accessible -- Modules: Module Address Debug info Name (83 modules) PE 400000-152e000 Deferred flatout2 PE 1740000-19a0000 Deferred d3dx9_30 ELF 7bf00000-7bf03000 Deferred ELF 7c663000-7c6ac000 Deferred dsound \-PE 7c670000-7c6ac000 \ dsound ELF 7c781000-7c7b3000 Deferred uxtheme \-PE 7c790000-7c7b3000 \ uxtheme ELF 7c7b3000-7c874000 Deferred libasound.so.2 ELF 7c87e000-7c893000 Deferred midimap \-PE 7c880000-7c893000 \ midimap ELF 7c893000-7c8be000 Deferred winealsa \-PE 7c8a0000-7c8be000 \ winealsa ELF 7cb5a000-7cb5f000 Deferred libxfixes.so.3 ELF 7cb5f000-7cb68000 Deferred libxcursor.so.1 PE 7cb70000-7cb85000 --none-- msacm32 ELF 7cb87000-7cb8a000 Deferred libxrandr.so.2 ELF 7cb8a000-7cb92000 Deferred libxrender.so.1 ELF 7cb92000-7cb95000 Deferred libxinerama.so.1 ELF 7cb98000-7cbb4000 Deferred imm32 \-PE 7cba0000-7cbb4000 \ imm32 ELF 7d55e000-7d5ec000 Deferred winex11 \-PE 7d570000-7d5ec000 \ winex11 ELF 7d650000-7d670000 Deferred libexpat.so.1 ELF 7d670000-7d69b000 Deferred libfontconfig.so.1 ELF 7d6ba000-7d724000 Deferred libfreetype.so.6 ELF 7d743000-7d769000 Deferred msacm32 ELF 7d769000-7d7cd000 Deferred msvcrt \-PE 7d780000-7d7cd000 \ msvcrt ELF 7d835000-7d840000 Deferred libgcc_s.so.1 ELF 7d925000-7d927000 Deferred libnvidia-tls.so.1 ELF 7d927000-7e298000 Deferred libglcore.so.1 ELF 7e298000-7e29d000 Deferred libxdmcp.so.6 ELF 7e29d000-7e32d000 Deferred libglu.so.1 ELF 7e32d000-7e3c1000 Deferred libgl.so.1 ELF 7e3c1000-7e4ad000 Deferred libx11.so.6 ELF 7e4ad000-7e4bb000 Deferred libxext.so.6 ELF 7e4bb000-7e4d3000 Deferred libice.so.6 ELF 7e4d3000-7e4dc000 Deferred libsm.so.6 ELF 7e4dc000-7e596000 Deferred wined3d \-PE 7e4f0000-7e596000 \ wined3d ELF 7e596000-7e5c1000 Deferred d3d9 \-PE 7e5a0000-7e5c1000 \ d3d9 ELF 7e5c1000-7e5ed000 Deferred ws2_32 \-PE 7e5d0000-7e5ed000 \ ws2_32 ELF 7e5ed000-7e6aa000 Deferred comctl32 \-PE 7e600000-7e6aa000 \ comctl32 ELF 7e6aa000-7e6bd000 Deferred libresolv.so.2 ELF 7e6c6000-7e6da000 Deferred libz.so.1 ELF 7e6dc000-7e6fa000 Deferred iphlpapi \-PE 7e6e0000-7e6fa000 \ iphlpapi ELF 7e6fa000-7e74f000 Deferred rpcrt4 \-PE 7e710000-7e74f000 \ rpcrt4 ELF 7e74f000-7e7e8000 Deferred ole32 \-PE 7e760000-7e7e8000 \ ole32 ELF 7e7e8000-7e840000 Deferred shlwapi \-PE 7e800000-7e840000 \ shlwapi ELF 7e840000-7e935000 Deferred shell32 \-PE 7e850000-7e935000 \ shell32 ELF 7e935000-7e97b000 Deferred advapi32 \-PE 7e940000-7e97b000 \ advapi32 ELF 7e97b000-7ea0e000 Deferred gdi32 \-PE 7e990000-7ea0e000 \ gdi32 ELF 7ea0e000-7eb48000 Deferred user32 \-PE 7ea30000-7eb48000 \ user32 ELF 7eb48000-7ebd6000 Deferred winmm \-PE 7eb50000-7ebd6000 \ winmm ELF 7edd6000-7eefc000 Deferred kernel32 \-PE 7edf0000-7eefc000 \ kernel32 ELF 7eefc000-7ef07000 Deferred libnss_files.so.2 ELF 7ef07000-7ef11000 Deferred libnss_nis.so.2 ELF 7ef11000-7ef27000 Deferred libnsl.so.1 ELF 7ef27000-7ef4c000 Deferred libm.so.6 ELF 7ef4c000-7ef4f000 Deferred libxau.so.6 ELF 7ef6b000-7f000000 Dwarf ntdll \-PE 7ef80000-7f000000 \ ntdll ELF b7cb0000-b7cb5000 Deferred libxxf86vm.so.1 ELF b7cb6000-b7cba000 Deferred libdl.so.2 ELF b7cba000-b7dec000 Export libc.so.6 ELF b7dec000-b7dfe000 Export libpthread.so.0 ELF b7e11000-b7e15000 Deferred iso8859-2.so ELF b7e15000-b7e1e000 Deferred libnss_compat.so.2 ELF b7e1e000-b7f2f000 Deferred libwine.so.1 ELF b7f31000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) G:\usr\games\flatout2\FlatOut2.exe 00000012 15 00000011 0 <== 00000010 0 0000000f 2 0000000e 15 0000000d 15 00000009 0 Stefan D?singer napsal(a): > The ddraw index buffer handling needs a proper fix somewhen, either by an VB + > up Indices drawing method(but there are already too many of them) or my a > SetMem method in index buffers > > This patch should(hopefully) fix the regressions introduced with my former > index buffer patch > > > ------------------------------------------------------------------------ > > From fadece932e1ff556a4434545d7bf6753aaabdaf1 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Tue, 20 Feb 2007 16:15:04 +0100 > Subject: [PATCH] D3D: Index buffer fixes > > Some things that missed in my former patch. Do not unset the index buffer in _Release, that > is not needed. Dirtify the index buffer state in unlock because the bound buffer is changed. > GL vbos are GLuints. The index buffer used by ddraw should have dynamic usage, and preferably > be locked only on the size that has to be locked > --- > dlls/ddraw/device.c | 2 +- > dlls/ddraw/direct3d.c | 2 +- > dlls/wined3d/device.c | 2 +- > dlls/wined3d/indexbuffer.c | 9 +++++++-- > 4 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/dlls/ddraw/device.c b/dlls/ddraw/device.c > index c201df7..0814921 100644 > --- a/dlls/ddraw/device.c > +++ b/dlls/ddraw/device.c > @@ -3691,7 +3691,7 @@ IDirect3DDeviceImpl_7_DrawIndexedPrimitiveVB(IDirect3DDevice7 *iface, > */ > hr = IWineD3DIndexBuffer_Lock(This->indexbuffer, > 0 /* OffSetToLock */, > - 0 /* SizeToLock - doesn't matter */, > + IndexCount * sizeof(WORD), > (BYTE **) &LockedIndices, > 0 /* Flags */); > assert(IndexCount < 0x100000); > diff --git a/dlls/ddraw/direct3d.c b/dlls/ddraw/direct3d.c > index 4896ba7..b716a60 100644 > --- a/dlls/ddraw/direct3d.c > +++ b/dlls/ddraw/direct3d.c > @@ -804,7 +804,7 @@ IDirect3DImpl_7_CreateDevice(IDirect3D7 *iface, > */ > hr = IWineD3DDevice_CreateIndexBuffer(This->wineD3DDevice, > 0x40000, /* Length. Don't know how long it should be */ > - 0, /* Usage */ > + WINED3DUSAGE_DYNAMIC, /* Usage */ > WINED3DFMT_INDEX16, /* Format. D3D7 uses WORDS */ > WINED3DPOOL_DEFAULT, > &object->indexbuffer, > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index c039798..2ac8797 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4294,7 +4294,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > UINT idxStride = 2; > IWineD3DIndexBuffer *pIB; > WINED3DINDEXBUFFER_DESC IdxBufDsc; > - GLint vbo; > + GLuint vbo; > > pIB = This->stateBlock->pIndexData; > This->stateBlock->streamIsUP = FALSE; > diff --git a/dlls/wined3d/indexbuffer.c b/dlls/wined3d/indexbuffer.c > index b16ddd0..ae2294a 100644 > --- a/dlls/wined3d/indexbuffer.c > +++ b/dlls/wined3d/indexbuffer.c > @@ -60,8 +60,11 @@ static ULONG WINAPI IWineD3DIndexBufferImpl_Release(IWineD3DIndexBuffer *iface) > if (ref == 0) { > if(This->vbo) { > ENTER_GL(); > - GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > - checkGLcall("glBindBufferARB"); > + /* No need to manually unset the buffer. glDeleteBuffers unsets it for the current context, > + * but not for other contexts. However, because the d3d buffer is destroyed the app has to > + * unset it before doing the next draw, thus dirtifying the index buffer state and forcing > + * binding a new buffer > + */ > GL_EXTCALL(glDeleteBuffersARB(1, &This->vbo)); > checkGLcall("glDeleteBuffersARB"); > LEAVE_GL(); > @@ -159,6 +162,8 @@ static HRESULT WINAPI IWineD3DIndexBufferImpl_Unlock(IWineD3DIndexBuffer *iface) > LEAVE_GL(); > This->dirtystart = 0; > This->dirtyend = 0; > + /* TODO: Move loading into preload when the buffer is used, that avoids dirtifying the state */ > + IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); > } > return WINED3D_OK; > } > > > ------------------------------------------------------------------------ > > From hverbeet at gmail.com Tue Feb 20 17:28:57 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 20 17:29:03 2007 Subject: [10/13] D3D9: Fix the circular converted vertex declaration reference In-Reply-To: <200702202259.39987.stefan@codeweavers.com> References: <200702202259.39987.stefan@codeweavers.com> Message-ID: On 20/02/07, Stefan D?singer wrote: > If anyone knows a nicer way to release the converted declaration from > SetVertexDeclaration feel free to comment. > > Not applying this patch won't affect patches 11-13 > Wouldn't it be better to directly compare This against convertedDecl from the device in IDirect3DVertexDeclaration9Impl_Release, rather than adding a convertedDecl flag to IDirect3DVertexDeclaration9Impl and setting / unsetting it? I think it makes things harder than it has to be. Also, afaik Ivan has some tests for the exact behaviour. From thestig at google.com Tue Feb 20 17:48:30 2007 From: thestig at google.com (Lei Zhang) Date: Tue Feb 20 17:48:56 2007 Subject: [Bug 7503] Eve Online pasword box on login screen doesn't work In-Reply-To: References: Message-ID: <558b2f5c0702201548u5afcedc5gb1644ab00080c16a@mail.gmail.com> Can we change wineprefixcreate to copy the truetype fonts (if any) from /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert distro specific X11/fonts/TTF directory] to $WINEPREFIX/drive_c/windows/fonts/ ? On 2/20/07, Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=7503 > > > > > > ------- Additional Comments From kelfe@gmx.de 2007-20-02 16:57 ------- > to fix the issue you need to copy the font file arial.ttf into > .wine/drive_c/windows/fonts folder (.wine is a hidden folder) > > the arial.ttf can be found in the mscorefonts packages or search engine/windows box > > I don't know if font files should be placed in the fonts folder by wine or by > the user. So close this bug or keep it open until basic fonts are installed by > wine when creating the .wine folder. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > > From stefan at codeweavers.com Tue Feb 20 18:16:39 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Tue Feb 20 18:17:26 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070220205503.GA26428@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702201105.56452.stefan@codeweavers.com> <20070220205503.GA26428@tangens.sinus.cz> Message-ID: <200702210116.44685.stefan@codeweavers.com> Am Dienstag 20 Februar 2007 21:55 schrieb Pavel Troller: > Hi! > > > Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > > > - Steam based games, mainly HL2: During game load, the screen goes > > > black. Moving the cursor causes sound effects as it hovers across the > > > menus and buttons, so the program runs, but nothing can be seen. > > > > This regression is known, and it should be fixed already. It was caused > > by my patch which made wined3d return an error if an unsupported query is > > created, like windows does. Wine does not support event queries, but many > > apps expect them to be supported. I have sent another patch(committed > > already) that re-enables the fake event queries. > > OK. This bug seems to be really fixed, but the game crashes later (during > the startup of the "real" game, after all the selections). It crashes in > its own code (called "Engine") but ntdll and kernel32 are visible in the > backtrace. I can send it exactly if it helps. I don't know how to bisect > this crash because the one initially mentioned is "masking" it. Yeah, I've introduced a new regression right after fixing the last one :-) Today's patches should fix it(and maybe bring a new breakage) > > > - Fallout Tactics (BOS.exe): Shows a dialog stating > > > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > > > Could not create display buffers" > > > and then another one about abnormal termination of the program and > > > quits. > > > > I don't know about this regression. Can you do a bisect? > > Yes, done. It's the following commit: > > commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc > Author: Stefan D??singer > Date: Wed Feb 14 17:59:08 2007 +0100 > > wined3d: More fullscreen window fixes. > > The game is run in a virtual desktop (i.e. it appears in the Linux window, > not in full screen). That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070221/010469c4/attachment.pgp From ivg231 at gmail.com Tue Feb 20 19:33:38 2007 From: ivg231 at gmail.com (Ivan Gyurdiev) Date: Tue Feb 20 19:29:34 2007 Subject: [10/13] D3D9: Fix the circular converted vertex declaration reference In-Reply-To: References: <200702202259.39987.stefan@codeweavers.com> Message-ID: <45DBA172.5010705@gmail.com> H. Verbeet wrote: > On 20/02/07, Stefan D?singer wrote: >> If anyone knows a nicer way to release the converted declaration from >> SetVertexDeclaration feel free to comment. >> >> Not applying this patch won't affect patches 11-13 >> > Wouldn't it be better to directly compare This against convertedDecl > from the device in IDirect3DVertexDeclaration9Impl_Release, rather > than adding a convertedDecl flag to IDirect3DVertexDeclaration9Impl > and setting / unsetting it? I think it makes things harder than it has > to be. Also, afaik Ivan has some tests for the exact behaviour. "Some tests" attached. I cannot guarantee whether the tests make any sense or are correct (don't remember what I was trying to do , but maybe they'll be helpful :) The converted declaration is evil... I lost patience when trying to figure out the exact behavior, so decided to leave it broken, rather than fix it incorrectly. I think I wasn't sure whether the conversion happens on the setFVF call, or on the GetDeclaration call following it. -------------- next part -------------- A non-text attachment was scrubbed... Name: some.tests.tar.bz2 Type: application/x-bzip2 Size: 3921 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070220/0aec50c2/some.tests.tar-0001.bin From dmitry at codeweavers.com Tue Feb 20 20:31:03 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 20 20:31:06 2007 Subject: [Bug 7503] Eve Online pasword box on login screen doesn't work References: <558b2f5c0702201548u5afcedc5gb1644ab00080c16a@mail.gmail.com> Message-ID: <006601c75560$589687b0$0100a8c0@DMITRY> "Lei Zhang" wrote: > Can we change wineprefixcreate to copy the truetype fonts (if any) from > /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert > distro specific X11/fonts/TTF directory] to > $WINEPREFIX/drive_c/windows/fonts/ ? No. It's the distribution's duty to put ttf fonts in the path available through the fontconfig APIs. -- Dmitry. From patrol at sinus.cz Tue Feb 20 22:50:37 2007 From: patrol at sinus.cz (Pavel Troller) Date: Tue Feb 20 22:50:52 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <200702210116.44685.stefan@codeweavers.com> References: <20070220053731.GA28646@tangens.sinus.cz> <200702201105.56452.stefan@codeweavers.com> <20070220205503.GA26428@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> Message-ID: <20070221045037.GA25247@tangens.sinus.cz> > > > I don't know about this regression. Can you do a bisect? > > > > Yes, done. It's the following commit: > > > > commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc > > Author: Stefan D??singer > > Date: Wed Feb 14 17:59:08 2007 +0100 > > > > wined3d: More fullscreen window fixes. > > > > The game is run in a virtual desktop (i.e. it appears in the Linux window, > > not in full screen). > That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace? OK, did it. Sending two traces: A bad one, and a good one made by wine just before the above commit. With regards, Pavel Troller > -------------- next part -------------- A non-text attachment was scrubbed... Name: bos_traces.tar.bz2 Type: application/x-tar-bz2 Size: 16084 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070221/c3ae457a/bos_traces.tar.bin From wine-devel at kievinfo.com Tue Feb 20 22:47:57 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Tue Feb 20 22:55:13 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <87sld12c2y.fsf@wine.dyndns.org> References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> <45DAF552.2060608@kievinfo.com> <87sld12c2y.fsf@wine.dyndns.org> Message-ID: <45DBCEFD.1070703@kievinfo.com> Alexandre Julliard wrote: > Vitaliy Margolen writes: > >> http://source.winehq.org/source/server/handle.c#L523 calls >> duplicate_handle with NULL process. > > Yes, but duplicate_handle has no reason to call get_handle on the dst Sure there is. How else do I set the requested access mask? > process. I see that your 3/3 patch does this, but that's broken. Right that's the way it's designed by the original! I tried to explain the reason by I guess all that and tests are not enough. If you have a better solution, please implement it by all means. I have other things to worry about ATM. Vitaliy. From frank.richter at gmail.com Tue Feb 20 23:53:48 2007 From: frank.richter at gmail.com (Frank Richter) Date: Wed Feb 21 01:10:07 2007 Subject: [Bug 7503] Eve Online pasword box on login screen doesn't work In-Reply-To: <006601c75560$589687b0$0100a8c0@DMITRY> References: <558b2f5c0702201548u5afcedc5gb1644ab00080c16a@mail.gmail.com> <006601c75560$589687b0$0100a8c0@DMITRY> Message-ID: On 21.02.2007 03:31, Dmitry Timoshkov wrote: > "Lei Zhang" wrote: > >> Can we change wineprefixcreate to copy the truetype fonts (if any) from >> /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert >> distro specific X11/fonts/TTF directory] to >> $WINEPREFIX/drive_c/windows/fonts/ ? > > No. It's the distribution's duty to put ttf fonts in the path available > through the fontconfig APIs. Unless the game tries to read the .TTF file directly from the Windows\Fonts directory. (For e.g. "custom" rendering without GDI. I don't know if that's the case, but it's a possibility.) -f.r. From julliard at winehq.org Wed Feb 21 02:22:48 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 21 02:22:53 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <45DBCEFD.1070703@kievinfo.com> (Vitaliy Margolen's message of "Tue\, 20 Feb 2007 21\:47\:57 -0700") References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> <45DAF552.2060608@kievinfo.com> <87sld12c2y.fsf@wine.dyndns.org> <45DBCEFD.1070703@kievinfo.com> Message-ID: <87fy8z3oo7.fsf@wine.dyndns.org> Vitaliy Margolen writes: > Alexandre Julliard wrote: >> Yes, but duplicate_handle has no reason to call get_handle on the dst > Sure there is. How else do I set the requested access mask? By creating the handle with the correct mask right away, instead of setting a wrong mask and patching it up afterwards. -- Alexandre Julliard julliard@winehq.org From stefan at codeweavers.com Wed Feb 21 04:52:49 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Wed Feb 21 04:53:29 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221045037.GA25247@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> Message-ID: <200702211152.55543.stefan@codeweavers.com> > OK, did it. Sending two traces: A bad one, and a good one made by wine just > before the above commit. > With regards, Pavel Troller > trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was > 90000000,00000008, setting to 90080000,00000008 > trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) This here seems strange. If you compare that to the good log you'll see that IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a possible reason for the abortion I think that somewhere an exception is thrown, caught by the game which terminates afterwards. You can do the following: -> Run the game in winedbg and see if it catches the execption and gives a backtrace and crash position -> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the last line that is exectuted successfully. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070221/a4e50ab2/attachment.pgp From julliard at winehq.org Wed Feb 21 06:14:47 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 21 06:15:51 2007 Subject: resend : gdi32:WidenPath partial implementation In-Reply-To: <45D8A3D8.9070609@vromman.org> (Laurent Vromman's message of "Sun\, 18 Feb 2007 20\:07\:04 +0100") References: <45D8A3D8.9070609@vromman.org> Message-ID: <87bqjn3dxk.fsf@wine.dyndns.org> Laurent Vromman writes: > + > + dc = DC_GetDCPtr( hdc ); You shouldn't need that, the caller has done it already. Simply pass a DC* to this function. > + if(pPath->state != PATH_Closed) { > + ERR("Path Closed\n"); > + return FALSE; > + } > + > + hPen = SelectObject(hdc, GetStockObject(DC_PEN)); You shouldn't select a new pen into the DC, just use the current one. > + case PT_BEZIERTO: > + // should never happen because of the FlattenPath call Please avoid C++ comments. > + default: > + ERR("Got path flag %d\n", (INT)pPath->pFlags[i]); Please avoid casts like this, use the correct printf format instead. -- Alexandre Julliard julliard@winehq.org From wine-devel at kievinfo.com Wed Feb 21 07:32:31 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Wed Feb 21 07:39:46 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <87fy8z3oo7.fsf@wine.dyndns.org> References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> <45DAF552.2060608@kievinfo.com> <87sld12c2y.fsf@wine.dyndns.org> <45DBCEFD.1070703@kievinfo.com> <87fy8z3oo7.fsf@wine.dyndns.org> Message-ID: <45DC49EF.402@kievinfo.com> Alexandre Julliard wrote: > Vitaliy Margolen writes: > >> Alexandre Julliard wrote: >>> Yes, but duplicate_handle has no reason to call get_handle on the dst >> Sure there is. How else do I set the requested access mask? > > By creating the handle with the correct mask right away, instead of > setting a wrong mask and patching it up afterwards. That can only be done if permissions are not checked. I thought it was clear from the tests that even when expressly prohibited, you can create a handle with full access rights to the process if you can duplicate handle. I tried to keep all the changes in the one place (duplicate_handle) and not spread them around into create_handle. Vitaliy. From julliard at winehq.org Wed Feb 21 07:59:09 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 21 07:59:06 2007 Subject: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them. In-Reply-To: <45DC49EF.402@kievinfo.com> (Vitaliy Margolen's message of "Wed\, 21 Feb 2007 06\:32\:31 -0700") References: <45DA8BEE.9030205@kievinfo.com> <874pph3zla.fsf@wine.dyndns.org> <45DAF552.2060608@kievinfo.com> <87sld12c2y.fsf@wine.dyndns.org> <45DBCEFD.1070703@kievinfo.com> <87fy8z3oo7.fsf@wine.dyndns.org> <45DC49EF.402@kievinfo.com> Message-ID: <877iub393m.fsf@wine.dyndns.org> Vitaliy Margolen writes: > Alexandre Julliard wrote: >> Vitaliy Margolen writes: >> >>> Alexandre Julliard wrote: >>>> Yes, but duplicate_handle has no reason to call get_handle on the dst >>> Sure there is. How else do I set the requested access mask? >> >> By creating the handle with the correct mask right away, instead of >> setting a wrong mask and patching it up afterwards. > > That can only be done if permissions are not checked. I thought it was > clear from the tests that even when expressly prohibited, you can create > a handle with full access rights to the process if you can duplicate handle. > I tried to keep all the changes in the one place (duplicate_handle) and > not spread them around into create_handle. No, all the mess is because you added checks in alloc_handle (which is fine) then try to hack around them in duplicate_handle. What you should do is do the appropriate checks in duplicate_handle and then call alloc_entry directly. -- Alexandre Julliard julliard@winehq.org From patrol at sinus.cz Wed Feb 21 08:24:45 2007 From: patrol at sinus.cz (Pavel Troller) Date: Wed Feb 21 08:24:59 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <200702211152.55543.stefan@codeweavers.com> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> Message-ID: <20070221142445.GA31967@tangens.sinus.cz> > > > trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was > > 90000000,00000008, setting to 90080000,00000008 > > trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) > This here seems strange. If you compare that to the good log you'll see that > IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a > possible reason for the abortion I think that somewhere an exception is > thrown, caught by the game which terminates afterwards. Doesn't seem so. See below. > > You can do the following: > -> Run the game in winedbg and see if it catches the execption and gives a > backtrace and crash position There is no such exception, at least winedbg doesn't catch any. Is a special action (command etc.) > -> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the > last line that is exectuted successfully. Hmm... I added some traces to device.c. We know that last known trace from Init3D in the bad case is "Creating implicit swapchain." I added a new trace here: /* Setup the implicit swapchain */ TRACE("Creating implicit swapchain\n"); if (D3D_OK != D3DCB_CreateAdditionalSwapChain((IUnknown *) This->parent, pPresentationParameters, (IWineD3DSwapChain **)&swapchain) || swapchain == NULL) { WARN("Failed to create implicit swapchain\n"); return WINED3DERR_INVALIDCALL; } TRACE("1674\n"); (it's on line 1674) and this one was NOT reached. I'm a bit confusd because I failed to find the code for D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its definition in wined3d_interface.h. So, what to do next ? With regards, Pavel Troller From patrol at sinus.cz Wed Feb 21 08:26:27 2007 From: patrol at sinus.cz (Pavel Troller) Date: Wed Feb 21 08:26:35 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221142445.GA31967@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> Message-ID: <20070221142627.GB31967@tangens.sinus.cz> > > You can do the following: > > -> Run the game in winedbg and see if it catches the execption and gives a > > backtrace and crash position > There is no such exception, at least winedbg doesn't catch any. Is a special > action (command etc.) Oops. Unfinished mail sent. I meant: Is a special action (command etc.) necessary to enable exception catching in winedbg ? Pavel From hverbeet at gmail.com Wed Feb 21 08:46:32 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Wed Feb 21 08:46:45 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221142445.GA31967@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> Message-ID: On 21/02/07, Pavel Troller wrote: > I'm a bit confusd because I failed to find the code for > D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its > definition in wined3d_interface.h. That's D3D7CB_CreateAdditionalSwapChain() in dlls/ddraw/ddraw.c From patrol at sinus.cz Wed Feb 21 10:38:51 2007 From: patrol at sinus.cz (Pavel Troller) Date: Wed Feb 21 10:39:05 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> Message-ID: <20070221163851.GA10525@tangens.sinus.cz> > On 21/02/07, Pavel Troller wrote: > >I'm a bit confusd because I failed to find the code for > >D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and > >its > >definition in wined3d_interface.h. > That's D3D7CB_CreateAdditionalSwapChain() in dlls/ddraw/ddraw.c > Hi! OK, thanks, found it now. I've modified its code by inserting many traces: { ICOM_THIS_FROM(IDirectDrawImpl, IDirectDraw7, device); IParentImpl *object = NULL; HRESULT res = D3D_OK; IWineD3DSwapChain *swapchain; TRACE("(%p) call back\n", device); TRACE("$$$$ 2672\n"); object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IParentImpl)); TRACE("$$$$ 2674\n"); if (NULL == object) { FIXME("Allocation of memory failed\n"); *ppSwapChain = NULL; return DDERR_OUTOFVIDEOMEMORY; } TRACE("$$$$ 2681\n"); ICOM_INIT_INTERFACE(object, IParent, IParent_Vtbl); TRACE("$$$$ 2683\n"); object->ref = 1; res = IWineD3DDevice_CreateAdditionalSwapChain(This->wineD3DDevice, pPresentationParameters, &swapchain, (IUnknown*) ICOM_INTERFACE(object, IParent), D3D7CB_CreateRenderTarget, D3D7CB_CreateDepthStencilSurface); TRACE("$$$$ 2692\n"); if (res != D3D_OK) { FIXME("(%p) call to IWineD3DDevice_CreateAdditionalSwapChain failed\n", This); HeapFree(GetProcessHeap(), 0 , object); *ppSwapChain = NULL; } else { TRACE("2701\n"); *ppSwapChain = swapchain; object->child = (IUnknown *) swapchain; } TRACE("$$$$ Returning\n"); return res; } The last trace which appeared in the log is 2683, so IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas from those names; where the hell this one grows :-) ? grep, as obvious, shows its calls only. With regards, Pavel Troller From hverbeet at gmail.com Wed Feb 21 12:09:38 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Wed Feb 21 12:09:54 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221163851.GA10525@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> <20070221163851.GA10525@tangens.sinus.cz> Message-ID: On 21/02/07, Pavel Troller wrote: > The last trace which appeared in the log is 2683, so > IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas > from those names; where the hell this one grows :-) ? grep, as obvious, shows > its calls only. IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c. IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined in include/wine/wined3d_interface.h. From patrol at sinus.cz Wed Feb 21 13:31:30 2007 From: patrol at sinus.cz (Pavel Troller) Date: Wed Feb 21 13:31:50 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> <20070221163851.GA10525@tangens.sinus.cz> Message-ID: <20070221193130.GA20217@tangens.sinus.cz> > On 21/02/07, Pavel Troller wrote: > > The last trace which appeared in the log is 2683, so > >IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas > >from those names; where the hell this one grows :-) ? grep, as obvious, > >shows > >its calls only. > IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c. > IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined > in include/wine/wined3d_interface.h. > Thanks, traced a few calls deeper. Now I'm standing at static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice *iface, HWND window) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; LONG style, exStyle; /* Don't do anything if an original style is stored. * That shouldn't happen */ TRACE("(%p): Setting up window %p for exclusive mode\n", This, window); if (This->style || This->exStyle) { ERR("(%p): Want to change the window parameters of HWND %p, but " "another style is stored for restoration afterwards\n", This, window); } /* Get the parameters and save them */ style = GetWindowLongW(window, GWL_STYLE); exStyle = GetWindowLongW(window, GWL_EXSTYLE); This->style = style; This->exStyle = exStyle; /* Filter out window decorations */ style &= ~WS_CAPTION; style &= ~WS_THICKFRAME; exStyle &= ~WS_EX_WINDOWEDGE; exStyle &= ~WS_EX_CLIENTEDGE; /* Make sure the window is managed, otherwise we won't get keyboard input */ style |= WS_POPUP | WS_SYSMENU; TRACE("Old style was %08x,%08x, setting to %08x,%08x\n", This->style, This->exStyle, style, exStyle); TRACE("1184\n"); SetWindowLongW(window, GWL_STYLE, style); SetWindowLongW(window, GWL_EXSTYLE, exStyle); TRACE("1187\n"); /* Inform the window about the update. */ SetWindowPos(window, HWND_TOP, 0, 0, This->ddraw_width, This->ddraw_height, SWP_FRAMECHANGED); TRACE("1191\n"); ShowWindow(window, TRUE); TRACE("1193\n"); } The last trace executed is 1187, which looks that SetWindowPos doesn't return. Should I trace even more deep, or is anybody getting an idea, what can be wrong here ? Where is SetWindowPos located ? With regards, Pavel Troller From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 21 14:00:54 2007 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed Feb 21 14:01:09 2007 Subject: wine.inf: Update the timezone information. In-Reply-To: References: Message-ID: <17884.42230.498425.450243@hertz.ikp.physik.tu-darmstadt.de> >>>>> "Francois" == Francois Gouget writes: Francois> --- I have used two sources to update Wine's timezone data: ... Francois> The display name was set to the Olson database ids and I have Francois> kept it that way as it seems to match what is displayed on Francois> Linux. Wherever we used old names I switched to the new names Francois> as specified in the Olson database. Francois> We still have a few differences with the Windows data and in a Francois> few instances I diverged from the CLDR mapping to tzids. I Francois> will now summarize all these differences in bug 7295. How do internaltional version of Windows get the localized names of the pletora of timezones? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From thestig at google.com Wed Feb 21 14:13:14 2007 From: thestig at google.com (Lei Zhang) Date: Wed Feb 21 14:13:31 2007 Subject: message sequence testing - message flags Message-ID: <558b2f5c0702211213p76826f42yd4678564834230e1@mail.gmail.com> Hi, In dlls/user32/tests/msg.c, there's the following enum: typedef enum { sent=0x1, posted=0x2, parent=0x4, wparam=0x8, lparam=0x10, defwinproc=0x20, beginpaint=0x40, optional=0x80, hook=0x100, winevent_hook=0x200 } msg_flags_t; Can someone explain what these flags mean? parent defwinproc beginpaint hook winevent_hook - Lei From reif at earthlink.net Wed Feb 21 19:24:26 2007 From: reif at earthlink.net (Robert Reif) Date: Wed Feb 21 19:24:43 2007 Subject: [DSOUND] Implement a locking mechanism In-Reply-To: <45DC9D15.8020100@gmail.com> References: <45DC9D15.8020100@gmail.com> Message-ID: <45DCF0CA.4080906@earthlink.net> Maarten Lankhorst wrote: >[DSOUND] Implement a locking mechanism > >Attempt to implement locking in dsounds mixer. > >Sadly horribly broken, I'm posting this in the hope someone knows what >magic values to fill in at the first "if (lock)" .. I really have no clue. > >As stated before it is required to be used with previous winealsa patch. > >Right now it also calls Unlock with lockamount as argument, this should >probably be changed to how much is actually written to (frag), but that >part doesn't really matter much I think, it's more important to get the >first Lock() right. > > You shouldn't need to make any changes to direct sound. You just need to remove the flag DSDDESC_DONTNEEDPRIMARYLOCK from alsa and make the necessary changes in alsa. The direct sound hardware primary buffer locking support is already in primary.c. From twickline at gmail.com Wed Feb 21 20:11:06 2007 From: twickline at gmail.com (Tom Wickline) Date: Wed Feb 21 20:11:17 2007 Subject: WineConf 2007 Fundraiser proposal Message-ID: <53e3a9930702211811k7fc8580ejeb037b3983ce60a0@mail.gmail.com> Hello Everyone, On February 14th I made a suggestion on the wine-conf mailing list that we should have a annual Fund Raiser to help raise funds for our annual Conference. http://www.winehq.org/pipermail/wineconf/2007-February/000397.html Jeremy replied with his thoughts/suggestions and some back ground info on how the WPF funds have helped in the past. http://www.winehq.org/pipermail/wineconf/2007-February/000403.html >From this, I cobbled together a extremely rough Donations page.. Keep in mind this is still very much a work in progress and the language within it needs major revisions. http://www.winehq.org/pipermail/wineconf/2007-February/000425.html The current discussion is now on whether or not a $1,000 donation is sufficient for a front page listing for one year since our search rank in so high. Dan suggested that we join adsence, and I replied that I had already suggested this in the past. http://www.winehq.org/pipermail/wineconf/2007-February/000437.html At this point there are many undecided questions about the original suggestion of us having a fund raiser, as well as if we should join adsence. If you have a opinion on this subject we would like (even suggest) that you to air them at this time before decisions are made. http://www.winehq.org/pipermail/wineconf/2007-February/000440.html Questions: Should we have a annual fundraiser to help with conference expenses? Thus far the consciences is Yes. What is a realistic goal? I believe $10,000 is very doable. What amount should we receive for a front page listing 'gold sponsor'? Is $10,000 to much or to small of a amount? If we decide on $10,000 the goal should be revised to about $25,000 Should the Wine project join the adsence network? With our high google page rank we are practically guaranteed to rake in a mint :D Comments and suggestions are at this time highly suggested! Tom From dmitry at codeweavers.com Wed Feb 21 21:44:24 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Wed Feb 21 21:44:21 2007 Subject: message sequence testing - message flags References: <558b2f5c0702211213p76826f42yd4678564834230e1@mail.gmail.com> Message-ID: <00bf01c75633$c26617e0$0100a8c0@DMITRY> "Lei Zhang" wrote: > In dlls/user32/tests/msg.c, there's the following enum: > > typedef enum { > sent=0x1, > posted=0x2, > parent=0x4, > wparam=0x8, > lparam=0x10, > defwinproc=0x20, > beginpaint=0x40, > optional=0x80, > hook=0x100, > winevent_hook=0x200 > } msg_flags_t; > > Can someone explain what these flags mean? I'd expect it should be obvious. Use the source Lei! :-) > parent A message sent by a parent > defwinproc A message resulted from a DefWindowProc call > beginpaint A message resulted from of a BeginPaint call > hook A message sent by a hook > winevent_hook A message sent by a winevent hook -- Dmitry. From scott at open-vote.org Wed Feb 21 22:20:08 2007 From: scott at open-vote.org (Scott Ritchie) Date: Wed Feb 21 22:47:13 2007 Subject: WineConf 2007 Fundraiser proposal In-Reply-To: <53e3a9930702211811k7fc8580ejeb037b3983ce60a0@mail.gmail.com> References: <53e3a9930702211811k7fc8580ejeb037b3983ce60a0@mail.gmail.com> Message-ID: <1172118008.17844.35.camel@scott-desktop> On Wed, 2007-02-21 at 21:11 -0500, Tom Wickline wrote: > Should the Wine project join the adsence network? > With our high google page rank we are practically guaranteed to rake > in a mint :D > Interesting note: our most likely sponsor is going to be a company involved with wine (the food item). Even though we have nothing to do with one-another, the ranking obtained by googling a term containing "wine" is certainly highly prized. Thanks, Scott Ritchie From patrol at sinus.cz Thu Feb 22 08:04:27 2007 From: patrol at sinus.cz (Pavel Troller) Date: Thu Feb 22 08:04:51 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221193130.GA20217@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> <20070221163851.GA10525@tangens.sinus.cz> <20070221193130.GA20217@tangens.sinus.cz> Message-ID: <20070222140427.GA27426@tangens.sinus.cz> > > On 21/02/07, Pavel Troller wrote: > > > The last trace which appeared in the log is 2683, so > > >IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas > > >from those names; where the hell this one grows :-) ? grep, as obvious, > > >shows > > >its calls only. > > IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c. > > IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined > > in include/wine/wined3d_interface.h. > > > Thanks, > traced a few calls deeper. Now I'm standing at > > static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice *iface, HWND window) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > > LONG style, exStyle; > /* Don't do anything if an original style is stored. > * That shouldn't happen > */ > TRACE("(%p): Setting up window %p for exclusive mode\n", This, window); > if (This->style || This->exStyle) { > ERR("(%p): Want to change the window parameters of HWND %p, but " > "another style is stored for restoration afterwards\n", This, window); > } > > /* Get the parameters and save them */ > style = GetWindowLongW(window, GWL_STYLE); > exStyle = GetWindowLongW(window, GWL_EXSTYLE); > This->style = style; > This->exStyle = exStyle; > > /* Filter out window decorations */ > style &= ~WS_CAPTION; > style &= ~WS_THICKFRAME; > exStyle &= ~WS_EX_WINDOWEDGE; > exStyle &= ~WS_EX_CLIENTEDGE; > > /* Make sure the window is managed, otherwise we won't get keyboard input */ > style |= WS_POPUP | WS_SYSMENU; > > TRACE("Old style was %08x,%08x, setting to %08x,%08x\n", > This->style, This->exStyle, style, exStyle); > TRACE("1184\n"); > SetWindowLongW(window, GWL_STYLE, style); > SetWindowLongW(window, GWL_EXSTYLE, exStyle); > TRACE("1187\n"); > /* Inform the window about the update. */ > SetWindowPos(window, HWND_TOP, 0, 0, > This->ddraw_width, This->ddraw_height, SWP_FRAMECHANGED); > TRACE("1191\n"); > ShowWindow(window, TRUE); > TRACE("1193\n"); > } > > The last trace executed is 1187, which looks that SetWindowPos doesn't return. > Should I trace even more deep, or is anybody getting an idea, what can be wrong > here ? > Where is SetWindowPos located ? > > With regards, Pavel Troller > Hi! Because I had to restore working wine, I did the following: 1) Restored original files 2) Pulled today's version 3) Compiled and verified ... Fallout tactics still didn't start with the obvious symptoms. So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow (on lines 1251&2 of the today's source) and... voilla, the game starts and runs perfectly. My son has verified it and didn't find any problems. Then he tried HL2 and it seems also fully functional. So... The bug is still there, but my workaround fixes it for me and I didn't find any drawbacks (trying a lot of programs I'm using like IDA and some special telco programs). Because I didn't read anything from Stefan for a while, I'll wait a bit more and then I'll create a bugzilla record for it. Is it ok ? With regards, Pavel Troller From stefan at codeweavers.com Thu Feb 22 08:42:20 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 22 08:42:56 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070222140427.GA27426@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <20070221193130.GA20217@tangens.sinus.cz> <20070222140427.GA27426@tangens.sinus.cz> Message-ID: <200702221542.26881.stefan@codeweavers.com> Am Donnerstag 22 Februar 2007 15:04 schrieb Pavel Troller: > So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow > (on lines 1251&2 of the today's source) and... voilla, the game starts and > runs perfectly. My son has verified it and didn't find any problems. Yeah, the SetWindowPos isn't required for all games. One game that needs it is Gothic 2. It is strange that SetWindowPos crashed. Can you check that window is valid(i.e. not NULL)? TRACE("window is %p\n", window); > Because I didn't read anything from Stefan for a while, I'll wait a bit > more and then I'll create a bugzilla record for it. > Is it ok ? I was away the last day on a small LAN party with friends, thats why I didn't reply. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070222/66efa7af/attachment.pgp From patrol at sinus.cz Thu Feb 22 09:08:24 2007 From: patrol at sinus.cz (Pavel Troller) Date: Thu Feb 22 09:08:48 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <200702221542.26881.stefan@codeweavers.com> References: <20070220053731.GA28646@tangens.sinus.cz> <20070221193130.GA20217@tangens.sinus.cz> <20070222140427.GA27426@tangens.sinus.cz> <200702221542.26881.stefan@codeweavers.com> Message-ID: <20070222150824.GA3258@tangens.sinus.cz> Hi! > Am Donnerstag 22 Februar 2007 15:04 schrieb Pavel Troller: > > So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow > > (on lines 1251&2 of the today's source) and... voilla, the game starts and > > runs perfectly. My son has verified it and didn't find any problems. > Yeah, the SetWindowPos isn't required for all games. One game that needs it is > Gothic 2. > > It is strange that SetWindowPos crashed. Can you check that window is > valid(i.e. not NULL)? And would it be possible that the immediately following ShowWindow(window, TRUE) wouldn't fail too ? > > TRACE("window is %p\n", window); > > > Because I didn't read anything from Stefan for a while, I'll wait a bit > > more and then I'll create a bugzilla record for it. > > Is it ok ? > I was away the last day on a small LAN party with friends, thats why I didn't > reply. OK, never mind. I can continue debugging tonight, just now the machine is occupied by my son and his friend :-). I will look at SetWindowPos(). Could you tell me in which file its source is ? With regards, Pavel Troller From hverbeet at gmail.com Thu Feb 22 09:15:04 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Thu Feb 22 09:15:20 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070222150824.GA3258@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <20070221193130.GA20217@tangens.sinus.cz> <20070222140427.GA27426@tangens.sinus.cz> <200702221542.26881.stefan@codeweavers.com> <20070222150824.GA3258@tangens.sinus.cz> Message-ID: On 22/02/07, Pavel Troller wrote: > OK, never mind. I can continue debugging tonight, just now the machine is > occupied by my son and his friend :-). I will look at SetWindowPos(). Could you > tell me in which file its source is ? That's in dlls/user32/winpos.c, but I'm not sure how likely it is for the problem to be in there. From julesrichardsonuk at yahoo.co.uk Thu Feb 22 09:15:24 2007 From: julesrichardsonuk at yahoo.co.uk (Jules Richardson) Date: Thu Feb 22 09:16:58 2007 Subject: How complete will Wine ever be for older apps? Message-ID: <45DDB38C.5060608@yahoo.co.uk> Sort of an open-ended question to developers :) It's obvious that Wine functionality will always lag behind Windows releases somewhat. But how accurate / complete do people think it will eventually be against older Windows releases? Is much development work even still being done on things that don't quite work as expected within apps that were current at the time of say NT4? I'm just trying to build up a picture in my head of whether there will come a day when Wine users can pick an app designed for a previous generation of Windows and expect it to work flawlessly (ignoring things that try to manipulate the hardware directly, I suppose)? Or will there always be incompatibilities? cheers Jules From stefan at codeweavers.com Thu Feb 22 09:46:11 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Thu Feb 22 09:46:50 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: References: <20070220053731.GA28646@tangens.sinus.cz> <20070222150824.GA3258@tangens.sinus.cz> Message-ID: <200702221646.15635.stefan@codeweavers.com> Am Donnerstag 22 Februar 2007 16:15 schrieb H. Verbeet: > On 22/02/07, Pavel Troller wrote: > > OK, never mind. I can continue debugging tonight, just now the machine is > > occupied by my son and his friend :-). I will look at SetWindowPos(). > > Could you tell me in which file its source is ? > > That's in dlls/user32/winpos.c, but I'm not sure how likely it is for > the problem to be in there. I do not think that the problem is in SetWindowPos. I think the problem is in wined3d, either some bad parameter to SetWindowPos or maybe SetWindowPos causes signals to be sent that native d3d does not send. That said, this is a Direct3D7 application, where the window setup is done BEFORE creating the Direct3D device(which calls Init3D in wined3d). So I gather that SetupFullscreenWindow should not be called during Init3D in the d3d7 case because the window and fullscreen setting are not changed. Setting window parameters there may cause signals to be sent to the application that cause crashes in the app. So I think the question is why SetupFullscreenWindow is called at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070222/348ed712/attachment.pgp From rob at codeweavers.com Thu Feb 22 09:49:28 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 22 09:50:09 2007 Subject: kernel32: Set object security on process object in CreateProcess. In-Reply-To: <45DD107C.3060206@kievinfo.com> References: <45DD107C.3060206@kievinfo.com> Message-ID: <45DDBB88.7070706@codeweavers.com> Vitaliy Margolen wrote: > + > + /* set process security */ > + if (ret && psa && psa->lpSecurityDescriptor) > + { > + NTSTATUS status; > + > + status = NtSetSecurityObject( info->hProcess, DACL_SECURITY_INFORMATION, > + psa->lpSecurityDescriptor ); > + ret = status == STATUS_SUCCESS; > + if (!ret) SetLastError( RtlNtStatusToDosError( status ) ); > + } > + > It would be better to pass the security descriptor (or just the DACL if you would prefer) in the new_process call. You should be able to change the security structure validation functions to return the number of bytes used. Therefore, you should be able to put the security data before the other variable data in the new_process call. Also, I think several tests in advapi32 should succeed after this patch is applied so you will need to patch that too. -- Rob Shearman From m.b.lankhorst at gmail.com Thu Feb 22 05:02:42 2007 From: m.b.lankhorst at gmail.com (M.B. Lankhorst) Date: Thu Feb 22 10:32:09 2007 Subject: [DSOUND] Implement a locking mechanism Message-ID: <45DD7852.8070503@gmail.com> Robert Reif wrote: > You shouldn't need to make any changes to direct sound. You just need > to remove the flag DSDDESC_DONTNEEDPRIMARYLOCK from alsa and make the > necessary changes in alsa. The direct sound hardware primary buffer > locking support is already in primary.c. You are right, partially, primary.c already has support for it, but that is only used when the application chooses to write to the primary buffer directly, in most cases the primary buffer is only used directly by the directsound mixer, and that's the case this patch is trying to handle. However the problem I have right now is that I miss some magic values so sound is a bit cumbersome, maybe someone with knowledge of dsound knows what I should put in there and be able to help me out a little. Maarten PS: CC to people you address in your emails, not everyone receives messages from wine-devel mailing lists. From twickline at gmail.com Thu Feb 22 12:04:27 2007 From: twickline at gmail.com (Tom Wickline) Date: Thu Feb 22 12:04:57 2007 Subject: WineConf 2007 Fundraiser proposal In-Reply-To: <53e3a9930702211811k7fc8580ejeb037b3983ce60a0@mail.gmail.com> References: <53e3a9930702211811k7fc8580ejeb037b3983ce60a0@mail.gmail.com> Message-ID: <53e3a9930702221004u14c8f0a2p65a6f7144d8466c2@mail.gmail.com> On 2/21/07, Tom Wickline wrote: > > Comments and suggestions are at this time highly suggested! We could have a small WPF "Guidelines" and spell out what we intend to spend any raised funds on/for.. Trying to answer the tough questions at hand! Here is a rough suggestion, please feel free to comment on it! (Q) What will the funds that I donate be spent on? (A) All WPF funds will go toward the goal of the Wine project being a self sufficient entity, from time to time we will need to purchase new servers and have maintenance done on our existing servers. We can also help subsidize the purchase of documentation and programming tools for core developers. But the bulk of the funds will be spent on a yearly conference for developers. (Q) What will the funds that are generated through adsence be spent on? (A) The above answer! (Q) Who is in charge of the WPF funds and distribution? (A) Jeremy White CEO and potentate of CodeWeavers (Q) What role will the WPF play in the conference? (A) The WPF will rent conference facilities, pay for one group meal, and one group outing for social conversation and comradery, sponsor travel expenses for core Wine developers. (Q) Who is eligible for conference sponsorship? (A) The top twenty core developers by lines of code committed to the git tree (Q) How often is eligibility reviewed? (A) On a yearly basis (Q) Who is in charge of the guidelines and how are changes made to it. (A) Changes can only be made by a consciences of the core developers and Jeremy White the overseer of the WPF. ----- The above suggestions and comments are my personal thoughts and suggestions, they should in no way be meant as a consciences or goals set by or of the Wine project. > > Tom > From juan_lang at yahoo.com Thu Feb 22 12:52:43 2007 From: juan_lang at yahoo.com (Juan Lang) Date: Thu Feb 22 12:53:33 2007 Subject: How complete will Wine ever be for older apps? Message-ID: <890256.77836.qm@web39702.mail.mud.yahoo.com> > I'm just trying to build up a picture in my head of whether there > will come a day when Wine users can pick an app designed for a > previous generation of Windows and expect it to work flawlessly > (ignoring things that try to manipulate the hardware directly, I > suppose)? Or will there always be incompatibilities? There will (likely) always be incompatibilities. Wine development has always been driven by app compatibility - someone picks an app and tries to run it, and tries to fix problems they come across. We don't aim for feature completeness - Windows is far, far too big to replicate with the resources we have. So, some apps (the ones developers have worked on, and likely others) will work quite well, while others (those that haven't been worked on) may not work as well. --Juan ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ From fgouget at codeweavers.com Thu Feb 22 13:14:35 2007 From: fgouget at codeweavers.com (Francois Gouget) Date: Thu Feb 22 13:14:52 2007 Subject: wine.inf: Update the timezone information. In-Reply-To: <17884.42230.498425.450243@hertz.ikp.physik.tu-darmstadt.de> References: <17884.42230.498425.450243@hertz.ikp.physik.tu-darmstadt.de> Message-ID: <45DDEB9B.2030103@codeweavers.com> Uwe Bonnes wrote: [...] > How do internaltional version of Windows get the localized names of the > pletora of timezones? Apparently the registry keys and values themselves are translated, at least in NT4. That does not seem scalable at all so I don't know if that's still the approach they use. -- Francois Gouget fgouget@codeweavers.com From wine.dev at web.de Thu Feb 22 15:48:29 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Thu Feb 22 15:49:10 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <20070221193130.GA20217@tangens.sinus.cz> References: <20070220053731.GA28646@tangens.sinus.cz> <200702210116.44685.stefan@codeweavers.com> <20070221045037.GA25247@tangens.sinus.cz> <200702211152.55543.stefan@codeweavers.com> <20070221142445.GA31967@tangens.sinus.cz> <20070221163851.GA10525@tangens.sinus.cz> <20070221193130.GA20217@tangens.sinus.cz> Message-ID: <1172180909.6908.48.camel@p4> On Mi, 2007-02-21 at 20:31 +0100, Pavel Troller wrote: > Where is SetWindowPos located ? You can find a function with "findfunc" detlef@p4:~/wine.cvs/src$ tools/findfunc SetWindowPos dlls/user32/winpos.c:BOOL WINAPI SetWindowPos( and also dlls/winex11.drv/winpos.c:BOOL X11DRV_SetWindowPos -- By by ... Detlef From rob at codeweavers.com Thu Feb 22 16:01:52 2007 From: rob at codeweavers.com (Robert Shearman) Date: Thu Feb 22 16:02:36 2007 Subject: ntdll: implement NtAllocateLocallyUniqueId with server call In-Reply-To: <514062.23234.qm@web39713.mail.mud.yahoo.com> References: <514062.23234.qm@web39713.mail.mud.yahoo.com> Message-ID: <45DE12D0.9040506@codeweavers.com> Juan Lang wrote: > This introduces a warning in trace.c about dump_luid being undeclared. > trace.c seems to be at least partially generated, so I wasn't sure about > sending a patch for it. Let me know how I should handle that and I'll fix > it up. > Hi Juan, dump_luid needs to be in trace.c. As you say, it is partially generated: > /* Everything below this line is generated automatically by > tools/make_requests > */ > /* ### make_requests begin ### */ So just put dump_luid above that line and it'll be fine. -- Rob Shearman From wine.dev at web.de Thu Feb 22 17:25:54 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Thu Feb 22 17:26:37 2007 Subject: xcopy support try 1... In-Reply-To: <000401c756cb$b3777a10$1001a8c0@JasonsPC> References: <000401c756cb$b3777a10$1001a8c0@JasonsPC> Message-ID: <1172186754.6908.76.camel@p4> On Do, 2007-02-22 at 21:52 +0000, Ann & Jason Edmeades wrote: > Firstly, I am not sure I have included everything correctly to define a new > directory in the build tree, With git, you only need to add all the new files to the Index ("git-update-index --add programs/xcopy/Makefile.in" as Example) and only that changes should be send. tools/make_makefiles does the rest, so you compile and test your new app. > I have only implemented the basics, Converting to unicode later is much harder. I suggest to use UNICODE from the begining. An example UNICODE console app is "programs/msiexec/*" When you really want to have also an ansi-version (for DOS or win9x as example), you can use TCHAR and test your app with and without "#define UNICODE". UNICODE is prefered and you avoid converting a lot of data, when the app is running. > which is file and subdirectory > copying plus the simple reporting information. The Patch would be even smaller, when you do no copy at all or just do a Filecopy without recursion / Parameter-Parsing (wildcards ) > + * According to http://www.microsoft.com/technet/archive/msdos/comm8.mspx?mfr=true Please remove that ref. Many URLs are a dead link really fast. -- By by ... Detlef From nlaw at nildram.co.uk Thu Feb 22 21:48:23 2007 From: nlaw at nildram.co.uk (Nick Law) Date: Thu Feb 22 21:46:38 2007 Subject: xcopy support try 1... In-Reply-To: <1172186754.6908.76.camel@p4> References: <000401c756cb$b3777a10$1001a8c0@JasonsPC> <1172186754.6908.76.camel@p4> Message-ID: <45DE6407.9030607@nildram.co.uk> Can somebody update the latest version number in AppDB to 0.9.31 Thanks Nick From hverbeet at gmail.com Fri Feb 23 02:35:27 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Fri Feb 23 02:35:33 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: <20070223082715.GE6219@crissy.swd.zerebecki.de> References: <20070223082715.GE6219@crissy.swd.zerebecki.de> Message-ID: On 23/02/07, Jan Zerebecki wrote: > From: Jan Zerebecki > Changelog: > winex11.drv: Set the refresh rate for the virtual desktop to 60 > instead of 0. If HKCU\Software\Wine\X11 Driver\FakeRefreshRate is > set, it is interpreted as a comma delimited list of refresh rates > to use instead. > --- Perhaps there should be a winecfg option for this, together with the one that already exists for the resolution. From jan.wine at zerebecki.de Fri Feb 23 02:46:05 2007 From: jan.wine at zerebecki.de (Jan Zerebecki) Date: Fri Feb 23 02:46:07 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: References: <20070223082715.GE6219@crissy.swd.zerebecki.de> Message-ID: <20070223084605.GG6219@crissy.swd.zerebecki.de> On Fri, Feb 23, 2007 at 09:35:27AM +0100, H. Verbeet wrote: > On 23/02/07, Jan Zerebecki wrote: > >winex11.drv: Set the refresh rate for the virtual desktop to 60 > >instead of 0. If HKCU\Software\Wine\X11 Driver\FakeRefreshRate is > >set, it is interpreted as a comma delimited list of refresh rates > >to use instead. > Perhaps there should be a winecfg option for this, together with the > one that already exists for the resolution. I don't think so. The only use is to make games happy that require a certain refresh rate (which is broken behaviour). If any require a refresh rate besides 60 we should extend the default value. So in the end the option would be of no use for the normal user. Jan From core5fedora at gmail.com Fri Feb 23 02:53:05 2007 From: core5fedora at gmail.com (Jeffrey Sabarese) Date: Fri Feb 23 02:53:10 2007 Subject: a big fan (now with bad news) Message-ID: hello there! thanks to all of you who replied to my inquiry about "ies4linux" vs compatibility w/ such "Windows-native" apps as Bradbury "TopStyle", HomeSite, etc... As Joris stated, IE6 sp1 is available at the MS site. I downloaded my own copy, but i haven't tried it yet because i think i "ruined" my WinE this evening. HOW? as my UserID (NOT as root), i "re installed" the [.reg] files in the ies4linux "faux directories" (as in a command such as :: [ wine '../win.reg' ]) . I tried [ yum remove wine ], and then [yum install wine] which went without a hitch, but there's no change in my Primary User (the broken one) HOWEVER, WinE continues to run perfectly under other user accounts, and ROOT. My QUESTION: How do i "restore" my WinE to a working state for my UserID? (because only UserID is affected) I wish to not destroy my Program Files while "repairing" WinE around it--- if possible. >From the primary UserID only, i can NOT launch [ winecfg.exe ] for example in terminal, or anything WinE that i can tell. ([while root, and other users were apparently not affected]) please help me to restore my "existing" Program files setup, if possible. it is no "tragedy" if i can not, but i'd like to try. in any event-- i do need to know how to "restore" it, maintaining program files or not. thank you!! best regards, -JS. On 2/21/07, SorinN wrote: > Indeed - ies4linux - don't use Wine folders - on other words - it use > winelib but is on other place, where TopStyle and other windows > programs don't know to look. I will try to talk with it's developer to > suggest him to use an existing Wine installation ( is Wine exist > already ). > > > > 2007/2/19, Jeffrey Sabarese : > > hi there! I have to wonder if i don't use WinE more than the "average" > > Fedora Core 5 user. I am forever trying to figure out how to run my > > old Windows apps here in the linux environment, using your incredible > > software. > > -- /* ************************************************ */ Quanta+ Web Development IDE: http://quanta.kdewebdev.org/ Quanta+ Wiki: http://tinyurl.com/3dzqxk Other Quanta Tips: http://invisiblepixels.org/progs/quanta.html /* ************************************************ */ From julliard at winehq.org Fri Feb 23 03:42:18 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Fri Feb 23 03:42:25 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: (H. Verbeet's message of "Fri\, 23 Feb 2007 09\:35\:27 +0100") References: <20070223082715.GE6219@crissy.swd.zerebecki.de> Message-ID: <873b4xnrb9.fsf@wine.dyndns.org> "H. Verbeet" writes: > On 23/02/07, Jan Zerebecki wrote: >> From: Jan Zerebecki >> Changelog: >> winex11.drv: Set the refresh rate for the virtual desktop to 60 >> instead of 0. If HKCU\Software\Wine\X11 Driver\FakeRefreshRate is >> set, it is interpreted as a comma delimited list of refresh rates >> to use instead. >> --- > Perhaps there should be a winecfg option for this, together with the > one that already exists for the resolution. In what case would you need to configure this? Can't we simply hardcode a couple of standard values? -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Fri Feb 23 03:55:21 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Fri Feb 23 03:55:26 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: <873b4xnrb9.fsf@wine.dyndns.org> References: <20070223082715.GE6219@crissy.swd.zerebecki.de> <873b4xnrb9.fsf@wine.dyndns.org> Message-ID: On 23/02/07, Alexandre Julliard wrote: > In what case would you need to configure this? Can't we simply > hardcode a couple of standard values? > Mostly for broken games that want specific values :-) But yeah, hardcoding standard values probably goes a long way. From meissner at suse.de Fri Feb 23 04:26:42 2007 From: meissner at suse.de (Marcus Meissner) Date: Fri Feb 23 04:26:46 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: References: <20070223082715.GE6219@crissy.swd.zerebecki.de> <873b4xnrb9.fsf@wine.dyndns.org> Message-ID: <20070223102642.GA11824@suse.de> On Fri, Feb 23, 2007 at 10:55:21AM +0100, H. Verbeet wrote: > On 23/02/07, Alexandre Julliard wrote: > >In what case would you need to configure this? Can't we simply > >hardcode a couple of standard values? > > > Mostly for broken games that want specific values :-) > But yeah, hardcoding standard values probably goes a long way. The RandR extension might help here too. Ciao, Marcus From hverbeet at gmail.com Fri Feb 23 04:45:36 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Fri Feb 23 04:46:27 2007 Subject: winex11.drv: Set the refresh rate for the virtual desktop to 60 In-Reply-To: <20070223102642.GA11824@suse.de> References: <20070223082715.GE6219@crissy.swd.zerebecki.de> <873b4xnrb9.fsf@wine.dyndns.org> <20070223102642.GA11824@suse.de> Message-ID: On 23/02/07, Marcus Meissner wrote: > On Fri, Feb 23, 2007 at 10:55:21AM +0100, H. Verbeet wrote: > > On 23/02/07, Alexandre Julliard wrote: > > >In what case would you need to configure this? Can't we simply > > >hardcode a couple of standard values? > > > > > Mostly for broken games that want specific values :-) > > But yeah, hardcoding standard values probably goes a long way. > > The RandR extension might help here too. Not for virtual desktop mode. Normal fullscreen mode works fine as long as your xorg.conf is setup properly, but virtual desktop currently reports 0 for the refresh rate. Unless you're suggesting getting a list of resolutions and refresh rates from XRandR? From joris_huizer at yahoo.com Fri Feb 23 04:51:08 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Fri Feb 23 04:51:42 2007 Subject: a big fan (now with bad news) In-Reply-To: Message-ID: <790136.38866.qm@web52704.mail.yahoo.com> --- Jeffrey Sabarese wrote: > > I tried [ yum remove wine ], and then [yum install > wine] which went > without a hitch, but there's no change in my Primary > User (the broken > one) > HOWEVER, WinE continues to run perfectly under other > user accounts, and ROOT. > The wine configuration is in ~/.wine Remove/rename it for a fresh start. Wine will automatically recreate the ~/.wine directory with required contents for normal functionality (but then you need to do installation of every program again) ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From damjan.jov at gmail.com Fri Feb 23 05:31:23 2007 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Fri Feb 23 05:50:39 2007 Subject: How complete will Wine ever be for older apps? In-Reply-To: <890256.77836.qm@web39702.mail.mud.yahoo.com> References: <890256.77836.qm@web39702.mail.mud.yahoo.com> Message-ID: <9e89675b0702230331u6678361bm512bb6331793024b@mail.gmail.com> On 2/22/07, Juan Lang wrote: > > I'm just trying to build up a picture in my head of whether there > > will come a day when Wine users can pick an app designed for a > > previous generation of Windows and expect it to work flawlessly > > (ignoring things that try to manipulate the hardware directly, I > > suppose)? Or will there always be incompatibilities? > > There will (likely) always be incompatibilities. Wine development has > always been driven by app compatibility - someone picks an app and tries > to run it, and tries to fix problems they come across. We don't aim for > feature completeness - Windows is far, far too big to replicate with the > resources we have. So, some apps (the ones developers have worked on, and > likely others) will work quite well, while others (those that haven't been > worked on) may not work as well. Many older apps do work well on wine. In fact, older apps usually work better than the newer ones. We don't need to replicate all of Windows for apps to work properly - just enough. Only a relatively small amount of functionality is required - look at NTDLL, only a tiny fraction of its 1000 or so functions are implemented at the moment, as few are needed. Look at what Microsoft did for Windows Vista: a year or so ago, the application compatibility was only 40% or so (there was a joke that wine runs more apps than Vista :-), and in that year, it's been improved so much that most apps work. The same can be done, and is being done, for wine. > --Juan Damjan From gslink at one.net Fri Feb 23 08:00:45 2007 From: gslink at one.net (gslink) Date: Fri Feb 23 07:59:09 2007 Subject: Sound problems with Alice Message-ID: <45DEF38D.5060504@one.net> In the past I have always used the demo version of the game Alice to test Wine. Recently I loaded a Wine installation and found the game had no sound. After considerable testing it appears that about a year ago a change was made in Wine that killed the sound. Has anyone else had this problem and does it affect anything else? On my loads most other things seem to have sound. From stefandoesinger at gmx.at Fri Feb 23 08:14:40 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Fri Feb 23 08:15:17 2007 Subject: 0.9.31 not suitable for gaming In-Reply-To: <200702221646.15635.stefan@codeweavers.com> References: <20070220053731.GA28646@tangens.sinus.cz> <200702221646.15635.stefan@codeweavers.com> Message-ID: <200702231514.48745.stefandoesinger@gmx.at> Am Donnerstag 22 Februar 2007 16:46 schrieb Stefan D?singer: > That said, this is a Direct3D7 application, where the window setup is done > BEFORE creating the Direct3D device(which calls Init3D in wined3d). So I > gather that SetupFullscreenWindow should not be called during Init3D in the > d3d7 case because the window and fullscreen setting are not changed. > Setting window parameters there may cause signals to be sent to the > application that cause crashes in the app. So I think the question is why > SetupFullscreenWindow is called at all. I have to correct myself, Init3D is not called when the application creates the Direct3DDevice7, it is called when a primary surface with 3D capatiblities is created(or any caps when the opengl ddraw renderer is selected). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/3ef6f1a1/attachment.pgp From stefandoesinger at gmx.at Fri Feb 23 08:17:12 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Fri Feb 23 08:18:32 2007 Subject: Progress in implementation of Direct3D In-Reply-To: <45DB5AB9.8020704@czela.net> References: <45DB5AB9.8020704@czela.net> Message-ID: <200702231517.16330.stefandoesinger@gmx.at> > http://headline.czela.net/Mirek/wine/ > > or via IP: http://62.240.181.87/Mirek/wine/ Hey, cool screenshots :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/2120ab71/attachment.pgp From us at edmeades.me.uk Fri Feb 23 10:06:10 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Fri Feb 23 10:06:57 2007 Subject: unicoding xcopy - question on wcschr Message-ID: <003701c75764$941022a0$1001a8c0@JasonsPC> Hi, Trying to convert my xcopy to Unicode proved simple on windows, but when putting into wine has proved more interesting. Most of the wide string calls are like lstrcmpW and they all work fine, but I really need the Unicode equivalent to strchr and strrchr. As far as I can tell my only option is wcschr. If I build as-is, I get errors saying wcschr is implicitly defined but the link etc is all ok (from a url http://fgouget.free.fr/wine/PrgApps/Chap7.shtml#filerev it implies this is because I am using the GNU C headers, and they don't define it in string.h). Grepping the source, I can only find a hit inside the msvcrt/string.h or wchar.h. If I add to the makefile EXTRAINCL = -I$(TOPSRCDIR)/include/msvcrt, to ensure I pick up the wine headers, I now get warnings like: ./../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function 'iswalnum' How do I #include / link a program using this function? It all just worked under windows :-) Jason From stefandoesinger at gmx.at Fri Feb 23 10:08:23 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Fri Feb 23 10:08:58 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <45DB82A5.2030103@czela.net> References: <200702202246.32004.stefan@codeweavers.com> <45DB82A5.2030103@czela.net> Message-ID: <200702231708.23457.stefandoesinger@gmx.at> Am Mittwoch 21 Februar 2007 00:22 schrieb Mirek: > Some games are still broken with latest 13 patches from your tree. > Oblivion still hangs while loading game and Flatout 2 crashed after 2 > seconds with this output: Can you try to add a return; at the beginning of CreateIndexBufferVBO() in dlls/wined3d/device.c, before the ENTER_GL()? If that does not fix the regressions then some different patches added other breakage. From us at edmeades.me.uk Fri Feb 23 10:33:02 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Fri Feb 23 10:33:33 2007 Subject: unicoding xcopy - question on wcschr Message-ID: <003801c75768$51d5cd50$1001a8c0@JasonsPC> For reference: 'obviously'... adding this line to the makefile solves it MODCFLAGS = -fno-builtin (Copied from msvcrt\tests) Jason From thunder.m at czela.net Fri Feb 23 14:20:55 2007 From: thunder.m at czela.net (Mirek) Date: Fri Feb 23 14:21:23 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <200702231708.23457.stefandoesinger@gmx.at> References: <200702202246.32004.stefan@codeweavers.com> <45DB82A5.2030103@czela.net> <200702231708.23457.stefandoesinger@gmx.at> Message-ID: <45DF4CA7.7020800@czela.net> Stefan D?singer napsal(a): > Am Mittwoch 21 Februar 2007 00:22 schrieb Mirek: >> Some games are still broken with latest 13 patches from your tree. >> Oblivion still hangs while loading game and Flatout 2 crashed after 2 >> seconds with this output: > Can you try to add a return; at the beginning of CreateIndexBufferVBO() in > dlls/wined3d/device.c, before the ENTER_GL()? If that does not fix the > regressions then some different patches added other breakage. > Hi, regression in Flatout 2 is bigger i should do regression testing and find patch which broke start of game, this doesn't fix it, but Oblivion with this hack works without problems (23.02.2007 CVS). Mirek From truiken at gmail.com Fri Feb 23 14:29:28 2007 From: truiken at gmail.com (James Hawkins) Date: Fri Feb 23 14:29:45 2007 Subject: msi: Free the data for type msidbCustomActionTypeContinue custom actions after DllThread executes In-Reply-To: <22821af30702230208m3aedcebarbb1f21b7b166835f@mail.gmail.com> References: <22821af30702230208m3aedcebarbb1f21b7b166835f@mail.gmail.com> Message-ID: <22821af30702231229m1e257bfq3bfcf8e4596b2538@mail.gmail.com> On 2/23/07, James Hawkins wrote: > Hi, > > This fixes bug 7461. http://bugs.winehq.org/show_bug.cgi?id=7461 > > Changelog: > * Free the data for type msidbCustomActionTypeContinue custom actions > after DllThread executes. > > dlls/msi/custom.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > Please ignore this patch. It's not exactly correct. -- James Hawkins From stefan at codeweavers.com Fri Feb 23 14:32:58 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Fri Feb 23 14:34:03 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <45DF4CA7.7020800@czela.net> References: <200702202246.32004.stefan@codeweavers.com> <200702231708.23457.stefandoesinger@gmx.at> <45DF4CA7.7020800@czela.net> Message-ID: <200702232133.03743.stefan@codeweavers.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/1d2075d6/attachment.pgp From thunder.m at czela.net Fri Feb 23 14:44:49 2007 From: thunder.m at czela.net (Mirek) Date: Fri Feb 23 14:45:00 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <200702232133.03743.stefan@codeweavers.com> References: <200702202246.32004.stefan@codeweavers.com> <200702231708.23457.stefandoesinger@gmx.at> <45DF4CA7.7020800@czela.net> <200702232133.03743.stefan@codeweavers.com> Message-ID: <45DF5241.5000708@czela.net> Thanks! This patch fixed Oblivion and even Flatout 2! Mirek Stefan D?singer napsal(a): > Am Freitag 23 Februar 2007 21:20 schrieb Mirek: >> Stefan D?singer napsal(a): >>> Am Mittwoch 21 Februar 2007 00:22 schrieb Mirek: >>>> Some games are still broken with latest 13 patches from your tree. >>>> Oblivion still hangs while loading game and Flatout 2 crashed after 2 >>>> seconds with this output: >>> Can you try to add a return; at the beginning of CreateIndexBufferVBO() >>> in dlls/wined3d/device.c, before the ENTER_GL()? If that does not fix the >>> regressions then some different patches added other breakage. >> Hi, regression in Flatout 2 is bigger i should do regression testing and >> find patch which broke start of game, this doesn't fix it, but Oblivion >> with this hack works without problems (23.02.2007 CVS). >> >> Mirek > Can you test the attached patch with oblivion? > > > > ------------------------------------------------------------------------ > > From faa5d7a0b710ded8f49db6337eb880cc4cd05e8b Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Fri, 23 Feb 2007 17:16:56 +0100 > Subject: [PATCH] WineD3D: Index buffer creation adjustments > > Index buffer creation changes the bound gl buffer, thus the state has to > be dirtified, simmilar to locking > > In an error case the function returned without calling LEAVE_GL() > --- > dlls/wined3d/device.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index b1e9c2d..500a857 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -447,6 +447,11 @@ static void CreateIndexBufferVBO(IWineD3DDeviceImpl *This, IWineD3DIndexBufferIm > GLenum error, glUsage; > TRACE("Creating VBO for Index Buffer %p\n", object); > > + /* The following code will modify the ELEMENT_ARRAY_BUFFER binding, make sure it is > + * restored on the next draw > + */ > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > + > ENTER_GL(); > while(glGetError()); > > @@ -454,8 +459,7 @@ static void CreateIndexBufferVBO(IWineD3DDeviceImpl *This, IWineD3DIndexBufferIm > error = glGetError(); > if(error != GL_NO_ERROR || object->vbo == 0) { > ERR("Creating a vbo failed, continueing without vbo for this buffer\n"); > - object->vbo = 0; > - return; > + goto out; > } > > GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, object->vbo)); From stefan at codeweavers.com Fri Feb 23 15:40:13 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Fri Feb 23 15:40:49 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <45DF5241.5000708@czela.net> References: <200702202246.32004.stefan@codeweavers.com> <200702232133.03743.stefan@codeweavers.com> <45DF5241.5000708@czela.net> Message-ID: <200702232240.16202.stefan@codeweavers.com> Am Freitag 23 Februar 2007 21:44 schrieb Mirek: > Thanks! This patch fixed Oblivion and even Flatout 2! Cool. I wonder why disabling index buffer vbos entirely didn't fix flatout 2 :-O I sense that there will be some more regressions on cards that do not support vbos. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/d9a9ebf7/attachment.pgp From ben at atomnet.co.uk Fri Feb 23 16:38:21 2007 From: ben at atomnet.co.uk (Ben Hodgetts (Enverex)) Date: Fri Feb 23 16:38:47 2007 Subject: Sound problems with Alice In-Reply-To: <45DEF38D.5060504@one.net> References: <45DEF38D.5060504@one.net> Message-ID: <45DF6CDD.5000404@atomnet.co.uk> Please use bugs.winehq.org for things like this, not the mailing list. It's a bug and should be reported so it can be fixed, it will just get lost or ignored on the mailing list. Ex. gslink wrote: > In the past I have always used the demo version of the game Alice to > test Wine. Recently I loaded a Wine installation and found the game > had no sound. After considerable testing it appears that about a year > ago a change was made in Wine that killed the sound. Has anyone else > had this problem and does it affect anything else? On my loads most > other things seem to have sound. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/b5be4fb8/signature.pgp From truiken at gmail.com Fri Feb 23 17:24:23 2007 From: truiken at gmail.com (James Hawkins) Date: Fri Feb 23 17:24:30 2007 Subject: [1/2] comctl32: add WM_PAINT message sequence tests In-Reply-To: <45DF7013.8080503@holycrap.org> References: <45DF7013.8080503@holycrap.org> Message-ID: <22821af30702231524s1ed899aaw743700744085f6ef@mail.gmail.com> On 2/23/07, Felix Nawothnig wrote: > Passed on XP SP2. > --- > dlls/comctl32/tests/listview.c | 209 > +++++++++++++++++++++++++++++++++++++++- > dlls/comctl32/tests/msg.c | 3 + > dlls/comctl32/tests/msg.h | 3 +- > 3 files changed, 211 insertions(+), 4 deletions(-) > This is wrong: +static LRESULT WINAPI header_subclass_proc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) +{ + struct subclass_info *info = (struct subclass_info *)GetWindowLongA(hwnd, GWL_USERDATA); + static long defwndproc_counter = 0; + LRESULT ret; + struct message msg; + + trace("header: %p, %04x, %08x, %08lx\n", hwnd, message, wParam, lParam); + + msg.message = message; + msg.flags = sent|wparam|lparam|hdr; + if (defwndproc_counter) msg.flags |= defwinproc; + msg.wParam = wParam; + msg.lParam = lParam; + add_message(sequences, LISTVIEW_SEQ_INDEX, &msg); + + defwndproc_counter++; + ret = CallWindowProcA(info->oldproc, hwnd, message, wParam, lParam); + defwndproc_counter--; + return ret; +} If you're subclassing the header control and checking messages from the header control, then you need to add another message sequence, HEADER_SEQ_INDEX. --- a/dlls/comctl32/tests/msg.c +++ b/dlls/comctl32/tests/msg.c @@ -158,6 +158,9 @@ void ok_sequence_(struct msg_sequence ** ok_(file, line) ((expected->flags & winevent_hook) == (actual->flags & winevent_hook), "%s: the msg 0x%04x should have been sent by a winevent hook\n", context, expected->message); + ok_(file, line) ((expected->flags & hdr) == (actual->flags & hdr), + "%s: the msg 0x%04x should have been sent by the header control\n", + context, expected->message); expected++; actual++; } msg.c is the message sequence testing code abstracted...keyword is abstraction. Nothing in msg.c should know anything about specific types of controls. -- James Hawkins From flexo at holycrap.org Fri Feb 23 17:40:11 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Fri Feb 23 17:32:25 2007 Subject: Message spy log viewer Message-ID: <45DF7B5B.2010300@holycrap.org> Hi. I just figured I never told anyone (did I?) - a while ago I wrote a Ruby/GTK2 tool to parse +message logs (along with other channels mixed in) and display them in a treeview - makes debugging message related problems much easier. I suppose others wrote similar scripts for their own use - but maybe someone will find it useful nevertheless: http://users.holycrap.org/flexo/spy.rb Use like: $ WINEDEBUG="+message" wine foo.exe 2>log $ ruby spy.rb log Felix From flexo at holycrap.org Fri Feb 23 17:43:35 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Fri Feb 23 17:35:47 2007 Subject: [1/2] comctl32: add WM_PAINT message sequence tests In-Reply-To: <22821af30702231524s1ed899aaw743700744085f6ef@mail.gmail.com> References: <45DF7013.8080503@holycrap.org> <22821af30702231524s1ed899aaw743700744085f6ef@mail.gmail.com> Message-ID: <45DF7C27.7010305@holycrap.org> James Hawkins wrote: > If you're subclassing the header control and checking messages from > the header control, then you need to add another message sequence, > HEADER_SEQ_INDEX. Problem is I need to test whether the header msgs are sent between the WM_PAINT and WM_NOTIFY of the listview - right now the WM_PAINT/WM_NCPAINT/WM_ERASEBKGND _are_ sent - just not in between but after WM_PAINT processing (which causes the flickering). I agree that the "hdr" flag is kinda hackish, any idea how to properly abstract away what I'm trying to do? Felix From wine.dev at web.de Fri Feb 23 18:00:06 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Fri Feb 23 18:00:52 2007 Subject: xcopy try 2 In-Reply-To: <003901c75769$f297b680$1001a8c0@JasonsPC> References: <003901c75769$f297b680$1001a8c0@JasonsPC> Message-ID: <1172275206.6917.78.camel@p4> On Fr, 2007-02-23 at 16:44 +0000, Ann & Jason Edmeades wrote: Looks nice, but a view over the code result in some more comments: --- a/configure.ac +++ b/configure.ac Not needed, when sending the Patch (and that line causes already an offset, when patching wine) "tools/make_makefiles" takes care of all required changes and when Alexandre commit your Patch, the changes from make_makefiles and autoconf are included in the commit. +EXTRADEFS = -DUNICODE There is no need for that define. Remove that line to get a warning for all ANSI-Functions, that missed the "W" +C_SRCS = \ + xcopy.c Spaces are wrong before the filename. You must use TAB in makefiles +/* Prototypes */ This can be avoided completly, when you rearange your functions (so main() is then the last function in the file) + printf("Invalid number of parameters - Use xcopy /? for help\n"); The text should be read from the resources, so it can be localized . You should convert the UNICODE-Message with WideCharToMultiByte. When the output-handle is the console, printing UNICODE-messages avoid converting the message twice (xcopy and kernel32) > + if (*argvW[0] != '/') { > + if (suppliedsource[0] == 0x00) { > + lstrcpyW(suppliedsource, *argvW); > + } else { > + lstrcpyW(supplieddestination, *argvW); > + } This is wrong. tested with: "xcopy file1 file2 file3" Your code would copy file1 to file3, while w2k fails with "Unzul?ssige Parameteranzahl" (Invalid number of parameters) I suggest to initialize supplieddestination as empty string and copy the arg to supplieddestination only, when it is emtpy. When supplieddestination was not empty, quit with the error. You need to fill supplieddestination with the default "." before /* Trace out the supplied information */, when it is still empty at that location. + if (flags & OPT_SIMULATE) { + printf("%d file(s) would be copied\n", filesCopied); + } else { + printf("%d file(s) copied\n", filesCopied); + } As Above: Format-Pattern from the resource and WriteFile() + if (GetFullPathName(suppliedsource, MAX_PATH, "W" missing: => GetFullPathNameW (More Functions in various locations and WIN32_FIND_DATA => WIN32_FIND_DATAW) I did not test the code very much, but I think, you did. (ToDo-Reminder: "xcopy file1 name_not_found" => is "name_not_found" a file or a directory) Thanks for your work. It's pretty good as start! -- By by ... Detlef From mk144210 at bcm.tmc.edu Fri Feb 23 19:20:01 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Fri Feb 23 19:20:50 2007 Subject: Update on msi JScript/VBScript support functions Message-ID: <1172280002.3568.5.camel@misha-laptop> Hi, just wanted to update everybody on my work with this, sorry I have not been good at replying to personal emails lately. I am not currently attaching any code but will clean things up and then submit my patches to wine-patches soon. So, the good news is that, as a proof of concept, I have gotten the Vector NTI installer to work successfully, which requires the JScript functionality. Specifically, this tests custom actions 5/6 and 37/38, there are two other sets that would be nice to test (but it is all the same script handler so it should work). Also, to make this work, I had to implement the OLE automation interface. Now, I have not implemented the entire interface yet, but I have made the entire .tlb file for this and made a framework which makes implementing everything fairly straightforward (and everything is a wrapper around the existing MSI database functions, so there is no actual functionality, it is just adding new cases to the switch statements that call the MSI database functions appropriately). Basically, because of the MSI design where everything that is an object has an MSIHANDLE, I have made one Automation Object that each specific object "inherits" from by implementing its invoke function (minus basic parameter checking, etc. which is all done by the automation object) and passing it to create_automation_object with its CLSID. It is pretty easy to implement more functions, and I will try to keep on adding more, probably as patches that I will periodically send to wine-patches. Anyhow, look for my first patches in the next couple of days. Misha From mk144210 at bcm.tmc.edu Fri Feb 23 19:22:05 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Fri Feb 23 19:22:46 2007 Subject: Update on msi JScript/VBScript support functions In-Reply-To: <1172280002.3568.5.camel@misha-laptop> References: <1172280002.3568.5.camel@misha-laptop> Message-ID: <1172280125.3568.8.camel@misha-laptop> On Fri, 2007-02-23 at 19:20 -0600, Misha Koshelev wrote: > Hi, just wanted to update everybody on my work with this, sorry I have > not been good at replying to personal emails lately. I am not currently > attaching any code but will clean things up and then submit my patches > to wine-patches soon. > > So, the good news is that, as a proof of concept, I have gotten the > Vector NTI installer to work successfully, which requires the JScript > functionality. Specifically, this tests custom actions 5/6 and 37/38, > there are two other sets that would be nice to test (but it is all the > same script handler so it should work). > > Also, to make this work, I had to implement the OLE automation > interface. Now, I have not implemented the entire interface yet, but I > have made the entire .tlb file for this and made a framework which makes > implementing everything fairly straightforward (and everything is a > wrapper around the existing MSI database functions, so there is no > actual functionality, it is just adding new cases to the switch > statements that call the MSI database functions appropriately). > > Basically, because of the MSI design where everything that is an object > has an MSIHANDLE, I have made one Automation Object that each specific > object "inherits" from by implementing its invoke function (minus basic > parameter checking, etc. which is all done by the automation object) and > passing it to create_automation_object with its CLSID. It is pretty easy > to implement more functions, and I will try to keep on adding more, > probably as patches that I will periodically send to wine-patches. > > Anyhow, look for my first patches in the next couple of days. > > Misha Almost forgot, one big caveat is right now for some reason Microsoft Script 5.6 does not install properly on wine either (bummer), it looks for some Scriptable.Dictionary (I am writing this from memory) object, doesn't find it, and then doesn't want to run the script, so currently one needs to install IE6 first to get Microsoft Script to work properly. But in any case IE6 < IE6+native MSI which was required before, and I think tracking down the Microsoft Script installation problem should not be too bad. Misha From truiken at gmail.com Fri Feb 23 18:48:39 2007 From: truiken at gmail.com (James Hawkins) Date: Fri Feb 23 19:35:59 2007 Subject: [1/2] comctl32: add WM_PAINT message sequence tests In-Reply-To: <45DF7C27.7010305@holycrap.org> References: <45DF7013.8080503@holycrap.org> <22821af30702231524s1ed899aaw743700744085f6ef@mail.gmail.com> <45DF7C27.7010305@holycrap.org> Message-ID: <22821af30702231648n3ae3ad0ej978a71898d7338c4@mail.gmail.com> On 2/23/07, Felix Nawothnig wrote: > James Hawkins wrote: > > If you're subclassing the header control and checking messages from > > the header control, then you need to add another message sequence, > > HEADER_SEQ_INDEX. > > Problem is I need to test whether the header msgs are sent between the > WM_PAINT and WM_NOTIFY of the listview - right now the > WM_PAINT/WM_NCPAINT/WM_ERASEBKGND _are_ sent - just not in between but > after WM_PAINT processing (which causes the flickering). > > I agree that the "hdr" flag is kinda hackish, any idea how to properly > abstract away what I'm trying to do? > Patch is attached. If you send it in to wine-patches, you need to put both our names in the Changelog. -- James Hawkins -------------- next part -------------- A non-text attachment was scrubbed... Name: listview.diff Type: text/x-patch Size: 9499 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070223/fa7e77df/listview.bin From mk144210 at bcm.tmc.edu Fri Feb 23 23:21:41 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Fri Feb 23 23:22:19 2007 Subject: Update on msi JScript/VBScript support functions In-Reply-To: <1172283327.3568.16.camel@misha-laptop> References: <1172280002.3568.5.camel@misha-laptop> <1172280125.3568.8.camel@misha-laptop> <1172283327.3568.16.camel@misha-laptop> Message-ID: <1172294502.3568.19.camel@misha-laptop> Ok nevermind about the IE6 requirement. Windows Script 5.6 needs mfc42.dll to install properly, that is all that is required with my patch for Vector NTI then: 1. Copy mfc42.dll to .wine/drive_c/windows/system32 2. Run the Vector NTI installer Yay, down from like 20 steps :) Misha From wine-devel at kievinfo.com Sat Feb 24 00:17:03 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 24 00:25:00 2007 Subject: winex11.drv: Catch and report screen resolution change errors. Message-ID: <45DFD85F.1060601@kievinfo.com> > winex11.drv: Catch and report screen resolution change errors. This patch brakes Half-life based games in virtual desktop. Vitaliy. From david at l8s.co.uk Sat Feb 24 02:08:23 2007 From: david at l8s.co.uk (David Laight) Date: Sat Feb 24 02:09:26 2007 Subject: xcopy try 2 In-Reply-To: <1172275206.6917.78.camel@p4> References: <003901c75769$f297b680$1001a8c0@JasonsPC> <1172275206.6917.78.camel@p4> Message-ID: <20070224080823.GI23450@snowdrop.l8s.co.uk> On Sat, Feb 24, 2007 at 01:00:06AM +0100, Detlef Riekenberg wrote: > > +C_SRCS = \ > + xcopy.c > > Spaces are wrong before the filename. You must use TAB in makefiles That is a contiuation line, IIRC the whitespace at the start of the continued line should be discarded (and can be space/tab anyway). David -- David Laight: david@l8s.co.uk From thunder.m at czela.net Sat Feb 24 02:20:49 2007 From: thunder.m at czela.net (Mirek) Date: Sat Feb 24 02:20:52 2007 Subject: [6/13]D3D: Index buffer fixes In-Reply-To: <200702232240.16202.stefan@codeweavers.com> References: <200702202246.32004.stefan@codeweavers.com> <200702232133.03743.stefan@codeweavers.com> <45DF5241.5000708@czela.net> <200702232240.16202.stefan@codeweavers.com> Message-ID: <45DFF561.7030705@czela.net> Stefan D?singer napsal(a): > Am Freitag 23 Februar 2007 21:44 schrieb Mirek: >> Thanks! This patch fixed Oblivion and even Flatout 2! > Cool. > > I wonder why disabling index buffer vbos entirely didn't fix flatout 2 :-O > I sense that there will be some more regressions on cards that do not support > vbos. Yes, it is realy strange, I tested it twice with same results. But now i tried it again, I first run 3D setup for Flatout 2, and after that game starts without any problems only with return; added in CreateIndexBufferVBO(). So it looks like it should work on cards without fbo. Mirek From stefan at codeweavers.com Sat Feb 24 05:10:52 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sat Feb 24 05:11:25 2007 Subject: winex11.drv: Catch and report screen resolution change errors. In-Reply-To: <45DFD85F.1060601@kievinfo.com> References: <45DFD85F.1060601@kievinfo.com> Message-ID: <200702241210.53772.stefan@codeweavers.com> Am Samstag 24 Februar 2007 07:17 schrieb Vitaliy Margolen: > > winex11.drv: Catch and report screen resolution change errors. > > This patch brakes Half-life based games in virtual desktop. Yes, I saw the same with moto racer 2 yesterday. I will send a patch to re-enable color depth faking for virtual desktops. From hverbeet at gmail.com Sat Feb 24 05:44:19 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Sat Feb 24 05:44:21 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. In-Reply-To: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> References: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> Message-ID: On 24/02/07, Saulius Krasuckas wrote: > This long line breaks automated rebasing of one of testing branches on > (namely ntoskrnl) on my box every time a new dll or program is added. > That's because I need to merge conflict for this line by my hand. > > And I am not sure what stops us from keeping "ac_config_files" list > multiline, so merging in future could be automatical. > > --- > configure | 326 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 325 insertions(+), 1 deletions(-) > configure is a generated file. From marcus at jet.franken.de Sat Feb 24 05:42:32 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Sat Feb 24 05:45:44 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. In-Reply-To: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> References: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> Message-ID: <20070224114232.GA19906@jet.franken.de> On Sat, Feb 24, 2007 at 02:15:29PM +0200, Saulius Krasuckas wrote: > This long line breaks automated rebasing of one of testing branches on > (namely ntoskrnl) on my box every time a new dll or program is added. > That's because I need to merge conflict for this line by my hand. > > And I am not sure what stops us from keeping "ac_config_files" list > multiline, so merging in future could be automatical. The problem is that configure is automatically generated from configure.ac. Ciao, Marcus From saulius2 at ar.fi.lt Sat Feb 24 06:31:25 2007 From: saulius2 at ar.fi.lt (Saulius Krasuckas) Date: Sat Feb 24 05:52:42 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. In-Reply-To: <20070224114232.GA19906@jet.franken.de> References: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> <20070224114232.GA19906@jet.franken.de> Message-ID: * On Sat, 24 Feb 2007, Marcus Meissner wrote: > * On Sat, Feb 24, 2007 at 02:15:29PM +0200, Saulius Krasuckas wrote: > > And I am not sure what stops us from keeping "ac_config_files" list > > multiline, so merging in future could be automatical. > > The problem is that configure is automatically generated from > configure.ac. Well, fair enough. Can its generator be reconfigured then? :) From saulius2 at ar.fi.lt Sat Feb 24 06:37:58 2007 From: saulius2 at ar.fi.lt (Saulius Krasuckas) Date: Sat Feb 24 05:59:24 2007 Subject: ANN: Wiki upgrade In-Reply-To: <3035.207.245.37.34.1171582355.squirrel@lattica.com> References: <3035.207.245.37.34.1171582355.squirrel@lattica.com> Message-ID: * On Thu, 15 Feb 2007, Dimi Paun wrote: > We finished upgrading the wiki to MoinMoin 1.5.7. > Please let me know if you encounter any problems. I've tried some searching on it, and it reports: Title Search: "ntoskrnl" 0 results out of about 1472 pages. (0.06 seconds) I guess it's searching only through titles of the pages. Could it be made to check all content of a page also, please? Thanks. From marcus at jet.franken.de Sat Feb 24 06:12:25 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Sat Feb 24 06:15:27 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. In-Reply-To: References: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> <20070224114232.GA19906@jet.franken.de> Message-ID: <20070224121225.GB19906@jet.franken.de> On Sat, Feb 24, 2007 at 02:31:25PM +0200, Saulius Krasuckas wrote: > * On Sat, 24 Feb 2007, Marcus Meissner wrote: > > * On Sat, Feb 24, 2007 at 02:15:29PM +0200, Saulius Krasuckas wrote: > > > And I am not sure what stops us from keeping "ac_config_files" list > > > multiline, so merging in future could be automatical. > > > > The problem is that configure is automatically generated from > > configure.ac. > > Well, fair enough. Can its generator be reconfigured then? :) After some experimenting, yes. We can write multiple AC_CONFIG_FILES and they will all get their own line in configure. Ciao, Marcus From hverbeet at gmail.com Sat Feb 24 06:27:23 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Sat Feb 24 06:27:24 2007 Subject: include/d3d9types.h: Remove Size from D3DVOLUME_DESC In-Reply-To: <45E02993.10303@email.si> References: <45E02993.10303@email.si> Message-ID: On 24/02/07, Rok Mandeljc wrote: > According to both MSDN and wine's d3d9 sources, Size was removed from > D3DVOLUME_DESC in DX9. This patch seems to have fixed crash in d3dx9_30.dll at NeverWinter Nights 2 startup (I assume it was due to wrong offset of Width, Height and Depth due to Size's presence). > > Regards, > Rok > Nice find, this fixes some stack corruption in a couple of applications. From flexo at holycrap.org Sat Feb 24 07:38:23 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sat Feb 24 07:30:28 2007 Subject: test.winehq.com status In-Reply-To: <45BF6D97.3060908@holycrap.org> References: <45BF6D97.3060908@holycrap.org> Message-ID: <45E03FCF.5070406@holycrap.org> Hi. A new crossbuild appeared today but the site shows all tests failing. See http://test.winehq.org/data/200702241000/ Felix From paul.vriens.wine at gmail.com Sat Feb 24 07:35:39 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Sat Feb 24 07:35:43 2007 Subject: New wintest executable is there (but there are some issues due to introduction of skip) Message-ID: <45E03F2B.5020602@gmail.com> Hi, as of today there's a new winetest executable available at the usual place: http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ There is however an issue with the generated reports. It looks like this is introduced when the 'skip' thingy was added to the test infrastructure. I'm currently going through the perl scripts but have no fix yet. Most likely we have to patch the 'dissect' script at line 158: } elsif (s/^($test: (\d+) tests executed, (\d+) marked as todo, (\d+) failures?\.)\r?$/$1/) { The previous lines were like: advapi32:crypt start dlls/advapi32/tests/crypt.c 1.31 crypt: 69 tests executed, 0 marked as todo, 0 failures. advapi32:crypt done (0) now it's: advapi32:crypt start dlls/advapi32/tests/crypt.c 1.31 crypt: 69 tests executed (0 marked as todo, 0 failures), 0 skipped. advapi32:crypt done (0) Anybody? Cheers, Paul. From paul.vriens.wine at gmail.com Sat Feb 24 08:11:47 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Sat Feb 24 08:11:46 2007 Subject: New wintest executable is there (but there are some issues due to introduction of skip) In-Reply-To: <45E03F2B.5020602@gmail.com> References: <45E03F2B.5020602@gmail.com> Message-ID: <45E047A3.30000@gmail.com> Paul Vriens wrote: > Hi, > > as of today there's a new winetest executable available at the usual place: > > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ > > There is however an issue with the generated reports. It looks like this > is introduced when the 'skip' thingy was added to the test > infrastructure. I'm currently going through the perl scripts but have no > fix yet. Most likely we have to patch the 'dissect' script at line 158: > > } elsif (s/^($test: (\d+) tests executed, (\d+) marked as todo, > (\d+) failures?\.)\r?$/$1/) { > > The previous lines were like: > > advapi32:crypt start dlls/advapi32/tests/crypt.c 1.31 > crypt: 69 tests executed, 0 marked as todo, 0 failures. > advapi32:crypt done (0) > > now it's: > > advapi32:crypt start dlls/advapi32/tests/crypt.c 1.31 > crypt: 69 tests executed (0 marked as todo, 0 failures), 0 skipped. > advapi32:crypt done (0) > > Anybody? > > Cheers, > > Paul. > > Hi, the attached patch should fix the 'dissect' script and retains backwards compatibility (if needed). It doesn't make use of the skip-count as that will mean fixing up a lot more. If somebody could have a look at the attached patch? Cheers, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: dissect.diff Type: text/x-patch Size: 835 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070224/aa56dec5/dissect.bin From wine-devel at kievinfo.com Sat Feb 24 09:24:32 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sat Feb 24 09:25:02 2007 Subject: kernel32: Set object security on process object in CreateProcess. In-Reply-To: <45DDBB88.7070706@codeweavers.com> References: <45DD107C.3060206@kievinfo.com> <45DDBB88.7070706@codeweavers.com> Message-ID: <45E058B0.3000206@kievinfo.com> Robert Shearman wrote: > Vitaliy Margolen wrote: >> + >> + /* set process security */ >> + if (ret && psa && psa->lpSecurityDescriptor) >> + { >> + NTSTATUS status; >> + >> + status = NtSetSecurityObject( info->hProcess, >> DACL_SECURITY_INFORMATION, >> + psa->lpSecurityDescriptor ); >> + ret = status == STATUS_SUCCESS; >> + if (!ret) SetLastError( RtlNtStatusToDosError( status ) ); >> + } >> + >> > > It would be better to pass the security descriptor (or just the DACL if > you would prefer) in the new_process call. You should be able to change > the security structure validation functions to return the number of > bytes used. Therefore, you should be able to put the security data > before the other variable data in the new_process call. I've discussed this with Alexandre on IRC and we agreed on using NtSetSecurityObject instead. The problem is we need to send all parts of the SD (as it's need to be validated) and one more SD (for thread). The total number of data would be more then maximum of 5. > Also, I think several tests in advapi32 should succeed after this patch > is applied so you will need to patch that too. Yes thank you. I totally forgot about that. Vitaliy. From stefan at codeweavers.com Sat Feb 24 10:04:13 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Sat Feb 24 10:04:54 2007 Subject: include/d3d9types.h: Remove Size from D3DVOLUME_DESC In-Reply-To: References: <45E02993.10303@email.si> Message-ID: <200702241704.18110.stefan@codeweavers.com> Am Samstag 24 Februar 2007 13:27 schrieb H. Verbeet: > On 24/02/07, Rok Mandeljc wrote: > > According to both MSDN and wine's d3d9 sources, Size was removed from > > D3DVOLUME_DESC in DX9. This patch seems to have fixed crash in > > d3dx9_30.dll at NeverWinter Nights 2 startup (I assume it was due to > > wrong offset of Width, Height and Depth due to Size's presence). > > > > Regards, > > Rok > > Nice find, this fixes some stack corruption in a couple of applications. Yeah, we've been hunting some rouge memory corruption since weeks, but we didn't suspect a problem with our headers :-) good catch :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070224/83b700ff/attachment.pgp From flexo at holycrap.org Sat Feb 24 10:27:11 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sat Feb 24 10:19:15 2007 Subject: New wintest executable is there (but there are some issues due to introduction of skip) In-Reply-To: <45E047A3.30000@gmail.com> References: <45E03F2B.5020602@gmail.com> <45E047A3.30000@gmail.com> Message-ID: <45E0675F.80102@holycrap.org> And while we're at it, there seems to be some misconfiguration of the httpd (for quite some time), as the following URL generates an 500 Internal Server Error: http://test.winehq.org/data/200702241000/2003_W2K3-SE-IE7/ntdll:error.txt From der.fabe at gmx.net Sat Feb 24 10:40:48 2007 From: der.fabe at gmx.net (Fabian Bieler) Date: Sat Feb 24 10:36:02 2007 Subject: [PATCH] user32: do not call NULL message callback In-Reply-To: <45E06818.306@holycrap.org> References: <200702241719.18637.der.fabe@gmx.net> <45E06818.306@holycrap.org> Message-ID: <200702241740.48425.der.fabe@gmx.net> On Saturday 24 February 2007 17:30, you wrote: > Fabian Bieler wrote: > > Windows silently ignores NULL pointers supplied to SendMessageCallback as > > callback function. > > A testcase would be nice. > > Felix The only way I know of to test this behavior would be to pass a NULL pointer as callback. Naturally this results in a segfault without this patch. Is this okay for a testcase? From flexo at holycrap.org Sat Feb 24 10:30:16 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sat Feb 24 10:39:57 2007 Subject: [PATCH] user32: do not call NULL message callback In-Reply-To: <200702241719.18637.der.fabe@gmx.net> References: <200702241719.18637.der.fabe@gmx.net> Message-ID: <45E06818.306@holycrap.org> Fabian Bieler wrote: > Windows silently ignores NULL pointers supplied to SendMessageCallback as > callback function. A testcase would be nice. Felix From flexo at holycrap.org Sat Feb 24 11:11:10 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Sat Feb 24 11:03:13 2007 Subject: [PATCH] user32: do not call NULL message callback In-Reply-To: <200702241740.48425.der.fabe@gmx.net> References: <200702241719.18637.der.fabe@gmx.net> <45E06818.306@holycrap.org> <200702241740.48425.der.fabe@gmx.net> Message-ID: <45E071AE.3000705@holycrap.org> Fabian Bieler wrote: > The only way I know of to test this behavior would be to pass a NULL pointer > as callback. Naturally this results in a segfault without this patch. Is this > okay for a testcase? Use if(0) instead of todo_wine then (and let the second patch, which fixes the bug, remove the if(0)). From stefan at codeweavers.com Sat Feb 24 12:31:00 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Sat Feb 24 12:31:47 2007 Subject: dplay: directplay should initialize session Guid patch + conformance tests In-Reply-To: <200702241725.49691.alex.pigna@inventati.org> References: <200702241725.49691.alex.pigna@inventati.org> Message-ID: <200702241931.03852.stefan@codeweavers.com> Am Samstag 24 Februar 2007 17:25 schrieb Alessandro Pignotti: > Hi everyone, > the directx sdk says that directplay has to initialize sesison guid in > SESSIONDESC2 struct that is passed by the application with the Open call. > This patch adresses that issue and includes proper conformance test. > It should be noted that the tests works under windows, but not yet under > wine, because it has not a working directplay service provider > implementation and it's not possible to mix builtin dplayx with native > service provider (i'm working on a patch to tha problem too) Use todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid not initialized"); For tests which are known to fail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070224/a30706a0/attachment.pgp From mk144210 at bcm.tmc.edu Fri Feb 23 20:15:27 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Sat Feb 24 13:21:49 2007 Subject: Update on msi JScript/VBScript support functions In-Reply-To: <1172280125.3568.8.camel@misha-laptop> References: <1172280002.3568.5.camel@misha-laptop> <1172280125.3568.8.camel@misha-laptop> Message-ID: <1172283327.3568.16.camel@misha-laptop> On Fri, 2007-02-23 at 19:22 -0600, Misha Koshelev wrote: > On Fri, 2007-02-23 at 19:20 -0600, Misha Koshelev wrote: > > Hi, just wanted to update everybody on my work with this, sorry I have > > not been good at replying to personal emails lately. I am not currently > > attaching any code but will clean things up and then submit my patches > > to wine-patches soon. > > > > So, the good news is that, as a proof of concept, I have gotten the > > Vector NTI installer to work successfully, which requires the JScript > > functionality. Specifically, this tests custom actions 5/6 and 37/38, > > there are two other sets that would be nice to test (but it is all the > > same script handler so it should work). > > > > Also, to make this work, I had to implement the OLE automation > > interface. Now, I have not implemented the entire interface yet, but I > > have made the entire .tlb file for this and made a framework which makes > > implementing everything fairly straightforward (and everything is a > > wrapper around the existing MSI database functions, so there is no > > actual functionality, it is just adding new cases to the switch > > statements that call the MSI database functions appropriately). > > > > Basically, because of the MSI design where everything that is an object > > has an MSIHANDLE, I have made one Automation Object that each specific > > object "inherits" from by implementing its invoke function (minus basic > > parameter checking, etc. which is all done by the automation object) and > > passing it to create_automation_object with its CLSID. It is pretty easy > > to implement more functions, and I will try to keep on adding more, > > probably as patches that I will periodically send to wine-patches. > > > > Anyhow, look for my first patches in the next couple of days. > > > > Misha > > Almost forgot, one big caveat is right now for some reason Microsoft > Script 5.6 does not install properly on wine either (bummer), it looks > for some Scriptable.Dictionary (I am writing this from memory) object, > doesn't find it, and then doesn't want to run the script, so currently > one needs to install IE6 first to get Microsoft Script to work properly. > But in any case IE6 < IE6+native MSI which was required before, and I > think tracking down the Microsoft Script installation problem should not > be too bad. > > Misha Okay, even though I said no code yet I actually didn't have that much cleaning to do, and here are the patches I am thinking of submitting. I would like to test these with an MSI file that has the other two scripting custom action types (script in an installed file and script in a property, already tested script in an MSI binary and script in the target field of the custom action table) though. Let me know what ppl think. Also, just to comment on the IE6 requirement with the Microsoft Script 5.6, it actually is not just a requirement of my patches to the wine MSI, but is required by native MSI as well, at least to install Vector NTI (native MSI complains about scripting and does not finish installing if I install Microsoft Script from the MS website or with the MS script that it comes bundled with and installed; however ,with IE6 it installs fine, and, as I said previously, there is something about a missing Dictionary entry in the registry in the logs, so I will have to look into it). In any case, the first patch can be applied by itself, but the other two must be applied together. Look at the bottom of automation.c to see how easy it will be to fill in all the other OLE automation functions (easy but a little tedious, mostly because of time checking things on MSDN; also QA is hard to do as all the tests would have to be wine_todo since wine has no native scripting engine) - I think these would be separate patches though. Anyhow, let me stress that these patches fix bug #7357 and possibly other installer bugs that require scripting or allow them to be easily fixed by implementing a few more OLE automation functions (when an unhandled function is called this triggers a FIXME with the function name and CLSID of the object, and as I mentioned they are all wrappers around already implemented functions anyway). Misha -------------- next part -------------- From ace5c7ed5707a03a47bfd4c6387c1c704689a501 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Fri, 23 Feb 2007 20:02:01 -0600 Subject: msi: Expand IDL file to contain all OLE automation interfaces. --- dlls/msi/msiserver.idl | 917 +++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 857 insertions(+), 60 deletions(-) diff --git a/dlls/msi/msiserver.idl b/dlls/msi/msiserver.idl index 9966d90..02def8e 100644 --- a/dlls/msi/msiserver.idl +++ b/dlls/msi/msiserver.idl @@ -1,5 +1,6 @@ /* * Copyright (C) 2007 Mike McCormack + * Misha Koshelev * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -21,9 +22,16 @@ import "wtypes.idl"; import "objidl.idl"; import "oaidl.idl"; -[ uuid(000C1092-0000-0000-C000-000000000046), version(1.0) ] +[ + uuid(000C1092-0000-0000-C000-000000000046), + version(1.0) +] library WindowsInstaller { + /* TLib : */ /* TLib : OLE Automation : {00020430-0000-0000-C000-000000000046} */ + importlib("stdole2.tlb"); + + /* Forward declare all types defined in this typelib */ dispinterface Installer; dispinterface Record; dispinterface Session; @@ -37,87 +45,876 @@ library WindowsInstaller dispinterface Product; dispinterface Patch; - [ uuid(000C1090-0000-0000-C000-000000000046) ] - dispinterface Installer - { - properties: - methods: - } - - [ uuid(000C1093-0000-0000-C000-000000000046) ] - dispinterface Record - { - properties: - methods: - } - - [ uuid(000C1095-0000-0000-C000-000000000046) ] - dispinterface StringList - { + /* All enumerations */ + + typedef + enum { + msiUILevelNoChange = 0, + msiUILevelDefault = 1, + msiUILevelNone = 2, + msiUILevelBasic = 3, + msiUILevelReduced = 4, + msiUILevelFull = 5, + msiUILevelHideCancel = 32, + msiUILevelProgressOnly = 64, + msiUILevelEndDialog = 128, + msiUILevelSourceResOnly = 256 + } MsiUILevel; + + typedef + enum { + msiReadStreamInteger = 0, + msiReadStreamBytes = 1, + msiReadStreamAnsi = 2, + msiReadStreamDirect = 3 + } MsiReadStream; + + typedef + enum { + msiRunModeAdmin = 0, + msiRunModeAdvertise = 1, + msiRunModeMaintenance = 2, + msiRunModeRollbackEnabled = 3, + msiRunModeLogEnabled = 4, + msiRunModeOperations = 5, + msiRunModeRebootAtEnd = 6, + msiRunModeRebootNow = 7, + msiRunModeCabinet = 8, + msiRunModeSourceShortNames = 9, + msiRunModeTargetShortNames = 10, + msiRunModeWindows9x = 12, + msiRunModeZawEnabled = 13, + msiRunModeScheduled = 16, + msiRunModeRollback = 17, + msiRunModeCommit = 18 + } MsiRunMode; + + typedef + enum { + msiDatabaseStateRead = 0, + msiDatabaseStateWrite = 1 + } MsiDatabaseState; + + typedef + enum { + msiViewModifySeek = -1, + msiViewModifyRefresh = 0, + msiViewModifyInsert = 1, + msiViewModifyUpdate = 2, + msiViewModifyAssign = 3, + msiViewModifyReplace = 4, + msiViewModifyMerge = 5, + msiViewModifyDelete = 6, + msiViewModifyInsertTemporary = 7, + msiViewModifyValidate = 8, + msiViewModifyValidateNew = 9, + msiViewModifyValidateField = 10, + msiViewModifyValidateDelete = 11 + } _MsiViewModify; /* Added underscore to avoid conflict with MsiViewModify function in msiquery.h */ + + typedef + enum { + msiColumnInfoNames = 0, + msiColumnInfoTypes = 1 + } MsiColumnInfo; + + typedef + enum { + msiTransformErrorNone = 0, + msiTransformErrorAddExistingRow = 1, + msiTransformErrorDeleteNonExistingRow = 2, + msiTransformErrorAddExistingTable = 4, + msiTransformErrorDeleteNonExistingTable = 8, + msiTransformErrorUpdateNonExistingRow = 16, + msiTransformErrorChangeCodePage = 32, + msiTransformErrorViewTransform = 256 + } MsiTransformError; + + typedef + enum { + msiEvaluateConditionFalse = 0, + msiEvaluateConditionTrue = 1, + msiEvaluateConditionNone = 2, + msiEvaluateConditionError = 3 + } _MsiEvaluateCondition; /* Added underscore to avoid conflict with function name */ + + typedef + enum { + msiTransformValidationNone = 0, + msiTransformValidationLanguage = 1, + msiTransformValidationProduct = 2, + msiTransformValidationPlatform = 4, + msiTransformValidationMajorVer = 8, + msiTransformValidationMinorVer = 16, + msiTransformValidationUpdateVer = 32, + msiTransformValidationLess = 64, + msiTransformValidationLessOrEqual = 128, + msiTransformValidationEqual = 256, + msiTransformValidationGreaterOrEqual = 512, + msiTransformValidationGreater = 1024, + msiTransformValidationUpgradeCode = 2048 + } MsiTransformValidation; + + typedef + enum { + msiDoActionStatusNoAction = 0, + msiDoActionStatusSuccess = 1, + msiDoActionStatusUserExit = 2, + msiDoActionStatusFailure = 3, + msiDoActionStatusSuspend = 4, + msiDoActionStatusFinished = 5, + msiDoActionStatusWrongState = 6, + msiDoActionStatusBadActionData = 7 + } MsiDoActionStatus; + + typedef + enum { + msiMessageStatusError = -1, + msiMessageStatusNone = 0, + msiMessageStatusOk = 1, + msiMessageStatusCancel = 2, + msiMessageStatusAbort = 3, + msiMessageStatusRetry = 4, + msiMessageStatusIgnore = 5, + msiMessageStatusYes = 6, + msiMessageStatusNo = 7 + } MsiMessageStatus; + + typedef + enum { + msiMessageTypeFatalExit = 0, + msiMessageTypeError = 16777216, + msiMessageTypeWarning = 33554432, + msiMessageTypeUser = 50331648, + msiMessageTypeInfo = 67108864, + msiMessageTypeFilesInUse = 83886080, + msiMessageTypeResolveSource = 100663296, + msiMessageTypeOutOfDiskSpace = 117440512, + msiMessageTypeActionStart = 134217728, + msiMessageTypeActionData = 150994944, + msiMessageTypeProgress = 167772160, + msiMessageTypeCommonData = 184549376, + msiMessageTypeOk = 0, + msiMessageTypeOkCancel = 1, + msiMessageTypeAbortRetryIgnore = 2, + msiMessageTypeYesNoCancel = 3, + msiMessageTypeYesNo = 4, + msiMessageTypeRetryCancel = 5, + msiMessageTypeDefault1 = 0, + msiMessageTypeDefault2 = 256, + msiMessageTypeDefault3 = 512 + } MsiMessageType; + + typedef + enum { + msiInstallStateNotUsed = -7, + msiInstallStateBadConfig = -6, + msiInstallStateIncomplete = -5, + msiInstallStateSourceAbsent = -4, + msiInstallStateInvalidArg = -2, + msiInstallStateUnknown = -1, + msiInstallStateBroken = 0, + msiInstallStateAdvertised = 1, + msiInstallStateRemoved = 1, + msiInstallStateAbsent = 2, + msiInstallStateLocal = 3, + msiInstallStateSource = 4, + msiInstallStateDefault = 5 + } MsiInstallState; + + typedef + enum { + msiCostTreeSelfOnly = 0, + msiCostTreeChildren = 1, + msiCostTreeParents = 2 + } MsiCostTree; + + typedef + enum { + msiReinstallModeFileMissing = 2, + msiReinstallModeFileOlderVersion = 4, + msiReinstallModeFileEqualVersion = 8, + msiReinstallModeFileExact = 16, + msiReinstallModeFileVerify = 32, + msiReinstallModeFileReplace = 64, + msiReinstallModeMachineData = 128, + msiReinstallModeUserData = 256, + msiReinstallModeShortcut = 512, + msiReinstallModePackage = 1024 + } MsiReinstallMode; + + typedef + enum { + msiInstallTypeDefault = 0, + msiInstallTypeNetworkImage = 1, + msiInstallTypeSingleInstance = 2 + } MsiInstallType; + + typedef + enum { + msiInstallModeNoSourceResolution = -3, + msiInstallModeNoDetection = -2, + msiInstallModeExisting = -1, + msiInstallModeDefault = 0 + } MsiInstallMode; + + typedef + enum { + msiSignatureInfoCertificate = 0, + msiSignatureInfoHash = 1 + } MsiSignatureInfo; + + typedef + enum { + msiInstallContextFirstVisible = 0, + msiInstallContextUserManaged = 1, + msiInstallContextUser = 2, + msiInstallContextMachine = 4, + msiInstallContextAllUserManaged = 8 + } MsiInstallContext; + + typedef + enum { + msiInstallSourceTypeUnknown = 0, + msiInstallSourceTypeNetwork = 1, + msiInstallSourceTypeURL = 2, + msiInstallSourceTypeMedia = 4 + } MsiInstallSourceType; + + typedef enum { + msiDatabaseNullInteger = 0x80000000 /* -2147483648 from oleview, but widl makes it into two "-"'s + * which screws up msiserver.h */ + } Constants; + + typedef + enum { + msiOpenDatabaseModeReadOnly = 0, + msiOpenDatabaseModeTransact = 1, + msiOpenDatabaseModeDirect = 2, + msiOpenDatabaseModeCreate = 3, + msiOpenDatabaseModeCreateDirect = 4, + msiOpenDatabaseModePatchFile = 32 + } MsiOpenDatabaseMode; + + typedef + enum { + msiSignatureOptionInvalidHashFatal = 1 + } MsiSignatureOption; + + /* + * Now the interfaces. + */ + + [ + uuid(000C1090-0000-0000-C000-000000000046), + ] + dispinterface Installer { + properties: + [id(0x00000006)] + MsiUILevel UILevel; + methods: + [id(0x00000001)] + Record* CreateRecord([in] long Count); + [id(0x00000002)] + Session* OpenPackage( + [in] VARIANT PackagePath, + [in, optional, defaultvalue(0)] long Options); + [id(0x00000003)] + Session* OpenProduct([in] BSTR ProductCode); + [id(0x00000004)] + Database* OpenDatabase( + [in] BSTR DatabasePath, + [in] VARIANT OpenMode); + [id(0x00000005), propget] + SummaryInfo* SummaryInformation( + [in] BSTR PackagePath, + [in, optional, defaultvalue(0)] long UpdateCount); + [id(0x00000007)] + void EnableLog( + [in] BSTR LogMode, + [in] BSTR LogFile); + [id(0x00000008)] + void InstallProduct( + [in] BSTR PackagePath, + [in, optional, defaultvalue("0")] BSTR PropertyValues); + [id(0x00000009), propget] + BSTR Version(); + [id(0x0000000a)] + Record* LastErrorRecord(); + [id(0x0000000b)] + BSTR RegistryValue( + [in] VARIANT Root, + [in] BSTR Key, + [in, optional] VARIANT Value); + [id(0x0000000d)] + long FileAttributes([in] BSTR FilePath); + [id(0x0000000f)] + long FileSize([in] BSTR FilePath); + [id(0x00000010)] + BSTR FileVersion( + [in] BSTR FilePath, + [in, optional] VARIANT Language); + [id(0x0000000c), propget] + BSTR Environment([in] BSTR Variable); + [id(0x0000000c), propput] + void Environment( + [in] BSTR Variable, + [in] BSTR rhs); + [id(0x00000011), propget] + MsiInstallState ProductState([in] BSTR Product); + [id(0x00000012), propget] + BSTR ProductInfo( + [in] BSTR Product, + [in] BSTR Attribute); + [id(0x00000013)] + void ConfigureProduct( + [in] BSTR Product, + [in] long InstallLevel, + [in] MsiInstallState InstallState); + [id(0x00000014)] + void ReinstallProduct( + [in] BSTR Product, + [in] MsiReinstallMode ReinstallMode); + [id(0x00000015)] + void CollectUserInfo([in] BSTR Product); + [id(0x00000016)] + void ApplyPatch( + [in] BSTR PatchPackage, + [in] BSTR InstallPackage, + [in] MsiInstallType InstallType, + [in] BSTR CommandLine); + [id(0x00000017), propget] + BSTR FeatureParent( + [in] BSTR Product, + [in] BSTR Feature); + [id(0x00000018), propget] + MsiInstallState FeatureState( + [in] BSTR Product, + [in] BSTR Feature); + [id(0x00000019)] + void UseFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallMode InstallMode); + [id(0x0000001a), propget] + long FeatureUsageCount( + [in] BSTR Product, + [in] BSTR Feature); + [id(0x0000001b), propget] + DATE FeatureUsageDate( + [in] BSTR Product, + [in] BSTR Feature); + [id(0x0000001c)] + void ConfigureFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallState InstallState); + [id(0x0000001d)] + void ReinstallFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiReinstallMode ReinstallMode); + [id(0x0000001e)] + BSTR ProvideComponent( + [in] BSTR Product, + [in] BSTR Feature, + [in] BSTR Component, + [in] long InstallMode); + [id(0x0000001f), propget] + BSTR ComponentPath( + [in] BSTR Product, + [in] BSTR Component); + [id(0x00000020)] + BSTR ProvideQualifiedComponent( + [in] BSTR Category, + [in] BSTR Qualifier, + [in] long InstallMode); + [id(0x00000021), propget] + BSTR QualifierDescription( + [in] BSTR Category, + [in] BSTR Qualifier); + [id(0x00000022), propget] + StringList* ComponentQualifiers([in] BSTR Category); + [id(0x00000023), propget] + StringList* Products(); + [id(0x00000024), propget] + StringList* Features([in] BSTR Product); + [id(0x00000025), propget] + StringList* Components(); + [id(0x00000026), propget] + StringList* ComponentClients([in] BSTR Component); + [id(0x00000027), propget] + StringList* Patches([in] BSTR Product); + [id(0x00000028), propget] + StringList* RelatedProducts([in] BSTR UpgradeCode); + [id(0x00000029), propget] + BSTR PatchInfo( + [in] BSTR Patch, + [in] BSTR Attribute); + [id(0x0000002a), propget] + BSTR PatchTransforms( + [in] BSTR Product, + [in] BSTR Patch); + [id(0x0000002b)] + void AddSource( + [in] BSTR Product, + [in] BSTR User, + [in] BSTR Source); + [id(0x0000002c)] + void ClearSourceList( + [in] BSTR Product, + [in] BSTR User); + [id(0x0000002d)] + void ForceSourceListResolution( + [in] BSTR Product, + [in] BSTR User); + [id(0x0000002e), propget] + Record* GetShortcutTarget([in] BSTR ShortcutPath); + [id(0x0000002f)] + Record* FileHash( + [in] BSTR FilePath, + [in] long Options); + [id(0x00000030)] + SAFEARRAY(unsigned char) FileSignatureInfo( + [in] BSTR FilePath, + [in] long Options, + [in] MsiSignatureInfo Format); + [id(0x00000031)] + void RemovePatches( + [in] BSTR PatchList, + [in] BSTR Product, + [in] MsiInstallType UninstallType, + [in, optional, defaultvalue("0")] BSTR PropertyList); + [id(0x00000033)] + void ApplyMultiplePatches( + [in] BSTR PatchPackage, + [in] BSTR Product, + [in] BSTR PropertiesList); + [id(0x00000035), propget] + HRESULT Product( + [in] BSTR Product, + [in] BSTR UserSid, + [in] MsiInstallContext iContext, + [out, retval] Product** retval); + [id(0x00000038), propget] + HRESULT Patch( + [in] BSTR PatchCode, + [in] BSTR ProductCode, + [in] BSTR UserSid, + [in] MsiInstallContext iContext, + [out, retval] Patch** retval); + [id(0x00000034), propget] + RecordList* ProductsEx( + [in] BSTR Product, + [in] BSTR UserSid, + [in] long Contexts); + [id(0x00000037), propget] + RecordList* PatchesEx( + [in] BSTR Product, + [in] BSTR UserSid, + [in] long Contexts, + [in] long filter); + [id(0x00000039)] + BSTR ExtractPatchXMLData([in] BSTR PatchPath); + }; + + + [ + uuid(000C1093-0000-0000-C000-000000000046) + ] + dispinterface Record { + properties: + methods: + [id(0x00000001), propget] + BSTR StringData([in] long Field); + [id(0x00000001), propput] + void StringData( + [in] long Field, + [in] BSTR rhs); + [id(0x00000002), propget] + long IntegerData([in] long Field); + [id(0x00000002), propput] + void IntegerData( + [in] long Field, + [in] long rhs); + [id(0x00000003)] + void SetStream( + [in] long Field, + [in] BSTR FilePath); + [id(0x00000004)] + BSTR ReadStream( + [in] long Field, + [in] long Length, + [in] MsiReadStream Format); + [id(00000000), propget] + long FieldCount(); + [id(0x00000006), propget] + VARIANT_BOOL IsNull([in] long Field); + [id(0x00000005), propget] + long DataSize([in] long Field); + [id(0x00000007)] + void ClearData(); + [id(0x00000008)] + BSTR FormatText(); + }; + + + [ + uuid(000C109E-0000-0000-C000-000000000046) + ] + dispinterface Session { properties: methods: - } + [id(0x00000001), propget] + Installer* Installer(); + [id(0x00000002), propget] + BSTR Property([in] BSTR Name); + [id(0x00000002), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(0x00000003), propget] + long Language(); + [id(0x00000004), propget] + VARIANT_BOOL Mode([in] MsiRunMode Flag); + [id(0x00000004), propput] + void Mode( + [in] MsiRunMode Flag, + [in] VARIANT_BOOL rhs); + [id(0x00000005), propget] + Database* Database(); + [id(0x00000006), propget] + BSTR SourcePath([in] BSTR Folder); + [id(0x00000007), propget] + BSTR TargetPath([in] BSTR Folder); + [id(0x00000007), propput] + void TargetPath( + [in] BSTR Folder, + [in] BSTR rhs); + [id(0x00000008)] + MsiDoActionStatus DoAction([in] BSTR Action); + [id(0x00000009)] + MsiDoActionStatus Sequence( + [in] BSTR Table, + [in, optional] VARIANT Mode); + [id(0x0000000a)] + _MsiEvaluateCondition EvaluateCondition([in] BSTR Expression); + [id(0x0000000b)] + BSTR FormatRecord([in] Record* Record); + [id(0x0000000c)] + MsiMessageStatus Message( + [in] MsiMessageType Kind, + [in] Record* Record); + [id(0x0000000d), propget] + MsiInstallState FeatureCurrentState([in] BSTR Feature); + [id(0x0000000e), propget] + MsiInstallState FeatureRequestState([in] BSTR Feature); + [id(0x0000000e), propput] + void FeatureRequestState( + [in] BSTR Feature, + [in] MsiInstallState rhs); + [id(0x0000000f), propget] + long FeatureValidStates([in] BSTR Feature); + [id(0x00000010), propget] + long FeatureCost( + [in] BSTR Feature, + [in] MsiCostTree CostTree, + [in] MsiInstallState State); + [id(0x00000011), propget] + MsiInstallState ComponentCurrentState([in] BSTR Component); + [id(0x00000012), propget] + MsiInstallState ComponentRequestState([in] BSTR Component); + [id(0x00000012), propput] + void ComponentRequestState( + [in] BSTR Component, + [in] MsiInstallState rhs); + [id(0x00000013)] + void SetInstallLevel([in] long Level); + [id(0x00000014), propget] + VARIANT_BOOL VerifyDiskSpace(); + [id(0x00000015), propget] + BSTR ProductProperty([in] BSTR Property); + [id(0x00000016), propget] + FeatureInfo* FeatureInfo([in] BSTR Feature); + [id(0x00000017), propget] + RecordList* ComponentCosts( + [in] BSTR Component, + [in] MsiInstallState State); + }; - [ uuid(000C1096-0000-0000-C000-000000000046) ] - dispinterface RecordList - { + + [ + uuid(000C109D-0000-0000-C000-000000000046) + ] + dispinterface Database { properties: methods: - } + [id(0x00000001), propget] + MsiDatabaseState DatabaseState(); + [id(0x00000002), propget] + SummaryInfo* SummaryInformation([in, optional, defaultvalue(0)] long UpdateCount); + [id(0x00000003)] + View* OpenView([in] BSTR Sql); + [id(0x00000004)] + void Commit(); + [id(0x00000005), propget] + Record* PrimaryKeys([in] BSTR Table); + [id(0x00000006)] + void Import( + [in] BSTR Folder, + [in] BSTR File); + [id(0x00000007)] + void Export( + [in] BSTR Table, + [in] BSTR Folder, + [in] BSTR File); + [id(0x00000008)] + VARIANT_BOOL Merge( + [in] Database* Database, + [in, optional, defaultvalue("0")] BSTR ErrorTable); + [id(0x00000009)] + VARIANT_BOOL GenerateTransform( + [in] Database* ReferenceDatabase, + [in, optional, defaultvalue("0")] BSTR TransformFile); + [id(0x0000000a)] + void ApplyTransform( + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions); + [id(0x0000000b)] + UIPreview* EnableUIPreview(); + [id(0x0000000c), propget] + _MsiEvaluateCondition TablePersistent([in] BSTR Table); + [id(0x0000000d)] + void CreateTransformSummaryInfo( + [in] Database* ReferenceDatabase, + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions, + [in] MsiTransformValidation Validation); + }; + - [ uuid(000C109A-0000-0000-C000-000000000046) ] - dispinterface UIPreview - { + [ + uuid(000C109B-0000-0000-C000-000000000046) + ] + dispinterface SummaryInfo { properties: methods: - } + [id(0x00000001), propget] + VARIANT Property([in] long Pid); + [id(0x00000001), propput] + void Property( + [in] long Pid, + [in] VARIANT rhs); + [id(0x00000002), propget] + long PropertyCount(); + [id(0x00000003)] + void Persist(); + }; - [ uuid(000C109B-0000-0000-C000-000000000046) ] - dispinterface SummaryInfo - { + [ + uuid(000C109C-0000-0000-C000-000000000046) + ] + dispinterface View { properties: methods: - } + [id(0x00000001)] + void Execute([in, optional, defaultvalue(0)] Record* Params); + [id(0x00000002)] + Record* Fetch(); + [id(0x00000003)] + void Modify( + [in] _MsiViewModify Mode, + Record* Record); + [id(0x00000005), propget] + Record* ColumnInfo([in] MsiColumnInfo Info); + [id(0x00000004)] + void Close(); + [id(0x00000006)] + BSTR GetError(); + }; - [ uuid(000C109C-0000-0000-C000-000000000046) ] - dispinterface View - { + [ + uuid(000C109A-0000-0000-C000-000000000046) + ] + dispinterface UIPreview { properties: methods: - } + [id(0x00000001), propget] + BSTR Property([in] BSTR Name); + [id(0x00000001), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(0x00000002)] + void ViewDialog([in] BSTR Dialog); + [id(0x00000003)] + void ViewBillboard( + [in] BSTR Control, + [in] BSTR Billboard); + }; - [ uuid(000C109D-0000-0000-C000-000000000046) ] - dispinterface Database - { + [ + uuid(000C109F-0000-0000-C000-000000000046) + ] + dispinterface FeatureInfo { properties: + [id(0x00000003)] + long Attributes; methods: - } - - [ uuid(000C109E-0000-0000-C000-000000000046) ] - dispinterface Session - { - properties: - methods: - } - - [ uuid(000C109F-0000-0000-C000-000000000046) ] - dispinterface FeatureInfo - { + [id(0x00000001), propget] + BSTR Title(); + [id(0x00000002), propget] + BSTR Description(); + }; + + [ + uuid(000C1096-0000-0000-C000-000000000046) + ] + dispinterface RecordList { properties: methods: - } + [id(0xfffffffc)] + IUnknown* _NewEnum(); + [id(00000000), propget] + Record* Item(long Index); + [id(0x00000001), propget] + long Count(); + }; - [ uuid(000C10A0-0000-0000-C000-000000000046) ] - dispinterface Product - { + + [ + uuid(000C1095-0000-0000-C000-000000000046) + ] + dispinterface StringList { properties: methods: - } + [id(0xfffffffc)] + IUnknown* _NewEnum(); + [id(00000000), propget] + BSTR Item(long Index); + [id(0x00000001), propget] + long Count(); + }; - [ uuid(000C10A1-0000-0000-C000-000000000046) ] - dispinterface Patch - { + [ + uuid(000C10A0-0000-0000-C000-000000000046) + ] + dispinterface Product { properties: methods: - } -} + [id(0x00000001), propget] + HRESULT ProductCode([out, retval] BSTR* retval); + [id(0x00000002), propget] + HRESULT UserSid([out, retval] BSTR* retval); + [id(0x00000003), propget] + HRESULT Context([out, retval] MsiInstallContext* retval); + [id(0x00000004), propget] + HRESULT State([out, retval] MsiInstallState* retval); + [id(0x00000005), propget] + HRESULT InstallProperty( + [in] BSTR Name, + [out, retval] BSTR* retval); + [id(0x00000006), propget] + HRESULT ComponentState( + [in] BSTR Component, + [out, retval] MsiInstallState* retval); + [id(0x00000007), propget] + HRESULT FeatureState( + [in] BSTR Feature, + [out, retval] MsiInstallState* retval); + [id(0x0000000e), propget] + HRESULT Sources( + [in] long SourceType, + [out, retval] StringList** retval); + [id(0x0000000f), propget] + HRESULT MediaDisks([out, retval] RecordList** retval); + [id(0x00000008)] + HRESULT SourceListAddSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source, + [in] long dwIndex); + [id(0x00000009)] + HRESULT SourceListAddMediaDisk( + [in] long dwDiskId, + [in] BSTR VolumeLabel, + [in] BSTR DiskPrompt); + [id(0x0000000a)] + HRESULT SourceListClearSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source); + [id(0x0000000b)] + HRESULT SourceListClearMediaDisk([in] long iDiskId); + [id(0x0000000c)] + HRESULT SourceListClearAll([in] MsiInstallSourceType iSourceType); + [id(0x0000000d)] + HRESULT SourceListForceResolution(); + [id(0x00000010), propget] + HRESULT SourceListInfo( + [in] BSTR Property, + [out, retval] BSTR* retval); + [id(0x00000010), propput] + HRESULT SourceListInfo( + [in] BSTR Property, + [in] BSTR retval); + }; + + + [ + uuid(000C10A1-0000-0000-C000-000000000046) + ] + dispinterface Patch { + properties: + methods: + [id(0x00000001), propget] + HRESULT PatchCode([out, retval] BSTR* retval); + [id(0x00000002), propget] + HRESULT ProductCode([out, retval] BSTR* retval); + [id(0x00000003), propget] + HRESULT UserSid([out, retval] BSTR* retval); + [id(0x00000004), propget] + HRESULT Context([out, retval] MsiInstallContext* retval); + [id(0x00000005), propget] + HRESULT State([out, retval] MsiInstallState* retval); + [id(0x0000000c), propget] + HRESULT Sources( + [in] long SourceType, + [out, retval] StringList** retval); + [id(0x0000000d), propget] + HRESULT MediaDisks([out, retval] RecordList** retval); + [id(0x00000006)] + HRESULT SourceListAddSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source, + [in] long dwIndex); + [id(0x00000007)] + HRESULT SourceListAddMediaDisk( + [in] long dwDiskId, + [in] BSTR VolumeLabel, + [in] BSTR DiskPrompt); + [id(0x00000008)] + HRESULT SourceListClearSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source); + [id(0x00000009)] + HRESULT SourceListClearMediaDisk([in] long iDiskId); + [id(0x0000000a)] + HRESULT SourceListClearAll([in] MsiInstallSourceType iSourceType); + [id(0x0000000b)] + HRESULT SourceListForceResolution(); + [id(0x0000000e), propget] + HRESULT SourceListInfo( + [in] BSTR Property, + [out, retval] BSTR* retval); + [id(0x0000000e), propput] + HRESULT SourceListInfo( + [in] BSTR Property, + [in] BSTR retval); + [id(0x0000000f), propget] + HRESULT PatchProperty( + [in] BSTR Property, + [out, retval] BSTR* Value); + }; +}; + + + -- 1.4.1 -------------- next part -------------- From ddcb832a5526ae5116d3b1fbdc508907704e859b Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Fri, 23 Feb 2007 20:03:50 -0600 Subject: msi: Add handles for JScript/VBScript actions that call one script function. --- dlls/msi/custom.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++++ dlls/msi/msipriv.h | 1 2 files changed, 218 insertions(+), 0 deletions(-) diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index ba5c825..2da7e97 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -58,6 +58,14 @@ static UINT HANDLE_CustomType50(MSIPACKA LPCWSTR target, const INT type, LPCWSTR action); static UINT HANDLE_CustomType34(MSIPACKAGE *package, LPCWSTR source, LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); typedef UINT (WINAPI *MsiCustomActionEntryPoint)( MSIHANDLE ); @@ -266,6 +274,22 @@ UINT ACTION_CustomAction(MSIPACKAGE *pac rc = MSI_SetPropertyW(package,source,deformated); msi_free(deformated); break; + case 37: /* JScript/VBScript text stored in target column. */ + case 38: + rc = HANDLE_CustomType37_38(package,source,target,type,action); + break; + case 5: + case 6: /* JScript/VBScript file stored in a Binary table stream. */ + rc = HANDLE_CustomType5_6(package,source,target,type,action); + break; + case 21: /* JScript/VBScript file installed with the product. */ + case 22: + rc = HANDLE_CustomType21_22(package,source,target,type,action); + break; + case 53: /* JScript/VBScript text specified by a property value. */ + case 54: + rc = HANDLE_CustomType53_54(package,source,target,type,action); + break; default: FIXME("UNHANDLED ACTION TYPE %i (%s %s)\n", type & CUSTOM_ACTION_TYPE_MASK, debugstr_w(source), @@ -855,6 +879,199 @@ static UINT HANDLE_CustomType34(MSIPACKA return wait_process_handle(package, type, info.hProcess, action); } +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + TRACE("%s %s\n", debugstr_w( info->dllname ), debugstr_w( info->function ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + TRACE("calling %s\n", debugstr_w( info->function ) ); + r = call_script( hPackage, info->type, info->dllname, info->function, info->action); + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} + +static DWORD WINAPI ScriptThread( LPVOID arg ) +{ + LPGUID guid = arg; + DWORD rc = 0; + + TRACE("custom action (%x) started\n", GetCurrentThreadId() ); + + rc = ACTION_CallScript( guid ); + + TRACE("custom action (%x) returned %i\n", GetCurrentThreadId(), rc ); + + MsiCloseAllHandles(); + return rc; +} + +static msi_custom_action_info *do_msidbCustomActionTypeScript( + MSIPACKAGE *package, INT type, LPCWSTR dllname, LPCWSTR function, LPCWSTR action ) +{ + msi_custom_action_info *info; + + info = msi_alloc( sizeof *info ); + if (!info) + return NULL; + + msiobj_addref( &package->hdr ); + info->package = package; + info->type = type; + info->function = strdupW( function ); + info->dllname = strdupW( dllname ); + info->action = strdupW( action ); + CoCreateGuid( &info->guid ); + + EnterCriticalSection( &msi_custom_action_cs ); + list_add_tail( &msi_pending_custom_actions, &info->entry ); + LeaveCriticalSection( &msi_custom_action_cs ); + + info->handle = CreateThread( NULL, 0, ScriptThread, &info->guid, 0, NULL ); + if (!info->handle) + { + free_custom_action_data( info ); + return NULL; + } + + return info; +} + +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR tmp_file[MAX_PATH]; + WCHAR fmt[MAX_PATH]; + static const WCHAR f1[] = {'m','s','i',0}; + HANDLE file; + DWORD sz, write; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + if (MSI_GetPropertyW(package, cszTempFolder, fmt, &sz) != ERROR_SUCCESS) + GetTempPathW(MAX_PATH, fmt); + + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) + { + TRACE("Unable to create file\n"); + return ERROR_FUNCTION_FAILED; + } + track_tempfile(package, tmp_file); + + /* Write out script from target field to file (a little roundabout but makes script code simpler) */ + file = CreateFileW(tmp_file, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, + FILE_ATTRIBUTE_NORMAL, NULL); + if (file == INVALID_HANDLE_VALUE) + return ERROR_FUNCTION_FAILED; + else + { + WriteFile(file, target, sizeof(WCHAR)*(strlenW(target)+1), &write, NULL); + CloseHandle(file); + } + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR tmp_file[MAX_PATH]; + UINT r; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + r = store_binary_to_temp(package, source, tmp_file); + if (r != ERROR_SUCCESS) + return r; + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, target, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + MSIFILE *file; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + file = get_loaded_file(package,source); + if (!file) + { + ERR("invalid file key %s\n", debugstr_w(source)); + return ERROR_FUNCTION_FAILED; + } + + info = do_msidbCustomActionTypeScript( package, type, file->TargetPath, target, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR *prop; + WCHAR tmp_file[MAX_PATH]; + WCHAR fmt[MAX_PATH]; + static const WCHAR f1[] = {'m','s','i',0}; + HANDLE file; + DWORD sz, write; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + prop = msi_dup_property(package,source); + if (!prop) + return ERROR_SUCCESS; + + if (MSI_GetPropertyW(package, cszTempFolder, fmt, &sz) != ERROR_SUCCESS) + GetTempPathW(MAX_PATH, fmt); + + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) + { + TRACE("Unable to create file\n"); + return ERROR_FUNCTION_FAILED; + } + track_tempfile(package, tmp_file); + + /* Write out script from target field to file (a little roundabout but makes script code simpler) */ + file = CreateFileW(tmp_file, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, + FILE_ATTRIBUTE_NORMAL, NULL); + if (file == INVALID_HANDLE_VALUE) + return ERROR_FUNCTION_FAILED; + else + { + WriteFile(file, prop, sizeof(WCHAR)*(strlenW(prop)+1), &write, NULL); + CloseHandle(file); + } + + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); + + return wait_thread_handle( info ); +} + void ACTION_FinishCustomActions(MSIPACKAGE* package) { struct list *item; diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h index 971f71e..fb43b05 100644 --- a/dlls/msi/msipriv.h +++ b/dlls/msi/msipriv.h @@ -750,6 +750,7 @@ extern UINT ACTION_RegisterMIMEInfo(MSIP extern UINT ACTION_RegisterFonts(MSIPACKAGE *package); /* Helpers */ +extern DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action); extern DWORD deformat_string(MSIPACKAGE *package, LPCWSTR ptr, WCHAR** data ); extern LPWSTR msi_dup_record_field(MSIRECORD *row, INT index); extern LPWSTR msi_dup_property(MSIPACKAGE *package, LPCWSTR prop); -- 1.4.1 -------------- next part -------------- From f04d238d950da30f8481d80e642136c1b2fc40fe Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Fri, 23 Feb 2007 20:05:28 -0600 Subject: msi: Add full JScript/VBScript support and partial expandable OLE automation support. --- dlls/msi/Makefile.in | 4 dlls/msi/automation.c | 754 +++++++++++++++++++++++++++++++++++++++++++++++++ dlls/msi/automation.h | 138 +++++++++ dlls/msi/script.c | 448 +++++++++++++++++++++++++++++ 4 files changed, 1344 insertions(+), 0 deletions(-) diff --git a/dlls/msi/Makefile.in b/dlls/msi/Makefile.in index 5fb0941..4e01dab 100644 --- a/dlls/msi/Makefile.in +++ b/dlls/msi/Makefile.in @@ -12,6 +12,7 @@ C_SRCS = \ action.c \ alter.c \ appsearch.c \ + automation.c \ classes.c \ create.c \ custom.c \ @@ -37,6 +38,7 @@ C_SRCS = \ record.c \ registry.c \ regsvr.c \ + script.c \ select.c \ source.c \ string.c \ @@ -48,6 +50,8 @@ C_SRCS = \ where.c IDL_TLB_SRCS = msiserver.idl +IDL_H_SRCS = msiserver.idl +IDL_I_SRCS = msiserver.idl BISON_SRCS = \ cond.y \ diff --git a/dlls/msi/automation.c b/dlls/msi/automation.c new file mode 100644 index 0000000..b1527c2 --- /dev/null +++ b/dlls/msi/automation.c @@ -0,0 +1,754 @@ +/* + * Implementation of OLE Automation for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +#include "automation.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +/* + * If you would like to implement a new automation function/object, look towards the bottom of this + * file for the "meat and potatoes" section. + */ + +/* FIXME: I don't know how big this should be */ +#define MAX_MSI_STRING 1000 + +static const struct IDispatchVtbl AutomationObject_Vtbl; +static const struct IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl; +static const struct IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl; +static const struct IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl; + +/* Load type info so we don't have to process GetIDsOfNames */ +HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid) +{ + HRESULT hr; + LPTYPELIB pLib = NULL; + LPTYPEINFO pInfo = NULL; + WCHAR szMsiServer[] = {'m','s','i','s','e','r','v','e','r','.','t','l','b'}; + + TRACE("(%p)->(%s,%d)\n", iface, debugstr_guid(clsid), lcid); + + /* Load registered type library */ + hr = LoadRegTypeLib(&LIBID_WindowsInstaller, 1, 0, lcid, &pLib); + if (FAILED(hr)) { + hr = LoadTypeLib(szMsiServer, &pLib); + if (FAILED(hr)) { + ERR("Could not load msiserver.tlb\n"); + return hr; + } + } + + /* Get type information for object */ + hr = ITypeLib_GetTypeInfoOfGuid(pLib, clsid, &pInfo); + ITypeLib_Release(pLib); + if (FAILED(hr)) { + ERR("Could not load ITypeInfo for %s\n", debugstr_guid(clsid)); + return hr; + } + *pptinfo = pInfo; + return S_OK; +} + +/* Create the automation object, placing the result in the pointer ppObj. The automation object is created + * with the appropriate clsid and invocation function. */ +HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke) +{ + AutomationObject *object; + HRESULT hr; + + TRACE("(%ld,%p,%p,%s,%p)\n", (unsigned long)msiHandle, pUnkOuter, ppObj, debugstr_guid(clsid), funcInvoke); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(AutomationObject)); + + /* Set all the VTable references */ + object->lpVtbl = &AutomationObject_Vtbl; + object->lpvtblIProvideClassInfo = &AutomationObject_IProvideClassInfo_Vtbl; + object->lpvtblIProvideClassInfo2 = &AutomationObject_IProvideClassInfo2_Vtbl; + object->lpvtblIProvideMultipleClassInfo = &AutomationObject_IProvideMultipleClassInfo_Vtbl; + object->ref = 1; + + /* Store data that was passed */ + object->msiHandle = msiHandle; + object->clsid = (LPCLSID)clsid; + object->funcInvoke = funcInvoke; + + /* Load our TypeInfo so we don't have to process GetIDsOfNames */ + object->iTypeInfo = NULL; + hr = LoadTypeInfo((IDispatch *)object, &object->iTypeInfo, clsid, 0x0); + if (FAILED(hr)) { + HeapFree(GetProcessHeap(), 0, object); + return hr; + } + + *ppObj = object; + + return S_OK; +} + +/* Macros to get pointer to AutomationObject) from the other VTables. */ +static inline AutomationObject *obj_from_IProvideClassInfo( IProvideClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo)); +} + +static inline AutomationObject *obj_from_IProvideClassInfo2( IProvideClassInfo2 *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo2)); +} + +static inline AutomationObject *obj_from_IProvideMultipleClassInfo( IProvideMultipleClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideMultipleClassInfo)); +} + +/* + * AutomationObject methods + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI AutomationObject_QueryInterface(IDispatch* iface, REFIID riid, void** ppvObject) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + /* + * Perform a sanity check on the parameters. + */ + if ( (This==0) || (ppvObject==0) ) + return E_INVALIDARG; + + /* + * Initialize the return parameter. + */ + *ppvObject = 0; + + /* + * Compare the riid with the interface IDs implemented by this object. + */ + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IDispatch) || IsEqualGUID(riid, This->clsid)) + *ppvObject = This; + else if (IsEqualGUID(riid, &IID_IProvideClassInfo)) + *ppvObject = (IProvideClassInfo*)&(This->lpvtblIProvideClassInfo); + else if (IsEqualGUID(riid, &IID_IProvideClassInfo2)) + *ppvObject = (IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2); + else if (IsEqualGUID(riid, &IID_IProvideMultipleClassInfo)) + *ppvObject = (IProvideMultipleClassInfo*)&(This->lpvtblIProvideMultipleClassInfo); + + /* + * Check that we obtained an interface. + */ + if ((*ppvObject)==0) + { + TRACE("() : asking for unsupported interface %s\n",debugstr_guid(riid)); + return E_NOINTERFACE; + } + + /* + * Query Interface always increases the reference count by one when it is + * successful + */ + IClassFactory_AddRef(iface); + + return S_OK; +} + +static ULONG WINAPI AutomationObject_AddRef(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI AutomationObject_Release(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + { + MsiCloseHandle(This->msiHandle); + HeapFree(GetProcessHeap(), 0, This); + } + + return ref; +} + +/*** IDispatch methods ***/ +static HRESULT WINAPI AutomationObject_GetTypeInfoCount( + IDispatch* iface, + UINT* pctinfo) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%p)\n", iface, This, pctinfo); + *pctinfo = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetTypeInfo( + IDispatch* iface, + UINT iTInfo, + LCID lcid, + ITypeInfo** ppTInfo) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%d,%d,%p)\n", iface, This, iTInfo, lcid, ppTInfo); + + ITypeInfo_AddRef(This->iTypeInfo); + *ppTInfo = This->iTypeInfo; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetIDsOfNames( + IDispatch* iface, + REFIID riid, + LPOLESTR* rgszNames, + UINT cNames, + LCID lcid, + DISPID* rgDispId) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%p,%p,%d,%d,%p)\n", iface, This, riid, rgszNames, cNames, lcid, rgDispId); + + if (!IsEqualGUID(riid, &IID_NULL)) return E_INVALIDARG; + return ITypeInfo_GetIDsOfNames(This->iTypeInfo, rgszNames, cNames, rgDispId); +} + +/* Error checking, etc. is done here to simplify individual object function invocation */ +static HRESULT WINAPI AutomationObject_Invoke( + IDispatch* iface, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + AutomationObject *This = (AutomationObject *)iface; + HRESULT (STDMETHODCALLTYPE *Invoke)( + AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*) = This->funcInvoke; + HRESULT hr; + BSTR bstrName = NULL; + + TRACE("(%p/%p)->(%d,%p,%d,%d,%p,%p,%p,%p)\n", iface, This, dispIdMember, riid, lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); + + if (!IsEqualIID(riid, &IID_NULL)) + { + ERR("riid was %s instead of IID_NULL\n", debugstr_guid(riid)); + return DISP_E_UNKNOWNNAME; + } + + if (!pDispParams) + { + ERR("NULL pDispParams not allowed\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + if (wFlags & DISPATCH_PROPERTYGET && !pVarResult) + { + ERR("NULL pVarResult not allowed when DISPATCH_PROPERTYGET specified\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + /* If there is a result, make default type empty */ + if (pVarResult) V_VT(pVarResult) = VT_EMPTY; + + /* If we are tracing, we want to see the name of the member we are invoking */ + if (TRACE_ON(msi)) + { + ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + TRACE("Method %d, %s\n", dispIdMember, debugstr_w(bstrName)); + } + + hr = Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr); + + if (hr == DISP_E_MEMBERNOTFOUND) { + if (bstrName == NULL) ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + FIXME("Method %d, %s wflags %d not implemented, clsid %s\n", dispIdMember, debugstr_w(bstrName), wFlags, debugstr_guid(This->clsid)); + } + + TRACE("Returning %d, %s\n", hr, hr == S_OK ? "ok" : "not ok"); + + return hr; +} + +static const struct IDispatchVtbl AutomationObject_Vtbl = +{ + AutomationObject_QueryInterface, + AutomationObject_AddRef, + AutomationObject_Release, + AutomationObject_GetTypeInfoCount, + AutomationObject_GetTypeInfo, + AutomationObject_GetIDsOfNames, + AutomationObject_Invoke +}; + +/* + * IProvideClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo_QueryInterface( + IProvideClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_AddRef(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_Release(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_GetClassInfo(IProvideClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, ppTI); + return LoadTypeInfo((IDispatch *)This, ppTI, This->clsid, 0); +} + +static const IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl = +{ + AutomationObject_IProvideClassInfo_QueryInterface, + AutomationObject_IProvideClassInfo_AddRef, + AutomationObject_IProvideClassInfo_Release, + AutomationObject_GetClassInfo +}; + +/* + * IProvideClassInfo2 methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_QueryInterface( + IProvideClassInfo2* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_AddRef(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_Release(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_GetClassInfo(IProvideClassInfo2* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_GetGUID(IProvideClassInfo2* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + TRACE("(%p/%p)->(%d,%s)\n", iface, This, dwGuidKind, debugstr_guid(pGUID)); + + if (dwGuidKind != GUIDKIND_DEFAULT_SOURCE_DISP_IID) + return E_INVALIDARG; + else { + *pGUID = *This->clsid; + return S_OK; + } +} + +static const IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl = +{ + AutomationObject_IProvideClassInfo2_QueryInterface, + AutomationObject_IProvideClassInfo2_AddRef, + AutomationObject_IProvideClassInfo2_Release, + AutomationObject_IProvideClassInfo2_GetClassInfo, + AutomationObject_GetGUID +}; + +/* + * IProvideMultipleClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_QueryInterface( + IProvideMultipleClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_AddRef(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_Release(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetClassInfo(IProvideMultipleClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetGUID(IProvideMultipleClassInfo* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetGUID((IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2), dwGuidKind, pGUID); +} + +static HRESULT WINAPI AutomationObject_GetMultiTypeInfoCount(IProvideMultipleClassInfo* iface, ULONG* pcti) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, pcti); + *pcti = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetInfoOfIndex(IProvideMultipleClassInfo* iface, + ULONG iti, + DWORD dwFlags, + ITypeInfo** pptiCoClass, + DWORD* pdwTIFlags, + ULONG* pcdispidReserved, + IID* piidPrimary, + IID* piidSource) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%d,%d,%p,%p,%p,%p,%p)\n", iface, This, iti, dwFlags, pptiCoClass, pdwTIFlags, pcdispidReserved, piidPrimary, piidSource); + + if (iti != 0) + return E_INVALIDARG; + + if (dwFlags & MULTICLASSINFO_GETTYPEINFO) + LoadTypeInfo((IDispatch *)This, pptiCoClass, This->clsid, 0); + + if (dwFlags & MULTICLASSINFO_GETNUMRESERVEDDISPIDS) + { + *pdwTIFlags = 0; + *pcdispidReserved = 0; + } + + if (dwFlags & MULTICLASSINFO_GETIIDPRIMARY){ + *piidPrimary = *This->clsid; + } + + if (dwFlags & MULTICLASSINFO_GETIIDSOURCE){ + *piidSource = *This->clsid; + } + + return S_OK; +} + +static const IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl = +{ + AutomationObject_IProvideMultipleClassInfo_QueryInterface, + AutomationObject_IProvideMultipleClassInfo_AddRef, + AutomationObject_IProvideMultipleClassInfo_Release, + AutomationObject_IProvideMultipleClassInfo_GetClassInfo, + AutomationObject_IProvideMultipleClassInfo_GetGUID, + AutomationObject_GetMultiTypeInfoCount, + AutomationObject_GetInfoOfIndex +}; + +/* + * Individual Object Invocation Functions - Our meat and potatoes + * + * - To add a method, just add an appropriate case to an appropriate switch statement + * * Follow syntax here for property get/puts and method calls. Remember, parameters + * are passed IN REVERSE ORDER (last parameter to function is first in array). This got me at first. + * * MSI specs seem to indicate that most functions return an S_OK. If you don't, chances are the + * script will stop running, but check the MSI documentation for your specific function. + * - To add a new object, just add an ObjectImpl_Invoke method and appropriate method call that + * creates your object. + */ + +HRESULT WINAPI RecordImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + UINT ret; + + switch (dispIdMember) + { + case RecordDispId_StringData: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BSTR; + if ((ret = MsiRecordGetStringW(This->msiHandle, V_I4(&pDispParams->rgvarg[0]), + szString, &dwLen)) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + else + { + TRACE("MsiRecordGetString returned %d\n", ret); + V_BSTR(pVarResult) = NULL; + } + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiRecordSetStringW(This->msiHandle, V_I4(&pDispParams->rgvarg[1]), + V_BSTR(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI ViewImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + AutomationObject *obj = NULL; + IDispatch *iDispatch = NULL; + UINT ret; + + switch (dispIdMember) + { + case ViewDispId_Execute: + if (wFlags & DISPATCH_METHOD) + { + obj = (AutomationObject *)V_DISPATCH(&pDispParams->rgvarg[0]); + MsiViewExecute(This->msiHandle, obj == NULL ? 0 : obj->msiHandle); + return S_OK; + } + break; + + case ViewDispId_Fetch: + if (wFlags & DISPATCH_METHOD) + { + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiViewFetch(This->msiHandle, &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Record, RecordImpl_Invoke); + else TRACE("MsiViewFetch returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + + case ViewDispId_Close: + if (wFlags & DISPATCH_METHOD) + { + MsiViewClose(This->msiHandle); + return S_OK; + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI DatabaseImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + IDispatch *iDispatch = NULL; + UINT ret; + + switch (dispIdMember) + { + case DatabaseDispId_OpenView: + if (wFlags & DISPATCH_METHOD) + { + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiDatabaseOpenViewW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_View, ViewImpl_Invoke); + else TRACE("MsiDatabaseOpenViewW returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI SessionImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + IDispatch *iDispatch = NULL; + MSIHANDLE msiHandle; + LANGID langId; + UINT ret; + INSTALLSTATE iInstalled, iAction; + + switch (dispIdMember) + { + case SessionDispId_Property: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BSTR; + V_BSTR(pVarResult) = NULL; + if (MsiGetPropertyW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + szString, &dwLen) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetPropertyW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[1]), + V_BSTR(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + + case SessionDispId_Language: + if (wFlags & DISPATCH_PROPERTYGET) { + langId = MsiGetLanguage(This->msiHandle); + if (langId != ERROR_INVALID_HANDLE) + { + V_VT(pVarResult) = VT_I4; + V_I4(pVarResult) = langId; + return S_OK; + } else return E_FAIL; + } + break; + + case SessionDispId_Mode: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BOOL; + V_BOOL(pVarResult) = MsiGetMode(This->msiHandle, V_I4(&pDispParams->rgvarg[0])); + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetMode(This->msiHandle, V_I4(&pDispParams->rgvarg[1]), + V_BOOL(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + + case SessionDispId_Database: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_DISPATCH; + msiHandle = MsiGetActiveDatabase(This->msiHandle); + if (msiHandle) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Database, DatabaseImpl_Invoke); + else TRACE("MsiGetActiveDatabase failed\n"); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + + case SessionDispId_FeatureCurrentState: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iInstalled; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + return S_OK; + } + break; + + case SessionDispId_FeatureRequestState: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iAction; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[1]), + (INSTALLSTATE)V_I4(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} diff --git a/dlls/msi/automation.h b/dlls/msi/automation.h new file mode 100644 index 0000000..ed67dbf --- /dev/null +++ b/dlls/msi/automation.h @@ -0,0 +1,138 @@ +/* + * Implementation of OLE Automation for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#ifndef __WINE_MSI_AUTOMATION__ +#define __WINE_MSI_AUTOMATION__ + +#include + +#include "windef.h" +#include "winbase.h" +#include "msi.h" +#include "msiquery.h" +#include "objbase.h" +#include "objidl.h" +#include "winnls.h" +#include "wine/list.h" + +#include "msiserver.h" + +/* + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just + * need to implement Invoke function for each dispinterface and pass the new function + * to create_automation_object. + */ + +typedef struct { + /* + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo + */ + const IDispatchVtbl *lpVtbl; + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; + + /* Object reference count */ + LONG ref; + + /* Clsid for this class and it's appropriate ITypeInfo object */ + LPCLSID clsid; + ITypeInfo *iTypeInfo; + + /* The MSI handle of the current object */ + MSIHANDLE msiHandle;; + + /* A function that is called from IDispatch::Invoke, specific to this type of object */ + LPVOID funcInvoke; +} AutomationObject; + +/* This is the function that one needs to call to create an automation object. */ +extern HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke); + +/* We need to expose these functions because our IActiveScriptSite calls it */ +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); +extern HRESULT WINAPI SessionImpl_Invoke(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*); + +/* Disp Ids + * (not complete, look in msiserver.idl to add more) */ +typedef enum { + RecordDispId_StringData=1, + RecordDispId_IntegerData, + RecordDispId_SetStream, + RecordDispId_ReadStream, + RecordDispId_FieldCount, + RecordDispId_IsNull, + RecordDispId_DataSize, + RecordDispId_ClearData, + RecordDispId_FormatText +} RecordDispId; + +typedef enum { + ViewDispId_Execute=1, + ViewDispId_Fetch, + ViewDispId_Modify, + ViewDispId_Close, + ViewDispId_ColumnInfo, + ViewDispId_GetError +} ViewDispId; + +typedef enum { + DatabaseDispId_DatabaseState=1, + DatabaseDispId_SummaryInformation, + DatabaseDispId_OpenView, + DatabaseDispId_Commit, + DatabaseDispId_PrimaryKeys, + DatabaseDispId_Import, + DatabaseDispId_Export, + DatabaseDispId_Merge, + DatabaseDispId_GenerateTransform, + DatabaseDispId_ApplyTransform, + DatabaseDispId_EnableUIPreview, + DatabaseDispId_TablePersistent, + DatabaseDispId_CreateTransformSummaryInfo +} DatabaseDispId; + +typedef enum { + SessionDispId_Installer=1, + SessionDispId_Property, + SessionDispId_Language, + SessionDispId_Mode, + SessionDispId_Database, + SessionDispId_SourcePath, + SessionDispId_TargetPath, + SessionDispId_DoAction, + SessionDispId_Sequence, + SessionDispId_EvaluateCondition, + SessionDispId_FormatRecord, + SessionDispId_Message, + SessionDispId_FeatureCurrentState, + SessionDispId_FeatureRequestState, + SessionDispId_FeatureValidStates, + SessionDispId_FeatureCost, + SessionDispId_ComponentCurrentState, + SessionDispId_ComponentRequestState, + SessionDispId_SetInstallLevel, + SessionDispId_VerifyDiskSpace, + SessionDispId_ProductProperty, + SessionDispId_FeatureInfo, + SessionDispId_ComponentCost +} SessionDispId; + +#endif /* __WINE_MSI_AUTOMATION__ */ diff --git a/dlls/msi/script.c b/dlls/msi/script.c new file mode 100644 index 0000000..6d62c41 --- /dev/null +++ b/dlls/msi/script.c @@ -0,0 +1,448 @@ +/* + * Implementation of scripting for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +#include "automation.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +const WCHAR szJScript[] = { 'J','S','c','r','i','p','t',0}; +const WCHAR szVBScript[] = { 'V','B','S','c','r','i','p','t',0}; +const WCHAR szSession[] = {'S','e','s','s','i','o','n',0}; + +/* Would be better not to have to define this here, but need to tell which scripts are Unicode and + * which are not so we can convert to unicode */ +#define CUSTOM_ACTION_TYPE_MASK 0x3F + +/* + * MsiActiveScriptSite - Our IActiveScriptSite implementation. + */ + +typedef struct { + IActiveScriptSite lpVtbl; + AutomationObject *session; + LONG ref; +} MsiActiveScriptSite; + +static const struct IActiveScriptSiteVtbl ASS_Vtbl; + +static HRESULT ASS_create(IUnknown *pUnkOuter, LPVOID *ppObj) +{ + MsiActiveScriptSite* object; + + TRACE("(%p,%p)\n", pUnkOuter, ppObj); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(MsiActiveScriptSite)); + + object->lpVtbl.lpVtbl = &ASS_Vtbl; + object->ref = 1; + object->session = NULL; + + *ppObj = object; + + return S_OK; +} + +/* + * Helper functions to run scripts + * + * - We write all scripts to a file in custom.c so we can use one function to implement both + * scripts that are files (either installed or written from an msi binary) and from properties + * or from the custom action table. + */ + +LPCWSTR read_script_from_file(LPCWSTR szFile, INT type) +{ + HANDLE hFile; + DWORD sz, szHighWord = 0, read; + WCHAR *script=NULL, *script2=NULL; + + hFile = CreateFileW(szFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); + if (hFile == INVALID_HANDLE_VALUE) + return NULL; + + sz = GetFileSize(hFile, &szHighWord); + if (sz == INVALID_FILE_SIZE || szHighWord != 0) + return NULL; + + script = msi_alloc(sizeof(CHAR)*(sz+1)); + if (!script) + return NULL; + + if (!ReadFile(hFile, (LPVOID)script, sz, &read, NULL)) + { + msi_free(script); + return NULL; + } + + /* Convert to unicode if necessary (hack to determine which types need to be converted) */ + switch (type & CUSTOM_ACTION_TYPE_MASK) + { + case 5: + case 6: + case 21: + case 22: + /* Null terminate string before converting */ + ((CHAR *)script)[read] = 0; + + TRACE("Converting script to UniCode\n"); + sz = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, (LPCSTR)script, -1, script2, 0); + script2 = msi_alloc(sizeof(WCHAR)*sz); + if (!script2) + { + msi_free(script); + return NULL; + } + if (!MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, (LPCSTR)script, -1, script2, sz)) + { + msi_free(script2); + msi_free(script); + return NULL; + } + TRACE("Converted successfully\n"); + return script2; + + default: + return script; + } +} + +/* JScript or VBScript? */ +LPCWSTR progid_from_type(INT type) +{ + if (type & msidbCustomActionTypeJScript) return szJScript; + else if (type & msidbCustomActionTypeVBScript) return szVBScript; + ERR("Unknown script type %d\n", type); + return NULL; +} + +/* + * Call a script. This is our meat and potatoes. + * - Currently, since the function is relatively new, it will always end up returning S_OK. + * Think of it like a bonus feature, we can run the script - great. If we have a problem, + * we are no worse off than if this function had not been called. + */ +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) +{ + LPCWSTR script = NULL, progId = NULL; + HRESULT hr; + IActiveScript *iActiveScript = NULL; + IActiveScriptParse *iActiveScriptParse = NULL; + MsiActiveScriptSite *msiActiveScriptSite = NULL; + IDispatch *iDispatch = NULL; + DISPPARAMS dispparamsNoArgs = {NULL, NULL, 0, 0}; + DISPID dispid; + CLSID clsid; + VARIANT var; + + /* Reeturn success by default (if Windows Script not installed) - not native behavior. This + * should be here until we implement wine scripting. */ + DWORD ret = ERROR_SUCCESS; + + CoInitialize(NULL); + + /* Create MsiActiveScriptSite object */ + hr = ASS_create(NULL, (void **)&msiActiveScriptSite); + if (hr != S_OK) goto done; + + /* Create a session object */ + hr = create_automation_object(hPackage, NULL, (void **)&msiActiveScriptSite->session, &DIID_Session, SessionImpl_Invoke); + if (hr != S_OK) goto done; + IUnknown_AddRef((IUnknown *)msiActiveScriptSite->session); + + /* Create the scripting engine */ + progId = progid_from_type(type); + hr = CLSIDFromProgID(progId, &clsid); + if (FAILED(hr)) { + ERR("Could not find CLSID for program ID %s. Is scripting installed?\n", debugstr_w(progId)); + goto done; + } + hr = CoCreateInstance(&clsid, NULL, CLSCTX_INPROC_SERVER, &IID_IActiveScript, (void **)&iActiveScript); + if (FAILED(hr)) { + ERR("Could not instantiate class for program ID %s\n", debugstr_w(progId)); + goto done; + } + + /* If we got this far, Windows Script is installed, so don't return success by default anymore */ + ret = ERROR_INSTALL_FAILURE; + + /* Try to load the script file */ + script = read_script_from_file(filename, type); + if (!script) goto done; + + TRACE("Calling function %s, script is %s\n", debugstr_w(function), debugstr_w(script)); + + /* Get the IActiveScriptParse engine interface */ + hr = IActiveScript_QueryInterface(iActiveScript, &IID_IActiveScriptParse, (void **)&iActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Give our host to the engine */ + hr = IActiveScript_SetScriptSite(iActiveScript, (IActiveScriptSite *)msiActiveScriptSite); + if (FAILED(hr)) goto done; + + /* Initialize the script engine */ + hr = IActiveScriptParse_InitNew(iActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Add the session object */ + hr = IActiveScript_AddNamedItem(iActiveScript, szSession, SCRIPTITEM_ISVISIBLE); + + /* Pass the script to the engine */ + hr = IActiveScriptParse_ParseScriptText(iActiveScriptParse, script, NULL, NULL, NULL, 0, 0, 0L, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Start processing the script */ + hr = IActiveScript_SetScriptState(iActiveScript, SCRIPTSTATE_CONNECTED); + if (FAILED(hr)) goto done; + + /* Call a function if necessary through the IDispatch interface */ + if (function != NULL && strlenW(function) > 0) { + TRACE("Calling function %s\n", debugstr_w(function)); + + hr = IActiveScript_GetScriptDispatch(iActiveScript, NULL, &iDispatch); + if (FAILED(hr)) goto done; + + hr = IDispatch_GetIDsOfNames(iDispatch, &IID_NULL, (WCHAR **)&function, 1,LOCALE_USER_DEFAULT, &dispid); + if (FAILED(hr)) goto done; + + hr = IDispatch_Invoke(iDispatch, dispid, &IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD, &dispparamsNoArgs, &var, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Check return value, if it's not IDOK we failed */ + hr = VariantChangeType(&var, &var, 0, VT_I4); + if (FAILED(hr)) goto done; + + if (V_I4(&var) == IDOK) + ret = ERROR_SUCCESS; + else ret = ERROR_INSTALL_FAILURE; + + VariantClear(&var); + } else { + /* If no function to be called, MSI behavior is to succeed */ + ret = ERROR_SUCCESS; + } + +done: + + /* Free everything that needs to be freed */ + if (iDispatch) IDispatch_Release(iDispatch); + if (iActiveScript) IActiveScriptSite_Release(iActiveScript); + if (msiActiveScriptSite && + msiActiveScriptSite->session) IUnknown_Release((IUnknown *)msiActiveScriptSite->session); + if (msiActiveScriptSite) IUnknown_Release((IUnknown *)msiActiveScriptSite); + if (script) msi_free((WCHAR *)script); + + CoUninitialize(); /* must call even if CoInitialize failed */ + +/* return ret; */ + return ERROR_SUCCESS; /* FIXME: Until thoroughly tested, always return success */ +} + +/* + * MsiActiveScriptSite + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI MsiActiveScriptSite_QueryInterface(IActiveScriptSite* iface, REFIID riid, void** ppvObject) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + if (IsEqualGUID(riid, &IID_IUnknown) || + IsEqualGUID(riid, &IID_IActiveScriptSite)) + { + IClassFactory_AddRef(iface); + *ppvObject = This; + return S_OK; + } + + TRACE("(%p)->(%s,%p),not found\n",This,debugstr_guid(riid),ppvObject); + + return E_NOINTERFACE; +} + +static ULONG WINAPI MsiActiveScriptSite_AddRef(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI MsiActiveScriptSite_Release(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + HeapFree(GetProcessHeap(), 0, This); + + return ref; +} + +/*** IActiveScriptSite methods **/ +static HRESULT WINAPI MsiActiveScriptSite_GetLCID(IActiveScriptSite* iface, LCID* plcid) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub!\n", This, iface, plcid); + return E_NOTIMPL; +} + +static HRESULT WINAPI MsiActiveScriptSite_GetItemInfo(IActiveScriptSite* iface, LPCOLESTR pstrName, DWORD dwReturnMask, IUnknown** ppiunkItem, ITypeInfo** ppti) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%d,%p,%p)!\n", This, iface, pstrName, dwReturnMask, ppiunkItem, ppti); + + /* Determine the kind of pointer that is requested, and make sure placeholder is valid */ + if (dwReturnMask & SCRIPTINFO_ITYPEINFO) { + if (!ppti) return E_INVALIDARG; + *ppti = NULL; + } + if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + if (!ppiunkItem) return E_INVALIDARG; + *ppiunkItem = NULL; + } + + /* Are we looking for the session object? */ + if (!strcmpW(szSession, pstrName)) { + if (dwReturnMask & SCRIPTINFO_ITYPEINFO) + return LoadTypeInfo((IDispatch *)This->session, ppti, &DIID_Session, 0); + else if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + IDispatch_QueryInterface((IDispatch *)This->session, &IID_IUnknown, (void **)ppiunkItem); + return S_OK; + } + } + + return TYPE_E_ELEMENTNOTFOUND; +} + +static HRESULT WINAPI MsiActiveScriptSite_GetDocVersionString(IActiveScriptSite* iface, BSTR* pbstrVersion) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub\n", This, iface, pbstrVersion); + return E_NOTIMPL; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnScriptTerminate(IActiveScriptSite* iface, const VARIANT* pvarResult, const EXCEPINFO* pexcepinfo) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%p) stub\n", This, iface, pvarResult, pexcepinfo); + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnStateChange(IActiveScriptSite* iface, SCRIPTSTATE ssScriptState) +{ + switch (ssScriptState) { + case SCRIPTSTATE_UNINITIALIZED: + TRACE("State: Uninitialized.\n"); + break; + + case SCRIPTSTATE_INITIALIZED: + TRACE("State: Initialized.\n"); + break; + + case SCRIPTSTATE_STARTED: + TRACE("State: Started.\n"); + break; + + case SCRIPTSTATE_CONNECTED: + TRACE("State: Connected.\n"); + break; + + case SCRIPTSTATE_DISCONNECTED: + TRACE("State: Disconnected.\n"); + break; + + case SCRIPTSTATE_CLOSED: + TRACE("State: Closed.\n"); + break; + + default: + ERR("Unknown State: %d\n", ssScriptState); + break; + } + + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnScriptError(IActiveScriptSite* iface, IActiveScriptError* pscripterror) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + EXCEPINFO exception; + HRESULT hr; + + TRACE("(%p/%p)->(%p)\n", This, iface, pscripterror); + + hr = IActiveScriptError_GetExceptionInfo(pscripterror, &exception); + if (SUCCEEDED(hr)) + ERR("script error: %s\n", debugstr_w(exception.bstrDescription)); + + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnEnterScript(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnLeaveScript(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static const struct IActiveScriptSiteVtbl ASS_Vtbl = +{ + MsiActiveScriptSite_QueryInterface, + MsiActiveScriptSite_AddRef, + MsiActiveScriptSite_Release, + MsiActiveScriptSite_GetLCID, + MsiActiveScriptSite_GetItemInfo, + MsiActiveScriptSite_GetDocVersionString, + MsiActiveScriptSite_OnScriptTerminate, + MsiActiveScriptSite_OnStateChange, + MsiActiveScriptSite_OnScriptError, + MsiActiveScriptSite_OnEnterScript, + MsiActiveScriptSite_OnLeaveScript +}; + -- 1.4.1 From eric.pouech at wanadoo.fr Sat Feb 24 02:41:10 2007 From: eric.pouech at wanadoo.fr (Eric Pouech) Date: Sat Feb 24 13:21:51 2007 Subject: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it. In-Reply-To: <45D9F8CB.1030109@wanadoo.fr> References: <45D9BED7.2020204@codeweavers.com> <45D9CF32.1040100@wanadoo.fr> <45D9D19C.6070701@codeweavers.com> <45D9F8CB.1030109@wanadoo.fr> Message-ID: <45DFFA26.6030706@wanadoo.fr> Eric Pouech a ?crit : > Robert Shearman a ?crit : >> Eric Pouech wrote: >>> Robert Shearman a ?crit : >>>> >>>> Keep the debuglink elf_file_map mapped until after >>>> elf_new_public_symbols is called, otherwise we could use unmapped >>>> memory. >>> >>> this is still not the full valid solution... what should be done is: >>> when we search for a given section, we should look first in the >>> original .so, then, if not found, in the .gnu_debuglink one... >>> your patch only covers the case where all relevant information is to >>> be found in the .gnu_debuglink file, which is not guaranteed >> >> And that should be easier for an interested person to do after this >> patch is applied, right? I was just interested in getting rid of >> bogus crc errors when using winedbg. >> > first, it's not exactly what your patch is entirely about... your > patch ensures that the newly .gnu_debuglink mapped file is present for > symbols resolution... and the bogus CRC errors come from the fact that > we have an ERR for that, were it should be a WARN... a user could have > different versions of the debug info files > secondly, the correct fix will require a rewrite of the mapping > algorithm itself, which is rather orthogonal to what you did > my reco would simply to downgrade the ERR to a WARN if you don't want > to go into the full fix > A+ > Rob, Peter as you both were looking for solution to public symbols hashing in .gnu_link files, the attached patches should fix it could you test them to ensure that they really fix it ? (order to apply patches: 1/ dbghelp-elf-map, 2/ dbghelp-elf-alternate, 3/ dbghelp-elf-link-alternate) A+ -------------- next part -------------- [DbgHelp]: allowed to add an alternate file_map for an ELF file (where to From: Eric Pouech look for its debug information) --- dlls/dbghelp/elf_module.c | 37 ++++++++++++++++++++++++------------- 1 files changed, 24 insertions(+), 13 deletions(-) diff --git a/dlls/dbghelp/elf_module.c b/dlls/dbghelp/elf_module.c index b0cc90c..41a37f9 100644 --- a/dlls/dbghelp/elf_module.c +++ b/dlls/dbghelp/elf_module.c @@ -115,6 +115,7 @@ struct elf_file_map unsigned with_crc; unsigned long crc; const char* shstrtab; + struct elf_file_map* alternate; /* another ELF file (linked to this one) */ }; struct elf_section_map @@ -167,6 +168,7 @@ static const char* elf_map_section(struc * elf_find_section * * Finds a section by name (and type) into memory from an ELF file + * or its alternate if any */ static BOOL elf_find_section(struct elf_file_map* fmap, const char* name, unsigned sht, struct elf_section_map* esm) @@ -179,15 +181,19 @@ static BOOL elf_find_section(struct elf_ fmap->shstrtab = elf_map_section(&hdr_esm); if (fmap->shstrtab == ELF_NO_MAP) return FALSE; } - for (i = 0; i < fmap->elfhdr.e_shnum; i++) + while (fmap) { - if (strcmp(fmap->shstrtab + fmap->sect[i].shdr.sh_name, name) == 0 && - (sht == SHT_NULL || sht == fmap->sect[i].shdr.sh_type)) + for (i = 0; i < fmap->elfhdr.e_shnum; i++) { - esm->fmap = fmap; - esm->sidx = i; - return TRUE; + if (strcmp(fmap->shstrtab + fmap->sect[i].shdr.sh_name, name) == 0 && + (sht == SHT_NULL || sht == fmap->sect[i].shdr.sh_type)) + { + esm->fmap = fmap; + esm->sidx = i; + return TRUE; + } } + fmap = fmap->alternate; } return FALSE; } @@ -257,6 +263,7 @@ static BOOL elf_map_file(const WCHAR* fi fmap->fd = -1; fmap->with_crc = 0; fmap->shstrtab = ELF_NO_MAP; + fmap->alternate = NULL; /* check that the file exists, and that the module hasn't been loaded yet */ if (stat(filename, &statbuf) == -1 || S_ISDIR(statbuf.st_mode)) goto done; @@ -312,16 +319,20 @@ done: */ static void elf_unmap_file(struct elf_file_map* fmap) { - if (fmap->fd != -1) + while (fmap) { - struct elf_section_map esm; - esm.fmap = fmap; - for (esm.sidx = 0; esm.sidx < fmap->elfhdr.e_shnum; esm.sidx++) + if (fmap->fd != -1) { - elf_unmap_section(&esm); + struct elf_section_map esm; + esm.fmap = fmap; + for (esm.sidx = 0; esm.sidx < fmap->elfhdr.e_shnum; esm.sidx++) + { + elf_unmap_section(&esm); + } + HeapFree(GetProcessHeap(), 0, fmap->sect); + close(fmap->fd); } - HeapFree(GetProcessHeap(), 0, fmap->sect); - close(fmap->fd); + fmap = fmap->alternate; } } -------------- next part -------------- [DbgHelp]: now handling the .gnu_debuglink files with the newly added From: Eric Pouech alternate mechanism --- dlls/dbghelp/elf_module.c | 118 +++++++++++++++++++-------------------------- 1 files changed, 51 insertions(+), 67 deletions(-) diff --git a/dlls/dbghelp/elf_module.c b/dlls/dbghelp/elf_module.c index 41a37f9..4c5e53a 100644 --- a/dlls/dbghelp/elf_module.c +++ b/dlls/dbghelp/elf_module.c @@ -112,8 +112,6 @@ struct elf_file_map const char* mapped; }* sect; int fd; - unsigned with_crc; - unsigned long crc; const char* shstrtab; struct elf_file_map* alternate; /* another ELF file (linked to this one) */ }; @@ -261,7 +259,6 @@ static BOOL elf_map_file(const WCHAR* fi WideCharToMultiByte(CP_UNIXCP, 0, filenameW, -1, filename, len, NULL, NULL); fmap->fd = -1; - fmap->with_crc = 0; fmap->shstrtab = ELF_NO_MAP; fmap->alternate = NULL; @@ -851,10 +848,18 @@ #define UPDC32(octet,crc) (crc_32_tab[(( #undef UPDC32 } -static BOOL elf_load_debug_info_from_map(struct module* module, - struct elf_file_map* fmap, - struct pool* pool, - struct hash_table* ht_symtab); +static BOOL elf_check_debug_link(const WCHAR* file, struct elf_file_map* fmap, DWORD crc) +{ + BOOL ret; + if (!elf_map_file(file, fmap)) return FALSE; + if (!(ret = crc == calc_crc32(fmap))) + { + WARN("Bad CRC for file %s (got %08x while expecting %08x)\n", + debugstr_w(file), calc_crc32(fmap), crc); + elf_unmap_file(fmap); + } + return ret; +} /****************************************************************** * elf_locate_debug_link @@ -875,20 +880,24 @@ static BOOL elf_load_debug_info_from_map * is the global debug file directory, and execdir has been turned * into a relative path)." (from GDB manual) */ -static WCHAR* elf_locate_debug_link(const char* filename, const WCHAR* loaded_file, - struct elf_file_map* fmap_link) +static BOOL elf_locate_debug_link(struct elf_file_map* fmap, const char* filename, + const WCHAR* loaded_file, DWORD crc) { static const WCHAR globalDebugDirW[] = {'/','u','s','r','/','l','i','b','/','d','e','b','u','g','/'}; static const WCHAR dotDebugW[] = {'.','d','e','b','u','g','/'}; const size_t globalDebugDirLen = sizeof(globalDebugDirW) / sizeof(WCHAR); size_t filename_len; - WCHAR* p; + WCHAR* p = NULL; WCHAR* slash; + struct elf_file_map* fmap_link = NULL; + + fmap_link = HeapAlloc(GetProcessHeap(), 0, sizeof(*fmap_link)); + if (!fmap_link) return FALSE; filename_len = MultiByteToWideChar(CP_UNIXCP, 0, filename, -1, NULL, 0); p = HeapAlloc(GetProcessHeap(), 0, (globalDebugDirLen + strlenW(loaded_file) + 6 + 1 + filename_len + 1) * sizeof(WCHAR)); - if (!p) return FALSE; + if (!p) goto found; /* we prebuild the string with "execdir" */ strcpyW(p, loaded_file); @@ -897,33 +906,34 @@ static WCHAR* elf_locate_debug_link(cons /* testing execdir/filename */ MultiByteToWideChar(CP_UNIXCP, 0, filename, -1, slash, filename_len); - if (elf_map_file(p, fmap_link)) goto found; - - HeapValidate(GetProcessHeap(), 0, 0); + if (elf_check_debug_link(p, fmap_link, crc)) goto found; /* testing execdir/.debug/filename */ memcpy(slash, dotDebugW, sizeof(dotDebugW)); MultiByteToWideChar(CP_UNIXCP, 0, filename, -1, slash + sizeof(dotDebugW) / sizeof(WCHAR), filename_len); - if (elf_map_file(p, fmap_link)) goto found; + if (elf_check_debug_link(p, fmap_link, crc)) goto found; /* testing globaldebugdir/execdir/filename */ memmove(p + globalDebugDirLen, p, (slash - p) * sizeof(WCHAR)); memcpy(p, globalDebugDirW, globalDebugDirLen * sizeof(WCHAR)); slash += globalDebugDirLen; MultiByteToWideChar(CP_UNIXCP, 0, filename, -1, slash, filename_len); - if (elf_map_file(p, fmap_link)) goto found; + if (elf_check_debug_link(p, fmap_link, crc)) goto found; /* finally testing filename */ - if (elf_map_file(slash, fmap_link)) goto found; + if (elf_check_debug_link(slash, fmap_link, crc)) goto found; - HeapFree(GetProcessHeap(), 0, p); WARN("Couldn't locate or map %s\n", filename); - return NULL; + HeapFree(GetProcessHeap(), 0, p); + HeapFree(GetProcessHeap(), 0, fmap_link); + return FALSE; found: TRACE("Located debug information file %s at %s\n", filename, debugstr_w(p)); - return p; + HeapFree(GetProcessHeap(), 0, p); + fmap->alternate = fmap_link; + return TRUE; } /****************************************************************** @@ -932,10 +942,8 @@ found: * Parses a .gnu_debuglink section and loads the debug info from * the external file specified there. */ -static BOOL elf_debuglink_parse (struct module* module, - struct pool* pool, - struct hash_table* ht_symtab, - const BYTE* debuglink) +static BOOL elf_debuglink_parse(struct elf_file_map* fmap, struct module* module, + const BYTE* debuglink) { /* The content of a debug link section is: * 1/ a NULL terminated string, containing the file name for the @@ -943,28 +951,11 @@ static BOOL elf_debuglink_parse (struct * 2/ padding on 4 byte boundary * 3/ CRC of the linked ELF file */ - BOOL ret = FALSE; const char* dbg_link = (char*)debuglink; - struct elf_file_map fmap_link; - WCHAR* link_file; + DWORD crc; - link_file = elf_locate_debug_link(dbg_link, module->module.LoadedImageName, &fmap_link); - - if (link_file) - { - fmap_link.crc = *(const DWORD*)(dbg_link + ((DWORD_PTR)(strlen(dbg_link) + 4) & ~3)); - fmap_link.with_crc = 1; - ret = elf_load_debug_info_from_map(module, &fmap_link, pool, - ht_symtab); - if (ret) - strcpyW(module->module.LoadedPdbName,link_file); - else - WARN("Couldn't load debug information from %s\n", debugstr_w(link_file)); - elf_unmap_file(&fmap_link); - HeapFree(GetProcessHeap(), 0, link_file); - } - - return ret; + crc = *(const DWORD*)(dbg_link + ((DWORD_PTR)(strlen(dbg_link) + 4) & ~3)); + return elf_locate_debug_link(fmap, dbg_link, module->module.LoadedImageName, crc); } /****************************************************************** @@ -997,14 +988,6 @@ static BOOL elf_load_debug_info_from_map {NULL, 0, 0, 0} }; - if (fmap->with_crc && (fmap->crc != calc_crc32(fmap))) - { - ERR("Bad CRC for module %s (got %08x while expecting %08lx)\n", - debugstr_w(module->module.LoadedImageName), calc_crc32(fmap), fmap->crc); - /* we don't tolerate mis-matched files */ - return FALSE; - } - module->module.SymType = SymExport; /* create a hash table for the symtab */ @@ -1017,6 +1000,22 @@ static BOOL elf_load_debug_info_from_map debug_line_sect, debug_loclist_sect; struct elf_section_map debuglink_sect; + /* if present, add the .gnu_debuglink file as an alternate to current one */ + if (elf_find_section(fmap, ".gnu_debuglink", SHT_NULL, &debuglink_sect)) + { + const BYTE* dbg_link; + + dbg_link = (const BYTE*)elf_map_section(&debuglink_sect); + if (dbg_link != ELF_NO_MAP) + { + lret = elf_debuglink_parse(fmap, module, dbg_link); + if (!lret) + WARN("Couldn't load linked debug file for %s\n", + debugstr_w(module->module.ModuleName)); + ret = ret || lret; + } + elf_unmap_section(&debuglink_sect); + } if (elf_find_section(fmap, ".stab", SHT_NULL, &stab_sect) && elf_find_section(fmap, ".stabstr", SHT_NULL, &stabstr_sect)) { @@ -1083,21 +1082,6 @@ static BOOL elf_load_debug_info_from_map elf_unmap_section(&debug_line_sect); elf_unmap_section(&debug_loclist_sect); } - if (elf_find_section(fmap, ".gnu_debuglink", SHT_NULL, &debuglink_sect)) - { - const BYTE* dbg_link; - - dbg_link = (const BYTE*)elf_map_section(&debuglink_sect); - if (dbg_link != ELF_NO_MAP) - { - lret = elf_debuglink_parse(module, pool, ht_symtab, dbg_link); - if (!lret) - WARN("Couldn't load linked debug file for %s\n", - debugstr_w(module->module.ModuleName)); - ret = ret || lret; - } - elf_unmap_section(&debuglink_sect); - } } if (strstrW(module->module.ModuleName, S_ElfW) || !strcmpW(module->module.ModuleName, S_WineLoaderW)) -------------- next part -------------- [DbgHelp]: rewrote the ELF section mapper for better data encapsulation From: Eric Pouech --- dlls/dbghelp/elf_module.c | 273 +++++++++++++++++++++++---------------------- 1 files changed, 137 insertions(+), 136 deletions(-) diff --git a/dlls/dbghelp/elf_module.c b/dlls/dbghelp/elf_module.c index 7758199..b0cc90c 100644 --- a/dlls/dbghelp/elf_module.c +++ b/dlls/dbghelp/elf_module.c @@ -114,6 +114,13 @@ struct elf_file_map int fd; unsigned with_crc; unsigned long crc; + const char* shstrtab; +}; + +struct elf_section_map +{ + struct elf_file_map* fmap; + unsigned sidx; }; struct symtab_elt @@ -137,21 +144,52 @@ struct elf_thunk_area * * Maps a single section into memory from an ELF file */ -static const char* elf_map_section(struct elf_file_map* fmap, int sidx) +static const char* elf_map_section(struct elf_section_map* esm) { unsigned pgsz = getpagesize(); unsigned ofst, size; - if (sidx < 0 || sidx >= fmap->elfhdr.e_shnum || - fmap->sect[sidx].shdr.sh_type == SHT_NOBITS) + if (esm->sidx < 0 || esm->sidx >= esm->fmap->elfhdr.e_shnum || + esm->fmap->sect[esm->sidx].shdr.sh_type == SHT_NOBITS) return ELF_NO_MAP; + /* align required information on page size (we assume pagesize is a power of 2) */ - ofst = fmap->sect[sidx].shdr.sh_offset & ~(pgsz - 1); - size = ((fmap->sect[sidx].shdr.sh_offset + - fmap->sect[sidx].shdr.sh_size + pgsz - 1) & ~(pgsz - 1)) - ofst; - fmap->sect[sidx].mapped = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fmap->fd, ofst); - if (fmap->sect[sidx].mapped == ELF_NO_MAP) return ELF_NO_MAP; - return fmap->sect[sidx].mapped + (fmap->sect[sidx].shdr.sh_offset & (pgsz - 1)); + ofst = esm->fmap->sect[esm->sidx].shdr.sh_offset & ~(pgsz - 1); + size = ((esm->fmap->sect[esm->sidx].shdr.sh_offset + + esm->fmap->sect[esm->sidx].shdr.sh_size + pgsz - 1) & ~(pgsz - 1)) - ofst; + esm->fmap->sect[esm->sidx].mapped = mmap(NULL, size, PROT_READ, MAP_PRIVATE, + esm->fmap->fd, ofst); + if (esm->fmap->sect[esm->sidx].mapped == ELF_NO_MAP) return ELF_NO_MAP; + return esm->fmap->sect[esm->sidx].mapped + (esm->fmap->sect[esm->sidx].shdr.sh_offset & (pgsz - 1)); +} + +/****************************************************************** + * elf_find_section + * + * Finds a section by name (and type) into memory from an ELF file + */ +static BOOL elf_find_section(struct elf_file_map* fmap, const char* name, + unsigned sht, struct elf_section_map* esm) +{ + unsigned i; + + if (fmap->shstrtab == ELF_NO_MAP) + { + struct elf_section_map hdr_esm = {fmap, fmap->elfhdr.e_shstrndx}; + fmap->shstrtab = elf_map_section(&hdr_esm); + if (fmap->shstrtab == ELF_NO_MAP) return FALSE; + } + for (i = 0; i < fmap->elfhdr.e_shnum; i++) + { + if (strcmp(fmap->shstrtab + fmap->sect[i].shdr.sh_name, name) == 0 && + (sht == SHT_NULL || sht == fmap->sect[i].shdr.sh_type)) + { + esm->fmap = fmap; + esm->sidx = i; + return TRUE; + } + } + return FALSE; } /****************************************************************** @@ -159,32 +197,41 @@ static const char* elf_map_section(struc * * Unmaps a single section from memory */ -static void elf_unmap_section(struct elf_file_map* fmap, int sidx) +static void elf_unmap_section(struct elf_section_map* esm) { - if (sidx >= 0 && sidx < fmap->elfhdr.e_shnum && fmap->sect[sidx].mapped != ELF_NO_MAP) + if (esm->sidx >= 0 && esm->sidx < esm->fmap->elfhdr.e_shnum && esm->fmap->sect[esm->sidx].mapped != ELF_NO_MAP) { unsigned pgsz = getpagesize(); unsigned ofst, size; - ofst = fmap->sect[sidx].shdr.sh_offset & ~(pgsz - 1); - size = ((fmap->sect[sidx].shdr.sh_offset + - fmap->sect[sidx].shdr.sh_size + pgsz - 1) & ~(pgsz - 1)) - ofst; - if (munmap((char*)fmap->sect[sidx].mapped, size) < 0) + ofst = esm->fmap->sect[esm->sidx].shdr.sh_offset & ~(pgsz - 1); + size = ((esm->fmap->sect[esm->sidx].shdr.sh_offset + + esm->fmap->sect[esm->sidx].shdr.sh_size + pgsz - 1) & ~(pgsz - 1)) - ofst; + if (munmap((char*)esm->fmap->sect[esm->sidx].mapped, size) < 0) WARN("Couldn't unmap the section\n"); - fmap->sect[sidx].mapped = ELF_NO_MAP; + esm->fmap->sect[esm->sidx].mapped = ELF_NO_MAP; } } +static void elf_end_find(struct elf_file_map* fmap) +{ + struct elf_section_map esm; + + esm.fmap = fmap; esm.sidx = fmap->elfhdr.e_shstrndx; + elf_unmap_section(&esm); + fmap->shstrtab = ELF_NO_MAP; +} + /****************************************************************** * elf_get_map_size * * Get the size of an ELF section */ -static inline unsigned elf_get_map_size(struct elf_file_map* fmap, int sidx) +static inline unsigned elf_get_map_size(struct elf_section_map* esm) { - if (sidx < 0 || sidx >= fmap->elfhdr.e_shnum) + if (esm->sidx < 0 || esm->sidx >= esm->fmap->elfhdr.e_shnum) return 0; - return fmap->sect[sidx].shdr.sh_size; + return esm->fmap->sect[esm->sidx].shdr.sh_size; } /****************************************************************** @@ -209,6 +256,7 @@ static BOOL elf_map_file(const WCHAR* fi fmap->fd = -1; fmap->with_crc = 0; + fmap->shstrtab = ELF_NO_MAP; /* check that the file exists, and that the module hasn't been loaded yet */ if (stat(filename, &statbuf) == -1 || S_ISDIR(statbuf.st_mode)) goto done; @@ -266,10 +314,11 @@ static void elf_unmap_file(struct elf_fi { if (fmap->fd != -1) { - int i; - for (i = 0; i < fmap->elfhdr.e_shnum; i++) + struct elf_section_map esm; + esm.fmap = fmap; + for (esm.sidx = 0; esm.sidx < fmap->elfhdr.e_shnum; esm.sidx++) { - elf_unmap_section(fmap, i); + elf_unmap_section(&esm); } HeapFree(GetProcessHeap(), 0, fmap->sect); close(fmap->fd); @@ -302,7 +351,7 @@ int elf_is_in_thunk_area(unsigned long a */ static void elf_hash_symtab(struct module* module, struct pool* pool, struct hash_table* ht_symtab, struct elf_file_map* fmap, - int symtab_idx, struct elf_thunk_area* thunks) + struct elf_thunk_area* thunks) { int i, j, nsym; const char* strp; @@ -311,12 +360,16 @@ static void elf_hash_symtab(struct modul const char* ptr; const Elf32_Sym* symp; struct symtab_elt* ste; + struct elf_section_map esm, esm_str; - symp = (const Elf32_Sym*)elf_map_section(fmap, symtab_idx); - strp = elf_map_section(fmap, fmap->sect[symtab_idx].shdr.sh_link); - if (symp == ELF_NO_MAP || strp == ELF_NO_MAP) return; + if (!elf_find_section(fmap, ".symtab", SHT_SYMTAB, &esm) && + !elf_find_section(fmap, ".dynsym", SHT_DYNSYM, &esm)) return; + if ((symp = (const Elf32_Sym*)elf_map_section(&esm)) == ELF_NO_MAP) return; + esm_str.fmap = fmap; + esm_str.sidx = fmap->sect[esm.sidx].shdr.sh_link; + if ((strp = elf_map_section(&esm_str)) == ELF_NO_MAP) return; - nsym = elf_get_map_size(fmap, symtab_idx) / sizeof(*symp); + nsym = elf_get_map_size(&esm) / sizeof(*symp); for (j = 0; thunks[j].symname; j++) thunks[j].rva_start = thunks[j].rva_end = 0; @@ -922,12 +975,6 @@ static BOOL elf_load_debug_info_from_map struct hash_table* ht_symtab) { BOOL ret = FALSE, lret; - const char* shstrtab; - int i; - int symtab_sect, dynsym_sect, stab_sect, stabstr_sect; - int debug_sect, debug_str_sect, debug_abbrev_sect; - int debug_line_sect, debug_loclist_sect; - int debuglink_sect; struct elf_thunk_area thunks[] = { {"__wine_spec_import_thunks", THUNK_ORDINAL_NOTYPE, 0, 0}, /* inter DLL calls */ @@ -947,77 +994,32 @@ static BOOL elf_load_debug_info_from_map return FALSE; } - /* - * Next, we need to find a few of the internal ELF headers within - * this thing. We need the main executable header, and the section - * table. - */ - shstrtab = elf_map_section(fmap, fmap->elfhdr.e_shstrndx); - if (shstrtab == ELF_NO_MAP) return FALSE; - - symtab_sect = dynsym_sect = stab_sect = stabstr_sect = -1; - debug_sect = debug_str_sect = debug_abbrev_sect = -1; - debug_line_sect = debug_loclist_sect = -1; - debuglink_sect = -1; - - for (i = 0; i < fmap->elfhdr.e_shnum; i++) - { - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".stab") == 0) - stab_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".stabstr") == 0) - stabstr_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".debug_info") == 0) - debug_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".debug_str") == 0) - debug_str_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".debug_abbrev") == 0) - debug_abbrev_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".debug_line") == 0) - debug_line_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".debug_loc") == 0) - debug_loclist_sect = i; - if (strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".gnu_debuglink") == 0) - debuglink_sect = i; - if ((strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".symtab") == 0) && - (fmap->sect[i].shdr.sh_type == SHT_SYMTAB)) - symtab_sect = i; - if ((strcmp(shstrtab + fmap->sect[i].shdr.sh_name, ".dynsym") == 0) && - (fmap->sect[i].shdr.sh_type == SHT_DYNSYM)) - dynsym_sect = i; - } - elf_unmap_section(fmap, fmap->elfhdr.e_shstrndx); - shstrtab = NULL; - - if (symtab_sect == -1) - { - /* if we don't have a symtab but a dynsym, process the dynsym - * section instead. It'll contain less (relevant) information, - * but it'll be better than nothing - */ - if (dynsym_sect == -1) return FALSE; - symtab_sect = dynsym_sect; - } - module->module.SymType = SymExport; /* create a hash table for the symtab */ - elf_hash_symtab(module, pool, ht_symtab, fmap, symtab_sect, thunks); + elf_hash_symtab(module, pool, ht_symtab, fmap, thunks); if (!(dbghelp_options & SYMOPT_PUBLICS_ONLY)) { - if (stab_sect != -1 && stabstr_sect != -1) + struct elf_section_map stab_sect, stabstr_sect; + struct elf_section_map debug_sect, debug_str_sect, debug_abbrev_sect, + debug_line_sect, debug_loclist_sect; + struct elf_section_map debuglink_sect; + + if (elf_find_section(fmap, ".stab", SHT_NULL, &stab_sect) && + elf_find_section(fmap, ".stabstr", SHT_NULL, &stabstr_sect)) { const char* stab; const char* stabstr; - stab = elf_map_section(fmap, stab_sect); - stabstr = elf_map_section(fmap, stabstr_sect); + stab = elf_map_section(&stab_sect); + stabstr = elf_map_section(&stabstr_sect); if (stab != ELF_NO_MAP && stabstr != ELF_NO_MAP) { /* OK, now just parse all of the stabs. */ lret = stabs_parse(module, module->elf_info->elf_addr, - stab, elf_get_map_size(fmap, stab_sect), - stabstr, elf_get_map_size(fmap, stabstr_sect)); + stab, elf_get_map_size(&stab_sect), + stabstr, elf_get_map_size(&stabstr_sect)); if (lret) /* and fill in the missing information for stabs */ elf_finish_stabs_info(module, ht_symtab); @@ -1026,11 +1028,10 @@ static BOOL elf_load_debug_info_from_map ret = ret || lret; } else lret = FALSE; - elf_unmap_section(fmap, stab_sect); - elf_unmap_section(fmap, stabstr_sect); - + elf_unmap_section(&stab_sect); + elf_unmap_section(&stabstr_sect); } - if (debug_sect != -1) + if (elf_find_section(fmap, ".debug_info", SHT_NULL, &debug_sect)) { /* Dwarf 2 debug information */ const BYTE* dw2_debug; @@ -1041,36 +1042,41 @@ static BOOL elf_load_debug_info_from_map TRACE("Loading Dwarf2 information for %s\n", module->module_name); - dw2_debug = (const BYTE*) elf_map_section(fmap, debug_sect); - dw2_debug_abbrev = (const BYTE*) elf_map_section(fmap, debug_abbrev_sect); - dw2_debug_str = (const BYTE*) elf_map_section(fmap, debug_str_sect); - dw2_debug_line = (const BYTE*) elf_map_section(fmap, debug_line_sect); - dw2_debug_loclist = (const BYTE*) elf_map_section(fmap, debug_loclist_sect); + elf_find_section(fmap, ".debug_str", SHT_NULL, &debug_str_sect); + elf_find_section(fmap, ".debug_abbrev", SHT_NULL, &debug_abbrev_sect); + elf_find_section(fmap, ".debug_line", SHT_NULL, &debug_line_sect); + elf_find_section(fmap, ".debug_loc", SHT_NULL, &debug_loclist_sect); + + dw2_debug = (const BYTE*)elf_map_section(&debug_sect); + dw2_debug_abbrev = (const BYTE*)elf_map_section(&debug_abbrev_sect); + dw2_debug_str = (const BYTE*)elf_map_section(&debug_str_sect); + dw2_debug_line = (const BYTE*)elf_map_section(&debug_line_sect); + dw2_debug_loclist = (const BYTE*)elf_map_section(&debug_loclist_sect); if (dw2_debug != ELF_NO_MAP && dw2_debug_abbrev != ELF_NO_MAP && dw2_debug_str != ELF_NO_MAP) { /* OK, now just parse dwarf2 debug infos. */ lret = dwarf2_parse(module, module->elf_info->elf_addr, thunks, - dw2_debug, elf_get_map_size(fmap, debug_sect), - dw2_debug_abbrev, elf_get_map_size(fmap, debug_abbrev_sect), - dw2_debug_str, elf_get_map_size(fmap, debug_str_sect), - dw2_debug_line, elf_get_map_size(fmap, debug_line_sect), - dw2_debug_loclist, elf_get_map_size(fmap, debug_loclist_sect)); + dw2_debug, elf_get_map_size(&debug_sect), + dw2_debug_abbrev, elf_get_map_size(&debug_abbrev_sect), + dw2_debug_str, elf_get_map_size(&debug_str_sect), + dw2_debug_line, elf_get_map_size(&debug_line_sect), + dw2_debug_loclist, elf_get_map_size(&debug_loclist_sect)); if (!lret) WARN("Couldn't correctly read stabs\n"); ret = ret || lret; } - elf_unmap_section(fmap, debug_sect); - elf_unmap_section(fmap, debug_abbrev_sect); - elf_unmap_section(fmap, debug_str_sect); - elf_unmap_section(fmap, debug_line_sect); - elf_unmap_section(fmap, debug_loclist_sect); + elf_unmap_section(&debug_sect); + elf_unmap_section(&debug_abbrev_sect); + elf_unmap_section(&debug_str_sect); + elf_unmap_section(&debug_line_sect); + elf_unmap_section(&debug_loclist_sect); } - if (debuglink_sect != -1) + if (elf_find_section(fmap, ".gnu_debuglink", SHT_NULL, &debuglink_sect)) { const BYTE* dbg_link; - dbg_link = (const BYTE*) elf_map_section(fmap, debuglink_sect); + dbg_link = (const BYTE*)elf_map_section(&debuglink_sect); if (dbg_link != ELF_NO_MAP) { lret = elf_debuglink_parse(module, pool, ht_symtab, dbg_link); @@ -1079,7 +1085,7 @@ static BOOL elf_load_debug_info_from_map debugstr_w(module->module.ModuleName)); ret = ret || lret; } - elf_unmap_section(fmap, debuglink_sect); + elf_unmap_section(&debuglink_sect); } } if (strstrW(module->module.ModuleName, S_ElfW) || @@ -1163,7 +1169,6 @@ static BOOL elf_load_file(struct process { BOOL ret = FALSE; struct elf_file_map fmap; - int i; TRACE("Processing elf file '%s' at %08lx\n", debugstr_w(filename), load_offset); @@ -1185,33 +1190,29 @@ static BOOL elf_load_file(struct process if (elf_info->flags & ELF_INFO_DEBUG_HEADER) { - const char* shstrtab = elf_map_section(&fmap, fmap.elfhdr.e_shstrndx); - if (shstrtab == ELF_NO_MAP) goto leave; - for (i = 0; i < fmap.elfhdr.e_shnum; i++) + struct elf_section_map esm; + + if (elf_find_section(&fmap, ".dynamic", SHT_DYNAMIC, &esm)) { - if (strcmp(shstrtab + fmap.sect[i].shdr.sh_name, ".dynamic") == 0 && - fmap.sect[i].shdr.sh_type == SHT_DYNAMIC) - { - Elf32_Dyn dyn; - char* ptr = (char*)fmap.sect[i].shdr.sh_addr; - unsigned long len; + Elf32_Dyn dyn; + char* ptr = (char*)fmap.sect[esm.sidx].shdr.sh_addr; + unsigned long len; - do + do + { + if (!ReadProcessMemory(pcs->handle, ptr, &dyn, sizeof(dyn), &len) || + len != sizeof(dyn)) + goto leave; + if (dyn.d_tag == DT_DEBUG) { - if (!ReadProcessMemory(pcs->handle, ptr, &dyn, sizeof(dyn), &len) || - len != sizeof(dyn)) - goto leave; - if (dyn.d_tag == DT_DEBUG) - { - elf_info->dbg_hdr_addr = dyn.d_un.d_ptr; - break; - } - ptr += sizeof(dyn); - } while (dyn.d_tag != DT_NULL); - if (dyn.d_tag == DT_NULL) goto leave; - } + elf_info->dbg_hdr_addr = dyn.d_un.d_ptr; + break; + } + ptr += sizeof(dyn); + } while (dyn.d_tag != DT_NULL); + if (dyn.d_tag == DT_NULL) goto leave; } - elf_unmap_section(&fmap, fmap.elfhdr.e_shstrndx); + elf_end_find(&fmap); } if (elf_info->flags & ELF_INFO_MODULE) -------------- next part -------------- # This series applies on GIT commit a52c2c0dfe3deaa872fe10c751447844e73dcdef dbghelp-elf-map dbghelp-elf-alternate dbghelp-elf-link-alternate From saulius.krasuckas at ieee.org Sat Feb 24 06:15:29 2007 From: saulius.krasuckas at ieee.org (Saulius Krasuckas) Date: Sat Feb 24 13:21:52 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. Message-ID: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> This long line breaks automated rebasing of one of testing branches on (namely ntoskrnl) on my box every time a new dll or program is added. That's because I need to merge conflict for this line by my hand. And I am not sure what stops us from keeping "ac_config_files" list multiline, so merging in future could be automatical. --- configure | 326 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 325 insertions(+), 1 deletions(-) diff --git a/configure b/configure index fb9c11f..67f1942 100755 --- a/configure +++ b/configure @@ -20427,7 +20427,331 @@ MAKE_TEST_RULES=dlls/Maketest.rules MAKE_PROG_RULES=programs/Makeprog.rules -ac_config_files="$ac_config_files Make.rules dlls/Makedll.rules dlls/Makeimplib.rules dlls/Maketest.rules programs/Makeprog.rules Makefile dlls/Makefile dlls/activeds/Makefile dlls/advapi32/Makefile dlls/advapi32/tests/Makefile dlls/advpack/Makefile dlls/advpack/tests/Makefile dlls/amstream/Makefile dlls/atl/Makefile dlls/avicap32/Makefile dlls/avifil32/Makefile dlls/browseui/Makefile dlls/browseui/tests/Makefile dlls/cabinet/Makefile dlls/cabinet/tests/Makefile dlls/capi2032/Makefile dlls/cards/Makefile dlls/cfgmgr32/Makefile dlls/clusapi/Makefile dlls/comcat/Makefile dlls/comcat/tests/Makefile dlls/comctl32/Makefile dlls/comctl32/tests/Makefile dlls/comdlg32/Makefile dlls/comdlg32/tests/Makefile dlls/compstui/Makefile dlls/credui/Makefile dlls/crtdll/Makefile dlls/crypt32/Makefile dlls/crypt32/tests/Makefile dlls/cryptdll/Makefile dlls/cryptnet/Makefile dlls/ctl3d32/Makefile dlls/d3d8/Makefile dlls/d3d8/tests/Makefile dlls/d3d9/Makefile dlls/d3d9/tests/Makefile dlls/d3dim/Makefile dlls/d3drm/Makefile dlls/d3dx8/Makefile dlls/d3dxof/Makefile dlls/dbghelp/Makefile dlls/dciman32/Makefile dlls/ddraw/Makefile dlls/ddraw/tests/Makefile dlls/ddrawex/Makefile dlls/devenum/Makefile dlls/dinput/Makefile dlls/dinput/tests/Makefile dlls/dinput8/Makefile dlls/dmband/Makefile dlls/dmcompos/Makefile dlls/dmime/Makefile dlls/dmloader/Makefile dlls/dmscript/Makefile dlls/dmstyle/Makefile dlls/dmsynth/Makefile dlls/dmusic/Makefile dlls/dmusic32/Makefile dlls/dnsapi/Makefile dlls/dnsapi/tests/Makefile dlls/dplay/Makefile dlls/dplayx/Makefile dlls/dpnet/Makefile dlls/dpnhpast/Makefile dlls/dsound/Makefile dlls/dsound/tests/Makefile dlls/dswave/Makefile dlls/dxdiagn/Makefile dlls/dxerr8/Makefile dlls/dxerr9/Makefile dlls/dxguid/Makefile dlls/gdi32/Makefile dlls/gdi32/tests/Makefile dlls/glu32/Makefile dlls/gphoto2.ds/Makefile dlls/hhctrl.ocx/Makefile dlls/hid/Makefile dlls/hlink/Makefile dlls/hlink/tests/Makefile dlls/iccvid/Makefile dlls/icmp/Makefile dlls/ifsmgr.vxd/Makefile dlls/imaadp32.acm/Makefile dlls/imagehlp/Makefile dlls/imm32/Makefile dlls/infosoft/Makefile dlls/infosoft/tests/Makefile dlls/inseng/Makefile dlls/iphlpapi/Makefile dlls/iphlpapi/tests/Makefile dlls/itss/Makefile dlls/itss/tests/Makefile dlls/kernel32/Makefile dlls/kernel32/tests/Makefile dlls/localspl/Makefile dlls/localspl/tests/Makefile dlls/lz32/Makefile dlls/lz32/tests/Makefile dlls/mapi32/Makefile dlls/mapi32/tests/Makefile dlls/mciavi32/Makefile dlls/mcicda/Makefile dlls/mciseq/Makefile dlls/mciwave/Makefile dlls/midimap/Makefile dlls/mlang/Makefile dlls/mlang/tests/Makefile dlls/mmdevldr.vxd/Makefile dlls/monodebg.vxd/Makefile dlls/mpr/Makefile dlls/mprapi/Makefile dlls/msacm32.drv/Makefile dlls/msacm32/Makefile dlls/msacm32/tests/Makefile dlls/msadp32.acm/Makefile dlls/mscms/Makefile dlls/mscms/tests/Makefile dlls/mscoree/Makefile dlls/msdmo/Makefile dlls/msftedit/Makefile dlls/msg711.acm/Makefile dlls/mshtml/Makefile dlls/mshtml/tests/Makefile dlls/msi/Makefile dlls/msi/tests/Makefile dlls/msimg32/Makefile dlls/msisys.ocx/Makefile dlls/msnet32/Makefile dlls/msrle32/Makefile dlls/msvcrt/Makefile dlls/msvcrt/tests/Makefile dlls/msvcrt20/Makefile dlls/msvcrt40/Makefile dlls/msvcrtd/Makefile dlls/msvcrtd/tests/Makefile dlls/msvfw32/Makefile dlls/msvidc32/Makefile dlls/mswsock/Makefile dlls/msxml3/Makefile dlls/msxml3/tests/Makefile dlls/nddeapi/Makefile dlls/netapi32/Makefile dlls/netapi32/tests/Makefile dlls/newdev/Makefile dlls/ntdll/Makefile dlls/ntdll/tests/Makefile dlls/ntdsapi/Makefile dlls/objsel/Makefile dlls/odbc32/Makefile dlls/odbccp32/Makefile dlls/odbccp32/tests/Makefile dlls/ole32/Makefile dlls/ole32/tests/Makefile dlls/oleacc/Makefile dlls/oleaut32/Makefile dlls/oleaut32/tests/Makefile dlls/olecli32/Makefile dlls/oledlg/Makefile dlls/olepro32/Makefile dlls/olesvr32/Makefile dlls/opengl32/Makefile dlls/powrprof/Makefile dlls/psapi/Makefile dlls/psapi/tests/Makefile dlls/pstorec/Makefile dlls/qcap/Makefile dlls/quartz/Makefile dlls/quartz/tests/Makefile dlls/query/Makefile dlls/rasapi32/Makefile dlls/resutils/Makefile dlls/riched20/Makefile dlls/riched20/tests/Makefile dlls/riched32/Makefile dlls/rpcrt4/Makefile dlls/rpcrt4/tests/Makefile dlls/rsabase/Makefile dlls/rsabase/tests/Makefile dlls/rsaenh/Makefile dlls/rsaenh/tests/Makefile dlls/sane.ds/Makefile dlls/secur32/Makefile dlls/secur32/tests/Makefile dlls/security/Makefile dlls/sensapi/Makefile dlls/serialui/Makefile dlls/serialui/tests/Makefile dlls/setupapi/Makefile dlls/setupapi/tests/Makefile dlls/sfc/Makefile dlls/sfc_os/Makefile dlls/shdoclc/Makefile dlls/shdocvw/Makefile dlls/shdocvw/tests/Makefile dlls/shell32/Makefile dlls/shell32/tests/Makefile dlls/shfolder/Makefile dlls/shlwapi/Makefile dlls/shlwapi/tests/Makefile dlls/snmpapi/Makefile dlls/snmpapi/tests/Makefile dlls/spoolss/Makefile dlls/stdole2.tlb/Makefile dlls/stdole32.tlb/Makefile dlls/sti/Makefile dlls/strmiids/Makefile dlls/svrapi/Makefile dlls/tapi32/Makefile dlls/twain_32/Makefile dlls/unicows/Makefile dlls/url/Makefile dlls/urlmon/Makefile dlls/urlmon/tests/Makefile dlls/user32/Makefile dlls/user32/tests/Makefile dlls/userenv/Makefile dlls/usp10/Makefile dlls/usp10/tests/Makefile dlls/uuid/Makefile dlls/uxtheme/Makefile dlls/uxtheme/tests/Makefile dlls/vdhcp.vxd/Makefile dlls/vdmdbg/Makefile dlls/version/Makefile dlls/version/tests/Makefile dlls/vmm.vxd/Makefile dlls/vnbt.vxd/Makefile dlls/vnetbios.vxd/Makefile dlls/vtdapi.vxd/Makefile dlls/vwin32.vxd/Makefile dlls/w32skrnl/Makefile dlls/winealsa.drv/Makefile dlls/winearts.drv/Makefile dlls/wineaudioio.drv/Makefile dlls/winecoreaudio.drv/Makefile dlls/winecrt0/Makefile dlls/wined3d/Makefile dlls/winedos/Makefile dlls/wineesd.drv/Makefile dlls/winejack.drv/Makefile dlls/winejoystick.drv/Makefile dlls/winemp3.acm/Makefile dlls/winenas.drv/Makefile dlls/wineoss.drv/Makefile dlls/wineps.drv/Makefile dlls/winequartz.drv/Makefile dlls/winex11.drv/Makefile dlls/wing32/Makefile dlls/wininet/Makefile dlls/wininet/tests/Makefile dlls/winmm/Makefile dlls/winmm/tests/Makefile dlls/winnls32/Makefile dlls/winspool.drv/Makefile dlls/winspool.drv/tests/Makefile dlls/wintab32/Makefile dlls/wintrust/Makefile dlls/wintrust/tests/Makefile dlls/wldap32/Makefile dlls/wnaspi32/Makefile dlls/wow32/Makefile dlls/ws2_32/Makefile dlls/ws2_32/tests/Makefile dlls/wsock32/Makefile dlls/wtsapi32/Makefile documentation/Makefile fonts/Makefile include/Makefile libs/Makefile libs/port/Makefile libs/wine/Makefile libs/wpp/Makefile loader/Makefile programs/Makefile programs/clock/Makefile programs/cmd/Makefile programs/cmdlgtst/Makefile programs/control/Makefile programs/eject/Makefile programs/expand/Makefile programs/explorer/Makefile programs/hh/Makefile programs/icinfo/Makefile programs/iexplore/Makefile programs/msiexec/Makefile programs/notepad/Makefile programs/oleview/Makefile programs/progman/Makefile programs/regedit/Makefile programs/regsvr32/Makefile programs/rpcss/Makefile programs/rundll32/Makefile programs/start/Makefile programs/taskmgr/Makefile programs/uninstaller/Makefile programs/view/Makefile programs/wineboot/Makefile programs/winebrowser/Makefile programs/winecfg/Makefile programs/wineconsole/Makefile programs/winedbg/Makefile programs/winefile/Makefile programs/winemenubuilder/Makefile programs/winemine/Makefile programs/winepath/Makefile programs/winetest/Makefile programs/winevdm/Makefile programs/winhelp/Makefile programs/winver/Makefile programs/wordpad/Makefile server/Makefile tools/Makefile tools/widl/Makefile tools/winebuild/Makefile tools/winedump/Makefile tools/winegcc/Makefile tools/wmc/Makefile tools/wrc/Makefile" +ac_config_files="$ac_config_files \ + Make.rules \ + dlls/Makedll.rules \ + dlls/Makeimplib.rules \ + dlls/Maketest.rules \ + programs/Makeprog.rules \ + Makefile \ + dlls/Makefile \ + dlls/activeds/Makefile \ + dlls/advapi32/Makefile \ + dlls/advapi32/tests/Makefile \ + dlls/advpack/Makefile \ + dlls/advpack/tests/Makefile \ + dlls/amstream/Makefile \ + dlls/atl/Makefile \ + dlls/avicap32/Makefile \ + dlls/avifil32/Makefile \ + dlls/browseui/Makefile \ + dlls/browseui/tests/Makefile \ + dlls/cabinet/Makefile \ + dlls/cabinet/tests/Makefile \ + dlls/capi2032/Makefile \ + dlls/cards/Makefile \ + dlls/cfgmgr32/Makefile \ + dlls/clusapi/Makefile \ + dlls/comcat/Makefile \ + dlls/comcat/tests/Makefile \ + dlls/comctl32/Makefile \ + dlls/comctl32/tests/Makefile \ + dlls/comdlg32/Makefile \ + dlls/comdlg32/tests/Makefile \ + dlls/compstui/Makefile \ + dlls/credui/Makefile \ + dlls/crtdll/Makefile \ + dlls/crypt32/Makefile \ + dlls/crypt32/tests/Makefile \ + dlls/cryptdll/Makefile \ + dlls/cryptnet/Makefile \ + dlls/ctl3d32/Makefile \ + dlls/d3d8/Makefile \ + dlls/d3d8/tests/Makefile \ + dlls/d3d9/Makefile \ + dlls/d3d9/tests/Makefile \ + dlls/d3dim/Makefile \ + dlls/d3drm/Makefile \ + dlls/d3dx8/Makefile \ + dlls/d3dxof/Makefile \ + dlls/dbghelp/Makefile \ + dlls/dciman32/Makefile \ + dlls/ddraw/Makefile \ + dlls/ddraw/tests/Makefile \ + dlls/ddrawex/Makefile \ + dlls/devenum/Makefile \ + dlls/dinput/Makefile \ + dlls/dinput/tests/Makefile \ + dlls/dinput8/Makefile \ + dlls/dmband/Makefile \ + dlls/dmcompos/Makefile \ + dlls/dmime/Makefile \ + dlls/dmloader/Makefile \ + dlls/dmscript/Makefile \ + dlls/dmstyle/Makefile \ + dlls/dmsynth/Makefile \ + dlls/dmusic/Makefile \ + dlls/dmusic32/Makefile \ + dlls/dnsapi/Makefile \ + dlls/dnsapi/tests/Makefile \ + dlls/dplay/Makefile \ + dlls/dplayx/Makefile \ + dlls/dpnet/Makefile \ + dlls/dpnhpast/Makefile \ + dlls/dsound/Makefile \ + dlls/dsound/tests/Makefile \ + dlls/dswave/Makefile \ + dlls/dxdiagn/Makefile \ + dlls/dxerr8/Makefile \ + dlls/dxerr9/Makefile \ + dlls/dxguid/Makefile \ + dlls/gdi32/Makefile \ + dlls/gdi32/tests/Makefile \ + dlls/glu32/Makefile \ + dlls/gphoto2.ds/Makefile \ + dlls/hhctrl.ocx/Makefile \ + dlls/hid/Makefile \ + dlls/hlink/Makefile \ + dlls/hlink/tests/Makefile \ + dlls/iccvid/Makefile \ + dlls/icmp/Makefile \ + dlls/ifsmgr.vxd/Makefile \ + dlls/imaadp32.acm/Makefile \ + dlls/imagehlp/Makefile \ + dlls/imm32/Makefile \ + dlls/infosoft/Makefile \ + dlls/infosoft/tests/Makefile \ + dlls/inseng/Makefile \ + dlls/iphlpapi/Makefile \ + dlls/iphlpapi/tests/Makefile \ + dlls/itss/Makefile \ + dlls/itss/tests/Makefile \ + dlls/kernel32/Makefile \ + dlls/kernel32/tests/Makefile \ + dlls/localspl/Makefile \ + dlls/localspl/tests/Makefile \ + dlls/lz32/Makefile \ + dlls/lz32/tests/Makefile \ + dlls/mapi32/Makefile \ + dlls/mapi32/tests/Makefile \ + dlls/mciavi32/Makefile \ + dlls/mcicda/Makefile \ + dlls/mciseq/Makefile \ + dlls/mciwave/Makefile \ + dlls/midimap/Makefile \ + dlls/mlang/Makefile \ + dlls/mlang/tests/Makefile \ + dlls/mmdevldr.vxd/Makefile \ + dlls/monodebg.vxd/Makefile \ + dlls/mpr/Makefile \ + dlls/mprapi/Makefile \ + dlls/msacm32.drv/Makefile \ + dlls/msacm32/Makefile \ + dlls/msacm32/tests/Makefile \ + dlls/msadp32.acm/Makefile \ + dlls/mscms/Makefile \ + dlls/mscms/tests/Makefile \ + dlls/mscoree/Makefile \ + dlls/msdmo/Makefile \ + dlls/msftedit/Makefile \ + dlls/msg711.acm/Makefile \ + dlls/mshtml/Makefile \ + dlls/mshtml/tests/Makefile \ + dlls/msi/Makefile \ + dlls/msi/tests/Makefile \ + dlls/msimg32/Makefile \ + dlls/msisys.ocx/Makefile \ + dlls/msnet32/Makefile \ + dlls/msrle32/Makefile \ + dlls/msvcrt/Makefile \ + dlls/msvcrt/tests/Makefile \ + dlls/msvcrt20/Makefile \ + dlls/msvcrt40/Makefile \ + dlls/msvcrtd/Makefile \ + dlls/msvcrtd/tests/Makefile \ + dlls/msvfw32/Makefile \ + dlls/msvidc32/Makefile \ + dlls/mswsock/Makefile \ + dlls/msxml3/Makefile \ + dlls/msxml3/tests/Makefile \ + dlls/nddeapi/Makefile \ + dlls/netapi32/Makefile \ + dlls/netapi32/tests/Makefile \ + dlls/newdev/Makefile \ + dlls/ntdll/Makefile \ + dlls/ntdll/tests/Makefile \ + dlls/ntdsapi/Makefile \ + dlls/objsel/Makefile \ + dlls/odbc32/Makefile \ + dlls/odbccp32/Makefile \ + dlls/odbccp32/tests/Makefile \ + dlls/ole32/Makefile \ + dlls/ole32/tests/Makefile \ + dlls/oleacc/Makefile \ + dlls/oleaut32/Makefile \ + dlls/oleaut32/tests/Makefile \ + dlls/olecli32/Makefile \ + dlls/oledlg/Makefile \ + dlls/olepro32/Makefile \ + dlls/olesvr32/Makefile \ + dlls/opengl32/Makefile \ + dlls/powrprof/Makefile \ + dlls/psapi/Makefile \ + dlls/psapi/tests/Makefile \ + dlls/pstorec/Makefile \ + dlls/qcap/Makefile \ + dlls/quartz/Makefile \ + dlls/quartz/tests/Makefile \ + dlls/query/Makefile \ + dlls/rasapi32/Makefile \ + dlls/resutils/Makefile \ + dlls/riched20/Makefile \ + dlls/riched20/tests/Makefile \ + dlls/riched32/Makefile \ + dlls/rpcrt4/Makefile \ + dlls/rpcrt4/tests/Makefile \ + dlls/rsabase/Makefile \ + dlls/rsabase/tests/Makefile \ + dlls/rsaenh/Makefile \ + dlls/rsaenh/tests/Makefile \ + dlls/sane.ds/Makefile \ + dlls/secur32/Makefile \ + dlls/secur32/tests/Makefile \ + dlls/security/Makefile \ + dlls/sensapi/Makefile \ + dlls/serialui/Makefile \ + dlls/serialui/tests/Makefile \ + dlls/setupapi/Makefile \ + dlls/setupapi/tests/Makefile \ + dlls/sfc/Makefile \ + dlls/sfc_os/Makefile \ + dlls/shdoclc/Makefile \ + dlls/shdocvw/Makefile \ + dlls/shdocvw/tests/Makefile \ + dlls/shell32/Makefile \ + dlls/shell32/tests/Makefile \ + dlls/shfolder/Makefile \ + dlls/shlwapi/Makefile \ + dlls/shlwapi/tests/Makefile \ + dlls/snmpapi/Makefile \ + dlls/snmpapi/tests/Makefile \ + dlls/spoolss/Makefile \ + dlls/stdole2.tlb/Makefile \ + dlls/stdole32.tlb/Makefile \ + dlls/sti/Makefile \ + dlls/strmiids/Makefile \ + dlls/svrapi/Makefile \ + dlls/tapi32/Makefile \ + dlls/twain_32/Makefile \ + dlls/unicows/Makefile \ + dlls/url/Makefile \ + dlls/urlmon/Makefile \ + dlls/urlmon/tests/Makefile \ + dlls/user32/Makefile \ + dlls/user32/tests/Makefile \ + dlls/userenv/Makefile \ + dlls/usp10/Makefile \ + dlls/usp10/tests/Makefile \ + dlls/uuid/Makefile \ + dlls/uxtheme/Makefile \ + dlls/uxtheme/tests/Makefile \ + dlls/vdhcp.vxd/Makefile \ + dlls/vdmdbg/Makefile \ + dlls/version/Makefile \ + dlls/version/tests/Makefile \ + dlls/vmm.vxd/Makefile \ + dlls/vnbt.vxd/Makefile \ + dlls/vnetbios.vxd/Makefile \ + dlls/vtdapi.vxd/Makefile \ + dlls/vwin32.vxd/Makefile \ + dlls/w32skrnl/Makefile \ + dlls/winealsa.drv/Makefile \ + dlls/winearts.drv/Makefile \ + dlls/wineaudioio.drv/Makefile \ + dlls/winecoreaudio.drv/Makefile \ + dlls/winecrt0/Makefile \ + dlls/wined3d/Makefile \ + dlls/winedos/Makefile \ + dlls/wineesd.drv/Makefile \ + dlls/winejack.drv/Makefile \ + dlls/winejoystick.drv/Makefile \ + dlls/winemp3.acm/Makefile \ + dlls/winenas.drv/Makefile \ + dlls/wineoss.drv/Makefile \ + dlls/wineps.drv/Makefile \ + dlls/winequartz.drv/Makefile \ + dlls/winex11.drv/Makefile \ + dlls/wing32/Makefile \ + dlls/wininet/Makefile \ + dlls/wininet/tests/Makefile \ + dlls/winmm/Makefile \ + dlls/winmm/tests/Makefile \ + dlls/winnls32/Makefile \ + dlls/winspool.drv/Makefile \ + dlls/winspool.drv/tests/Makefile \ + dlls/wintab32/Makefile \ + dlls/wintrust/Makefile \ + dlls/wintrust/tests/Makefile \ + dlls/wldap32/Makefile \ + dlls/wnaspi32/Makefile \ + dlls/wow32/Makefile \ + dlls/ws2_32/Makefile \ + dlls/ws2_32/tests/Makefile \ + dlls/wsock32/Makefile \ + dlls/wtsapi32/Makefile \ + documentation/Makefile \ + fonts/Makefile \ + include/Makefile \ + libs/Makefile \ + libs/port/Makefile \ + libs/wine/Makefile \ + libs/wpp/Makefile \ + loader/Makefile \ + programs/Makefile \ + programs/clock/Makefile \ + programs/cmd/Makefile \ + programs/cmdlgtst/Makefile \ + programs/control/Makefile \ + programs/eject/Makefile \ + programs/expand/Makefile \ + programs/explorer/Makefile \ + programs/hh/Makefile \ + programs/icinfo/Makefile \ + programs/iexplore/Makefile \ + programs/msiexec/Makefile \ + programs/notepad/Makefile \ + programs/oleview/Makefile \ + programs/progman/Makefile \ + programs/regedit/Makefile \ + programs/regsvr32/Makefile \ + programs/rpcss/Makefile \ + programs/rundll32/Makefile \ + programs/start/Makefile \ + programs/taskmgr/Makefile \ + programs/uninstaller/Makefile \ + programs/view/Makefile \ + programs/wineboot/Makefile \ + programs/winebrowser/Makefile \ + programs/winecfg/Makefile \ + programs/wineconsole/Makefile \ + programs/winedbg/Makefile \ + programs/winefile/Makefile \ + programs/winemenubuilder/Makefile \ + programs/winemine/Makefile \ + programs/winepath/Makefile \ + programs/winetest/Makefile \ + programs/winevdm/Makefile \ + programs/winhelp/Makefile \ + programs/winver/Makefile \ + programs/wordpad/Makefile \ + server/Makefile \ + tools/Makefile \ + tools/widl/Makefile \ + tools/winebuild/Makefile \ + tools/winedump/Makefile \ + tools/winegcc/Makefile \ + tools/wmc/Makefile \ + tools/wrc/Makefile" cat >confcache <<\_ACEOF -- 1.4.4.2 From paul.vriens.wine at gmail.com Sat Feb 24 13:23:57 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Sat Feb 24 13:24:13 2007 Subject: dplay: directplay should initialize session Guid patch + conformance tests In-Reply-To: <200702242014.14315.alex.pigna@inventati.org> References: <200702241725.49691.alex.pigna@inventati.org> <200702241931.03852.stefan@codeweavers.com> <200702242014.14315.alex.pigna@inventati.org> Message-ID: <45E090CD.8050700@gmail.com> Alessandro Pignotti wrote: > On Saturday 24 February 2007 19:31, Stefan D?singer wrote: > >> todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid >> not initialized"); >> >> For tests which are known to fail > > This version of the patch follows Stefan's advice. > > > > ------------------------------------------------------------------------ > > diff --git a/configure.ac b/configure.ac > index 672dd78..4ef4e23 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1587,6 +1587,7 @@ dlls/dnsapi/Makefile > dlls/dnsapi/tests/Makefile > dlls/dplay/Makefile > dlls/dplayx/Makefile > +dlls/dplayx/tests/Makefile > dlls/dpnet/Makefile > dlls/dpnhpast/Makefile > dlls/dsound/Makefile > diff --git a/dlls/dplayx/dplay.c b/dlls/dplayx/dplay.c > index f5c630a..475e59c 100644 > --- a/dlls/dplayx/dplay.c > +++ b/dlls/dplayx/dplay.c > @@ -2828,6 +2828,8 @@ static HRESULT WINAPI DP_SecureOpen > > This->dp2->bHostInterface = TRUE; > > + //Initializing session GUID > + CoCreateGuid(&(lpsd->guidInstance)); > hr = DP_SetSessionDesc( This, lpsd, 0, TRUE, bAnsi ); > if( FAILED( hr ) ) > { > diff --git a/dlls/dplayx/tests/Makefile.in b/dlls/dplayx/tests/Makefile.in > new file mode 100644 > index 0000000..02007d1 > --- /dev/null > +++ b/dlls/dplayx/tests/Makefile.in > @@ -0,0 +1,14 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +TESTDLL = dplayx.dll > +IMPORTS = kernel32 ole32 dxguid > +EXTRALIBS = > + > +CTESTS = \ > + dplayx.c > + > +@MAKE_TEST_RULES@ > + > +@DEPENDENCIES@ # everything below this line is overwritten by make depend > diff --git a/dlls/dplayx/tests/dplayx.c b/dlls/dplayx/tests/dplayx.c > new file mode 100644 > index 0000000..ba96125 > --- /dev/null > +++ b/dlls/dplayx/tests/dplayx.c > @@ -0,0 +1,55 @@ > +#include > +#include > + > +BOOL validSP=0; > + > +BOOL FAR PASCAL EnumConnectionsCallback(LPCGUID lpguidSP, LPVOID lpConnection, > + DWORD dwConnectionSize, LPCDPNAME lpName, DWORD dwFlags, > + LPVOID lpContext) > +{ > + if(!memcmp(lpguidSP,&DPSPGUID_TCPIP,16)) > + { > + //I'm forcing TCP/IP Sevice provider > + HRESULT hr=IDirectPlayX_InitializeConnection((LPDIRECTPLAY4)lpContext,lpConnection,0); > + todo_wine > + { > + ok(SUCCEEDED(hr),"It's not possible to initialize TCP/IP service provider\n"); > + } > + if(SUCCEEDED(hr)) > + validSP=1; > + > + return FALSE; > + } > + return TRUE; > +} > + > +START_TEST(dplayx) > +{ > + LPDIRECTPLAY4 pDP = NULL; > + GUID appGuid; > + GUID zeroGuid; > + DPSESSIONDESC2 sessionDesc; > + CoInitialize(NULL); > + CoCreateGuid(&appGuid); > + CoCreateInstance(&CLSID_DirectPlay,NULL, CLSCTX_ALL, > + &IID_IDirectPlay4A,(VOID**)&pDP); > + IDirectPlayX_EnumConnections(pDP,&appGuid,EnumConnectionsCallback, > + pDP,0); > + if(validSP) > + { > + bzero(&sessionDesc,sizeof(DPSESSIONDESC2)); > + bzero(&zeroGuid,16); > + sessionDesc.dwSize=sizeof(DPSESSIONDESC2); > + sessionDesc.dwFlags=DPSESSION_CLIENTSERVER; > + memcpy(&sessionDesc.guidApplication,&appGuid,16); > + sessionDesc.lpszSessionNameA="DPlay conformance test"; > + sessionDesc.dwMaxPlayers=10; > + sessionDesc.dwCurrentPlayers=0; > + sessionDesc.guidInstance=CLSID_DirectPlay; > + IDirectPlayX_Open(pDP,&sessionDesc,DPOPEN_CREATE); > + todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid not initialized"); > + } > + IDirectPlayX_Release(pDP); > + CoUninitialize(); > + > +} > > > ------------------------------------------------------------------------ > > Hi, no clue about dplayx but: - there are some C++ style comments, please use C-style - there is no copyright/license information Cheers, Paul. From wferi at niif.hu Sat Feb 24 15:17:05 2007 From: wferi at niif.hu (Wagner Ferenc) Date: Sat Feb 24 15:19:10 2007 Subject: New wintest executable is there (but there are some issues due to introduction of skip) In-Reply-To: <45E047A3.30000@gmail.com> (Paul Vriens's message of "Sat, 24 Feb 2007 15:11:47 +0100") References: <45E03F2B.5020602@gmail.com> <45E047A3.30000@gmail.com> Message-ID: <87bqjj45ny.fsf@szonett.ki.iif.hu> Paul Vriens writes: > It doesn't make use of the skip-count as that will mean fixing up a > lot more. If somebody could have a look at the attached patch? Looks good. The already submitted report files could be moved from the data dir back into the queue on the web server as http://cvs.winehq.org/cvsweb/tools/winetest/README tries to explain. (The original directories can be removed afterwards.) -- Regards, Feri. From hverbeet at gmail.com Sat Feb 24 14:54:10 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Sat Feb 24 15:19:28 2007 Subject: dplay: directplay should initialize session Guid patch + conformance tests In-Reply-To: <200702241931.03852.stefan@codeweavers.com> References: <200702241725.49691.alex.pigna@inventati.org> <200702241931.03852.stefan@codeweavers.com> Message-ID: On 24/02/07, Stefan D?singer wrote: > Use > > todo_wine ok(memcmp(&sessionDesc.guidInstance,&zeroGuid,16),"Session guid not > initialized"); > Afaik the proper way is to use IsEqualGUID() rather than memcmp(). From us at edmeades.me.uk Sat Feb 24 15:32:17 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Sat Feb 24 15:32:38 2007 Subject: xcopy try 2 In-Reply-To: <1172275206.6917.78.camel@p4> Message-ID: <000601c7585b$424efed0$1001a8c0@JasonsPC> Hi Detlef, Firstly thanks for taking the time to comment on this... Configure.ac - I included that because another 'regular' developer who added a dll recently added it (See:) http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html) I'll leave it in for that reason unless there's a big problem with it (I always thought you were supposed to send in configure.ac but not configure) >+EXTRADEFS = -DUNICODE >There is no need for that define. >Remove that line to get a warning for all ANSI-Functions, that >missed the "W" and >+ if (GetFullPathName(suppliedsource, MAX_PATH, >"W" missing: => GetFullPathNameW >(More Functions in various locations and >WIN32_FIND_DATA => WIN32_FIND_DATAW) I disagree here - I don't think we should be coding with explicit W and A method names, that's the whole point of the define, and when you look through the MSDN it's the main symbol name which is used all the time, the W and A ones are side effects of the implementation of the definitions. It also mirrors what is used by e.g. oleview, wineconsole and winefile. >+C_SRCS = \ Yes - my mistake, I'll fix that and resubmit it in try 3 >+/* Prototypes */ >This can be avoided completly, when you rearange your functions >(so main() is then the last function in the file) It can, but I also believed that putting prototypes was good programming practice. Why would we not want them as they are harmless? They are easy enough to remove, I just wanted justification. >+ printf("Invalid number of parameters - Use xcopy /? for help\n"); >The text should be read from the resources, so it can be localized . >You should convert the UNICODE-Message with WideCharToMultiByte. >When the output-handle is the console, printing UNICODE-messages >avoid converting the message twice (xcopy and kernel32) You wanted the patch small, remember :-) Lets leave that as something for a later patch - I just want to get the infrastructure in first, then fix up some of the other parameters, localization, help etc - Its something which is trivial to do. >This is wrong. tested with: "xcopy file1 file2 file3" Yes, I'll also fix that in the try 3 resubmit (and your suggested solution is fine). The code as it stands certainly isn't perfect especially as I am just trying to put the minimum in to be functional, and some other error checking may also be missing. >(ToDo-Reminder: "xcopy file1 name_not_found" => is "name_not_found" a file or a directory) Its already in there (another string to be localized though!) - See middle of XCOPY_ProcessDestParm. >Thanks for your work. It's pretty good as start! Thanks - its all pretty simple, and I am surprised how little code it is! Jason From us at edmeades.me.uk Sat Feb 24 15:35:56 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Sat Feb 24 15:36:19 2007 Subject: xcopy try 2 Message-ID: <000701c7585b$c7591200$1001a8c0@JasonsPC> Hi Detlef, (again) >Configure.ac - I included that because another 'regular' developer who >added a dll recently added it (See:) > http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html) >I'll leave it in for that reason unless there's a big problem with it (I >always thought you were supposed to send in configure.ac but not configure) I stand corrected - tools\make_makefiles does that update for me as well as the others :-) Jason From dank at kegel.com Sat Feb 24 15:41:24 2007 From: dank at kegel.com (Dan Kegel) Date: Sat Feb 24 15:41:38 2007 Subject: Success with enhanced cd's... kind of Message-ID: I noticed that my copy of "No!" by "They Might Be Giants" is an "enhanced cd", so I inserted it into my Ubuntu Dapper laptop. Ubuntu only noticed the audio tracks, so I had to actually use the commandline to mount the data tracks: sudo mount -oro,loop -tiso9660 /dev/cdrom /mnt After that it went fine; wine was able to run the flash app on the disc. Looks like others have complained about this, e.g. http://ubuntuforums.org/showthread.php?p=2143161 but I didn't see any bug reports about it, so I filed https://launchpad.net/ubuntu/+bug/87663 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv From joris_huizer at yahoo.com Sat Feb 24 16:13:52 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Sat Feb 24 16:14:48 2007 Subject: a big fan (now with bad news) In-Reply-To: Message-ID: <143659.85414.qm@web52708.mail.yahoo.com> Aww... yes, I'm seeing that too According the the wine application database (http://appdb.winehq.org/appview.php?iVersionId=469) some settings help it get a bit further, but it reports: "Microsoft Internet Explorer has encountered a problem and needs to close. We are sorry for the inconvenience." (With a "debug" button) With these messages: fixme:shell:StopWatchMode () stub! fixme:shdocvw:IEWinMain "" 10 fixme:ole:CoResumeClassObjects stub err:module:DelayLoadFailureHook failed to delay load urlmon.dll.CreateURLMoniker wine: Call from 0x7b842138 to unimplemented function urlmon.dll.CreateURLMoniker, aborting fixme:imm:ImmDisableIME (-1): stub fixme:advapi:RegisterEventSourceW ((null),L"Microsoft Internet Explorer"): stub fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0005,0x00000050,0x632f6ec0,0x632f6a84): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0005,0x00000050,0x161400,0x632f6a84): stub err:eventlog:ReportEventW L"iexplore.exe" err:eventlog:ReportEventW L"6.0.2800.1106" err:eventlog:ReportEventW L"" err:eventlog:ReportEventW L"0.0.0.0" err:eventlog:ReportEventW L"00000000" fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:wininet:InternetGetConnectedState always returning LAN connection. Hitting "debug" crashes as an unimplemented function in urlmon is called - that seems weird, as it should be using the native version of urlmon... oh well I guess you need to use ies4linux to get a working IE for now. I had it installed as some program thought it needed it - hadn't noticed it didn't actually run Jeffrey Sabarese wrote: Hi Joris, Thanks again for corresponding with me on this. (i realize there's much text here, so please take you time, get to it when you can...) for the link, just think: "this dude is such a 'NOVICE'!! he really should take more 'NOTES'!!!..." get it? novicenotes? hee hee then a text search (upper right) of WinE ie will get you there, undoubtedly. but that's not why i am writing. i wanted to let you know that the "genuine" installer, http://www.microsoft.com/windows/ie/ie6/downloads/critical/ie6sp1/default.mspx did not succeed in placing a useable software on the system. it seemed to "install" just fine, but launching it: [ wine '/home/user/.wine/drive_c/Program Files/Internet Explorer/iexplore.exe' ] brings up a window w/ nothing but "white space". as if it "wants" to launch, but doesn't quite get there. when ie was installed via "ies4linux", i DID experience a similar activity, but only if i launched IE via WinE application link, for example, if i linked to IE from... say EditPlus, as an external browser, i would get the same: a window w/ nothing in it-- as you might see after an app has crashed, the window's still up, but no screen-updating, so you get a "frozen" image, or white screen. so, the only time i've ever seen it look "right" myself was using the "non-standard" ies4linux launcher, as i've illustrated specifically, here some time ago (showing the 3 versions of IE in that package): http://digisquirrel.blogspot.com/2006/08/fiddlers-three.html please understand that i want to install it the proper, WinE developers' recommended way, so this is why i continue to research the subject (and continue to probably annoy you, for which i apologize). What might i be doing wrong? i noticed in my blog entry-- (a different one this time) http://novicenotes.com/2006/08/04/ie_on_linux_wine/ where i discussed DCOM98.EXE . i haven't actively installed that component this time-- so unless it came down w/ the MS installer, might i need to have that installed as well? any other feedback you have on this subject is appreciated. perhaps you have URL w/ the preferred, WinE dev's method? (assuming it's "okay [legal]" to do the MS installer) thank you for your generous help!! --Jeff Sabarese PS. I apologize if it's been an invasion-- i thought i mailed to the "list" last time, but it looks like i sent just to you last time? (and i know i sent only to you this time, so if you wish to forward to the list, please do so. i have a real problem w/ being not-concise [as you've noticed, i'm sure], so i tried to spare the other members for now. sorry i can't seem to shorten things more than i do). On 2/24/07, Joris Huizer wrote: > I think I don't have it anymore, though I'd like to > see - though I'm pretty sure you got it covered well, > like before. > > regards, > > Joris > > > > --- Jeffrey Sabarese wrote: > > > hey there! thanks for the valuable lesson learned > > here! > > > > btw-- i changed my web log info , per > > recommendations i received in > > this mail conversation. if you still have the link > > and care to see > > it-- you'll see that i've now got the wineHQ URL > > there, and a > > recommendation about IE6 should install properly > > :) > > > > On 2/23/07, Joris Huizer > > wrote: > > > > > > --- Jeffrey Sabarese > > wrote: > > > > > > > > > > > I tried [ yum remove wine ], and then [yum > > install > > > > wine] which went > > > > without a hitch, but there's no change in my > > Primary > > > > User (the broken > > > > one) > > > > HOWEVER, WinE continues to run perfectly under > > other > > > > user accounts, and ROOT. > > > > > > > > > > The wine configuration is in ~/.wine > > > Remove/rename it for a fresh start. Wine will > > > automatically recreate the ~/.wine directory with > > > required contents for normal functionality (but > > then > > > you need to do installation of every program > > again) > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > Yahoo! Music Unlimited > > > Access over 1 million songs. > > > http://music.yahoo.com/unlimited > > > > > > > > > > > > > > > -- > > /* ************************************************ > > */ > > Quanta+ Web Development IDE: > > http://quanta.kdewebdev.org/ > > Quanta+ Wiki: > > http://tinyurl.com/3dzqxk > > Other Quanta Tips: > > http://invisiblepixels.org/progs/quanta.html > > /* ************************************************ > > */ > > > > > > > ____________________________________________________________________________________ > Looking for earth-friendly autos? > Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. > http://autos.yahoo.com/green_center/ > -- /* ************************************************ */ Quanta+ Web Development IDE: http://quanta.kdewebdev.org/ Quanta+ Wiki: http://tinyurl.com/3dzqxk Other Quanta Tips: http://invisiblepixels.org/progs/quanta.html /* ************************************************ */ --------------------------------- Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070224/739b2122/attachment.htm From ben at atomnet.co.uk Sat Feb 24 16:18:04 2007 From: ben at atomnet.co.uk (Ben Hodgetts (Enverex)) Date: Sat Feb 24 16:18:26 2007 Subject: Success with enhanced cd's... kind of In-Reply-To: References: Message-ID: <45E0B99C.6020900@atomnet.co.uk> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070224/08a910d2/signature-0003.pgp From wes.parish at paradise.net.nz Sun Feb 25 01:52:43 2007 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Sun Feb 25 01:48:51 2007 Subject: wine and msys rxvt.exe Message-ID: <200702252052.44341.wes.parish@paradise.net.nz> I installed msys a couple of years back, and decided to test rxvt.exe: bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe libGL warning: 3D driver claims to not support visual 0x4b fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x00000001,0x68f494) stub fixme:advapi:LsaClose (0xcafe) stub fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 0x68ef0c 8 L"DOMAIN" (nil)) fixme:advapi:LsaClose (0xcafe) stub fixme:netapi32:NetUserGetInfo Level 3 is not implemented fixme:netapi32:NetUserGetInfo Level 3 is not implemented failed to load libX11.dllbash-3.1$ bash-3.1$ wine --version wine-0.9.29 Those are the error messages. My version of wine is a little old. Have the fixme's been fixed in the latest wine? thanks Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. From research at science.su Sun Feb 25 03:30:43 2007 From: research at science.su (L. Rahyen) Date: Sun Feb 25 03:29:57 2007 Subject: wine and msys rxvt.exe In-Reply-To: <200702252052.44341.wes.parish@paradise.net.nz> References: <200702252052.44341.wes.parish@paradise.net.nz> Message-ID: <200702250930.44500.research@science.su> Sunday February 25 2007 07:52?Wesley Parish ????????: > I installed msys a couple of years back, and decided to test rxvt.exe: > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > libGL warning: 3D driver claims to not support visual 0x4b > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > implemented fixme:advapi:LsaOpenPolicy > ((null),0x68f478,0x00000001,0x68f494) stub fixme:advapi:LsaClose (0xcafe) > stub > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 0x68ef0c > 8 L"DOMAIN" (nil)) > fixme:advapi:LsaClose (0xcafe) stub > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > failed to load libX11.dllbash-3.1$ > > bash-3.1$ wine --version > wine-0.9.29 > > Those are the error messages. > > My version of wine is a little old. Have the fixme's been fixed in the > latest wine? Fixmes doesn't mean problems if there is no problems. This is rule of thumb. If you want to get help please tell what problems you see when trying to run the software. And if you can give a link to download demo version of the software (or full version if it's free). From rob at codeweavers.com Sun Feb 25 06:51:45 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 25 06:52:50 2007 Subject: msi: Add handlers for JScript/VBScript actions that call one script function. [PATCH 2/3] In-Reply-To: <1172298559.12860.8.camel@misha-laptop> References: <1172298559.12860.8.camel@misha-laptop> Message-ID: <45E18661.5060906@codeweavers.com> Misha Koshelev wrote: > All > actual script implementation is left (for the next patch) in the > call_script function. Patches should attempt to be atomic changes that compile and pass all tests without another patch needing to be applied on top. I suggest you implement automation.c and the associated header file in patch 2 and combine this patch with the rest of patch 3. > +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, > + LPCWSTR target, const INT type, LPCWSTR action) > +{ > ... > + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) > ... > + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); > + > + return wait_thread_handle( info ); > +} > + > +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, > + LPCWSTR target, const INT type, LPCWSTR action) > +{ > ... > + r = store_binary_to_temp(package, source, tmp_file); > ... > + info = do_msidbCustomActionTypeScript( package, type, tmp_file, target, action ); > + > + return wait_thread_handle( info ); > +} > + > +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, > + LPCWSTR target, const INT type, LPCWSTR action) > +{ > ... > + info = do_msidbCustomActionTypeScript( package, type, file->TargetPath, target, action ); > + > + return wait_thread_handle( info ); > +} > + > +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, > + LPCWSTR target, const INT type, LPCWSTR action) > +{ > ... > + if (GetTempFileNameW(fmt, f1, 0, tmp_file) == 0) > ... > + info = do_msidbCustomActionTypeScript( package, type, tmp_file, NULL, action ); > + > + return wait_thread_handle( info ); > +} > It would seem simpler here to just open the file here for the one case that has an external file and just pass in the LPWSTR script for all cases. -- Rob Shearman From rob at codeweavers.com Sun Feb 25 07:00:10 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 25 07:00:47 2007 Subject: msi: Add full JScript/VBScript support and partial expandable OLE automation support. [PATCH 3/3] In-Reply-To: <1172298914.12860.15.camel@misha-laptop> References: <1172298914.12860.15.camel@misha-laptop> Message-ID: <45E1885A.9040809@codeweavers.com> Misha Koshelev wrote: > +/* Macros to get pointer to AutomationObject) from the other VTables. */ > Typo with extra ")" here. > +HRESULT WINAPI SessionImpl_Invoke( > + AutomationObject* This, > + DISPID dispIdMember, > + REFIID riid, > + LCID lcid, > + WORD wFlags, > + DISPPARAMS* pDispParams, > + VARIANT* pVarResult, > + EXCEPINFO* pExcepInfo, > + UINT* puArgErr) > +{ > + WCHAR szString[MAX_MSI_STRING]; > + DWORD dwLen = MAX_MSI_STRING; > + IDispatch *iDispatch = NULL; > + MSIHANDLE msiHandle; > + LANGID langId; > + UINT ret; > + INSTALLSTATE iInstalled, iAction; > Some error checking here would be good, like you do in AutomationObject_Invoke. > + > + switch (dispIdMember) > + { > ... > +/* > + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just > + * need to implement Invoke function for each dispinterface and pass the new function > + * to create_automation_object. > + */ > + > +typedef struct { > + /* > + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo > + */ > + const IDispatchVtbl *lpVtbl; > + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; > + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; > + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; > + > + /* Object reference count */ > + LONG ref; > + > + /* Clsid for this class and it's appropriate ITypeInfo object */ > + LPCLSID clsid; > + ITypeInfo *iTypeInfo; > + > + /* The MSI handle of the current object */ > + MSIHANDLE msiHandle;; > + > + /* A function that is called from IDispatch::Invoke, specific to this type of object */ > + LPVOID funcInvoke; > +} AutomationObject; > You shouldn't need to expose the implementation details of AutomationObject outside of automation.c. > + > +/* This is the function that one needs to call to create an automation object. */ > +extern HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke); > It is dangerous to use LPVOID as the type to pass a function in. > + > +/* We need to expose these functions because our IActiveScriptSite calls it */ > +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); > +extern HRESULT WINAPI SessionImpl_Invoke(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*); > + > +/* Disp Ids > + * (not complete, look in msiserver.idl to add more) */ > +typedef enum { > + RecordDispId_StringData=1, > + RecordDispId_IntegerData, > + RecordDispId_SetStream, > + RecordDispId_ReadStream, > + RecordDispId_FieldCount, > + RecordDispId_IsNull, > + RecordDispId_DataSize, > + RecordDispId_ClearData, > + RecordDispId_FormatText > +} RecordDispId; > + > +typedef enum { > + ViewDispId_Execute=1, > + ViewDispId_Fetch, > + ViewDispId_Modify, > + ViewDispId_Close, > + ViewDispId_ColumnInfo, > + ViewDispId_GetError > +} ViewDispId; > + > +typedef enum { > + DatabaseDispId_DatabaseState=1, > + DatabaseDispId_SummaryInformation, > + DatabaseDispId_OpenView, > + DatabaseDispId_Commit, > + DatabaseDispId_PrimaryKeys, > + DatabaseDispId_Import, > + DatabaseDispId_Export, > + DatabaseDispId_Merge, > + DatabaseDispId_GenerateTransform, > + DatabaseDispId_ApplyTransform, > + DatabaseDispId_EnableUIPreview, > + DatabaseDispId_TablePersistent, > + DatabaseDispId_CreateTransformSummaryInfo > +} DatabaseDispId; > + > +typedef enum { > + SessionDispId_Installer=1, > + SessionDispId_Property, > + SessionDispId_Language, > + SessionDispId_Mode, > + SessionDispId_Database, > + SessionDispId_SourcePath, > + SessionDispId_TargetPath, > + SessionDispId_DoAction, > + SessionDispId_Sequence, > + SessionDispId_EvaluateCondition, > + SessionDispId_FormatRecord, > + SessionDispId_Message, > + SessionDispId_FeatureCurrentState, > + SessionDispId_FeatureRequestState, > + SessionDispId_FeatureValidStates, > + SessionDispId_FeatureCost, > + SessionDispId_ComponentCurrentState, > + SessionDispId_ComponentRequestState, > + SessionDispId_SetInstallLevel, > + SessionDispId_VerifyDiskSpace, > + SessionDispId_ProductProperty, > + SessionDispId_FeatureInfo, > + SessionDispId_ComponentCost > +} SessionDispId; > See dlls/oleaut32/tests/tmarshal_dispids.h and dlls/oleaut32/tests/tmarshal.idl for how to use DISPIDs properly. > +typedef struct { > + IActiveScriptSite lpVtbl; > + AutomationObject *session; > You don't actually access this as anything other than an IDispatch object, so you might as well change to "IDispatch *session". > +LPCWSTR read_script_from_file(LPCWSTR szFile, INT type) > Should be static. > +/* JScript or VBScript? */ > +LPCWSTR progid_from_type(INT type) > Should also be static. > + > +/* > + * Call a script. This is our meat and potatoes. > + * - Currently, since the function is relatively new, it will always end up returning S_OK. > + * Think of it like a bonus feature, we can run the script - great. If we have a problem, > + * we are no worse off than if this function had not been called. > + */ > +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) > +{ > + LPCWSTR script = NULL, progId = NULL; > + HRESULT hr; > + IActiveScript *iActiveScript = NULL; > + IActiveScriptParse *iActiveScriptParse = NULL; > I haven't seen this variable notation style before. In Hungarian notation "p" is used instead of "i" to show a pointer to an object exposing the interface declared. -- Rob Shearman From rob at codeweavers.com Sun Feb 25 07:19:13 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 25 07:19:51 2007 Subject: a big fan (now with bad news) In-Reply-To: <143659.85414.qm@web52708.mail.yahoo.com> References: <143659.85414.qm@web52708.mail.yahoo.com> Message-ID: <45E18CD1.3020202@codeweavers.com> Joris Huizer wrote: > Aww... yes, I'm seeing that too > According the the wine application database > (http://appdb.winehq.org/appview.php?iVersionId=469) some settings > help it get a bit further, but it reports: "Microsoft Internet > Explorer has encountered a problem and needs to close. We are sorry > for the inconvenience." > (With a "debug" button) > > With these messages: > > fixme:shell:StopWatchMode () stub! > fixme:shdocvw:IEWinMain "" 10 > fixme:ole:CoResumeClassObjects stub > err:module:DelayLoadFailureHook failed to delay load > urlmon.dll.CreateURLMoniker > wine: Call from 0x7b842138 to unimplemented function > urlmon.dll.CreateURLMoniker, aborting > fixme:imm:ImmDisableIME (-1): stub > fixme:advapi:RegisterEventSourceW ((null),L"Microsoft Internet > Explorer"): stub > fixme:advapi:ReportEventA > (0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0005,0x00000050,0x632f6ec0,0x632f6a84): > stub > fixme:advapi:ReportEventW > (0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0005,0x00000050,0x161400,0x632f6a84): > stub > err:eventlog:ReportEventW L"iexplore.exe" > err:eventlog:ReportEventW L"6.0.2800.1106" > err:eventlog:ReportEventW L"" > err:eventlog:ReportEventW L"0.0.0.0" > err:eventlog:ReportEventW L"00000000" > fixme:advapi:DeregisterEventSource (0xcafe4242) stub > fixme:wininet:InternetGetConnectedState always returning LAN connection. > > Hitting "debug" crashes as an unimplemented function in urlmon is > called - that seems weird, as it should be using the native version of > urlmon... oh well > > I guess you need to use ies4linux to get a working IE for now. > I had it installed as some program thought it needed it - hadn't > noticed it didn't actually run This is a list for discussion of wine development. I suggest you continue the discussion on wine-users. P.S. You might want to pay attention to the appdb entry that you linked to, especially the bit about setting DLLs to use native versions. -- Rob Shearman From rob at codeweavers.com Sun Feb 25 07:20:06 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 25 07:20:44 2007 Subject: wine and msys rxvt.exe In-Reply-To: <200702252052.44341.wes.parish@paradise.net.nz> References: <200702252052.44341.wes.parish@paradise.net.nz> Message-ID: <45E18D06.80603@codeweavers.com> Wesley Parish wrote: > I installed msys a couple of years back, and decided to test rxvt.exe: > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > libGL warning: 3D driver claims to not support visual 0x4b > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented > fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x00000001,0x68f494) stub > fixme:advapi:LsaClose (0xcafe) stub > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 0x68ef0c 8 > L"DOMAIN" (nil)) > fixme:advapi:LsaClose (0xcafe) stub > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > failed to load libX11.dllbash-3.1$ > > bash-3.1$ wine --version > wine-0.9.29 > > Those are the error messages. > > My version of wine is a little old. Have the fixme's been fixed in the latest > wine? > What is the program supposed to do? -- Rob Shearman From rob at codeweavers.com Sun Feb 25 07:28:49 2007 From: rob at codeweavers.com (Robert Shearman) Date: Sun Feb 25 07:29:23 2007 Subject: [2/2] user32: do not call NULL message callback In-Reply-To: <200702241957.22594.der.fabe@gmx.net> References: <200702241957.22594.der.fabe@gmx.net> Message-ID: <45E18F11.1040609@codeweavers.com> Fabian Bieler wrote: > @@ -8894,23 +8894,20 @@ static void test_nullCallback(void) > HWND hwnd; > MSG msg; > > - if(0) > - { > - hwnd = CreateWindowExA(0, "TestWindowClass", "Test overlapped", WS_OVERLAPPEDWINDOW, > - 100, 100, 200, 200, 0, 0, 0, NULL); > - ok (hwnd != 0, "Failed to create overlapped window\n"); > + hwnd = CreateWindowExA(0, "TestWindowClass", "Test overlapped", WS_OVERLAPPEDWINDOW, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (hwnd != 0, "Failed to create overlapped window\n"); > > - ShowWindow(hwnd, SW_SHOW); > - UpdateWindow( hwnd ); > + ShowWindow(hwnd, SW_SHOW); > + UpdateWindow( hwnd ); > > - SendMessageCallbackA(hwnd,WM_NULL,0,0,NULL,0); > + SendMessageCallbackA(hwnd,WM_NULL,0,0,NULL,0); > > - while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); > + while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); > > - ok(1, "\n"); > + ok(1, "\n"); > > - DestroyWindow(hwnd); > - } > + DestroyWindow(hwnd); > } > > START_TEST(msg) > You might as well add the test and fix the bug in one patch since the second patch is no shorter due to all of the whitespace changes. -- Rob Shearman From Stefan.Leichter at camline.com Sun Feb 25 12:13:22 2007 From: Stefan.Leichter at camline.com (Stefan Leichter) Date: Sun Feb 25 12:13:40 2007 Subject: mingw linking problem Message-ID: <200702251913.23177.Stefan.Leichter@camline.com> Hello, i'm trying to build wine/its dlls with mingw. This fail for some dlls at the linking, eg. comdlg32.dll misses the imports _IID_IContextMenu, _IID_IShellFolder, _IID_IPersistFolder2, _IID_IShellBrowser, _IID_ICommDlgBrowser, _IID_IShellView, _SID_STopLevelBrowser My investigations are showing that mingw has the missing imports in libshell32.a., but the linker links against wine's shell32.dll. The missing symbols are also in wine's libuuid.a, but this is not used because the linker does not see the file. When i extend the linker call with -L../../dlls/uuid i can link the comdlg32.dll successfully.. I have tried to find the symbols with strings on my win2k box, but the symbols are not there. So the first question is: What is the correct way to build the dll? The second question when we agreed on the first one is: Can someone please fix configure/Makefile.in to work properly . Thanks Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: text/x-log Size: 2448 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070225/7eba3c4a/make.bin From mk144210 at bcm.tmc.edu Sun Feb 25 13:14:09 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Sun Feb 25 13:14:54 2007 Subject: msi: Add full JScript/VBScript support and partial expandable OLE automation support. [PATCH 3/3] In-Reply-To: <45E1885A.9040809@codeweavers.com> References: <1172298914.12860.15.camel@misha-laptop> <45E1885A.9040809@codeweavers.com> Message-ID: <1172430849.7297.16.camel@misha-laptop> On Sun, 2007-02-25 at 13:00 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > +/* Macros to get pointer to AutomationObject) from the other VTables. */ > > > > Typo with extra ")" here. > > > +HRESULT WINAPI SessionImpl_Invoke( > > + AutomationObject* This, > > + DISPID dispIdMember, > > + REFIID riid, > > + LCID lcid, > > + WORD wFlags, > > + DISPPARAMS* pDispParams, > > + VARIANT* pVarResult, > > + EXCEPINFO* pExcepInfo, > > + UINT* puArgErr) > > +{ > > + WCHAR szString[MAX_MSI_STRING]; > > + DWORD dwLen = MAX_MSI_STRING; > > + IDispatch *iDispatch = NULL; > > + MSIHANDLE msiHandle; > > + LANGID langId; > > + UINT ret; > > + INSTALLSTATE iInstalled, iAction; > > > > Some error checking here would be good, like you do in > AutomationObject_Invoke. > Well perhaps there is a little confusion here as these functions are actually always called from _within_ AutomationObject_Invoke, hence the error checking is already done. I did this as there is quite a few objects to implement and to save writing the same code over and over I thought this would be a good idea. Do you think I should rename these functions to something else so it is more clear that they are not actually called directly through an IDispatch interface but rather from an AutomationObject? > > + > > + switch (dispIdMember) > > + { > > > ... > > +/* > > + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just > > + * need to implement Invoke function for each dispinterface and pass the new function > > + * to create_automation_object. > > + */ > > + > > +typedef struct { > > + /* > > + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo > > + */ > > + const IDispatchVtbl *lpVtbl; > > + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; > > + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; > > + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; > > + > > + /* Object reference count */ > > + LONG ref; > > + > > + /* Clsid for this class and it's appropriate ITypeInfo object */ > > + LPCLSID clsid; > > + ITypeInfo *iTypeInfo; > > + > > + /* The MSI handle of the current object */ > > + MSIHANDLE msiHandle;; > > + > > + /* A function that is called from IDispatch::Invoke, specific to this type of object */ > > + LPVOID funcInvoke; > > +} AutomationObject; > > > > You shouldn't need to expose the implementation details of > AutomationObject outside of automation.c. > > > + > > +/* This is the function that one needs to call to create an automation object. */ > > +extern HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke); > > > > It is dangerous to use LPVOID as the type to pass a function in. > > > + > > +/* We need to expose these functions because our IActiveScriptSite calls it */ > > +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); > > +extern HRESULT WINAPI SessionImpl_Invoke(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*); > > + > > +/* Disp Ids > > + * (not complete, look in msiserver.idl to add more) */ > > +typedef enum { > > + RecordDispId_StringData=1, > > + RecordDispId_IntegerData, > > + RecordDispId_SetStream, > > + RecordDispId_ReadStream, > > + RecordDispId_FieldCount, > > + RecordDispId_IsNull, > > + RecordDispId_DataSize, > > + RecordDispId_ClearData, > > + RecordDispId_FormatText > > +} RecordDispId; > > + > > +typedef enum { > > + ViewDispId_Execute=1, > > + ViewDispId_Fetch, > > + ViewDispId_Modify, > > + ViewDispId_Close, > > + ViewDispId_ColumnInfo, > > + ViewDispId_GetError > > +} ViewDispId; > > + > > +typedef enum { > > + DatabaseDispId_DatabaseState=1, > > + DatabaseDispId_SummaryInformation, > > + DatabaseDispId_OpenView, > > + DatabaseDispId_Commit, > > + DatabaseDispId_PrimaryKeys, > > + DatabaseDispId_Import, > > + DatabaseDispId_Export, > > + DatabaseDispId_Merge, > > + DatabaseDispId_GenerateTransform, > > + DatabaseDispId_ApplyTransform, > > + DatabaseDispId_EnableUIPreview, > > + DatabaseDispId_TablePersistent, > > + DatabaseDispId_CreateTransformSummaryInfo > > +} DatabaseDispId; > > + > > +typedef enum { > > + SessionDispId_Installer=1, > > + SessionDispId_Property, > > + SessionDispId_Language, > > + SessionDispId_Mode, > > + SessionDispId_Database, > > + SessionDispId_SourcePath, > > + SessionDispId_TargetPath, > > + SessionDispId_DoAction, > > + SessionDispId_Sequence, > > + SessionDispId_EvaluateCondition, > > + SessionDispId_FormatRecord, > > + SessionDispId_Message, > > + SessionDispId_FeatureCurrentState, > > + SessionDispId_FeatureRequestState, > > + SessionDispId_FeatureValidStates, > > + SessionDispId_FeatureCost, > > + SessionDispId_ComponentCurrentState, > > + SessionDispId_ComponentRequestState, > > + SessionDispId_SetInstallLevel, > > + SessionDispId_VerifyDiskSpace, > > + SessionDispId_ProductProperty, > > + SessionDispId_FeatureInfo, > > + SessionDispId_ComponentCost > > +} SessionDispId; > > > > See dlls/oleaut32/tests/tmarshal_dispids.h and > dlls/oleaut32/tests/tmarshal.idl for how to use DISPIDs properly. > > > +typedef struct { > > + IActiveScriptSite lpVtbl; > > + AutomationObject *session; > > > > You don't actually access this as anything other than an IDispatch > object, so you might as well change to "IDispatch *session". > > > +LPCWSTR read_script_from_file(LPCWSTR szFile, INT type) > > > > Should be static. > > > +/* JScript or VBScript? */ > > +LPCWSTR progid_from_type(INT type) > > > > Should also be static. > > > + > > +/* > > + * Call a script. This is our meat and potatoes. > > + * - Currently, since the function is relatively new, it will always end up returning S_OK. > > + * Think of it like a bonus feature, we can run the script - great. If we have a problem, > > + * we are no worse off than if this function had not been called. > > + */ > > +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) > > +{ > > + LPCWSTR script = NULL, progId = NULL; > > + HRESULT hr; > > + IActiveScript *iActiveScript = NULL; > > + IActiveScriptParse *iActiveScriptParse = NULL; > > > > I haven't seen this variable notation style before. In Hungarian > notation "p" is used instead of "i" to show a pointer to an object > exposing the interface declared. > Other comments sound good, I will make appropriate changes. I think I will make patch 2 the scripting functions with a dummy call_script that just does a TRACE, and then patch 3 will apply automation and scripting. Misha From rok.mandeljc at email.si Sun Feb 25 14:57:00 2007 From: rok.mandeljc at email.si (Rok Mandeljc) Date: Sun Feb 25 14:57:20 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize Message-ID: <45E1F81C.5040805@email.si> Hey all, I've been experiencing an odd behavior in Baldur's Gate 2; when "VideoMemorySize" registry key for wined3d is set to anything greater than 64MB (69MB, actually), it stops before playing intro movie, printing following line: err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. Tracing the source of issue by inserting custom traces I got the following: IDirectDrawImpl_CreateNewSurface -> IWineD3DDeviceImpl_CreateSurface (decides to use GDI surface) -> IWineGDISurfaceImpl_PrivateSetup -> IWineD3DSurfaceImpl_GetDC -> CreateCompatibleDC -> CreateRectRgn -> REGION_CreateRegion -> GDI_AllocObject -> alloc_large_heap alloc_large_heap fails because it can't find next large handle and returns NULL, which is passed up the chain, where CreateCompatibleDC puts it in dc->hVisRgn. Then DC_InitDC is called with that dc, which calls CLIPPING_UpdateGCRegion, and that one finally chokes on it, printing afore-mentioned line and calling exit(1). Now, when the game is run with 64MB of VideoMemorySize, upon reaching the same point, IDirectDrawImpl_CreateNewSurface returns WINED3DERR_OUTOFVIDEOMEMORY (because of "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. So it seems Baldur's Gate 2 is trying to create as many surfaces as possible before running out of memory. And the problem arises when specified memory size is large enough to take up all GDI's heap... Sorry for the long-winded description of the problem, but I'm not sure where and how this should be fixed (is it wined3d issue or should GDI have its heap enlarged?), otherwise I'd do it myself... Regards, Rok -=-=-=-=-=- Never say "Never" unless it is to say "Never Give Up." -=-=-=-=-=--=-=-=-=-=- * Generated by TagZilla 0.066 * http://tagzilla.mozdev.org * From andrew.james.barr at gmail.com Sun Feb 25 13:38:51 2007 From: andrew.james.barr at gmail.com (Andrew J. Barr) Date: Sun Feb 25 15:50:22 2007 Subject: Wine and XP Themes Message-ID: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org> I would like to use the XP ClearLooks theme that is available to make Wine apps blend in with my GNOME desktop. However, it seems that using themes in Wine makes it rather slow. Is this a known problem, is there a workaround of some kind, a registry setting or a patch, or is it best just not to use themes with Wine right now? I am running Wine 0.9.31. According to a Google search, there seem to be scattered reports of this problem but no diagnosis or solution. Regards, Andrew Barr (cc'd replies requested) From wine-devel at kievinfo.com Sun Feb 25 17:33:17 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 25 17:33:55 2007 Subject: Wine and XP Themes In-Reply-To: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org> References: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org> Message-ID: <45E21CBD.9080609@kievinfo.com> Wrong mailing list. Use wine-users. Unless you want to hack on this yourself of course. Oh and yeah the only "workaround" is not using themes at all. They are buggy and never worked right anyway. They are an extra hackish layer on top of some controls. Vitaliy Andrew J. Barr wrote: > I would like to use the XP ClearLooks theme that is available to make > Wine apps blend in with my GNOME desktop. However, it seems that using > themes in Wine makes it rather slow. Is this a known problem, is there a > workaround of some kind, a registry setting or a patch, or is it best > just not to use themes with Wine right now? I am running Wine 0.9.31. > > According to a Google search, there seem to be scattered reports of this > problem but no diagnosis or solution. > > Regards, > Andrew Barr > > (cc'd replies requested) > > From wine-devel at kievinfo.com Sun Feb 25 17:36:02 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 25 17:36:51 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <45E1F81C.5040805@email.si> References: <45E1F81C.5040805@email.si> Message-ID: <45E21D62.8080300@kievinfo.com> Submit proper bug report to Wine bugzilla. The memory size setting is only in registry because you should not touch it in the first place. For any user support problems - use wine-users mailing list. Vitaliy Rok Mandeljc wrote: > Hey all, > > I've been experiencing an odd behavior in Baldur's Gate 2; when > "VideoMemorySize" registry key for wined3d is set to anything greater > than 64MB (69MB, actually), it stops before playing intro movie, > printing following line: > err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. > > Tracing the source of issue by inserting custom traces I got the following: > IDirectDrawImpl_CreateNewSurface -> IWineD3DDeviceImpl_CreateSurface > (decides to use GDI surface) -> IWineGDISurfaceImpl_PrivateSetup -> > IWineD3DSurfaceImpl_GetDC -> > CreateCompatibleDC -> CreateRectRgn -> REGION_CreateRegion -> > GDI_AllocObject -> alloc_large_heap > > alloc_large_heap fails because it can't find next large handle and > returns NULL, which is passed up the chain, where CreateCompatibleDC > puts it in dc->hVisRgn. Then DC_InitDC is called with that dc, which > calls CLIPPING_UpdateGCRegion, and that one finally chokes on it, > printing afore-mentioned line and calling exit(1). > > Now, when the game is run with 64MB of VideoMemorySize, upon reaching > the same point, IDirectDrawImpl_CreateNewSurface returns > WINED3DERR_OUTOFVIDEOMEMORY (because of > "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in > D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. > So it seems Baldur's Gate 2 is trying to create as many surfaces as > possible before running out of memory. And the problem arises when > specified memory size is large enough to take up all GDI's heap... > > Sorry for the long-winded description of the problem, but I'm not sure > where and how this should be fixed (is it wined3d issue or should GDI > have its heap enlarged?), otherwise I'd do it myself... > > Regards, > Rok > -=-=-=-=-=- > Never say "Never" unless it is to say "Never Give Up." > -=-=-=-=-=--=-=-=-=-=- > * Generated by TagZilla 0.066 * http://tagzilla.mozdev.org * > > From frank.richter at gmail.com Sun Feb 25 19:12:13 2007 From: frank.richter at gmail.com (Frank Richter) Date: Sun Feb 25 19:12:31 2007 Subject: Wine and XP Themes In-Reply-To: <45E21CBD.9080609@kievinfo.com> References: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org> <45E21CBD.9080609@kievinfo.com> Message-ID: On 26.02.2007 00:33, Vitaliy Margolen wrote: > Oh and yeah the only "workaround" is not using themes at all. They are > buggy and never worked right anyway. They are an extra hackish layer on > top of some controls. The comctl32 controls all do theming "natively". The subclassing is done only for control residing in user32 (the motivation was to avoid copying and pasting all the control implementations from user32 to comctl32, as Microsoft supposedly did). WRT speed: themes usually use alpha-blending extensively; however, the speed of Wine's AlphaBlend() can almost be measured in geological terms; so at least part of the performance problem can be found there. -f.r. From stefan at codeweavers.com Sun Feb 25 19:36:24 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Sun Feb 25 19:37:02 2007 Subject: wined3d: Use application provided fog range when fog is enabled. In-Reply-To: <45E231C4.5060108@kievinfo.com> References: <45E231C4.5060108@kievinfo.com> Message-ID: <200702260236.56935.stefan@codeweavers.com> Am Montag 26 Februar 2007 02:03 schrieb Vitaliy Margolen: > This should fix fog issues with PoP SoT. > --- > dlls/wined3d/state.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) Just wanted to add that this would fix the fixed function Z vs specular color alpha selection with table and vertex fog. Vertex shaders seem to be treated as transformed vertices. That said, the way the fixed function pipeline uses was developed by looking at what games need. The patch Vitaly sent looks good to me, but if there are any regressions I will have to try to write a unit test(though it will be tricky due to the pixel exactness thingy) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070226/d8e2d8cb/attachment.pgp From dmitry at codeweavers.com Sun Feb 25 21:18:29 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Sun Feb 25 21:18:39 2007 Subject: Wine and XP Themes References: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org><45E21CBD.9080609@kievinfo.com> Message-ID: <00b201c75954$cdde2080$0100a8c0@DMITRY> "Frank Richter" wrote: > The comctl32 controls all do theming "natively". The subclassing is done > only for control residing in user32 (the motivation was to avoid copying > and pasting all the control implementations from user32 to comctl32, as > Microsoft supposedly did). Sounds like a deja-vu: http://www.winehq.org/?issue=267#Theming%20Revisited -- Dmitry. From scott at open-vote.org Sun Feb 25 22:29:00 2007 From: scott at open-vote.org (Scott Ritchie) Date: Sun Feb 25 22:50:17 2007 Subject: We should have a .desktop file for the Uninstaller application Message-ID: <1172464140.15155.2.camel@scott-desktop> As it is, most people don't even know this handy uninstaller applet exists. So let's fix that. Thanks, Scott Ritchie From truiken at gmail.com Sun Feb 25 22:51:43 2007 From: truiken at gmail.com (James Hawkins) Date: Sun Feb 25 22:51:47 2007 Subject: [2/4 revised] msi: Expand IDL file to contain all OLE automation interfaces. In-Reply-To: <1172464988.11845.12.camel@misha-laptop> References: <1172464988.11845.12.camel@misha-laptop> Message-ID: <22821af30702252051o65b0299an1794b8ad39d8ae9f@mail.gmail.com> On 2/25/07, Misha Koshelev wrote: > This patch expands the IDL to contain all OLE automation interfaces that > the freely downloadable MS Windows Installer contains, and adds a > msiserver_dispids.h file that has define statements for all the dispids. > > Changelog: > > * msi: Expand IDL file to contain all OLE automation interfaces. > * Copyright (C) 2007 Mike McCormack + * Misha Koshelev You have to repeat the Copyright (C) 2007 part for your name. + [id(DISPID_INSTALLER_OPENDATABASE)] + Database* OpenDatabase( + [in] BSTR DatabasePath, + [in] VARIANT OpenMode); + [id(DISPID_INSTALLER_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation( + [in] BSTR PackagePath, + [in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_INSTALLER_ENABLELOG)] + void EnableLog( + [in] BSTR LogMode, + [in] BSTR LogFile); Did you copy and paste this from OleView? This formatting is ridiculous. -- James Hawkins From truiken at gmail.com Sun Feb 25 22:55:53 2007 From: truiken at gmail.com (James Hawkins) Date: Sun Feb 25 22:56:01 2007 Subject: [3/4 revised] msi: Add partial, expandable OLE automation support. In-Reply-To: <1172465150.11845.17.camel@misha-laptop> References: <1172465150.11845.17.camel@misha-laptop> Message-ID: <22821af30702252055x33fffdaau3e27f6cc1c05618@mail.gmail.com> On 2/25/07, Misha Koshelev wrote: > This patch adds OLE automation support to MSI. It does this by creating > a wrapper class, which implements any of the OLE automation classes as > long as a function is given which is called from within the wrapper > classes invoke method after appropriate error checking. Basic > functionality is implemented, and it is fairly straightforward to add > the rest as the methods are all already implemented as functions in the > DLL. > +/* + * If you would like to implement a new automation function/object, look towards the bottom of this + * file for the "meat and potatoes" section. + */ + +/* FIXME: I don't know how big this should be */ +#define MAX_MSI_STRING 1000 + +/* + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just + * need to implement Invoke function for each dispinterface that is called from within + * the AutomationObject Invoke function which performs error checking, and pass the new + * function to create_automation_object. + */ + +typedef interface AutomationObject AutomationObject; + +interface AutomationObject { + /* + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo + */ + const IDispatchVtbl *lpVtbl; + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; + + /* Object reference count */ + LONG ref; + + /* Clsid for this class and it's appropriate ITypeInfo object */ + LPCLSID clsid; + ITypeInfo *iTypeInfo; + + /* The MSI handle of the current object */ + MSIHANDLE msiHandle; + + /* A function that is called from IDispatch::Invoke, specific to this type of object. By the + * time this function is called, basic error checking has been done in the AutomationObject + * Invoke function */ + HRESULT (STDMETHODCALLTYPE *funcInvoke)( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr); +}; You went a little comment crazy here (and elsewhere). You should tone it down a bit. Good code explains itself and requires little or no commenting. + /* + * Perform a sanity check on the parameters. + */ + if ( (This==0) || (ppvObject==0) ) + return E_INVALIDARG; + + /* + * Initialize the return parameter. + */ + *ppvObject = 0; + + /* + * Compare the riid with the interface IDs implemented by this object. + */ + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IDispatch) || IsEqualGUID(riid, This->clsid)) + *ppvObject = This; + else if (IsEqualGUID(riid, &IID_IProvideClassInfo)) + *ppvObject = (IProvideClassInfo*)&(This->lpvtblIProvideClassInfo); + else if (IsEqualGUID(riid, &IID_IProvideClassInfo2)) + *ppvObject = (IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2); + else if (IsEqualGUID(riid, &IID_IProvideMultipleClassInfo)) + *ppvObject = (IProvideMultipleClassInfo*)&(This->lpvtblIProvideMultipleClassInfo); + + /* + * Check that we obtained an interface. + */ + if ((*ppvObject)==0) + { + TRACE("() : asking for unsupported interface %s\n",debugstr_guid(riid)); + return E_NOINTERFACE; + } + + /* + * Query Interface always increases the reference count by one when it is + * successful + */ + IClassFactory_AddRef(iface); + + return S_OK; +} Way too many comments. It may seem like nitpicking, but the comments clutter up the code and don't provide any useful information. -- James Hawkins From jrliggett at cox.net Sun Feb 25 23:11:42 2007 From: jrliggett at cox.net (James Liggett) Date: Sun Feb 25 23:14:28 2007 Subject: We should have a .desktop file for the Uninstaller application In-Reply-To: <1172464140.15155.2.camel@scott-desktop> References: <1172464140.15155.2.camel@scott-desktop> Message-ID: <1172466702.8846.1.camel@james> On Sun, 2007-02-25 at 20:29 -0800, Scott Ritchie wrote: > As it is, most people don't even know this handy uninstaller applet > exists. So let's fix that. Good idea. And while we're at it, why not one for winecfg too? James From wine-devel at kievinfo.com Sun Feb 25 23:26:40 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Sun Feb 25 23:27:14 2007 Subject: We should have a .desktop file for the Uninstaller application In-Reply-To: <1172466702.8846.1.camel@james> References: <1172464140.15155.2.camel@scott-desktop> <1172466702.8846.1.camel@james> Message-ID: <45E26F90.2090605@kievinfo.com> James Liggett wrote: > On Sun, 2007-02-25 at 20:29 -0800, Scott Ritchie wrote: >> As it is, most people don't even know this handy uninstaller applet >> exists. So let's fix that. > Good idea. And while we're at it, why not one for winecfg too? > > James > I was actually thinking about automatically creating those and other entries from wineshelllink whenever it creates Wine menu entry for the first time. However it would have to be aware of the WINEPREFIX and create separate entries for at least winecfg and uninstaller. So it's kind of defeats the propose of making it easy. Vitaliy. From xixsimplicityxix at gmail.com Sun Feb 25 23:59:06 2007 From: xixsimplicityxix at gmail.com (John Smith) Date: Sun Feb 25 23:59:11 2007 Subject: wine and msys rxvt.exe In-Reply-To: <45E18D06.80603@codeweavers.com> References: <200702252052.44341.wes.parish@paradise.net.nz> <45E18D06.80603@codeweavers.com> Message-ID: <78a7dad00702252159w7d326819j59d168d609bb4680@mail.gmail.com> If I recall correctly, MSYS is the mingw linux environment emulated on windows. rxvt would be the terminal used in the msys environment. Hopefully this will be of some use, John Klehm On 2/25/07, Robert Shearman wrote: > > Wesley Parish wrote: > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > libGL warning: 3D driver claims to not support visual 0x4b > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > implemented > > fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x00000001,0x68f494) stub > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > 0x68ef0c 8 > > L"DOMAIN" (nil)) > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > failed to load libX11.dllbash-3.1$ > > > > bash-3.1$ wine --version > > wine-0.9.29 > > > > Those are the error messages. > > > > My version of wine is a little old. Have the fixme's been fixed in the > latest > > wine? > > > > What is the program supposed to do? > > -- > Rob Shearman > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070225/26827f31/attachment.html From dmitry at codeweavers.com Mon Feb 26 00:25:10 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Mon Feb 26 00:25:31 2007 Subject: wine and msys rxvt.exe References: <200702252052.44341.wes.parish@paradise.net.nz> Message-ID: <001f01c7596e$ea763b00$0100a8c0@DMITRY> "Wesley Parish" wrote: > failed to load libX11.dll Looks like rxvt.exe is linked to an MSys provided X11 libraries that require a Windows X11 sever to be present and running. That's a sort of layer on layer and I don't think that there is someone who wants to make this configuration work. -- Dmitry. From wes.parish at paradise.net.nz Mon Feb 26 02:58:58 2007 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Mon Feb 26 02:55:13 2007 Subject: wine and msys rxvt.exe In-Reply-To: <78a7dad00702252159w7d326819j59d168d609bb4680@mail.gmail.com> References: <200702252052.44341.wes.parish@paradise.net.nz> <45E18D06.80603@codeweavers.com> <78a7dad00702252159w7d326819j59d168d609bb4680@mail.gmail.com> Message-ID: <200702262159.00175.wes.parish@paradise.net.nz> That is the case. cygwin's just one of several POSIX environments on the Win32 platform, and msys is the other FOSS POSIX environment on Win32. I thought it would be a good test. I will have to upgrade my Wine version, admittedly ... Wesley Parish On Monday 26 February 2007 18:59, John Smith wrote: > If I recall correctly, MSYS is the mingw linux environment emulated on > windows. rxvt would be the terminal used in the msys environment. > > Hopefully this will be of some use, > John Klehm > > On 2/25/07, Robert Shearman wrote: > > Wesley Parish wrote: > > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > > libGL warning: 3D driver claims to not support visual 0x4b > > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > > > > implemented > > > > > fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x00000001,0x68f494) stub > > > fixme:advapi:LsaClose (0xcafe) stub > > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > > > > 0x68ef0c 8 > > > > > L"DOMAIN" (nil)) > > > fixme:advapi:LsaClose (0xcafe) stub > > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > > failed to load libX11.dllbash-3.1$ > > > > > > bash-3.1$ wine --version > > > wine-0.9.29 > > > > > > Those are the error messages. > > > > > > My version of wine is a little old. Have the fixme's been fixed in the > > > > latest > > > > > wine? > > > > What is the program supposed to do? > > > > -- > > Rob Shearman -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. From wes.parish at paradise.net.nz Mon Feb 26 03:07:05 2007 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Mon Feb 26 03:03:17 2007 Subject: wine and msys rxvt.exe In-Reply-To: <200702250930.44500.research@science.su> References: <200702252052.44341.wes.parish@paradise.net.nz> <200702250930.44500.research@science.su> Message-ID: <200702262207.07263.wes.parish@paradise.net.nz> On Sunday 25 February 2007 22:30, L. Rahyen wrote: > Sunday February 25 2007 07:52?Wesley Parish ????????: > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > libGL warning: 3D driver claims to not support visual 0x4b > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > > implemented fixme:advapi:LsaOpenPolicy > > ((null),0x68f478,0x00000001,0x68f494) stub fixme:advapi:LsaClose (0xcafe) > > stub > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > > 0x68ef0c 8 L"DOMAIN" (nil)) > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > failed to load libX11.dllbash-3.1$ > > > > bash-3.1$ wine --version > > wine-0.9.29 > > > > Those are the error messages. > > > > My version of wine is a little old. Have the fixme's been fixed in the > > latest wine? > > Fixmes doesn't mean problems if there is no problems. This is rule of > thumb. If you want to get help please tell what problems you see when > trying to run the software. And if you can give a link to download demo > version of the software (or full version if it's free). Can do, will do. http://www.mingw.org/msys.shtml http://sourceforge.net/project/showfiles.php?group_id=2435 It's free. -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. From julliard at winehq.org Mon Feb 26 07:30:17 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 07:30:19 2007 Subject: dlls: Move the 16-bit dll stubs to the appropriate subdirectories. In-Reply-To: <45E047E6.2070705@didntduck.org> (Brian Gerst's message of "Sat\, 24 Feb 2007 09\:12\:54 -0500") References: <45E047E6.2070705@didntduck.org> Message-ID: <87y7mlf3me.fsf@wine.dyndns.org> Brian Gerst writes: >>From 36873109949f308cc9d34f4df9bb0af4c219262b Mon Sep 17 00:00:00 2001 > From: Brian Gerst > Date: Sat, 24 Feb 2007 08:59:48 -0500 > Subject: dlls: Move the 16-bit dll stubs to the appropriate subdirectories. This won't work, they won't be found when running inside the build tree. -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Mon Feb 26 07:10:29 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 07:49:57 2007 Subject: comctl32: rebar[2/3]: WM_SETFONT should send a RBN_HEIGHTCHANGED if necessary (with testcase) In-Reply-To: <45E17602.2030506@zalewski.pl> (=?utf-8?Q?Miko=C5=82aj?= Zalewski's message of "Sun\, 25 Feb 2007 12\:41\:54 +0100") References: <45E17602.2030506@zalewski.pl> Message-ID: <873b4tgj3u.fsf@wine.dyndns.org> Miko?aj Zalewski writes: > This allows as to eliminate the third parameter of REBAR_Layout. > From 2edae3656159e84a0366b65e1bd1d13e3089dc97 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= > Date: Mon, 19 Feb 2007 20:42:08 +0100 > Subject: [PATCH] comctl32: rebar: WM_SETFONT should send a RBN_HEIGHTCHANGED if necessary (with testcase) The tests fail here: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so rebar.c && touch rebar.ok rebar.c:696: Test failed: (int)SendMessage(hRebar, RB_GETROWCOUNT, 0, 0) expected 2 got 1 rebar.c:696: Test failed: invalid rect (notify) (-1,-1) (-1,-1) - expected (0,0) (672,20) make: *** [rebar.ok] Error 2 -- Alexandre Julliard julliard@winehq.org From mk144210 at bcm.tmc.edu Mon Feb 26 08:25:47 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 26 08:26:24 2007 Subject: [2/4 revised] msi: Expand IDL file to contain all OLE automation interfaces. In-Reply-To: <22821af30702252051o65b0299an1794b8ad39d8ae9f@mail.gmail.com> References: <1172464988.11845.12.camel@misha-laptop> <22821af30702252051o65b0299an1794b8ad39d8ae9f@mail.gmail.com> Message-ID: <1172499947.2464.1.camel@misha-laptop> On Sun, 2007-02-25 at 22:51 -0600, James Hawkins wrote: > On 2/25/07, Misha Koshelev wrote: > > This patch expands the IDL to contain all OLE automation interfaces that > > the freely downloadable MS Windows Installer contains, and adds a > > msiserver_dispids.h file that has define statements for all the dispids. > > > > Changelog: > > > > * msi: Expand IDL file to contain all OLE automation interfaces. > > > > * Copyright (C) 2007 Mike McCormack > + * Misha Koshelev > > You have to repeat the Copyright (C) 2007 part for your name. It seems from doing a find . -name \*.idl -exec head {} \; -print that you are generally correct, but the formatting for copyright notices does vary. dlls/stdole32.tlb/std_ole_v1.idl and std_ole_v2.idl in that directory has: /* * Copyright (C) 2003 Robert Shearman * 2005 Huw Davies which is where I got the idea to do mine that way in the first place. > > + [id(DISPID_INSTALLER_OPENDATABASE)] > + Database* OpenDatabase( > + [in] BSTR > DatabasePath, > + [in] > VARIANT OpenMode); > + [id(DISPID_INSTALLER_SUMMARYINFORMATION), propget] > + SummaryInfo* SummaryInformation( > + > [in] BSTR PackagePath, > + > [in, optional, defaultvalue(0)] long UpdateCount); > + [id(DISPID_INSTALLER_ENABLELOG)] > + void EnableLog( > + [in] BSTR LogMode, > + [in] BSTR LogFile); > > Did you copy and paste this from OleView? This formatting is ridiculous. > From rob at codeweavers.com Mon Feb 26 08:53:25 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 26 08:53:58 2007 Subject: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions Message-ID: <45E2F465.3070406@codeweavers.com> Hi Alexandre, A patch of yours from 2.5 years ago (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) changed the behaviour to not send WM_GETTEXT any more. My experiments on Windows show that WM_GETTEXT should be used. Can you remember what the reasoning behind the change in this patch was? -- Rob Shearman From julliard at winehq.org Mon Feb 26 09:20:29 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 09:20:36 2007 Subject: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions In-Reply-To: <45E2F465.3070406@codeweavers.com> (Robert Shearman's message of "Mon\, 26 Feb 2007 14\:53\:25 +0000") References: <45E2F465.3070406@codeweavers.com> Message-ID: <87slcteyiq.fsf@wine.dyndns.org> Robert Shearman writes: > Hi Alexandre, > > A patch of yours from 2.5 years ago > (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) > changed the behaviour to not send WM_GETTEXT any more. My experiments > on Windows show that WM_GETTEXT should be used. Can you remember what > the reasoning behind the change in this patch was? Probably to avoid potential deadlocks; I'm not sure there's one correct way, IIRC Win2k doesn't send them but XP does. Do you have something that depends on receiving them? -- Alexandre Julliard julliard@winehq.org From rob at codeweavers.com Mon Feb 26 09:23:19 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 26 09:24:15 2007 Subject: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions In-Reply-To: <87slcteyiq.fsf@wine.dyndns.org> References: <45E2F465.3070406@codeweavers.com> <87slcteyiq.fsf@wine.dyndns.org> Message-ID: <45E2FB67.5030307@codeweavers.com> Alexandre Julliard wrote: > Robert Shearman writes: > > >> Hi Alexandre, >> >> A patch of yours from 2.5 years ago >> (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) >> changed the behaviour to not send WM_GETTEXT any more. My experiments >> on Windows show that WM_GETTEXT should be used. Can you remember what >> the reasoning behind the change in this patch was? >> > > Probably to avoid potential deadlocks; I'm not sure there's one > correct way, IIRC Win2k doesn't send them but XP does. Do you have > something that depends on receiving them? Yes, the table windows in the query designer in Access 2003. Access 2003 works on Windows 2000+. -- Rob Shearman From stefan at codeweavers.com Mon Feb 26 09:31:51 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Mon Feb 26 09:31:46 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <45E1F81C.5040805@email.si> References: <45E1F81C.5040805@email.si> Message-ID: <200702261631.52060.stefan@codeweavers.com> Am Sonntag 25 Februar 2007 21:57 schrieb Rok Mandeljc: > Hey all, > Now, when the game is run with 64MB of VideoMemorySize, upon reaching > the same point, IDirectDrawImpl_CreateNewSurface returns > WINED3DERR_OUTOFVIDEOMEMORY (because of > "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in > D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. > So it seems Baldur's Gate 2 is trying to create as many surfaces as > possible before running out of memory. And the problem arises when > specified memory size is large enough to take up all GDI's heap... Now that seems interesting. Actually, I have never had a 2D application creating that much surfaces, and the old ddraw code only advertised 8 mb of mem. It might be an out of memory somewhere, but not sure how and why. You could try opengl surfaces. Those do not have a DIB section, unless the app calls GetDC on the surface From hverbeet at gmail.com Mon Feb 26 09:36:01 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 26 09:36:14 2007 Subject: [3/12 WineD3D/DDraw: Forward DDSCL_MULTITHREADED to WineD3D In-Reply-To: <200702261348.29128.stefan@codeweavers.com> References: <200702261348.29128.stefan@codeweavers.com> Message-ID: On 26/02/07, Stefan D?singer wrote: > Note: that this patch conflicts with the ddraw thread safety patch. After this > patch here is applied, I will send an updated thread safety patch for the > ddraw implementation > What exactly is this supposed to fix? We already pass the behaviour flags through to IWineD3DImpl_CreateDevice(), so shouldn't wined3d just handle it there? From julliard at winehq.org Mon Feb 26 09:37:38 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 09:37:40 2007 Subject: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions In-Reply-To: <45E2FB67.5030307@codeweavers.com> (Robert Shearman's message of "Mon\, 26 Feb 2007 15\:23\:19 +0000") References: <45E2F465.3070406@codeweavers.com> <87slcteyiq.fsf@wine.dyndns.org> <45E2FB67.5030307@codeweavers.com> Message-ID: <87bqjhexq5.fsf@wine.dyndns.org> Robert Shearman writes: > Yes, the table windows in the query designer in Access 2003. Access > 2003 works on Windows 2000+. Maybe it's NT4 that doesn't send them then. Anyway, if the app needs them I don't have a problem with adding them back. -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Mon Feb 26 09:48:15 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Mon Feb 26 09:48:25 2007 Subject: [9/12] WineD3D: When multithreading, call glFinish after drawing In-Reply-To: <200702261351.01646.stefan@codeweavers.com> References: <200702261351.01646.stefan@codeweavers.com> Message-ID: Would GL_NV_fence be usefull here? From flexo at holycrap.org Mon Feb 26 10:04:15 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Mon Feb 26 09:56:26 2007 Subject: Wine and XP Themes In-Reply-To: References: <1172432331.4154.3.camel@conroe.oakcourt.dyndns.org> <45E21CBD.9080609@kievinfo.com> Message-ID: <45E304FF.7020509@holycrap.org> Frank Richter wrote: > WRT speed: themes usually use alpha-blending extensively; however, the > speed of Wine's AlphaBlend() can almost be measured in geological terms; Why is that? Looking at it it seems to be using XRender - since theming doesn't require Aero and stuff what way would there be to speed it up? (I admit I didn't really read the code. :) Felix From mk144210 at bcm.tmc.edu Sun Feb 25 22:50:37 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Mon Feb 26 10:18:20 2007 Subject: msi: Add full JScript/VBScript support and partial expandable OLE automation support. [PATCH 3/3] In-Reply-To: <45E1885A.9040809@codeweavers.com> References: <1172298914.12860.15.camel@misha-laptop> <45E1885A.9040809@codeweavers.com> Message-ID: <1172465437.11845.25.camel@misha-laptop> On Sun, 2007-02-25 at 13:00 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > +/* Macros to get pointer to AutomationObject) from the other VTables. */ > > > > Typo with extra ")" here. > > > +HRESULT WINAPI SessionImpl_Invoke( > > + AutomationObject* This, > > + DISPID dispIdMember, > > + REFIID riid, > > + LCID lcid, > > + WORD wFlags, > > + DISPPARAMS* pDispParams, > > + VARIANT* pVarResult, > > + EXCEPINFO* pExcepInfo, > > + UINT* puArgErr) > > +{ > > + WCHAR szString[MAX_MSI_STRING]; > > + DWORD dwLen = MAX_MSI_STRING; > > + IDispatch *iDispatch = NULL; > > + MSIHANDLE msiHandle; > > + LANGID langId; > > + UINT ret; > > + INSTALLSTATE iInstalled, iAction; > > > > Some error checking here would be good, like you do in > AutomationObject_Invoke. > > > + > > + switch (dispIdMember) > > + { > > > ... > > +/* > > + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just > > + * need to implement Invoke function for each dispinterface and pass the new function > > + * to create_automation_object. > > + */ > > + > > +typedef struct { > > + /* > > + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo > > + */ > > + const IDispatchVtbl *lpVtbl; > > + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; > > + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; > > + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; > > + > > + /* Object reference count */ > > + LONG ref; > > + > > + /* Clsid for this class and it's appropriate ITypeInfo object */ > > + LPCLSID clsid; > > + ITypeInfo *iTypeInfo; > > + > > + /* The MSI handle of the current object */ > > + MSIHANDLE msiHandle;; > > + > > + /* A function that is called from IDispatch::Invoke, specific to this type of object */ > > + LPVOID funcInvoke; > > +} AutomationObject; > > > > You shouldn't need to expose the implementation details of > AutomationObject outside of automation.c. > > > + > > +/* This is the function that one needs to call to create an automation object. */ > > +extern HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke); > > > > It is dangerous to use LPVOID as the type to pass a function in. > > > + > > +/* We need to expose these functions because our IActiveScriptSite calls it */ > > +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); > > +extern HRESULT WINAPI SessionImpl_Invoke(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*); > > + > > +/* Disp Ids > > + * (not complete, look in msiserver.idl to add more) */ > > +typedef enum { > > + RecordDispId_StringData=1, > > + RecordDispId_IntegerData, > > + RecordDispId_SetStream, > > + RecordDispId_ReadStream, > > + RecordDispId_FieldCount, > > + RecordDispId_IsNull, > > + RecordDispId_DataSize, > > + RecordDispId_ClearData, > > + RecordDispId_FormatText > > +} RecordDispId; > > + > > +typedef enum { > > + ViewDispId_Execute=1, > > + ViewDispId_Fetch, > > + ViewDispId_Modify, > > + ViewDispId_Close, > > + ViewDispId_ColumnInfo, > > + ViewDispId_GetError > > +} ViewDispId; > > + > > +typedef enum { > > + DatabaseDispId_DatabaseState=1, > > + DatabaseDispId_SummaryInformation, > > + DatabaseDispId_OpenView, > > + DatabaseDispId_Commit, > > + DatabaseDispId_PrimaryKeys, > > + DatabaseDispId_Import, > > + DatabaseDispId_Export, > > + DatabaseDispId_Merge, > > + DatabaseDispId_GenerateTransform, > > + DatabaseDispId_ApplyTransform, > > + DatabaseDispId_EnableUIPreview, > > + DatabaseDispId_TablePersistent, > > + DatabaseDispId_CreateTransformSummaryInfo > > +} DatabaseDispId; > > + > > +typedef enum { > > + SessionDispId_Installer=1, > > + SessionDispId_Property, > > + SessionDispId_Language, > > + SessionDispId_Mode, > > + SessionDispId_Database, > > + SessionDispId_SourcePath, > > + SessionDispId_TargetPath, > > + SessionDispId_DoAction, > > + SessionDispId_Sequence, > > + SessionDispId_EvaluateCondition, > > + SessionDispId_FormatRecord, > > + SessionDispId_Message, > > + SessionDispId_FeatureCurrentState, > > + SessionDispId_FeatureRequestState, > > + SessionDispId_FeatureValidStates, > > + SessionDispId_FeatureCost, > > + SessionDispId_ComponentCurrentState, > > + SessionDispId_ComponentRequestState, > > + SessionDispId_SetInstallLevel, > > + SessionDispId_VerifyDiskSpace, > > + SessionDispId_ProductProperty, > > + SessionDispId_FeatureInfo, > > + SessionDispId_ComponentCost > > +} SessionDispId; > > > > See dlls/oleaut32/tests/tmarshal_dispids.h and > dlls/oleaut32/tests/tmarshal.idl for how to use DISPIDs properly. > > > +typedef struct { > > + IActiveScriptSite lpVtbl; > > + AutomationObject *session; > > > > You don't actually access this as anything other than an IDispatch > object, so you might as well change to "IDispatch *session". > > > +LPCWSTR read_script_from_file(LPCWSTR szFile, INT type) > > > > Should be static. > > > +/* JScript or VBScript? */ > > +LPCWSTR progid_from_type(INT type) > > > > Should also be static. > > > + > > +/* > > + * Call a script. This is our meat and potatoes. > > + * - Currently, since the function is relatively new, it will always end up returning S_OK. > > + * Think of it like a bonus feature, we can run the script - great. If we have a problem, > > + * we are no worse off than if this function had not been called. > > + */ > > +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) > > +{ > > + LPCWSTR script = NULL, progId = NULL; > > + HRESULT hr; > > + IActiveScript *iActiveScript = NULL; > > + IActiveScriptParse *iActiveScriptParse = NULL; > > > > I haven't seen this variable notation style before. In Hungarian > notation "p" is used instead of "i" to show a pointer to an object > exposing the interface declared. > I have implemented all the changes you outlined (thanks a lot) in this and your other email, with the exception of the extra error checking in each of the individual Invoke functions as they are called from within AutomationObject::Invoke after the error checking already occurs. What do you think? Thanks Misha p.s. The 5th patch is not a part of my submission, but is just a hack I used to make the IDL file with the dispids using oleview. This patch will make oleview use the DISPID_PARENT_MEMBER notation for ids and will output the include file to standard output. Thought maybe it would be useful for someone. -------------- next part -------------- From bfde4dd7c028bf9e708d12b92a8e8439cb3358f1 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 25 Feb 2007 22:19:22 -0600 Subject: msi: Added handlers for JScript/VBScript actions that call one script function. --- dlls/msi/custom.c | 252 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 252 insertions(+), 0 deletions(-) diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index ba5c825..7cbbf40 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -58,6 +58,14 @@ static UINT HANDLE_CustomType50(MSIPACKA LPCWSTR target, const INT type, LPCWSTR action); static UINT HANDLE_CustomType34(MSIPACKAGE *package, LPCWSTR source, LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action); typedef UINT (WINAPI *MsiCustomActionEntryPoint)( MSIHANDLE ); @@ -266,6 +274,22 @@ UINT ACTION_CustomAction(MSIPACKAGE *pac rc = MSI_SetPropertyW(package,source,deformated); msi_free(deformated); break; + case 37: /* JScript/VBScript text stored in target column. */ + case 38: + rc = HANDLE_CustomType37_38(package,source,target,type,action); + break; + case 5: + case 6: /* JScript/VBScript file stored in a Binary table stream. */ + rc = HANDLE_CustomType5_6(package,source,target,type,action); + break; + case 21: /* JScript/VBScript file installed with the product. */ + case 22: + rc = HANDLE_CustomType21_22(package,source,target,type,action); + break; + case 53: /* JScript/VBScript text specified by a property value. */ + case 54: + rc = HANDLE_CustomType53_54(package,source,target,type,action); + break; default: FIXME("UNHANDLED ACTION TYPE %i (%s %s)\n", type & CUSTOM_ACTION_TYPE_MASK, debugstr_w(source), @@ -855,6 +879,234 @@ static UINT HANDLE_CustomType34(MSIPACKA return wait_process_handle(package, type, info.hProcess, action); } +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + FIXME("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + r = S_OK; + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} + +static DWORD WINAPI ScriptThread( LPVOID arg ) +{ + LPGUID guid = arg; + DWORD rc = 0; + + TRACE("custom action (%x) started\n", GetCurrentThreadId() ); + + rc = ACTION_CallScript( guid ); + + TRACE("custom action (%x) returned %i\n", GetCurrentThreadId(), rc ); + + MsiCloseAllHandles(); + return rc; +} + +static msi_custom_action_info *do_msidbCustomActionTypeScript( + MSIPACKAGE *package, INT type, LPCWSTR script, LPCWSTR function, LPCWSTR action ) +{ + msi_custom_action_info *info; + + info = msi_alloc( sizeof *info ); + if (!info) + return NULL; + + msiobj_addref( &package->hdr ); + info->package = package; + info->type = type; + info->function = strdupW( function ); + info->dllname = strdupW( script ); + info->action = strdupW( action ); + CoCreateGuid( &info->guid ); + + EnterCriticalSection( &msi_custom_action_cs ); + list_add_tail( &msi_pending_custom_actions, &info->entry ); + LeaveCriticalSection( &msi_custom_action_cs ); + + info->handle = CreateThread( NULL, 0, ScriptThread, &info->guid, 0, NULL ); + if (!info->handle) + { + free_custom_action_data( info ); + return NULL; + } + + return info; +} + +static UINT HANDLE_CustomType37_38(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + info = do_msidbCustomActionTypeScript( package, type, target, NULL, action ); + + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType5_6(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + static const WCHAR query[] = { + 'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', + '`','B','i' ,'n','a','r','y','`',' ','W','H','E','R','E',' ', + '`','N','a','m','e','`',' ','=',' ','\'','%','s','\'',0}; + MSIRECORD *row = 0; + msi_custom_action_info *info; + CHAR *buffer = NULL; + WCHAR *bufferw = NULL; + DWORD sz = 0, szw = 0; + UINT r; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + row = MSI_QueryGetRecord(package->db, query, source); + if (!row) + return ERROR_FUNCTION_FAILED; + + r = MSI_RecordReadStream(row, 2, NULL, &sz); + if (r != ERROR_SUCCESS) + return r; + + buffer = msi_alloc(sizeof(CHAR)*(sz+1)); + if (!buffer) + return ERROR_FUNCTION_FAILED; + + r = MSI_RecordReadStream(row, 2, buffer, &sz); + if (r != ERROR_SUCCESS) + { + msi_free(buffer); + return r; + } + + buffer[sz] = 0; + szw = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, 0); + bufferw = msi_alloc(sizeof(WCHAR)*szw); + if (!szw) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + r = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, szw); + msi_free(buffer); + if (!r) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + info = do_msidbCustomActionTypeScript( package, type, bufferw, target, action ); + msi_free(bufferw); + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType21_22(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + MSIFILE *file; + HANDLE hFile; + DWORD sz, szw, szHighWord = 0, read; + CHAR *buffer=NULL; + WCHAR *bufferw=NULL; + BOOL bRet; + UINT r; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + file = get_loaded_file(package,source); + if (!file) + { + ERR("invalid file key %s\n", debugstr_w(source)); + return ERROR_FUNCTION_FAILED; + } + + hFile = CreateFileW(file->TargetPath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); + if (hFile == INVALID_HANDLE_VALUE) + return ERROR_FUNCTION_FAILED; + + sz = GetFileSize(hFile, &szHighWord); + if (sz == INVALID_FILE_SIZE || szHighWord != 0) + { + CloseHandle(hFile); + return ERROR_FUNCTION_FAILED; + } + + buffer = msi_alloc(sizeof(CHAR)*(sz+1)); + if (!buffer) + { + CloseHandle(hFile); + return ERROR_FUNCTION_FAILED; + } + + bRet = ReadFile(hFile, (LPVOID)buffer, sz, &read, NULL); + CloseHandle(hFile); + if (!bRet); + { + msi_free(buffer); + return ERROR_FUNCTION_FAILED; + } + + buffer[read] = 0; + szw = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, 0); + bufferw = msi_alloc(sizeof(WCHAR)*szw); + if (!szw) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + r = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, szw); + msi_free(buffer); + if (!r) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + info = do_msidbCustomActionTypeScript( package, type, bufferw, target, action ); + msi_free(bufferw); + return wait_thread_handle( info ); +} + +static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, + LPCWSTR target, const INT type, LPCWSTR action) +{ + msi_custom_action_info *info; + WCHAR *prop; + + TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); + + prop = msi_dup_property(package,source); + if (!prop) + return ERROR_SUCCESS; + + info = do_msidbCustomActionTypeScript( package, type, prop, NULL, action ); + msi_free(prop); + return wait_thread_handle( info ); +} + void ACTION_FinishCustomActions(MSIPACKAGE* package) { struct list *item; -- 1.4.1 -------------- next part -------------- From e46996893110b24d0e8a15ef7df158563bc56a1c Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 25 Feb 2007 22:22:02 -0600 Subject: msi: Expand IDL file to contain all OLE automation interfaces. --- dlls/msi/msiserver.idl | 721 ++++++++++++++++++++++++++++++++++++++---- dlls/msi/msiserver_dispids.h | 140 ++++++++ 2 files changed, 798 insertions(+), 63 deletions(-) diff --git a/dlls/msi/msiserver.idl b/dlls/msi/msiserver.idl index 9966d90..d5b140c 100644 --- a/dlls/msi/msiserver.idl +++ b/dlls/msi/msiserver.idl @@ -1,5 +1,6 @@ /* * Copyright (C) 2007 Mike McCormack + * Misha Koshelev * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -16,14 +17,21 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +#include "msiserver_dispids.h" import "unknwn.idl"; import "wtypes.idl"; import "objidl.idl"; import "oaidl.idl"; -[ uuid(000C1092-0000-0000-C000-000000000046), version(1.0) ] +[ + uuid(000C1092-0000-0000-C000-000000000046), + version(1.0), + helpstring("Microsoft Windows Installer Object Library") +] library WindowsInstaller { + /* TLib : + * Forward declare all types defined in this typelib */ dispinterface Installer; dispinterface Record; dispinterface Session; @@ -34,90 +42,677 @@ library WindowsInstaller dispinterface FeatureInfo; dispinterface RecordList; dispinterface StringList; - dispinterface Product; - dispinterface Patch; - - [ uuid(000C1090-0000-0000-C000-000000000046) ] - dispinterface Installer - { - properties: - methods: - } - - [ uuid(000C1093-0000-0000-C000-000000000046) ] - dispinterface Record - { - properties: - methods: - } - - [ uuid(000C1095-0000-0000-C000-000000000046) ] - dispinterface StringList - { + + typedef enum { + msiUILevelNoChange = 0, + msiUILevelDefault = 1, + msiUILevelNone = 2, + msiUILevelBasic = 3, + msiUILevelReduced = 4, + msiUILevelFull = 5, + msiUILevelHideCancel = 32, + msiUILevelProgressOnly = 64, + msiUILevelEndDialog = 128 + } MsiUILevel; + + typedef enum { + msiInstallStateNotUsed = -7, + msiInstallStateBadConfig = -6, + msiInstallStateIncomplete = -5, + msiInstallStateSourceAbsent = -4, + msiInstallStateInvalidArg = -2, + msiInstallStateUnknown = -1, + msiInstallStateBroken = 0, + msiInstallStateAdvertised = 1, + msiInstallStateRemoved = 1, + msiInstallStateAbsent = 2, + msiInstallStateLocal = 3, + msiInstallStateSource = 4, + msiInstallStateDefault = 5 + } MsiInstallState; + + typedef enum { + msiReinstallModeFileMissing = 2, + msiReinstallModeFileOlderVersion = 4, + msiReinstallModeFileEqualVersion = 8, + msiReinstallModeFileExact = 16, + msiReinstallModeFileVerify = 32, + msiReinstallModeFileReplace = 64, + msiReinstallModeMachineData = 128, + msiReinstallModeUserData = 256, + msiReinstallModeShortcut = 512, + msiReinstallModePackage = 1024 + } MsiReinstallMode; + + typedef enum { + msiInstallTypeDefault = 0, + msiInstallTypeNetworkImage = 1 + } MsiInstallType; + + typedef enum { + msiInstallModeNoSourceResolution = -3, + msiInstallModeNoDetection = -2, + msiInstallModeExisting = -1, + msiInstallModeDefault = 0 + } MsiInstallMode; + + typedef enum { + msiSignatureInfoCertificate = 0, + msiSignatureInfoHash = 1 + } MsiSignatureInfo; + + typedef enum { + msiReadStreamInteger = 0, + msiReadStreamBytes = 1, + msiReadStreamAnsi = 2, + msiReadStreamDirect = 3 + } MsiReadStream; + + typedef enum { + msiRunModeAdmin = 0, + msiRunModeAdvertise = 1, + msiRunModeMaintenance = 2, + msiRunModeRollbackEnabled = 3, + msiRunModeLogEnabled = 4, + msiRunModeOperations = 5, + msiRunModeRebootAtEnd = 6, + msiRunModeRebootNow = 7, + msiRunModeCabinet = 8, + msiRunModeSourceShortNames = 9, + msiRunModeTargetShortNames = 10, + msiRunModeWindows9x = 12, + msiRunModeZawEnabled = 13, + msiRunModeScheduled = 16, + msiRunModeRollback = 17, + msiRunModeCommit = 18 + } MsiRunMode; + + [ + uuid(000C1090-0000-0000-C000-000000000046), + helpcontext(0x00002328) + ] + dispinterface Installer { properties: + [id(DISPID_INSTALLER_UILEVEL)] + MsiUILevel UILevel; methods: - } + [id(DISPID_INSTALLER_CREATERECORD)] + Record* CreateRecord([in] long Count); + [id(DISPID_INSTALLER_OPENPACKAGE)] + Session* OpenPackage([in] VARIANT PackagePath); + [id(DISPID_INSTALLER_OPENPRODUCT)] + Session* OpenProduct([in] BSTR ProductCode); + [id(DISPID_INSTALLER_OPENDATABASE)] + Database* OpenDatabase( + [in] BSTR DatabasePath, + [in] VARIANT OpenMode); + [id(DISPID_INSTALLER_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation( + [in] BSTR PackagePath, + [in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_INSTALLER_ENABLELOG)] + void EnableLog( + [in] BSTR LogMode, + [in] BSTR LogFile); + [id(DISPID_INSTALLER_INSTALLPRODUCT)] + void InstallProduct( + [in] BSTR PackagePath, + [in, optional, defaultvalue("0")] BSTR PropertyValues); + [id(DISPID_INSTALLER_VERSION), propget] + BSTR Version(); + [id(DISPID_INSTALLER_LASTERRORRECORD)] + Record* LastErrorRecord(); + [id(DISPID_INSTALLER_REGISTRYVALUE)] + BSTR RegistryValue( + [in] VARIANT Root, + [in] BSTR Key, + [in, optional] VARIANT Value); + [id(DISPID_INSTALLER_FILEATTRIBUTES)] + long FileAttributes([in] BSTR FilePath); + [id(DISPID_INSTALLER_FILESIZE)] + long FileSize([in] BSTR FilePath); + [id(DISPID_INSTALLER_FILEVERSION)] + BSTR FileVersion( + [in] BSTR FilePath, + [in, optional] VARIANT Language); + [id(DISPID_INSTALLER_ENVIRONMENT), propget] + BSTR Environment([in] BSTR Variable); + [id(DISPID_INSTALLER_ENVIRONMENT), propput] + void Environment( + [in] BSTR Variable, + [in] BSTR rhs); + [id(DISPID_INSTALLER_PRODUCTSTATE), propget] + MsiInstallState ProductState([in] BSTR Product); + [id(DISPID_INSTALLER_PRODUCTINFO), propget] + BSTR ProductInfo( + [in] BSTR Product, + [in] BSTR Attribute); + [id(DISPID_INSTALLER_CONFIGUREPRODUCT)] + void ConfigureProduct( + [in] BSTR Product, + [in] long InstallLevel, + [in] MsiInstallState InstallState); + [id(DISPID_INSTALLER_REINSTALLPRODUCT)] + void ReinstallProduct( + [in] BSTR Product, + [in] MsiReinstallMode ReinstallMode); + [id(DISPID_INSTALLER_COLLECTUSERINFO)] + void CollectUserInfo([in] BSTR Product); + [id(DISPID_INSTALLER_APPLYPATCH)] + void ApplyPatch( + [in] BSTR PatchPackage, + [in] BSTR InstallPackage, + [in] MsiInstallType InstallType, + [in] BSTR CommandLine); + [id(DISPID_INSTALLER_FEATUREPARENT), propget] + BSTR FeatureParent( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_FEATURESTATE), propget] + MsiInstallState FeatureState( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_USEFEATURE)] + void UseFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallMode InstallMode); + [id(DISPID_INSTALLER_FEATUREUSAGECOUNT), propget] + long FeatureUsageCount( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_FEATUREUSAGEDATE), propget] + DATE FeatureUsageDate( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_CONFIGUREFEATURE)] + void ConfigureFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallState InstallState); + [id(DISPID_INSTALLER_REINSTALLFEATURE)] + void ReinstallFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiReinstallMode ReinstallMode); + [id(DISPID_INSTALLER_PROVIDECOMPONENT)] + BSTR ProvideComponent( + [in] BSTR Product, + [in] BSTR Feature, + [in] BSTR Component, + [in] long InstallMode); + [id(DISPID_INSTALLER_COMPONENTPATH), propget] + BSTR ComponentPath( + [in] BSTR Product, + [in] BSTR Component); + [id(DISPID_INSTALLER_PROVIDEQUALIFIEDCOMPONENT)] + BSTR ProvideQualifiedComponent( + [in] BSTR Category, + [in] BSTR Qualifier, + [in] long InstallMode); + [id(DISPID_INSTALLER_QUALIFIERDESCRIPTION), propget] + BSTR QualifierDescription( + [in] BSTR Category, + [in] BSTR Qualifier); + [id(DISPID_INSTALLER_COMPONENTQUALIFIERS), propget] + StringList* ComponentQualifiers([in] BSTR Category); + [id(DISPID_INSTALLER_PRODUCTS), propget] + StringList* Products(); + [id(DISPID_INSTALLER_FEATURES), propget] + StringList* Features([in] BSTR Product); + [id(DISPID_INSTALLER_COMPONENTS), propget] + StringList* Components(); + [id(DISPID_INSTALLER_COMPONENTCLIENTS), propget] + StringList* ComponentClients([in] BSTR Component); + [id(DISPID_INSTALLER_PATCHES), propget] + StringList* Patches([in] BSTR Product); + [id(DISPID_INSTALLER_RELATEDPRODUCTS), propget] + StringList* RelatedProducts([in] BSTR UpgradeCode); + [id(DISPID_INSTALLER_PATCHINFO), propget] + BSTR PatchInfo( + [in] BSTR Patch, + [in] BSTR Attribute); + [id(DISPID_INSTALLER_PATCHTRANSFORMS), propget] + BSTR PatchTransforms( + [in] BSTR Product, + [in] BSTR Patch); + [id(DISPID_INSTALLER_ADDSOURCE)] + void AddSource( + [in] BSTR Product, + [in] BSTR User, + [in] BSTR Source); + [id(DISPID_INSTALLER_CLEARSOURCELIST)] + void ClearSourceList( + [in] BSTR Product, + [in] BSTR User); + [id(DISPID_INSTALLER_FORCESOURCELISTRESOLUTION)] + void ForceSourceListResolution( + [in] BSTR Product, + [in] BSTR User); + [id(DISPID_INSTALLER_GETSHORTCUTTARGET), propget] + Record* GetShortcutTarget([in] BSTR ShortcutPath); + [id(DISPID_INSTALLER_FILEHASH)] + Record* FileHash( + [in] BSTR FilePath, + [in] long Options); + [id(DISPID_INSTALLER_FILESIGNATUREINFO)] + SAFEARRAY(unsigned char) FileSignatureInfo( + [in] BSTR FilePath, + [in] long Options, + [in] MsiSignatureInfo Format); + }; - [ uuid(000C1096-0000-0000-C000-000000000046) ] - dispinterface RecordList - { + [ + uuid(000C1093-0000-0000-C000-000000000046), + helpcontext(0x00002454) + ] + dispinterface Record { properties: methods: - } + [id(DISPID_RECORD_STRINGDATA), propget] + BSTR StringData([in] long Field); + [id(DISPID_RECORD_STRINGDATA), propput] + void StringData( + [in] long Field, + [in] BSTR rhs); + [id(DISPID_RECORD_INTEGERDATA), propget] + long IntegerData([in] long Field); + [id(DISPID_RECORD_INTEGERDATA), propput] + void IntegerData( + [in] long Field, + [in] long rhs); + [id(DISPID_RECORD_SETSTREAM)] + void SetStream( + [in] long Field, + [in] BSTR FilePath); + [id(DISPID_RECORD_READSTREAM)] + BSTR ReadStream( + [in] long Field, + [in] long Length, + [in] MsiReadStream Format); + [id(DISPID_RECORD_FIELDCOUNT), propget] + long FieldCount(); + [id(DISPID_RECORD_ISNULL), propget] + VARIANT_BOOL IsNull([in] long Field); + [id(DISPID_RECORD_DATASIZE), propget] + long DataSize([in] long Field); + [id(DISPID_RECORD_CLEARDATA)] + void ClearData(); + [id(DISPID_RECORD_FORMATTEXT)] + BSTR FormatText(); + }; + + typedef enum { + msiDoActionStatusNoAction = 0, + msiDoActionStatusSuccess = 1, + msiDoActionStatusUserExit = 2, + msiDoActionStatusFailure = 3, + msiDoActionStatusSuspend = 4, + msiDoActionStatusFinished = 5, + msiDoActionStatusWrongState = 6, + msiDoActionStatusBadActionData = 7 + } MsiDoActionStatus; + + typedef enum { + msiEvaluateConditionFalse = 0, + msiEvaluateConditionTrue = 1, + msiEvaluateConditionNone = 2, + msiEvaluateConditionError = 3 + } _MsiEvaluateCondition; /* Added underscore to avoid conflict with function name */ + + typedef enum { + msiMessageStatusError = -1, + msiMessageStatusNone = 0, + msiMessageStatusOk = 1, + msiMessageStatusCancel = 2, + msiMessageStatusAbort = 3, + msiMessageStatusRetry = 4, + msiMessageStatusIgnore = 5, + msiMessageStatusYes = 6, + msiMessageStatusNo = 7 + } MsiMessageStatus; + + typedef enum { + msiMessageTypeFatalExit = 0, + msiMessageTypeError = 16777216, + msiMessageTypeWarning = 33554432, + msiMessageTypeUser = 50331648, + msiMessageTypeInfo = 67108864, + msiMessageTypeFilesInUse = 83886080, + msiMessageTypeResolveSource = 100663296, + msiMessageTypeOutOfDiskSpace = 117440512, + msiMessageTypeActionStart = 134217728, + msiMessageTypeActionData = 150994944, + msiMessageTypeProgress = 167772160, + msiMessageTypeCommonData = 184549376, + msiMessageTypeOk = 0, + msiMessageTypeOkCancel = 1, + msiMessageTypeAbortRetryIgnore = 2, + msiMessageTypeYesNoCancel = 3, + msiMessageTypeYesNo = 4, + msiMessageTypeRetryCancel = 5, + msiMessageTypeDefault1 = 0, + msiMessageTypeDefault2 = 256, + msiMessageTypeDefault3 = 512 + } MsiMessageType; + + typedef enum { + msiCostTreeSelfOnly = 0, + msiCostTreeChildren = 1, + msiCostTreeParents = 2 + } MsiCostTree; - [ uuid(000C109A-0000-0000-C000-000000000046) ] - dispinterface UIPreview - { + typedef enum { + msiDatabaseStateRead = 0, + msiDatabaseStateWrite = 1 + } MsiDatabaseState; + + [ + uuid(000C109E-0000-0000-C000-000000000046), + helpcontext(0x000025e4) + ] + dispinterface Session { properties: methods: - } + [id(DISPID_SESSION_INSTALLER), propget] + Installer* Installer(); + [id(DISPID_SESSION_PROPERTY), propget] + BSTR Property([in] BSTR Name); + [id(DISPID_SESSION_PROPERTY), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(DISPID_SESSION_LANGUAGE), propget] + long Language(); + [id(DISPID_SESSION_MODE), propget] + VARIANT_BOOL Mode([in] MsiRunMode Flag); + [id(DISPID_SESSION_MODE), propput] + void Mode( + [in] MsiRunMode Flag, + [in] VARIANT_BOOL rhs); + [id(DISPID_SESSION_DATABASE), propget] + Database* Database(); + [id(DISPID_SESSION_SOURCEPATH), propget] + BSTR SourcePath([in] BSTR Folder); + [id(DISPID_SESSION_TARGETPATH), propget] + BSTR TargetPath([in] BSTR Folder); + [id(DISPID_SESSION_TARGETPATH), propput] + void TargetPath( + [in] BSTR Folder, + [in] BSTR rhs); + [id(DISPID_SESSION_DOACTION)] + MsiDoActionStatus DoAction([in] BSTR Action); + [id(DISPID_SESSION_SEQUENCE)] + MsiDoActionStatus Sequence( + [in] BSTR Table, + [in, optional] VARIANT Mode); + [id(DISPID_SESSION_EVALUATECONDITION)] + _MsiEvaluateCondition EvaluateCondition([in] BSTR Expression); + [id(DISPID_SESSION_FORMATRECORD)] + BSTR FormatRecord([in] Record* Record); + [id(DISPID_SESSION_MESSAGE)] + MsiMessageStatus Message( + [in] MsiMessageType Kind, + [in] Record* Record); + [id(DISPID_SESSION_FEATURECURRENTSTATE), propget] + MsiInstallState FeatureCurrentState([in] BSTR Feature); + [id(DISPID_SESSION_FEATUREREQUESTSTATE), propget] + MsiInstallState FeatureRequestState([in] BSTR Feature); + [id(DISPID_SESSION_FEATUREREQUESTSTATE), propput] + void FeatureRequestState( + [in] BSTR Feature, + [in] MsiInstallState rhs); + [id(DISPID_SESSION_FEATUREVALIDSTATES), propget] + long FeatureValidStates([in] BSTR Feature); + [id(DISPID_SESSION_FEATURECOST), propget] + long FeatureCost( + [in] BSTR Feature, + [in] MsiCostTree CostTree, + [in] MsiInstallState State); + [id(DISPID_SESSION_COMPONENTCURRENTSTATE), propget] + MsiInstallState ComponentCurrentState([in] BSTR Component); + [id(DISPID_SESSION_COMPONENTREQUESTSTATE), propget] + MsiInstallState ComponentRequestState([in] BSTR Component); + [id(DISPID_SESSION_COMPONENTREQUESTSTATE), propput] + void ComponentRequestState( + [in] BSTR Component, + [in] MsiInstallState rhs); + [id(DISPID_SESSION_SETINSTALLLEVEL)] + void SetInstallLevel([in] long Level); + [id(DISPID_SESSION_VERIFYDISKSPACE), propget] + VARIANT_BOOL VerifyDiskSpace(); + [id(DISPID_SESSION_PRODUCTPROPERTY), propget] + BSTR ProductProperty([in] BSTR Property); + [id(DISPID_SESSION_FEATUREINFO), propget] + FeatureInfo* FeatureInfo([in] BSTR Feature); + [id(DISPID_SESSION_COMPONENTCOSTS), propget] + RecordList* ComponentCosts( + [in] BSTR Component, + [in] MsiInstallState State); + }; + + typedef enum { + msiTransformErrorNone = 0, + msiTransformErrorAddExistingRow = 1, + msiTransformErrorDeleteNonExistingRow = 2, + msiTransformErrorAddExistingTable = 4, + msiTransformErrorDeleteNonExistingTable = 8, + msiTransformErrorUpdateNonExistingRow = 16, + msiTransformErrorChangeCodePage = 32, + msiTransformErrorViewTransform = 256 + } MsiTransformError; + + + typedef enum { + msiTransformValidationNone = 0, + msiTransformValidationLanguage = 1, + msiTransformValidationProduct = 2, + msiTransformValidationPlatform = 4, + msiTransformValidationMajorVer = 8, + msiTransformValidationMinorVer = 16, + msiTransformValidationUpdateVer = 32, + msiTransformValidationLess = 64, + msiTransformValidationLessOrEqual = 128, + msiTransformValidationEqual = 256, + msiTransformValidationGreaterOrEqual = 512, + msiTransformValidationGreater = 1024, + msiTransformValidationUpgradeCode = 2048 + } MsiTransformValidation; - [ uuid(000C109B-0000-0000-C000-000000000046) ] - dispinterface SummaryInfo - { + [ + uuid(000C109D-0000-0000-C000-000000000046), + helpcontext(0x0000251c) + ] + dispinterface Database { properties: methods: - } + [id(DISPID_DATABASE_DATABASESTATE), propget] + MsiDatabaseState DatabaseState(); + [id(DISPID_DATABASE_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation([in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_DATABASE_OPENVIEW)] + View* OpenView([in] BSTR Sql); + [id(DISPID_DATABASE_COMMIT)] + void Commit(); + [id(DISPID_DATABASE_PRIMARYKEYS), propget] + Record* PrimaryKeys([in] BSTR Table); + [id(DISPID_DATABASE_IMPORT)] + void Import( + [in] BSTR Folder, + [in] BSTR File); + [id(DISPID_DATABASE_EXPORT)] + void Export( + [in] BSTR Table, + [in] BSTR Folder, + [in] BSTR File); + [id(DISPID_DATABASE_MERGE)] + VARIANT_BOOL Merge( + [in] Database* Database, + [in, optional, defaultvalue("0")] BSTR ErrorTable); + [id(DISPID_DATABASE_GENERATETRANSFORM)] + VARIANT_BOOL GenerateTransform( + [in] Database* ReferenceDatabase, + [in, optional, defaultvalue("0")] BSTR TransformFile); + [id(DISPID_DATABASE_APPLYTRANSFORM)] + void ApplyTransform( + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions); + [id(DISPID_DATABASE_ENABLEUIPREVIEW)] + UIPreview* EnableUIPreview(); + [id(DISPID_DATABASE_TABLEPERSISTENT), propget] + _MsiEvaluateCondition TablePersistent([in] BSTR Table); + [id(DISPID_DATABASE_CREATETRANSFORMSUMMARYINFO)] + void CreateTransformSummaryInfo( + [in] Database* ReferenceDatabase, + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions, + [in] MsiTransformValidation Validation); + }; - [ uuid(000C109C-0000-0000-C000-000000000046) ] - dispinterface View - { + [ + uuid(000C109B-0000-0000-C000-000000000046), + helpcontext(0x00002580) + ] + dispinterface SummaryInfo { properties: methods: - } + [id(DISPID_SUMMARYINFO_PROPERTY), propget] + VARIANT Property([in] long Pid); + [id(DISPID_SUMMARYINFO_PROPERTY), propput] + void Property( + [in] long Pid, + [in] VARIANT rhs); + [id(DISPID_SUMMARYINFO_PROPERTYCOUNT), propget] + long PropertyCount(); + [id(DISPID_SUMMARYINFO_PERSIST)] + void Persist(); + }; - [ uuid(000C109D-0000-0000-C000-000000000046) ] - dispinterface Database - { + typedef enum { + msiViewModifySeek = -1, + msiViewModifyRefresh = 0, + msiViewModifyInsert = 1, + msiViewModifyUpdate = 2, + msiViewModifyAssign = 3, + msiViewModifyReplace = 4, + msiViewModifyMerge = 5, + msiViewModifyDelete = 6, + msiViewModifyInsertTemporary = 7, + msiViewModifyValidate = 8, + msiViewModifyValidateNew = 9, + msiViewModifyValidateField = 10, + msiViewModifyValidateDelete = 11 + } _MsiViewModify; /* Added underscore to avoid conflict with MsiViewModify function in msiquery.h */ + + typedef enum { + msiColumnInfoNames = 0, + msiColumnInfoTypes = 1 + } MsiColumnInfo; + + [ + uuid(000C109C-0000-0000-C000-000000000046), + helpcontext(0x000024b8) + ] + dispinterface View { properties: methods: - } - - [ uuid(000C109E-0000-0000-C000-000000000046) ] - dispinterface Session - { - properties: - methods: - } - - [ uuid(000C109F-0000-0000-C000-000000000046) ] - dispinterface FeatureInfo - { + [id(DISPID_VIEW_EXECUTE)] + void Execute([in, optional, defaultvalue(0)] Record* Params); + [id(DISPID_VIEW_FETCH)] + Record* Fetch(); + [id(DISPID_VIEW_MODIFY)] + void Modify( + [in] _MsiViewModify Mode, + Record* Record); + [id(DISPID_VIEW_COLUMNINFO), propget] + Record* ColumnInfo([in] MsiColumnInfo Info); + [id(DISPID_VIEW_CLOSE)] + void Close(); + [id(DISPID_VIEW_GETERROR)] + BSTR GetError(); + }; + + [ + uuid(000C109A-0000-0000-C000-000000000046), + helpcontext(0x00002648) + ] + dispinterface UIPreview { properties: methods: - } + [id(DISPID_UIPREVIEW_PROPERTY), propget] + BSTR Property([in] BSTR Name); + [id(DISPID_UIPREVIEW_PROPERTY), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(DISPID_UIPREVIEW_VIEWDIALOG)] + void ViewDialog([in] BSTR Dialog); + [id(DISPID_UIPREVIEW_VIEWBILLBOARD)] + void ViewBillboard( + [in] BSTR Control, + [in] BSTR Billboard); + }; - [ uuid(000C10A0-0000-0000-C000-000000000046) ] - dispinterface Product - { + [ + uuid(000C109F-0000-0000-C000-000000000046), + helpcontext(0x0000238c) + ] + dispinterface FeatureInfo { properties: + [id(DISPID_FEATUREINFO_ATTRIBUTES)] + long Attributes; methods: - } + [id(DISPID_FEATUREINFO_TITLE), propget] + BSTR Title(); + [id(DISPID_FEATUREINFO_DESCRIPTION), propget] + BSTR Description(); + }; - [ uuid(000C10A1-0000-0000-C000-000000000046) ] - dispinterface Patch - { + [ + uuid(000C1096-0000-0000-C000-000000000046), + helpcontext(0x000023f3) + ] + dispinterface RecordList { properties: methods: - } -} + [id(DISPID_RECORDLIST__NEWENUM)] + IUnknown _NewEnum(); + [id(DISPID_RECORDLIST_ITEM), propget] + Record* Item(long Index); + [id(DISPID_RECORDLIST_COUNT), propget] + long Count(); + }; + + [ + uuid(000C1095-0000-0000-C000-000000000046), + helpcontext(0x000023f0) + ] + dispinterface StringList { + properties: + methods: + [id(DISPID_STRINGLIST__NEWENUM)] + IUnknown _NewEnum(); + [id(DISPID_STRINGLIST_ITEM), propget] + BSTR Item(long Index); + [id(DISPID_STRINGLIST_COUNT), propget] + long Count(); + }; + + typedef enum { + msiDatabaseNullInteger = 0x80000000 /* -2147483648 from oleview, but widl makes it into two "-"'s + * which screws up msiserver.h */ + } Constants; + + typedef enum { + msiOpenDatabaseModeReadOnly = 0, + msiOpenDatabaseModeTransact = 1, + msiOpenDatabaseModeDirect = 2, + msiOpenDatabaseModeCreate = 3, + msiOpenDatabaseModeCreateDirect = 4, + msiOpenDatabaseModePatchFile = 32 + } MsiOpenDatabaseMode; + + typedef enum { + msiSignatureOptionInvalidHashFatal = 1 + } MsiSignatureOption; +}; diff --git a/dlls/msi/msiserver_dispids.h b/dlls/msi/msiserver_dispids.h new file mode 100644 index 0000000..db39ec0 --- /dev/null +++ b/dlls/msi/msiserver_dispids.h @@ -0,0 +1,140 @@ +/* + * Copyright (C) 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define DISPID_INSTALLER_UILEVEL 6 +#define DISPID_INSTALLER_CREATERECORD 1 +#define DISPID_INSTALLER_OPENPACKAGE 2 +#define DISPID_INSTALLER_OPENPRODUCT 3 +#define DISPID_INSTALLER_OPENDATABASE 4 +#define DISPID_INSTALLER_SUMMARYINFORMATION 5 +#define DISPID_INSTALLER_ENABLELOG 7 +#define DISPID_INSTALLER_INSTALLPRODUCT 8 +#define DISPID_INSTALLER_VERSION 9 +#define DISPID_INSTALLER_LASTERRORRECORD 10 +#define DISPID_INSTALLER_REGISTRYVALUE 11 +#define DISPID_INSTALLER_FILEATTRIBUTES 13 +#define DISPID_INSTALLER_FILESIZE 15 +#define DISPID_INSTALLER_FILEVERSION 16 +#define DISPID_INSTALLER_ENVIRONMENT 12 +#define DISPID_INSTALLER_PRODUCTSTATE 17 +#define DISPID_INSTALLER_PRODUCTINFO 18 +#define DISPID_INSTALLER_CONFIGUREPRODUCT 19 +#define DISPID_INSTALLER_REINSTALLPRODUCT 20 +#define DISPID_INSTALLER_COLLECTUSERINFO 21 +#define DISPID_INSTALLER_APPLYPATCH 22 +#define DISPID_INSTALLER_FEATUREPARENT 23 +#define DISPID_INSTALLER_FEATURESTATE 24 +#define DISPID_INSTALLER_USEFEATURE 25 +#define DISPID_INSTALLER_FEATUREUSAGECOUNT 26 +#define DISPID_INSTALLER_FEATUREUSAGEDATE 27 +#define DISPID_INSTALLER_CONFIGUREFEATURE 28 +#define DISPID_INSTALLER_REINSTALLFEATURE 29 +#define DISPID_INSTALLER_PROVIDECOMPONENT 30 +#define DISPID_INSTALLER_COMPONENTPATH 31 +#define DISPID_INSTALLER_PROVIDEQUALIFIEDCOMPONENT 32 +#define DISPID_INSTALLER_QUALIFIERDESCRIPTION 33 +#define DISPID_INSTALLER_COMPONENTQUALIFIERS 34 +#define DISPID_INSTALLER_PRODUCTS 35 +#define DISPID_INSTALLER_FEATURES 36 +#define DISPID_INSTALLER_COMPONENTS 37 +#define DISPID_INSTALLER_COMPONENTCLIENTS 38 +#define DISPID_INSTALLER_PATCHES 39 +#define DISPID_INSTALLER_RELATEDPRODUCTS 40 +#define DISPID_INSTALLER_PATCHINFO 41 +#define DISPID_INSTALLER_PATCHTRANSFORMS 42 +#define DISPID_INSTALLER_ADDSOURCE 43 +#define DISPID_INSTALLER_CLEARSOURCELIST 44 +#define DISPID_INSTALLER_FORCESOURCELISTRESOLUTION 45 +#define DISPID_INSTALLER_GETSHORTCUTTARGET 46 +#define DISPID_INSTALLER_FILEHASH 47 +#define DISPID_INSTALLER_FILESIGNATUREINFO 48 + +#define DISPID_RECORD_STRINGDATA 1 +#define DISPID_RECORD_INTEGERDATA 2 +#define DISPID_RECORD_SETSTREAM 3 +#define DISPID_RECORD_READSTREAM 4 +#define DISPID_RECORD_FIELDCOUNT 0 +#define DISPID_RECORD_ISNULL 6 +#define DISPID_RECORD_DATASIZE 5 +#define DISPID_RECORD_CLEARDATA 7 +#define DISPID_RECORD_FORMATTEXT 8 + +#define DISPID_SESSION_INSTALLER 1 +#define DISPID_SESSION_PROPERTY 2 +#define DISPID_SESSION_LANGUAGE 3 +#define DISPID_SESSION_MODE 4 +#define DISPID_SESSION_DATABASE 5 +#define DISPID_SESSION_SOURCEPATH 6 +#define DISPID_SESSION_TARGETPATH 7 +#define DISPID_SESSION_DOACTION 8 +#define DISPID_SESSION_SEQUENCE 9 +#define DISPID_SESSION_EVALUATECONDITION 10 +#define DISPID_SESSION_FORMATRECORD 11 +#define DISPID_SESSION_MESSAGE 12 +#define DISPID_SESSION_FEATURECURRENTSTATE 13 +#define DISPID_SESSION_FEATUREREQUESTSTATE 14 +#define DISPID_SESSION_FEATUREVALIDSTATES 15 +#define DISPID_SESSION_FEATURECOST 16 +#define DISPID_SESSION_COMPONENTCURRENTSTATE 17 +#define DISPID_SESSION_COMPONENTREQUESTSTATE 18 +#define DISPID_SESSION_SETINSTALLLEVEL 19 +#define DISPID_SESSION_VERIFYDISKSPACE 20 +#define DISPID_SESSION_PRODUCTPROPERTY 21 +#define DISPID_SESSION_FEATUREINFO 22 +#define DISPID_SESSION_COMPONENTCOSTS 23 + +#define DISPID_DATABASE_DATABASESTATE 1 +#define DISPID_DATABASE_SUMMARYINFORMATION 2 +#define DISPID_DATABASE_OPENVIEW 3 +#define DISPID_DATABASE_COMMIT 4 +#define DISPID_DATABASE_PRIMARYKEYS 5 +#define DISPID_DATABASE_IMPORT 6 +#define DISPID_DATABASE_EXPORT 7 +#define DISPID_DATABASE_MERGE 8 +#define DISPID_DATABASE_GENERATETRANSFORM 9 +#define DISPID_DATABASE_APPLYTRANSFORM 10 +#define DISPID_DATABASE_ENABLEUIPREVIEW 11 +#define DISPID_DATABASE_TABLEPERSISTENT 12 +#define DISPID_DATABASE_CREATETRANSFORMSUMMARYINFO 13 + +#define DISPID_SUMMARYINFO_PROPERTY 1 +#define DISPID_SUMMARYINFO_PROPERTYCOUNT 2 +#define DISPID_SUMMARYINFO_PERSIST 3 + +#define DISPID_VIEW_EXECUTE 1 +#define DISPID_VIEW_FETCH 2 +#define DISPID_VIEW_MODIFY 3 +#define DISPID_VIEW_COLUMNINFO 5 +#define DISPID_VIEW_CLOSE 4 +#define DISPID_VIEW_GETERROR 6 + +#define DISPID_UIPREVIEW_PROPERTY 1 +#define DISPID_UIPREVIEW_VIEWDIALOG 2 +#define DISPID_UIPREVIEW_VIEWBILLBOARD 3 + +#define DISPID_FEATUREINFO_ATTRIBUTES 3 +#define DISPID_FEATUREINFO_TITLE 1 +#define DISPID_FEATUREINFO_DESCRIPTION 2 + +#define DISPID_RECORDLIST__NEWENUM -4 +#define DISPID_RECORDLIST_ITEM 0 +#define DISPID_RECORDLIST_COUNT 1 + +#define DISPID_STRINGLIST__NEWENUM -4 +#define DISPID_STRINGLIST_ITEM 0 +#define DISPID_STRINGLIST_COUNT 1 -- 1.4.1 -------------- next part -------------- From 3c20af7127de00c3bafb859036b17cc221a3fc74 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 25 Feb 2007 22:23:15 -0600 Subject: msi: Add partial, expandable OLE automation support. --- dlls/msi/Makefile.in | 3 dlls/msi/automation.c | 809 +++++++++++++++++++++++++++++++++++++++++++++++++ dlls/msi/msipriv.h | 4 3 files changed, 816 insertions(+), 0 deletions(-) diff --git a/dlls/msi/Makefile.in b/dlls/msi/Makefile.in index 5fb0941..3418fb5 100644 --- a/dlls/msi/Makefile.in +++ b/dlls/msi/Makefile.in @@ -12,6 +12,7 @@ C_SRCS = \ action.c \ alter.c \ appsearch.c \ + automation.c \ classes.c \ create.c \ custom.c \ @@ -47,6 +48,8 @@ C_SRCS = \ upgrade.c \ where.c +IDL_H_SRCS = msiserver.idl +IDL_I_SRCS = msiserver.idl IDL_TLB_SRCS = msiserver.idl BISON_SRCS = \ diff --git a/dlls/msi/automation.c b/dlls/msi/automation.c new file mode 100644 index 0000000..c7ca30b --- /dev/null +++ b/dlls/msi/automation.c @@ -0,0 +1,809 @@ +/* + * Implementation of OLE Automation for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +#include "msiserver.h" +#include "msiserver_dispids.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +/* + * If you would like to implement a new automation function/object, look towards the bottom of this + * file for the "meat and potatoes" section. + */ + +/* FIXME: I don't know how big this should be */ +#define MAX_MSI_STRING 1000 + +/* + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just + * need to implement Invoke function for each dispinterface that is called from within + * the AutomationObject Invoke function which performs error checking, and pass the new + * function to create_automation_object. + */ + +typedef interface AutomationObject AutomationObject; + +interface AutomationObject { + /* + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo + */ + const IDispatchVtbl *lpVtbl; + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; + + /* Object reference count */ + LONG ref; + + /* Clsid for this class and it's appropriate ITypeInfo object */ + LPCLSID clsid; + ITypeInfo *iTypeInfo; + + /* The MSI handle of the current object */ + MSIHANDLE msiHandle; + + /* A function that is called from IDispatch::Invoke, specific to this type of object. By the + * time this function is called, basic error checking has been done in the AutomationObject + * Invoke function */ + HRESULT (STDMETHODCALLTYPE *funcInvoke)( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr); +}; + +/* VTables */ +static const struct IDispatchVtbl AutomationObject_Vtbl; +static const struct IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl; +static const struct IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl; +static const struct IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl; + +/* Load type info so we don't have to process GetIDsOfNames */ +HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid) +{ + HRESULT hr; + LPTYPELIB pLib = NULL; + LPTYPEINFO pInfo = NULL; + WCHAR szMsiServer[] = {'m','s','i','s','e','r','v','e','r','.','t','l','b'}; + + TRACE("(%p)->(%s,%d)\n", iface, debugstr_guid(clsid), lcid); + + /* Load registered type library */ + hr = LoadRegTypeLib(&LIBID_WindowsInstaller, 1, 0, lcid, &pLib); + if (FAILED(hr)) { + hr = LoadTypeLib(szMsiServer, &pLib); + if (FAILED(hr)) { + ERR("Could not load msiserver.tlb\n"); + return hr; + } + } + + /* Get type information for object */ + hr = ITypeLib_GetTypeInfoOfGuid(pLib, clsid, &pInfo); + ITypeLib_Release(pLib); + if (FAILED(hr)) { + ERR("Could not load ITypeInfo for %s\n", debugstr_guid(clsid)); + return hr; + } + *pptinfo = pInfo; + return S_OK; +} + +/* Create the automation object, placing the result in the pointer ppObj. The automation object is created + * with the appropriate clsid and invocation function. */ +HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, + HRESULT (STDMETHODCALLTYPE *funcInvoke)(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*, + VARIANT*,EXCEPINFO*,UINT*)) +{ + AutomationObject *object; + HRESULT hr; + + TRACE("(%ld,%p,%p,%s,%p)\n", (unsigned long)msiHandle, pUnkOuter, ppObj, debugstr_guid(clsid), funcInvoke); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(AutomationObject)); + + /* Set all the VTable references */ + object->lpVtbl = &AutomationObject_Vtbl; + object->lpvtblIProvideClassInfo = &AutomationObject_IProvideClassInfo_Vtbl; + object->lpvtblIProvideClassInfo2 = &AutomationObject_IProvideClassInfo2_Vtbl; + object->lpvtblIProvideMultipleClassInfo = &AutomationObject_IProvideMultipleClassInfo_Vtbl; + object->ref = 1; + + /* Store data that was passed */ + object->msiHandle = msiHandle; + object->clsid = (LPCLSID)clsid; + object->funcInvoke = funcInvoke; + + /* Load our TypeInfo so we don't have to process GetIDsOfNames */ + object->iTypeInfo = NULL; + hr = LoadTypeInfo((IDispatch *)object, &object->iTypeInfo, clsid, 0x0); + if (FAILED(hr)) { + HeapFree(GetProcessHeap(), 0, object); + return hr; + } + + *ppObj = object; + + return S_OK; +} + +/* Macros to get pointer to AutomationObject from the other VTables. */ +static inline AutomationObject *obj_from_IProvideClassInfo( IProvideClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo)); +} + +static inline AutomationObject *obj_from_IProvideClassInfo2( IProvideClassInfo2 *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo2)); +} + +static inline AutomationObject *obj_from_IProvideMultipleClassInfo( IProvideMultipleClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideMultipleClassInfo)); +} + +/* + * AutomationObject methods + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI AutomationObject_QueryInterface(IDispatch* iface, REFIID riid, void** ppvObject) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + /* + * Perform a sanity check on the parameters. + */ + if ( (This==0) || (ppvObject==0) ) + return E_INVALIDARG; + + /* + * Initialize the return parameter. + */ + *ppvObject = 0; + + /* + * Compare the riid with the interface IDs implemented by this object. + */ + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IDispatch) || IsEqualGUID(riid, This->clsid)) + *ppvObject = This; + else if (IsEqualGUID(riid, &IID_IProvideClassInfo)) + *ppvObject = (IProvideClassInfo*)&(This->lpvtblIProvideClassInfo); + else if (IsEqualGUID(riid, &IID_IProvideClassInfo2)) + *ppvObject = (IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2); + else if (IsEqualGUID(riid, &IID_IProvideMultipleClassInfo)) + *ppvObject = (IProvideMultipleClassInfo*)&(This->lpvtblIProvideMultipleClassInfo); + + /* + * Check that we obtained an interface. + */ + if ((*ppvObject)==0) + { + TRACE("() : asking for unsupported interface %s\n",debugstr_guid(riid)); + return E_NOINTERFACE; + } + + /* + * Query Interface always increases the reference count by one when it is + * successful + */ + IClassFactory_AddRef(iface); + + return S_OK; +} + +static ULONG WINAPI AutomationObject_AddRef(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI AutomationObject_Release(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + { + MsiCloseHandle(This->msiHandle); + HeapFree(GetProcessHeap(), 0, This); + } + + return ref; +} + +/*** IDispatch methods ***/ +static HRESULT WINAPI AutomationObject_GetTypeInfoCount( + IDispatch* iface, + UINT* pctinfo) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%p)\n", iface, This, pctinfo); + *pctinfo = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetTypeInfo( + IDispatch* iface, + UINT iTInfo, + LCID lcid, + ITypeInfo** ppTInfo) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%d,%d,%p)\n", iface, This, iTInfo, lcid, ppTInfo); + + ITypeInfo_AddRef(This->iTypeInfo); + *ppTInfo = This->iTypeInfo; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetIDsOfNames( + IDispatch* iface, + REFIID riid, + LPOLESTR* rgszNames, + UINT cNames, + LCID lcid, + DISPID* rgDispId) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%p,%p,%d,%d,%p)\n", iface, This, riid, rgszNames, cNames, lcid, rgDispId); + + if (!IsEqualGUID(riid, &IID_NULL)) return E_INVALIDARG; + return ITypeInfo_GetIDsOfNames(This->iTypeInfo, rgszNames, cNames, rgDispId); +} + +/* Error checking, etc. is done here to simplify individual object function invocation */ +static HRESULT WINAPI AutomationObject_Invoke( + IDispatch* iface, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + AutomationObject *This = (AutomationObject *)iface; + HRESULT (STDMETHODCALLTYPE *Invoke)( + AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*) = This->funcInvoke; + HRESULT hr; + BSTR bstrName = NULL; + + TRACE("(%p/%p)->(%d,%p,%d,%d,%p,%p,%p,%p)\n", iface, This, dispIdMember, riid, lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); + + if (!IsEqualIID(riid, &IID_NULL)) + { + ERR("riid was %s instead of IID_NULL\n", debugstr_guid(riid)); + return DISP_E_UNKNOWNNAME; + } + + if (!pDispParams) + { + ERR("NULL pDispParams not allowed\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + if (wFlags & DISPATCH_PROPERTYGET && !pVarResult) + { + ERR("NULL pVarResult not allowed when DISPATCH_PROPERTYGET specified\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + /* If there is a result, make default type empty */ + if (pVarResult) V_VT(pVarResult) = VT_EMPTY; + + /* If we are tracing, we want to see the name of the member we are invoking */ + if (TRACE_ON(msi)) + { + ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + TRACE("Method %d, %s\n", dispIdMember, debugstr_w(bstrName)); + } + + hr = Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr); + + if (hr == DISP_E_MEMBERNOTFOUND) { + if (bstrName == NULL) ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + FIXME("Method %d, %s wflags %d not implemented, clsid %s\n", dispIdMember, debugstr_w(bstrName), wFlags, debugstr_guid(This->clsid)); + } + + TRACE("Returning %d, %s\n", hr, hr == S_OK ? "ok" : "not ok"); + + return hr; +} + +static const struct IDispatchVtbl AutomationObject_Vtbl = +{ + AutomationObject_QueryInterface, + AutomationObject_AddRef, + AutomationObject_Release, + AutomationObject_GetTypeInfoCount, + AutomationObject_GetTypeInfo, + AutomationObject_GetIDsOfNames, + AutomationObject_Invoke +}; + +/* + * IProvideClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo_QueryInterface( + IProvideClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_AddRef(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_Release(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_GetClassInfo(IProvideClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, ppTI); + return LoadTypeInfo((IDispatch *)This, ppTI, This->clsid, 0); +} + +static const IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl = +{ + AutomationObject_IProvideClassInfo_QueryInterface, + AutomationObject_IProvideClassInfo_AddRef, + AutomationObject_IProvideClassInfo_Release, + AutomationObject_GetClassInfo +}; + +/* + * IProvideClassInfo2 methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_QueryInterface( + IProvideClassInfo2* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_AddRef(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_Release(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_GetClassInfo(IProvideClassInfo2* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_GetGUID(IProvideClassInfo2* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + TRACE("(%p/%p)->(%d,%s)\n", iface, This, dwGuidKind, debugstr_guid(pGUID)); + + if (dwGuidKind != GUIDKIND_DEFAULT_SOURCE_DISP_IID) + return E_INVALIDARG; + else { + *pGUID = *This->clsid; + return S_OK; + } +} + +static const IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl = +{ + AutomationObject_IProvideClassInfo2_QueryInterface, + AutomationObject_IProvideClassInfo2_AddRef, + AutomationObject_IProvideClassInfo2_Release, + AutomationObject_IProvideClassInfo2_GetClassInfo, + AutomationObject_GetGUID +}; + +/* + * IProvideMultipleClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_QueryInterface( + IProvideMultipleClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_AddRef(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_Release(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetClassInfo(IProvideMultipleClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetGUID(IProvideMultipleClassInfo* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetGUID((IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2), dwGuidKind, pGUID); +} + +static HRESULT WINAPI AutomationObject_GetMultiTypeInfoCount(IProvideMultipleClassInfo* iface, ULONG* pcti) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, pcti); + *pcti = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetInfoOfIndex(IProvideMultipleClassInfo* iface, + ULONG iti, + DWORD dwFlags, + ITypeInfo** pptiCoClass, + DWORD* pdwTIFlags, + ULONG* pcdispidReserved, + IID* piidPrimary, + IID* piidSource) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%d,%d,%p,%p,%p,%p,%p)\n", iface, This, iti, dwFlags, pptiCoClass, pdwTIFlags, pcdispidReserved, piidPrimary, piidSource); + + if (iti != 0) + return E_INVALIDARG; + + if (dwFlags & MULTICLASSINFO_GETTYPEINFO) + LoadTypeInfo((IDispatch *)This, pptiCoClass, This->clsid, 0); + + if (dwFlags & MULTICLASSINFO_GETNUMRESERVEDDISPIDS) + { + *pdwTIFlags = 0; + *pcdispidReserved = 0; + } + + if (dwFlags & MULTICLASSINFO_GETIIDPRIMARY){ + *piidPrimary = *This->clsid; + } + + if (dwFlags & MULTICLASSINFO_GETIIDSOURCE){ + *piidSource = *This->clsid; + } + + return S_OK; +} + +static const IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl = +{ + AutomationObject_IProvideMultipleClassInfo_QueryInterface, + AutomationObject_IProvideMultipleClassInfo_AddRef, + AutomationObject_IProvideMultipleClassInfo_Release, + AutomationObject_IProvideMultipleClassInfo_GetClassInfo, + AutomationObject_IProvideMultipleClassInfo_GetGUID, + AutomationObject_GetMultiTypeInfoCount, + AutomationObject_GetInfoOfIndex +}; + +/* + * Individual Object Invocation Functions - Our meat and potatoes + * + * - To add a method, just add an appropriate case to an appropriate switch statement + * * Follow syntax here for property get/puts and method calls. Remember, parameters + * are passed IN REVERSE ORDER (last parameter to function is first in array). This got me at first. + * * MSI specs seem to indicate that most functions return an S_OK. If you don't, chances are the + * script will stop running, but check the MSI documentation for your specific function. + * - To add a new object, just add an ObjectImpl_Invoke method and appropriate method call that + * creates your object. Note that these are not true Invoke methods, but are called from + * AutomationObject_Invoke with some appropriate parameter error checking, made to ensure that + * the functions below remain just down to what they need to do. + */ + +HRESULT WINAPI RecordImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + UINT ret; + + switch (dispIdMember) + { + case DISPID_RECORD_STRINGDATA: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BSTR; + if ((ret = MsiRecordGetStringW(This->msiHandle, V_I4(&pDispParams->rgvarg[0]), + szString, &dwLen)) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + else + { + TRACE("MsiRecordGetString returned %d\n", ret); + V_BSTR(pVarResult) = NULL; + } + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiRecordSetStringW(This->msiHandle, V_I4(&pDispParams->rgvarg[1]), + V_BSTR(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI ViewImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + AutomationObject *obj = NULL; + IDispatch *iDispatch = NULL; + UINT ret; + + switch (dispIdMember) + { + case DISPID_VIEW_EXECUTE: + if (wFlags & DISPATCH_METHOD) + { + obj = (AutomationObject *)V_DISPATCH(&pDispParams->rgvarg[0]); + MsiViewExecute(This->msiHandle, obj == NULL ? 0 : obj->msiHandle); + return S_OK; + } + break; + + case DISPID_VIEW_FETCH: + if (wFlags & DISPATCH_METHOD) + { + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiViewFetch(This->msiHandle, &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Record, RecordImpl_Invoke); + else TRACE("MsiViewFetch returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + + case DISPID_VIEW_CLOSE: + if (wFlags & DISPATCH_METHOD) + { + MsiViewClose(This->msiHandle); + return S_OK; + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI DatabaseImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + IDispatch *iDispatch = NULL; + UINT ret; + + switch (dispIdMember) + { + case DISPID_DATABASE_OPENVIEW: + if (wFlags & DISPATCH_METHOD) + { + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiDatabaseOpenViewW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_View, ViewImpl_Invoke); + else TRACE("MsiDatabaseOpenViewW returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +HRESULT WINAPI SessionImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + IDispatch *iDispatch = NULL; + MSIHANDLE msiHandle; + LANGID langId; + UINT ret; + INSTALLSTATE iInstalled, iAction; + + switch (dispIdMember) + { + case DISPID_SESSION_PROPERTY: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BSTR; + V_BSTR(pVarResult) = NULL; + if (MsiGetPropertyW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + szString, &dwLen) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetPropertyW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[1]), + V_BSTR(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + + case DISPID_SESSION_LANGUAGE: + if (wFlags & DISPATCH_PROPERTYGET) { + langId = MsiGetLanguage(This->msiHandle); + if (langId != ERROR_INVALID_HANDLE) + { + V_VT(pVarResult) = VT_I4; + V_I4(pVarResult) = langId; + return S_OK; + } else return E_FAIL; + } + break; + + case DISPID_SESSION_MODE: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_BOOL; + V_BOOL(pVarResult) = MsiGetMode(This->msiHandle, V_I4(&pDispParams->rgvarg[0])); + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetMode(This->msiHandle, V_I4(&pDispParams->rgvarg[1]), + V_BOOL(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + + case DISPID_SESSION_DATABASE: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_DISPATCH; + msiHandle = MsiGetActiveDatabase(This->msiHandle); + if (msiHandle) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Database, DatabaseImpl_Invoke); + else TRACE("MsiGetActiveDatabase failed\n"); + V_DISPATCH(pVarResult) = iDispatch; + return S_OK; + } + break; + + case DISPID_SESSION_FEATURECURRENTSTATE: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iInstalled; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + return S_OK; + } + break; + + case DISPID_SESSION_FEATUREREQUESTSTATE: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[0]), + &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iAction; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + return S_OK; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + return (MsiSetFeatureStateW(This->msiHandle, V_BSTR(&pDispParams->rgvarg[1]), + (INSTALLSTATE)V_I4(&pDispParams->rgvarg[0])) == ERROR_SUCCESS ? S_OK : E_FAIL); + } + break; + } + + return DISP_E_MEMBERNOTFOUND; +} + +/* Wrapper around create_automation_object to create a session object. */ +HRESULT create_session(MSIHANDLE msiHandle, IDispatch **pDispatch) +{ + return create_automation_object(msiHandle, NULL, (LPVOID)pDispatch, &DIID_Session, SessionImpl_Invoke); +} diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h index 971f71e..23768c0 100644 --- a/dlls/msi/msipriv.h +++ b/dlls/msi/msipriv.h @@ -788,6 +788,10 @@ extern VOID ControlEvent_SubscribeToEven extern VOID ControlEvent_UnSubscribeToEvent( MSIPACKAGE *package, LPCWSTR event, LPCWSTR control, LPCWSTR attribute ); +/* OLE automation */ +extern HRESULT create_session(MSIHANDLE msiHandle, IDispatch **pDispatch); +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); + /* User Interface messages from the actions */ extern void ui_progress(MSIPACKAGE *, int, int, int, int); extern void ui_actiondata(MSIPACKAGE *, LPCWSTR, MSIRECORD *); -- 1.4.1 -------------- next part -------------- From bea150c6a681acd029ee2c95faab9b77d7e613c6 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 25 Feb 2007 22:24:06 -0600 Subject: msi: Add full JScript/VBScript support. --- dlls/msi/Makefile.in | 1 dlls/msi/custom.c | 4 - dlls/msi/msipriv.h | 3 dlls/msi/script.c | 369 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 375 insertions(+), 2 deletions(-) diff --git a/dlls/msi/Makefile.in b/dlls/msi/Makefile.in index 3418fb5..5b7a991 100644 --- a/dlls/msi/Makefile.in +++ b/dlls/msi/Makefile.in @@ -38,6 +38,7 @@ C_SRCS = \ record.c \ registry.c \ regsvr.c \ + script.c \ select.c \ source.c \ string.c \ diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index 7cbbf40..bdffe8b 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -892,12 +892,12 @@ static DWORD WINAPI ACTION_CallScript( c return r; } - FIXME("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); + TRACE("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); hPackage = alloc_msihandle( &info->package->hdr ); if (hPackage) { - r = S_OK; + r = call_script( hPackage, info->type, info->dllname, info->function, info->action ); MsiCloseHandle( hPackage ); } else diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h index 23768c0..57f2531 100644 --- a/dlls/msi/msipriv.h +++ b/dlls/msi/msipriv.h @@ -792,6 +792,9 @@ extern VOID ControlEvent_UnSubscribeToEv extern HRESULT create_session(MSIHANDLE msiHandle, IDispatch **pDispatch); extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); +/* Scripting */ +extern DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR script, LPCWSTR function, LPCWSTR action); + /* User Interface messages from the actions */ extern void ui_progress(MSIPACKAGE *, int, int, int, int); extern void ui_actiondata(MSIPACKAGE *, LPCWSTR, MSIRECORD *); diff --git a/dlls/msi/script.c b/dlls/msi/script.c new file mode 100644 index 0000000..65a937d --- /dev/null +++ b/dlls/msi/script.c @@ -0,0 +1,369 @@ +/* + * Implementation of scripting for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +#include "msiserver.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +const WCHAR szJScript[] = { 'J','S','c','r','i','p','t',0}; +const WCHAR szVBScript[] = { 'V','B','S','c','r','i','p','t',0}; +const WCHAR szSession[] = {'S','e','s','s','i','o','n',0}; + +/* + * MsiActiveScriptSite - Our IActiveScriptSite implementation. + */ + +typedef struct { + IActiveScriptSite lpVtbl; + IDispatch *pSession; + LONG ref; +} MsiActiveScriptSite; + +static const struct IActiveScriptSiteVtbl ASS_Vtbl; + +static HRESULT ASS_create(IUnknown *pUnkOuter, LPVOID *ppObj) +{ + MsiActiveScriptSite* object; + + TRACE("(%p,%p)\n", pUnkOuter, ppObj); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(MsiActiveScriptSite)); + + object->lpVtbl.lpVtbl = &ASS_Vtbl; + object->ref = 1; + object->pSession = NULL; + + *ppObj = object; + + return S_OK; +} + +/* + * Call a script. This is our meat and potatoes. + * - Currently, since the function is relatively new, it will always end up returning S_OK. + * Think of it like a bonus feature, we can run the script - great. If we have a problem, + * we are no worse off than if this function had not been called. + */ +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR script, LPCWSTR function, LPCWSTR action) +{ + HRESULT hr; + IActiveScript *pActiveScript = NULL; + IActiveScriptParse *pActiveScriptParse = NULL; + MsiActiveScriptSite *pActiveScriptSite = NULL; + IDispatch *pDispatch = NULL; + DISPPARAMS dispparamsNoArgs = {NULL, NULL, 0, 0}; + DISPID dispid; + CLSID clsid; + VARIANT var; + + /* Return success by default (if Windows Script not installed) - not native behavior. This + * should be here until we implement wine scripting. */ + DWORD ret = ERROR_SUCCESS; + + CoInitialize(NULL); + + /* Create MsiActiveScriptSite object */ + hr = ASS_create(NULL, (void **)&pActiveScriptSite); + if (hr != S_OK) goto done; + + /* Create a session object */ + hr = create_session(hPackage, &pActiveScriptSite->pSession); + if (hr != S_OK) goto done; + IUnknown_AddRef((IUnknown *)pActiveScriptSite->pSession); + + /* Create the scripting engine */ + if (type & msidbCustomActionTypeJScript) + hr = CLSIDFromProgID(szJScript, &clsid); + else if (type & msidbCustomActionTypeVBScript) + hr = CLSIDFromProgID(szVBScript, &clsid); + else { + ERR("Unknown script type %d\n", type); + goto done; + } + if (FAILED(hr)) { + ERR("Could not find CLSID for Windows Script\n"); + goto done; + } + hr = CoCreateInstance(&clsid, NULL, CLSCTX_INPROC_SERVER, &IID_IActiveScript, (void **)&pActiveScript); + if (FAILED(hr)) { + ERR("Could not instantiate class for Windows Script\n"); + goto done; + } + + /* If we got this far, Windows Script is installed, so don't return success by default anymore */ + ret = ERROR_INSTALL_FAILURE; + + /* Get the IActiveScriptParse engine interface */ + hr = IActiveScript_QueryInterface(pActiveScript, &IID_IActiveScriptParse, (void **)&pActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Give our host to the engine */ + hr = IActiveScript_SetScriptSite(pActiveScript, (IActiveScriptSite *)pActiveScriptSite); + if (FAILED(hr)) goto done; + + /* Initialize the script engine */ + hr = IActiveScriptParse_InitNew(pActiveScriptParse); + if (FAILED(hr)) goto done; + + /* Add the session object */ + hr = IActiveScript_AddNamedItem(pActiveScript, szSession, SCRIPTITEM_ISVISIBLE); + + /* Pass the script to the engine */ + hr = IActiveScriptParse_ParseScriptText(pActiveScriptParse, script, NULL, NULL, NULL, 0, 0, 0L, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Start processing the script */ + hr = IActiveScript_SetScriptState(pActiveScript, SCRIPTSTATE_CONNECTED); + if (FAILED(hr)) goto done; + + /* Call a function if necessary through the IDispatch interface */ + if (function != NULL && strlenW(function) > 0) { + TRACE("Calling function %s\n", debugstr_w(function)); + + hr = IActiveScript_GetScriptDispatch(pActiveScript, NULL, &pDispatch); + if (FAILED(hr)) goto done; + + hr = IDispatch_GetIDsOfNames(pDispatch, &IID_NULL, (WCHAR **)&function, 1,LOCALE_USER_DEFAULT, &dispid); + if (FAILED(hr)) goto done; + + hr = IDispatch_Invoke(pDispatch, dispid, &IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD, &dispparamsNoArgs, &var, NULL, NULL); + if (FAILED(hr)) goto done; + + /* Check return value, if it's not IDOK we failed */ + hr = VariantChangeType(&var, &var, 0, VT_I4); + if (FAILED(hr)) goto done; + + if (V_I4(&var) == IDOK) + ret = ERROR_SUCCESS; + else ret = ERROR_INSTALL_FAILURE; + + VariantClear(&var); + } else { + /* If no function to be called, MSI behavior is to succeed */ + ret = ERROR_SUCCESS; + } + +done: + + /* Free everything that needs to be freed */ + if (pDispatch) IDispatch_Release(pDispatch); + if (pActiveScript) IActiveScriptSite_Release(pActiveScript); + if (pActiveScriptSite && + pActiveScriptSite->pSession) IUnknown_Release((IUnknown *)pActiveScriptSite->pSession); + if (pActiveScriptSite) IUnknown_Release((IUnknown *)pActiveScriptSite); + + CoUninitialize(); /* must call even if CoInitialize failed */ + +/* return ret; */ + return ERROR_SUCCESS; /* FIXME: Until thoroughly tested, always return success */ +} + +/* + * MsiActiveScriptSite + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI MsiActiveScriptSite_QueryInterface(IActiveScriptSite* iface, REFIID riid, void** ppvObject) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + if (IsEqualGUID(riid, &IID_IUnknown) || + IsEqualGUID(riid, &IID_IActiveScriptSite)) + { + IClassFactory_AddRef(iface); + *ppvObject = This; + return S_OK; + } + + TRACE("(%p)->(%s,%p),not found\n",This,debugstr_guid(riid),ppvObject); + + return E_NOINTERFACE; +} + +static ULONG WINAPI MsiActiveScriptSite_AddRef(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI MsiActiveScriptSite_Release(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + HeapFree(GetProcessHeap(), 0, This); + + return ref; +} + +/*** IActiveScriptSite methods **/ +static HRESULT WINAPI MsiActiveScriptSite_GetLCID(IActiveScriptSite* iface, LCID* plcid) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub!\n", This, iface, plcid); + return E_NOTIMPL; +} + +static HRESULT WINAPI MsiActiveScriptSite_GetItemInfo(IActiveScriptSite* iface, LPCOLESTR pstrName, DWORD dwReturnMask, IUnknown** ppiunkItem, ITypeInfo** ppti) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%d,%p,%p)!\n", This, iface, pstrName, dwReturnMask, ppiunkItem, ppti); + + /* Determine the kind of pointer that is requested, and make sure placeholder is valid */ + if (dwReturnMask & SCRIPTINFO_ITYPEINFO) { + if (!ppti) return E_INVALIDARG; + *ppti = NULL; + } + if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + if (!ppiunkItem) return E_INVALIDARG; + *ppiunkItem = NULL; + } + + /* Are we looking for the session object? */ + if (!strcmpW(szSession, pstrName)) { + if (dwReturnMask & SCRIPTINFO_ITYPEINFO) + return LoadTypeInfo(This->pSession, ppti, &DIID_Session, 0); + else if (dwReturnMask & SCRIPTINFO_IUNKNOWN) { + IDispatch_QueryInterface(This->pSession, &IID_IUnknown, (void **)ppiunkItem); + return S_OK; + } + } + + return TYPE_E_ELEMENTNOTFOUND; +} + +static HRESULT WINAPI MsiActiveScriptSite_GetDocVersionString(IActiveScriptSite* iface, BSTR* pbstrVersion) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub\n", This, iface, pbstrVersion); + return E_NOTIMPL; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnScriptTerminate(IActiveScriptSite* iface, const VARIANT* pvarResult, const EXCEPINFO* pexcepinfo) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p,%p) stub\n", This, iface, pvarResult, pexcepinfo); + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnStateChange(IActiveScriptSite* iface, SCRIPTSTATE ssScriptState) +{ + switch (ssScriptState) { + case SCRIPTSTATE_UNINITIALIZED: + TRACE("State: Uninitialized.\n"); + break; + + case SCRIPTSTATE_INITIALIZED: + TRACE("State: Initialized.\n"); + break; + + case SCRIPTSTATE_STARTED: + TRACE("State: Started.\n"); + break; + + case SCRIPTSTATE_CONNECTED: + TRACE("State: Connected.\n"); + break; + + case SCRIPTSTATE_DISCONNECTED: + TRACE("State: Disconnected.\n"); + break; + + case SCRIPTSTATE_CLOSED: + TRACE("State: Closed.\n"); + break; + + default: + ERR("Unknown State: %d\n", ssScriptState); + break; + } + + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnScriptError(IActiveScriptSite* iface, IActiveScriptError* pscripterror) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + EXCEPINFO exception; + HRESULT hr; + + TRACE("(%p/%p)->(%p)\n", This, iface, pscripterror); + + hr = IActiveScriptError_GetExceptionInfo(pscripterror, &exception); + if (SUCCEEDED(hr)) + ERR("script error: %s\n", debugstr_w(exception.bstrDescription)); + + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnEnterScript(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static HRESULT WINAPI MsiActiveScriptSite_OnLeaveScript(IActiveScriptSite* iface) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p) stub\n", This, iface); + return S_OK; +} + +static const struct IActiveScriptSiteVtbl ASS_Vtbl = +{ + MsiActiveScriptSite_QueryInterface, + MsiActiveScriptSite_AddRef, + MsiActiveScriptSite_Release, + MsiActiveScriptSite_GetLCID, + MsiActiveScriptSite_GetItemInfo, + MsiActiveScriptSite_GetDocVersionString, + MsiActiveScriptSite_OnScriptTerminate, + MsiActiveScriptSite_OnStateChange, + MsiActiveScriptSite_OnScriptError, + MsiActiveScriptSite_OnEnterScript, + MsiActiveScriptSite_OnLeaveScript +}; + -- 1.4.1 -------------- next part -------------- From 1be8b9e7543653fe59cee4674a1bd7e8f1fbb1f7 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Sun, 25 Feb 2007 17:55:32 -0600 Subject: oleview: My private dispid patch. --- programs/oleview/typelib.c | 30 ++++++++++++++++++++++++++++-- 1 files changed, 28 insertions(+), 2 deletions(-) diff --git a/programs/oleview/typelib.c b/programs/oleview/typelib.c index 4336cf1..d96117a 100644 --- a/programs/oleview/typelib.c +++ b/programs/oleview/typelib.c @@ -372,6 +372,28 @@ #define VTADDTOSTR(x) case x:\ } } +void printw(WCHAR *w) +{ + int i=0; + while (w[i]) { printf("%c", (char)w[i]); i++; } +} + +void dispidhack(ITypeInfo *pTypeInfo, BSTR bstrName, MEMBERID memid, WCHAR *szOut) +{ + ITypeLib *pTLib; + UINT iTLib; + BSTR bstrTypeLibName; + WCHAR wformat[] = {'D','I','S','P','I','D','_','%','s','_','%','s',0}; + + ITypeInfo_GetContainingTypeLib(pTypeInfo, &pTLib, &iTLib); + ITypeLib_GetDocumentation(pTLib, iTLib, &bstrTypeLibName, NULL, NULL, NULL); + + wsprintfW(szOut, wformat, bstrTypeLibName, bstrName); + printf("#define "); + printw(struprW(szOut)); + printf(" %d\n", memid); +} + int EnumVars(ITypeInfo *pTypeInfo, int cVars, HTREEITEM hParent) { int i; @@ -403,7 +425,9 @@ int EnumVars(ITypeInfo *pTypeInfo, int c AddToTLDataStrW(tld, wszOpenBrackets1); AddToTLDataStrW(tld, wszId); AddToTLDataStrW(tld, wszOpenBrackets2); - wsprintfW(wszText, wszFormat, pVarDesc->memid); + // wsprintfW(wszText, wszFormat, pVarDesc->memid); + dispidhack(pTypeInfo, bstrName, pVarDesc->memid, wszText); + AddToTLDataStrW(tld, wszText); memset(wszText, 0, sizeof(wszText)); AddToTLDataStrW(tld, wszCloseBrackets2); @@ -537,7 +561,9 @@ int EnumFuncs(ITypeInfo *pTypeInfo, int bFirst = FALSE; AddToTLDataStrW(tld, wszId); AddToTLDataStrW(tld, wszOpenBrackets2); - wsprintfW(wszText, wszFormat, pFuncDesc->memid); +// wsprintfW(wszText, wszFormat, pFuncDesc->memid); + dispidhack(pTypeInfo, bstrName, pFuncDesc->memid, wszText); + AddToTLDataStrW(tld, wszText); AddToTLDataStrW(tld, wszCloseBrackets2); memset(wszText, 0, sizeof(wszText)); -- 1.4.1 From phil.krylov at gmail.com Mon Feb 26 00:40:38 2007 From: phil.krylov at gmail.com (Phil Krylov) Date: Mon Feb 26 10:18:21 2007 Subject: wine and msys rxvt.exe In-Reply-To: <001f01c7596e$ea763b00$0100a8c0@DMITRY> References: <200702252052.44341.wes.parish@paradise.net.nz> <001f01c7596e$ea763b00$0100a8c0@DMITRY> Message-ID: On 26/02/07, Dmitry Timoshkov wrote: > "Wesley Parish" wrote: > > > failed to load libX11.dll > > Looks like rxvt.exe is linked to an MSys provided X11 libraries > that require a Windows X11 sever to be present and running. That's > a sort of layer on layer and I don't think that there is someone > who wants to make this configuration work. AFAIR MSys's rxvt.exe uses libW11.dll, which implements Xlib API on top of Win32 USER/GDI (no extra X server). However, it could be still difficult (probably because of API name clashes?) Not sure why the message is about libX11.dll - probably it sees $DISPLAY and tries to use real X? -- Ph. From n.escuder at intra-links.com Mon Feb 26 09:16:30 2007 From: n.escuder at intra-links.com (Escuder Nicolas) Date: Mon Feb 26 10:18:22 2007 Subject: wine or wine-preloader exit with code 2 on x86_64 In-Reply-To: <45E2F76D.1080700@codeweavers.com> Message-ID: <437901c759b9$17fdcf80$1e45a8c0@yoshi> Hello, I have build wine with the help of wiki WineOn64bit LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure --prefix=/opt/wine --datadir=/usr/share But wine or wine-preloader always return 2 as you can see : [root@nico wine-0.9.31]# loader/wine-preloader [root@nico wine-0.9.31]# echo $? 2 [root@nico wine-0.9.31]# ./wine --version [root@nico wine-0.9.31]# echo $? 2 Anyone can help please ? See you, Escuder Nicolas From rob at codeweavers.com Mon Feb 26 10:35:21 2007 From: rob at codeweavers.com (Robert Shearman) Date: Mon Feb 26 10:35:54 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <45E1F81C.5040805@email.si> References: <45E1F81C.5040805@email.si> Message-ID: <45E30C49.9000800@codeweavers.com> Rok Mandeljc wrote: > Hey all, > > I've been experiencing an odd behavior in Baldur's Gate 2; when > "VideoMemorySize" registry key for wined3d is set to anything greater > than 64MB (69MB, actually), it stops before playing intro movie, > printing following line: > err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. > > Tracing the source of issue by inserting custom traces I got the following: > IDirectDrawImpl_CreateNewSurface -> IWineD3DDeviceImpl_CreateSurface > (decides to use GDI surface) -> IWineGDISurfaceImpl_PrivateSetup -> > IWineD3DSurfaceImpl_GetDC -> > CreateCompatibleDC -> CreateRectRgn -> REGION_CreateRegion -> > GDI_AllocObject -> alloc_large_heap > > alloc_large_heap fails because it can't find next large handle and > returns NULL, which is passed up the chain, where CreateCompatibleDC > puts it in dc->hVisRgn. Then DC_InitDC is called with that dc, which > calls CLIPPING_UpdateGCRegion, and that one finally chokes on it, > printing afore-mentioned line and calling exit(1). > > Now, when the game is run with 64MB of VideoMemorySize, upon reaching > the same point, IDirectDrawImpl_CreateNewSurface returns > WINED3DERR_OUTOFVIDEOMEMORY (because of > "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in > D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. > So it seems Baldur's Gate 2 is trying to create as many surfaces as > possible before running out of memory. And the problem arises when > specified memory size is large enough to take up all GDI's heap... > > Sorry for the long-winded description of the problem, but I'm not sure > where and how this should be fixed (is it wined3d issue or should GDI > have its heap enlarged?), otherwise I'd do it myself... > CreateCompatibleDC should be made to fail if the CreateRectRgn call fails. -- Rob Shearman From julliard at winehq.org Mon Feb 26 12:12:31 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 12:12:54 2007 Subject: xcopy try 3 In-Reply-To: <000801c7585e$0c93c750$1001a8c0@JasonsPC> (Ann & Jason Edmeades's message of "Sat\, 24 Feb 2007 21\:52\:11 -0000") References: <000801c7585e$0c93c750$1001a8c0@JasonsPC> Message-ID: <874pp86b5c.fsf@wine.dyndns.org> "Ann & Jason Edmeades" writes: > diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in > new file mode 100755 All the files you create or modify are marked executable, could you please fix that? -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Mon Feb 26 12:19:50 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Mon Feb 26 12:20:21 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <45E30C49.9000800@codeweavers.com> (Robert Shearman's message of "Mon\, 26 Feb 2007 16\:35\:21 +0000") References: <45E1F81C.5040805@email.si> <45E30C49.9000800@codeweavers.com> Message-ID: <87zm704w8p.fsf@wine.dyndns.org> Robert Shearman writes: > CreateCompatibleDC should be made to fail if the CreateRectRgn call fails. Yes, I committed a fix for that. -- Alexandre Julliard julliard@winehq.org From thunder.m at czela.net Mon Feb 26 12:58:00 2007 From: thunder.m at czela.net (Mirek) Date: Mon Feb 26 12:58:19 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <200702261352.28663.stefan@codeweavers.com> References: <200702261352.28663.stefan@codeweavers.com> Message-ID: <45E32DB8.5080502@czela.net> Hi, this series of patches broke some textures in TES IV: Oblivion, should I create bug in winebugs? I tried some other apps, they looks ok. (bug is here after patch 7/12 and 8/12). Mirek From flexo at holycrap.org Mon Feb 26 14:11:30 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Mon Feb 26 14:04:05 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> Message-ID: <45E33EF2.7070302@holycrap.org> Erich Hoover wrote: > Real Name: > Erich Hoover > Description: > Implements the functions ReplaceFileA and ReplaceFileW in kernel32 > (Bug #7544). Also provides conformance test code to ensure proper > functionality. > Changelog: > kernel32: Implement ReplaceFileA/ReplaceFileW Your patch seems to introduce lots of race cons. It's possible these exist on Win32 too but can't we avoid them? From stefan at codeweavers.com Mon Feb 26 15:01:56 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Mon Feb 26 15:02:06 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <45E32DB8.5080502@czela.net> References: <200702261352.28663.stefan@codeweavers.com> <45E32DB8.5080502@czela.net> Message-ID: <200702262202.00167.stefan@codeweavers.com> Am Montag 26 Februar 2007 19:58 schrieb Mirek: > Hi, this series of patches broke some textures in TES IV: Oblivion, > should I create bug in winebugs? I tried some other apps, they looks ok. > (bug is here after patch 7/12 and 8/12). Which patch breaks oblivion? Can you describe the kind of breakage? *cough* That game seems to be really picky *cough* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070226/8178249e/attachment.pgp From truiken at gmail.com Mon Feb 26 15:45:04 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 26 15:45:14 2007 Subject: wininet: Constify a formal parameter of CommitURLCache{A|W}() (Resend) In-Reply-To: <200702262128.09876.Andrew.Talbot@talbotville.com> References: <200702262128.09876.Andrew.Talbot@talbotville.com> Message-ID: <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> On 2/26/07, Andrew Talbot wrote: > What is wrong with this patch, please? > This isn't how it's defined in the SDK headers. -- James Hawkins From flexo at holycrap.org Mon Feb 26 15:54:27 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Mon Feb 26 15:46:41 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> Message-ID: <45E35713.1090100@holycrap.org> Erich Hoover wrote: > I assume you're referring to the file existence check and file delete, > followed by the actual copy and move. I implemented these checks in > this manner in order to provide error codes consistent with the > documentation. I am not incredibly familiar with the Wine internals, > but it looks to me like the functions called should handle a > simultaneous call from another thread (without unnecessary code > duplication). For example, if the "replaced" file goes missing between > the check and the CopyFileW call then CopyFileW will return an error. > If the "replaced" file appears between the DeleteFileW call and the > MoveFileExW call (since the MOVEFILE_REPLACE_EXISTING flag is not set), > then the MoveFileExW call will fail. The documentation's expected error > codes for ReplaceFile seem to be consistent with these potential > outcomes. Reading MSDN that doesn't seem to be the case. The way I see it all those errors documented could be caused by file permisions. MSDN doesn't say anything about race cons. Some notes about the patch: + /* Maker sure the "replacement" file exists before continuing */ + if(!RtlDoesFileExists_U( lpReplacementFileName )) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } This would probably the right place to lock the file... + /* + * If the user wants a backup then that needs to be performed first + * * Do not fail to backup if "replaced" does not exist + */ + if( lpBackupFileName && RtlDoesFileExists_U( lpReplacedFileName ) ) The call to RtlDoesFileExists_U() is redundant and introduces a race con. CopyFileW() will check for existence, check GLE afterwards. + { + /* If an existing backup exists then copy over it */ + */ + if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } + } + /* + * Now that the backup has been performed (if requested), copy the replacement + * into place (make sure we can delete the original file first) + * * Do not fail if "replaced" does not exist + */ + if(RtlDoesFileExists_U( lpReplacedFileName ) && !DeleteFileW( lpReplacedFileName )) Same here, DeleteFile() will check for existence. + { + SetLastError(ERROR_UNABLE_TO_REMOVE_REPLACED); + return FALSE; + } + if(!MoveFileExW( lpReplacementFileName, lpReplacedFileName, flags )) Couldn't you just get rid of the DeleteFile, check why MoveFileEx() failed and get rid of the call to RtlDoesFileExists_U(lpReplacedFileName)? + { + SetLastError(ERROR_UNABLE_TO_MOVE_REPLACEMENT); + return FALSE; + } + /* All done, file replacement successful */ + return TRUE; From thunder.m at czela.net Mon Feb 26 15:52:48 2007 From: thunder.m at czela.net (Mirek) Date: Mon Feb 26 15:53:10 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <200702262202.00167.stefan@codeweavers.com> References: <200702261352.28663.stefan@codeweavers.com> <45E32DB8.5080502@czela.net> <200702262202.00167.stefan@codeweavers.com> Message-ID: <45E356B0.7070604@czela.net> Stefan D?singer napsal(a): > Am Montag 26 Februar 2007 19:58 schrieb Mirek: >> Hi, this series of patches broke some textures in TES IV: Oblivion, >> should I create bug in winebugs? I tried some other apps, they looks ok. >> (bug is here after patch 7/12 and 8/12). > Which patch breaks oblivion? Can you describe the kind of breakage? > > *cough* That game seems to be really picky *cough* Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works normal but with graphical problems). I have Core 2 Duo CPU and SMP enabled, Nvidia GF6800GS with latest stable drivers. Here are some screenshots: http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ 2007-02-26-224223.jpg is for comparsion. This is realy strange, because after I do some spells (graphical efects) in game it just recover to normal state (everything looks like before). From ehoover at mines.edu Mon Feb 26 14:42:53 2007 From: ehoover at mines.edu (Erich Hoover) Date: Mon Feb 26 15:58:36 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <45E33EF2.7070302@holycrap.org> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> Message-ID: <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> I assume you're referring to the file existence check and file delete, followed by the actual copy and move. I implemented these checks in this manner in order to provide error codes consistent with the documentation. I am not incredibly familiar with the Wine internals, but it looks to me like the functions called should handle a simultaneous call from another thread (without unnecessary code duplication). For example, if the "replaced" file goes missing between the check and the CopyFileW call then CopyFileW will return an error. If the "replaced" file appears between the DeleteFileW call and the MoveFileExW call (since the MOVEFILE_REPLACE_EXISTING flag is not set), then the MoveFileExW call will fail. The documentation's expected error codes for ReplaceFile seem to be consistent with these potential outcomes. I apologize if there's something I'm missing here, please let me know. Erich Hoover ehoover@mines.edu On 2/26/07, Felix Nawothnig wrote: > > Erich Hoover wrote: > > Real Name: > > Erich Hoover > > Description: > > Implements the functions ReplaceFileA and ReplaceFileW in kernel32 > > (Bug #7544). Also provides conformance test code to ensure proper > > functionality. > > Changelog: > > kernel32: Implement ReplaceFileA/ReplaceFileW > > Your patch seems to introduce lots of race cons. It's possible these > exist on Win32 too but can't we avoid them? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070226/9741663a/attachment.htm From truiken at gmail.com Mon Feb 26 16:06:07 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 26 16:06:26 2007 Subject: Add localizable strings support for popup menu in selection tree control. In-Reply-To: <777930391.1172525777.177755500.8625@mcgi29.rambler.ru> References: <777930391.1172525777.177755500.8625@mcgi29.rambler.ru> Message-ID: <22821af30702261406h6f21ec43y63cafc812fb61273@mail.gmail.com> On 2/26/07, ?????? ??????? wrote: > diff --git a/dlls/msi/dialog.c b/dlls/msi/dialog.c > index 35a192c..3826326 100644 > --- a/dlls/msi/dialog.c > +++ b/dlls/msi/dialog.c > @@ -1755,17 +1755,41 @@ msi_seltree_popup_menu( HWND hwnd, INT x > HMENU hMenu; > INT r; > > + static const WCHAR szMenuLocal[] = > {'M','e','n','u','L','o','c','a','l',0}; > + static const WCHAR szMenuAllLocal[] = > {'M','e','n','u','A','l','l','L','o','c','a','l',0}; > + static const WCHAR szMenuAdvertise[] = > {'M','e','n','u','A','d','v','e','r','t','i','s','e',0}; > + static const WCHAR szMenuAbsent[] = > {'M','e','n','u','A','b','s','e','n','t',0}; > + /* If msi_dialog_get_uitext returns NULL - use default strings: */ > + static const WCHAR szMenuLocalDef[] = > {'I','n','s','t','a','l','l',' ','f','e','a','t','u','r','e',' ', > 'l','o','c','a','l','l','y',0}; > + static const WCHAR szMenuAllLocalDef[] = > {'I','n','s','t','a','l','l',' ','e','n','t','i','r','e',' > ','f','e','a','t','u','r','e',0}; > + static const WCHAR szMenuAdvertiseDef[] = > {'I','n','s','t','a','l','l',' ','o','n',' ','d','e','m','a','n','d',0}; > + static const WCHAR szMenuAbsentDef[] = {'D','o','n','\'','t',' > ','i','n','s','t','a','l','l',0}; > + > + LPWSTR szLocal,szAllLocal,szAdvertise,szAbsent; > + struct msi_selection_tree_info *info; > + > + info = GetPropW(hwnd, szButtonData); > + > + szLocal= msi_dialog_get_uitext( info->dialog, szMenuLocal ); > + szAllLocal= msi_dialog_get_uitext( info->dialog, szMenuAllLocal ); > + szAdvertise= msi_dialog_get_uitext( info->dialog, szMenuAdvertise > ); > + szAbsent= msi_dialog_get_uitext( info->dialog, szMenuAbsent ); > + > /* create a menu to display */ > hMenu = CreatePopupMenu(); > > - /* FIXME: load strings from resources */ > - AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_LOCAL, "Install > feature locally"); > - AppendMenuA( hMenu, MF_GRAYED, 0x1000, "Install entire feature"); > - AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_ADVERTISED, "Install > on demand"); > - AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_ABSENT, "Don't > install"); > + /* Use strings from resources */ > + AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_LOCAL, > (szLocal==NULL)?szMenuLocalDef:szLocal ); > + AppendMenuW( hMenu, MF_GRAYED, 0x1000, > (szAllLocal==NULL)?szMenuAllLocalDef:szAllLocal ); > + AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_ADVERTISED, > (szAdvertise==NULL)?szMenuAdvertiseDef:szAdvertise ); > + AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_ABSENT, > (szAbsent==NULL)?szMenuAbsentDef:szAbsent ); > r = TrackPopupMenu( hMenu, TPM_LEFTALIGN | TPM_TOPALIGN | > TPM_RETURNCMD, > x, y, 0, hwnd, NULL ); > DestroyMenu( hMenu ); > + if(szLocal) msi_free(szLocal); > + if(szAllLocal) msi_free(szAllLocal); > + if(szAdvertise) msi_free(szAdvertise); > + if(szAbsent) msi_free(szAbsent); > return r; > } > Don't check values for NULL before freeing them. The check is redundant, and we spent a long time removing such checks. -- James Hawkins From Andrew.Talbot at talbotville.com Mon Feb 26 16:20:20 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Mon Feb 26 16:21:13 2007 Subject: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend) References: <200702262128.09876.Andrew.Talbot@talbotville.com> <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> Message-ID: James Hawkins wrote: > On 2/26/07, Andrew Talbot wrote: >> What is wrong with this patch, please? >> > > This isn't how it's defined in the SDK headers. > Am I right in thinking that for non-embedded-CE versions of Windows the lpHeaderInfo variable of CommitURLCacheEntry() is now a LPCTSTR? In which case, I presume that the comment about the ascii version requiring a LPBYTE is now wrong: the "A" version should now have a LPCSTR and the "W" version, a LPCWSTR. -- Andy. From Andrew.Talbot at talbotville.com Mon Feb 26 16:53:49 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Mon Feb 26 16:54:27 2007 Subject: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend) References: <200702262128.09876.Andrew.Talbot@talbotville.com> <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> Message-ID: The problem seems to be that the INTERNET_CACHE_ENTRY_INFO structure has a member lpHeaderInfo that is a LPBYTE, but the corresponding parameter of CommitURLCacheEntry() - sorry, I truncated its name in the original posting - ought to be a LPTSTR. It is not yet clear to me what is required. -- Andy. From Andrew.Talbot at talbotville.com Mon Feb 26 17:11:37 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Mon Feb 26 17:12:22 2007 Subject: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend) References: <200702262128.09876.Andrew.Talbot@talbotville.com> <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> Message-ID: Andrew Talbot wrote: > ... but the corresponding parameter of > CommitURLCacheEntry() [...] ought to be a LPTSTR.... Or rather, a LPCTSTR. So, is there any scope to constify, here? -- A. From truiken at gmail.com Mon Feb 26 17:27:30 2007 From: truiken at gmail.com (James Hawkins) Date: Mon Feb 26 17:27:42 2007 Subject: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend) In-Reply-To: References: <200702262128.09876.Andrew.Talbot@talbotville.com> <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> Message-ID: <22821af30702261527w5c70b3a4h7741241c9eebd204@mail.gmail.com> On 2/26/07, Andrew Talbot wrote: > James Hawkins wrote: > > > On 2/26/07, Andrew Talbot wrote: > >> What is wrong with this patch, please? > >> > > > > This isn't how it's defined in the SDK headers. > > > > Am I right in thinking that for non-embedded-CE versions of Windows the > lpHeaderInfo variable of CommitURLCacheEntry() is now a LPCTSTR? In which > case, I presume that the comment about the ascii version requiring a LPBYTE > is now wrong: the "A" version should now have a LPCSTR and the "W" version, > a LPCWSTR. > #ifndef USE_FIXED_COMMIT_URL_CACHE_ENTRY // Temporary state of affairs until we reconcile our apis. // Why are we doing this? HeaderInfo _should_ be string data. // However, one group is passing binary data instead. For the // unicode api, we've decided to disallow this, but this // brings up an inconsistency between the u and a apis, which // is undesirable. // For Beta 1, we'll go with this behaviour, but in future releases // we want to make these apis consistent. BOOLAPI CommitUrlCacheEntryA( __in LPCSTR lpszUrlName, __in_opt LPCSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPBYTE lpHeaderInfo, __in_opt DWORD dwHeaderSize, __reserved LPCSTR lpszFileExtension, __in_opt LPCSTR lpszOriginalUrl ); BOOLAPI CommitUrlCacheEntryW( __in LPCWSTR lpszUrlName, __in_opt LPCWSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaders) LPWSTR lpszHeaderInfo, __in DWORD dwHeaders, __reserved LPCWSTR lpszFileExtension, __in_opt LPCWSTR lpszOriginalUrl ); #ifdef UNICODE #define CommitUrlCacheEntry CommitUrlCacheEntryW #else #define CommitUrlCacheEntry CommitUrlCacheEntryA #endif #else CommitUrlCacheEntryA( __in LPCSTR lpszUrlName, __in_opt LPCSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPCSTR lpHeaderInfo, __in DWORD dwHeaderSize, __reserved LPCSTR lpszFileExtension, __in_opt LPCSTR lpszOriginalUrl ); CommitUrlCacheEntryW( __in LPCWSTR lpszUrlName, __in_opt LPCWSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPCWSTR lpHeaderInfo, __in DWORD dwHeaderSize, __reserved LPCWSTR lpszFileExtension, __in_opt LPCWSTR lpszOriginalUrl ); #ifdef UNICODE #define CommitUrlCacheEntry CommitUrlCacheEntryW #else #define CommitUrlCacheEntry CommitUrlCacheEntryA #endif // !UNICODE #endif -- James Hawkins From stefan at codeweavers.com Mon Feb 26 17:31:14 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Mon Feb 26 17:31:25 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <45E356B0.7070604@czela.net> References: <200702261352.28663.stefan@codeweavers.com> <200702262202.00167.stefan@codeweavers.com> <45E356B0.7070604@czela.net> Message-ID: <200702270031.18206.stefan@codeweavers.com> Am Montag 26 Februar 2007 22:52 schrieb Mirek: > Stefan D?singer napsal(a): > > Am Montag 26 Februar 2007 19:58 schrieb Mirek: > >> Hi, this series of patches broke some textures in TES IV: Oblivion, > >> should I create bug in winebugs? I tried some other apps, they looks ok. > >> (bug is here after patch 7/12 and 8/12). > > > > Which patch breaks oblivion? Can you describe the kind of breakage? > > > > *cough* That game seems to be really picky *cough* > > Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works > normal but with graphical problems). I have Core 2 Duo CPU and SMP > enabled, Nvidia GF6800GS with latest stable drivers. > > Here are some screenshots: > http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ > > 2007-02-26-224223.jpg is for comparsion. > > This is realy strange, because after I do some spells (graphical efects) > in game it just recover to normal state (everything looks like before). Strange yes. Does it print any fixme right before it crashes if you only apply patch 7? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/005e037e/attachment.pgp From wine.dev at web.de Mon Feb 26 18:03:09 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Mon Feb 26 18:03:47 2007 Subject: [PATCH] seperate AC_CONFIG_FILES. In-Reply-To: <1172524863.7050.10.camel@p4> References: <1172524863.7050.10.camel@p4> Message-ID: <1172534589.7050.16.camel@p4> On Mo, 2007-02-26 at 22:06 +0100, Marcus Meissner wrote: > -AC_CONFIG_FILES([ > -Make.rules > -dlls/Makedll.rules > -dlls/Makeimplib.rules > -dlls/Maketest.rules > -programs/Makeprog.rules > -Makefile > -dlls/Makefile Does "tools/make_makefiles" still work after your Patch? - for a new dll - for a new test - for a new program I'm unable to test that here (my autoconf is to old) -- By by ... Detlef From stefan at codeweavers.com Mon Feb 26 18:41:04 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-15?q?D=F6singer?=) Date: Mon Feb 26 18:41:17 2007 Subject: [7/12] WineD3D: Select an onscreen context based on the thread In-Reply-To: <200702261349.21123.stefan@codeweavers.com> References: <200702261349.21123.stefan@codeweavers.com> Message-ID: <200702270141.07953.stefan@codeweavers.com> Am Montag 26 Februar 2007 13:49 schrieb Stefan D?singer: Alexandre, do not patch 7, 8 and 9 yet, they are reported to cause regressions. Patch 10, 11 and 12 should apply without them too. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/cfe45f15/attachment.pgp From flexo at holycrap.org Mon Feb 26 21:30:41 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Mon Feb 26 21:22:49 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> <45E35713.1090100@holycrap.org> <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> Message-ID: <45E3A5E1.90400@holycrap.org> Erich Hoover wrote: > Is the attached more like what you're looking for? I did some investigation and... actually I'm looking for an equivalent to the linux splice syscall. Win32 is the most braindead API ever. Duh. The "right" way would probably to do the copying yourself by read/write.. but I dunno. Your code looks solid at the first glance. Three things: - I'd remove the FILE_SHARE_DELETE and FILE_SHARE_WRITE. - Use MoveFile instead of CopyFile/DeleteFile at the end? - Are you sure you're supposed to set ERROR_INVALID_PARAMETER no matter what bad happens? If the function which failed already set LE you should probably keep it... Felix From chris.kcat at gmail.com Mon Feb 26 22:32:15 2007 From: chris.kcat at gmail.com (Chris Robinson) Date: Mon Feb 26 22:33:12 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <45E21D62.8080300@kievinfo.com> References: <45E1F81C.5040805@email.si> <45E21D62.8080300@kievinfo.com> Message-ID: <200702262032.15395.chris.kcat@gmail.com> On Sunday 25 February 2007 03:36:02 pm Vitaliy Margolen wrote: > The memory size setting is only in registry because you should not touch > it in the first place. I thought it was added to the registry because Wine can't figure out the video memory amount itself from OpenGL or X, and that allows the user to make it report the proper amount (or at least, more proper). Before it was hard-coded to 64MB. From jan.wine at zerebecki.de Mon Feb 26 23:47:14 2007 From: jan.wine at zerebecki.de (Jan Zerebecki) Date: Mon Feb 26 23:47:24 2007 Subject: configure: Break single-line ac_config_files list into multiple lines. In-Reply-To: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> References: <200702241215.l1OCFTfO014481@tvarka.ar.fi.lt> Message-ID: <20070227054714.GH6219@crissy.swd.zerebecki.de> On Sat, Feb 24, 2007 at 02:15:29PM +0200, Saulius Krasuckas wrote: > This long line breaks automated rebasing of one of testing branches on > (namely ntoskrnl) on my box every time a new dll or program is added. > That's because I need to merge conflict for this line by my hand. You might find http://wiki.winehq.org/There_are_always_conflicts_in_configure interesting. Jan From marcus at jet.franken.de Tue Feb 27 00:20:06 2007 From: marcus at jet.franken.de (Marcus Meissner) Date: Tue Feb 27 00:22:52 2007 Subject: [PATCH] seperate AC_CONFIG_FILES. In-Reply-To: <1172534589.7050.16.camel@p4> References: <1172524863.7050.10.camel@p4> <1172534589.7050.16.camel@p4> Message-ID: <20070227062006.GA30422@jet.franken.de> On Tue, Feb 27, 2007 at 01:03:09AM +0100, Detlef Riekenberg wrote: > On Mo, 2007-02-26 at 22:06 +0100, Marcus Meissner wrote: > > > -AC_CONFIG_FILES([ > > -Make.rules > > -dlls/Makedll.rules > > -dlls/Makeimplib.rules > > -dlls/Maketest.rules > > -programs/Makeprog.rules > > -Makefile > > -dlls/Makefile > > Does "tools/make_makefiles" still work after your Patch? > - for a new dll > - for a new test > - for a new program > > I'm unable to test that here (my autoconf is to old) Seems I need to actually change tools/make_makefiles instead of configure.ac :( Ciao, Marcus From thunder.m at czela.net Tue Feb 27 02:33:58 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 27 02:34:11 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <200702270031.18206.stefan@codeweavers.com> References: <200702261352.28663.stefan@codeweavers.com> <200702262202.00167.stefan@codeweavers.com> <45E356B0.7070604@czela.net> <200702270031.18206.stefan@codeweavers.com> Message-ID: <45E3ECF6.3090306@czela.net> Stefan D?singer napsal(a): > Am Montag 26 Februar 2007 22:52 schrieb Mirek: >> Stefan D?singer napsal(a): >>> Am Montag 26 Februar 2007 19:58 schrieb Mirek: >>>> Hi, this series of patches broke some textures in TES IV: Oblivion, >>>> should I create bug in winebugs? I tried some other apps, they looks ok. >>>> (bug is here after patch 7/12 and 8/12). >>> Which patch breaks oblivion? Can you describe the kind of breakage? >>> >>> *cough* That game seems to be really picky *cough* >> Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works >> normal but with graphical problems). I have Core 2 Duo CPU and SMP >> enabled, Nvidia GF6800GS with latest stable drivers. >> >> Here are some screenshots: >> http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ >> >> 2007-02-26-224223.jpg is for comparsion. >> >> This is realy strange, because after I do some spells (graphical efects) >> in game it just recover to normal state (everything looks like before). > Strange yes. Does it print any fixme right before it crashes if you only apply > patch 7? Here is output with only patches 1,2,3,4,5,6,7,10,11,12 (without patch 8 and 9): fixme:d3d:ActivateContext Context creation for a new thread not implemented yet wine: Unhandled page fault on read access to 0x00001098 at address 0x7c544f6c (thread 0010), starting debugger... Unhandled exception: page fault on read access to 0x00001098 in 32-bit code (0x7c544f6c). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c544f6c ESP:7bdedd70 EBP:7bdeddd8 EFLAGS:00210246( - 00 -RIZP1) EAX:001b9268 EBX:7c5db078 ECX:00000000 EDX:00000000 ESI:00000000 EDI:0016be08 Stack dump: 0x7bdedd70: 0018ab38 7c5db9c4 7c5bc8dc 7c5bc694 0x7bdedd80: 16e9fa10 7efe5368 7bdedde8 7efa2396 0x7bdedd90: 00110020 175e21e0 7bdeddb8 7efa16f3 0x7bdedda0: 7efe5368 000e0000 00000000 00000000 0x7bdeddb0: 00000000 7efe5368 7bdede18 7e32d53c 0x7bdeddc0: 175069b8 001b9268 0018ab38 7c5db078 Backtrace: =>1 0x7c544f6c ActivateContext+0x2ac(This=0x1b9268, target=0x205618, usage=0x1) [/usr/src/wine/dlls/wined3d/context.c:761] in wined3d (0x7bdeddd8) 2 0x7c54f23d CreateVBO+0x6d(object=) [/usr/src/wine/dlls/wined3d/device.c:330] in wined3d (0x7bdede18) 3 0x7c553e27 IWineD3DDeviceImpl_CreateVertexBuffer+0x1f7(iface=, Size=0x120, Usage=0x8, FVF=0x0, Pool=0x1, ppVertexBuffer=0x16e9fa08, sharedHandle=0x0, parent=0x16e9fa00) [/usr/src/wine/dlls/wined3d/device.c:447] in wined3d (0x7bdede68) 4 0x7c781815 IDirect3DDevice9Impl_CreateVertexBuffer+0x95(iface=0x186870, Size=0x120, Usage=, FVF=0x0, Pool=0x1, ppVertexBuffer=0x7bdedee0, pSharedHandle=0x0) [/root/.WineCVS/sources/cvswine/wine/dlls/d3d9/vertexbuffer.c:177] in d3d9 (0x7bdedea8) 5 0x006e2d7d in oblivion (+0x2e2d7d) (0x7bdedee0) 6 0x00000000 (0x26034550) 7 0x130003e4 (0x01c00000) 8 0x2a08eed8 (0x2a08ee10) 9 0xbffadd7c (0xbfd1fd64) 10 0x00000000 (0x00000000) 0x7c544f6c ActivateContext+0x2ac [/usr/src/wine/dlls/wined3d/context.c:761] in wined3d: movl 0x1098(%edx),%eax 761 ret = glXMakeCurrent(context->display, context->drawable, context->glCtx); Modules: Module Address Debug info Name (104 modules) PE 400000-b59000 Export oblivion PE b60000-daf000 Deferred d3dx9_27 PE 18000000-18068000 Deferred binkw32 ELF 7b1f1000-7b28a000 Deferred oleaut32 \-PE 7b200000-7b28a000 \ oleaut32 ELF 7bf00000-7bf03000 Deferred ELF 7bf80000-7bfa7000 Deferred msvfw32 \-PE 7bf90000-7bfa7000 \ msvfw32 ELF 7bfa7000-7c000000 Deferred quartz \-PE 7bfb0000-7c000000 \ quartz ELF 7c491000-7c521000 Deferred libglu.so.1 ELF 7c521000-7c5dc000 Dwarf wined3d \-PE 7c530000-7c5dc000 \ wined3d ELF 7c718000-7c737000 Deferred devenum \-PE 7c720000-7c737000 \ devenum ELF 7c737000-7c742000 Deferred libgcc_s.so.1 ELF 7c747000-7c75b000 Deferred avicap32 \-PE 7c750000-7c75b000 \ avicap32 ELF 7c762000-7c78d000 Dwarf d3d9 \-PE 7c770000-7c78d000 \ d3d9 ELF 7c9a8000-7ca69000 Deferred libasound.so.2 ELF 7ca69000-7ca94000 Deferred winealsa \-PE 7ca70000-7ca94000 \ winealsa ELF 7ca94000-7cac6000 Deferred uxtheme \-PE 7caa0000-7cac6000 \ uxtheme ELF 7cd55000-7cd6a000 Deferred midimap \-PE 7cd60000-7cd6a000 \ midimap ELF 7cd6a000-7cd6f000 Deferred libxfixes.so.3 ELF 7cd75000-7cd8d000 Deferred msacm32 \-PE 7cd80000-7cd8d000 \ msacm32 ELF 7cd8f000-7cd92000 Deferred libxinerama.so.1 ELF 7cd95000-7cdb2000 Deferred imm32 \-PE 7cda0000-7cdb2000 \ imm32 ELF 7d75c000-7e0cd000 Deferred libglcore.so.1 ELF 7e0cd000-7e161000 Deferred libgl.so.1 ELF 7e161000-7e166000 Deferred libxdmcp.so.6 ELF 7e166000-7e169000 Deferred libxau.so.6 ELF 7e169000-7e255000 Deferred libx11.so.6 ELF 7e255000-7e263000 Deferred libxext.so.6 ELF 7e263000-7e268000 Deferred libxxf86vm.so.1 ELF 7e268000-7e280000 Deferred libice.so.6 ELF 7e280000-7e289000 Deferred libsm.so.6 ELF 7e289000-7e292000 Deferred libxcursor.so.1 ELF 7e292000-7e295000 Deferred libxrandr.so.2 ELF 7e295000-7e29d000 Deferred libxrender.so.1 ELF 7e2a9000-7e336000 Deferred winex11 \-PE 7e2c0000-7e336000 \ winex11 ELF 7e3ac000-7e3cc000 Deferred libexpat.so.1 ELF 7e3cc000-7e3f7000 Deferred libfontconfig.so.1 ELF 7e3f7000-7e40b000 Deferred libz.so.1 ELF 7e40b000-7e475000 Deferred libfreetype.so.6 ELF 7e495000-7e4c1000 Deferred ws2_32 \-PE 7e4a0000-7e4c1000 \ ws2_32 ELF 7e4c1000-7e4db000 Deferred wsock32 \-PE 7e4d0000-7e4db000 \ wsock32 ELF 7e4db000-7e53f000 Deferred msvcrt \-PE 7e4f0000-7e53f000 \ msvcrt ELF 7e53f000-7e553000 Deferred lz32 \-PE 7e550000-7e553000 \ lz32 ELF 7e553000-7e5ab000 Deferred shlwapi \-PE 7e560000-7e5ab000 \ shlwapi ELF 7e5ab000-7e6a0000 Deferred shell32 \-PE 7e5c0000-7e6a0000 \ shell32 ELF 7e6a0000-7e6e9000 Deferred dsound \-PE 7e6b0000-7e6e9000 \ dsound ELF 7e6e9000-7e777000 Deferred winmm \-PE 7e6f0000-7e777000 \ winmm ELF 7e777000-7e78a000 Deferred libresolv.so.2 ELF 7e78a000-7e78c000 Deferred libnvidia-tls.so.1 ELF 7e791000-7e7aa000 Deferred version \-PE 7e7a0000-7e7aa000 \ version ELF 7e7aa000-7e7c8000 Deferred iphlpapi \-PE 7e7b0000-7e7c8000 \ iphlpapi ELF 7e7c8000-7e81d000 Deferred rpcrt4 \-PE 7e7d0000-7e81d000 \ rpcrt4 ELF 7e81d000-7e8b6000 Deferred ole32 \-PE 7e830000-7e8b6000 \ ole32 ELF 7e8b6000-7e8ec000 Deferred dinput \-PE 7e8c0000-7e8ec000 \ dinput ELF 7e8ec000-7e905000 Deferred dinput8 \-PE 7e8f0000-7e905000 \ dinput8 ELF 7e905000-7e94b000 Deferred advapi32 \-PE 7e910000-7e94b000 \ advapi32 ELF 7e94b000-7e9de000 Deferred gdi32 \-PE 7e960000-7e9de000 \ gdi32 ELF 7e9de000-7eb18000 Deferred user32 \-PE 7ea00000-7eb18000 \ user32 ELF 7eb18000-7ebd5000 Deferred comctl32 \-PE 7eb20000-7ebd5000 \ comctl32 ELF 7edd5000-7eefb000 Deferred kernel32 \-PE 7edf0000-7eefb000 \ kernel32 ELF 7eefb000-7ef06000 Deferred libnss_files.so.2 ELF 7ef06000-7ef10000 Deferred libnss_nis.so.2 ELF 7ef10000-7ef26000 Deferred libnsl.so.1 ELF 7ef26000-7ef4b000 Deferred libm.so.6 ELF 7ef4b000-7ef4f000 Deferred iso8859-2.so ELF 7ef6b000-7f000000 Deferred ntdll \-PE 7ef80000-7f000000 \ ntdll ELF b7d2a000-b7d2e000 Deferred libdl.so.2 ELF b7d2e000-b7e60000 Deferred libc.so.6 ELF b7e60000-b7e72000 Deferred libpthread.so.0 ELF b7e77000-b7e80000 Deferred libnss_compat.so.2 ELF b7e93000-b7fa4000 Deferred libwine.so.1 ELF b7fa6000-b7fbd000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) G:\usr\games\oblivion\Oblivion.exe 00000013 0 00000010 -1 <== 0000000f -1 0000000e 15 0000000d 0 00000009 0 From thunder.m at czela.net Tue Feb 27 02:54:44 2007 From: thunder.m at czela.net (Mirek) Date: Tue Feb 27 02:54:49 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <45E3ECF6.3090306@czela.net> References: <200702261352.28663.stefan@codeweavers.com> <200702262202.00167.stefan@codeweavers.com> <45E356B0.7070604@czela.net> <200702270031.18206.stefan@codeweavers.com> <45E3ECF6.3090306@czela.net> Message-ID: <45E3F1D4.4080704@czela.net> Mirek napsal(a): > Stefan D?singer napsal(a): >> Am Montag 26 Februar 2007 22:52 schrieb Mirek: >>> Stefan D?singer napsal(a): >>>> Am Montag 26 Februar 2007 19:58 schrieb Mirek: >>>>> Hi, this series of patches broke some textures in TES IV: Oblivion, >>>>> should I create bug in winebugs? I tried some other apps, they >>>>> looks ok. >>>>> (bug is here after patch 7/12 and 8/12). >>>> Which patch breaks oblivion? Can you describe the kind of breakage? >>>> >>>> *cough* That game seems to be really picky *cough* >>> Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works >>> normal but with graphical problems). I have Core 2 Duo CPU and SMP >>> enabled, Nvidia GF6800GS with latest stable drivers. >>> >>> Here are some screenshots: >>> http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ >>> >>> 2007-02-26-224223.jpg is for comparsion. >>> >>> This is realy strange, because after I do some spells (graphical efects) >>> in game it just recover to normal state (everything looks like before). >> Strange yes. Does it print any fixme right before it crashes if you >> only apply patch 7? > Output with all patches 1,2,3,4,5,6,7,8,9,10,11,12 (only interesting part): fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:ActivateContext Offscreen rendering is only supported from the creation thread yet fixme:d3d:ActivateContext Expect a crash now ... fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found And output without patch 7,8 an 9 (same part): fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=24400 < primary_done=24404) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=8016 < primary_done=8020) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=8016 < primary_done=8020) fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=19580 < primary_done=19584) fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:d3d:CreateVBO Failed to create a vertex buffer object. Continuing, but performance issues can occur err:d3d:CreateIndexBufferVBO Creating a vbo failed, continueing without vbo for this buffer fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:d3d:IWineD3DDeviceImpl_ResourceReleased Vertex buffer released while bound to a state block, stream 0 fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found From hverbeet at gmail.com Tue Feb 27 03:28:16 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 27 03:28:28 2007 Subject: GDI surfaces, GDI heap and wined3d's VideoMemorySize In-Reply-To: <200702262032.15395.chris.kcat@gmail.com> References: <45E1F81C.5040805@email.si> <45E21D62.8080300@kievinfo.com> <200702262032.15395.chris.kcat@gmail.com> Message-ID: On 27/02/07, Chris Robinson wrote: > I thought it was added to the registry because Wine can't figure out the video > memory amount itself from OpenGL or X, and that allows the user to make it > report the proper amount (or at least, more proper). Before it was hard-coded > to 64MB. > Pretty much. From kai.blin at gmail.com Tue Feb 27 04:36:57 2007 From: kai.blin at gmail.com (Kai Blin) Date: Tue Feb 27 04:38:02 2007 Subject: dplay: directplay should initialize session Guid patch + conformance tests In-Reply-To: <200702242211.02623.alex.pigna@inventati.org> References: <200702241725.49691.alex.pigna@inventati.org> <200702242211.02623.alex.pigna@inventati.org> Message-ID: <200702271137.02442.kai.blin@gmail.com> On Saturday 24 February 2007 22:10, Alessandro Pignotti wrote: > Thanks for the suggestions, this version of the patch uses IsEqualGUID and > eliminates C++ style comments and insert a proper copyright notice in the > added file You might want to use #include "wine/test.h" instead of #include , all the other tests do that. Also, you should split out the test from the START_TEST(dplayx) function into a function called e.g. test_session_guid and do all the testing there. Also, please use IsEqualGUID() in EnumConnectionsCallback, too. Sorry for not replying earlier, but last week was kind of a mess, and I'm slowly catching up. Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/6cf7860e/attachment.pgp From stefan at codeweavers.com Tue Feb 27 04:59:30 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Tue Feb 27 04:59:29 2007 Subject: [1/12] - [12/12] WineD3D (multithreading) In-Reply-To: <45E3F1D4.4080704@czela.net> References: <200702261352.28663.stefan@codeweavers.com> <45E3ECF6.3090306@czela.net> <45E3F1D4.4080704@czela.net> Message-ID: <200702271159.34760.stefan@codeweavers.com> Am Dienstag 27 Februar 2007 09:54 schrieb Mirek: Looks like we have a rouge multithreaded game here - which is pretty strange since it worked before. > Here is output with only patches 1,2,3,4,5,6,7,10,11,12 (without patch 8 > and 9): > fixme:d3d:ActivateContext Context creation for a new thread not > implemented yet Can you send me a +d3d9,tid trace from that? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/8dd2d45d/attachment.pgp From julliard at winehq.org Tue Feb 27 05:33:48 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 27 05:33:52 2007 Subject: [4/6] cmd.exe : Prompt during rd /s command In-Reply-To: <008101c759fa$90281330$1001a8c0@JasonsPC> (Ann & Jason Edmeades's message of "Mon\, 26 Feb 2007 23\:05\:09 -0000") References: <008101c759fa$90281330$1001a8c0@JasonsPC> Message-ID: <87fy8r4yxv.fsf@wine.dyndns.org> "Ann & Jason Edmeades" writes: > + /* Load the translated 'Are you sure' message */ > + LoadString (hinst, WCMD_YESORN, buffer, sizeof(buffer)); > + > + /* Loop waiting on a Y or N */ > + while (answer[0] != 'Y' && answer[0] != 'N') { Making the message translatable is good, but the Y/N answers need to be translatable too... -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Tue Feb 27 05:43:19 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Tue Feb 27 05:43:26 2007 Subject: ntdll: resend 1/4 NtCreateMailslotFile tests In-Reply-To: <45E3EB22.2030004@yless4u.com.au> (Jeff Latimer's message of "Tue\, 27 Feb 2007 19\:26\:10 +1100") References: <45E3EB22.2030004@yless4u.com.au> Message-ID: <87bqjf4yi0.fsf@wine.dyndns.org> Jeff Latimer writes: > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index cccc4c5..4ceccfd 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -14,6 +14,7 @@ CTESTS = \ > generated.c \ > info.c \ > large_int.c \ > + mailslot.c \ Naming it file.c would be better, since that's the name of the corresponding source file, and that makes it more general so it can later contain other tests too. -- Alexandre Julliard julliard@winehq.org From dmitry at codeweavers.com Tue Feb 27 06:30:59 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 27 06:31:03 2007 Subject: dplay: directplay should initialize session Guid patch +conformance tests References: <200702241725.49691.alex.pigna@inventati.org><200702242211.02623.alex.pigna@inventati.org><200702271137.02442.kai.blin@gmail.com> <200702271315.52669.alex.pigna@inventati.org> Message-ID: <003301c75a6b$2819abc0$0100a8c0@DMITRY> "Alessandro Pignotti" wrote: > +BOOL FAR PASCAL EnumConnectionsCallback(LPCGUID lpguidSP, LPVOID lpConnection, > + DWORD dwConnectionSize, LPCDPNAME lpName, DWORD dwFlags, > + LPVOID lpContext) > +{ This doesn't look like a proper type of callb ack for IDirectPlayX_EnumConnections. > + bzero(&sessionDesc,sizeof(DPSESSIONDESC2)); > + bzero(&zeroGuid,16); Use memset instead of non-portable bzero. > + LPDIRECTPLAY4 pDP = NULL; This initialization is redundant. If you also could use 4 spaces indents instead of tabs, and add an empty line after data declarations that would be nice as well. And a personal opinion: all that lines without a single space delimiting variables, functions, equal signs are absolutely not readable. -- Dmitry. From hverbeet at gmail.com Tue Feb 27 07:17:03 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Tue Feb 27 07:17:03 2007 Subject: dplay: directplay should initialize session Guid patch +conformance tests In-Reply-To: <003301c75a6b$2819abc0$0100a8c0@DMITRY> References: <200702241725.49691.alex.pigna@inventati.org> <200702242211.02623.alex.pigna@inventati.org> <200702271137.02442.kai.blin@gmail.com> <200702271315.52669.alex.pigna@inventati.org> <003301c75a6b$2819abc0$0100a8c0@DMITRY> Message-ID: On 27/02/07, Dmitry Timoshkov wrote: > > +BOOL FAR PASCAL EnumConnectionsCallback(LPCGUID lpguidSP, LPVOID lpConnection, > > + DWORD dwConnectionSize, LPCDPNAME lpName, DWORD dwFlags, > > + LPVOID lpContext) > > +{ > > This doesn't look like a proper type of callb ack for IDirectPlayX_EnumConnections. > I wondered about that as well, but it does appear to be what the DXSDK headers specify. From stefan at codeweavers.com Tue Feb 27 08:40:21 2007 From: stefan at codeweavers.com (Stefan =?iso-8859-1?q?D=F6singer?=) Date: Tue Feb 27 08:40:31 2007 Subject: [3/12 WineD3D/DDraw: Forward DDSCL_MULTITHREADED to WineD3D In-Reply-To: References: <200702261348.29128.stefan@codeweavers.com> Message-ID: <200702271540.25349.stefan@codeweavers.com> > What exactly is this supposed to fix? We already pass the behaviour > flags through to IWineD3DImpl_CreateDevice(), so shouldn't wined3d > just handle it there? In DirectDraw the multithreading flag is set after creating the device, so I need a seperate method to set it in wined3d, because I don't know it at initialization time. This method has to initialize the thread safety things in wined3d. Now d3d8 and d3d9 call SetMultithreaded too because it is clearer to have SetMultithreaded called by ddraw, d3d8 and d3d9 instead of ddraw and wined3d. On the other hand, there are now 2 places where the multithreaded flag is passed to wined3d now, CreateDevice and SetMultithreaded. I could call SetMultithreaded from wined3d::CreateDevice, and not call it from d3d8/9, or I could remove the WINED3DCREATE_MULTITHREADED flag from the public wined3d_interface.h header, sinaling that CreateDevice ignores that flag? Or anything I missed? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/b263fbfc/attachment.pgp From inckie at gmail.com Tue Feb 27 09:14:50 2007 From: inckie at gmail.com (Pedro Araujo Chaves Jr.) Date: Tue Feb 27 09:15:04 2007 Subject: Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation Message-ID: Hi all, After some regression testing, I found out that commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 by Dmitry Timoshkov breaks accentuation - at least for Brazilian Portuguese in Lotus Notes R5. I did some testing and found out that only TrueType fonts are affected - that is, the fonts Notes lists as 'default foo' without the double-T icon are all accented properly. To make matters worse, the affected fonts don't behave the same way. For example, the string ????? ????? ????? ????? ?? ?? ????? ????? ????? ????? renders as ????? ????? ????? ????? ?? ?? ????? ????? ????? ????? with Trebuchet MS. You can see they're pretty different - well, most of you, at least. However, that's only a display-and-print issue, as I can copy the text and paste it elsewhere, and the accents are in their right places (and in the right letters, for that matter) - as one would expect. Regarding Microsoft fonts, by the way, Calibri, Candara, Consolas, Constantia, Corbel, Segoe Print, and Segoe Script (couldn't test Cambria) all behave exactly like Trebuchet MS, whereas Segoe UI behaves just like Times New Roman, which shows problems only with graves and tildes. However the behavior is kinda random among the many other fonts (from many unrelated sources, of course) I tested, so I (still) didn't do an exhaustive check for a pattern. Would anybody have any word on this? Cheers, Pedro. From dmitry at codeweavers.com Tue Feb 27 09:30:45 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Tue Feb 27 09:30:37 2007 Subject: Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation References: Message-ID: <010201c75a84$438a79c0$0100a8c0@DMITRY> "Pedro Araujo Chaves Jr." wrote: > After some regression testing, I found out that commit > 37591409b28c2000e70bd0d3c654a3a7559a4a26 by Dmitry Timoshkov breaks > accentuation - at least for Brazilian Portuguese in Lotus Notes R5. > > I did some testing and found out that only TrueType fonts are affected > - that is, the fonts Notes lists as 'default foo' without the double-T > icon are all accented properly. To make matters worse, the affected > fonts don't behave the same way. > > For example, the string > > ????? ????? ????? ????? ?? ?? ????? ????? ????? ????? > > renders as > > ????? ????? ????? ????? ?? ?? ????? ????? ????? ????? > > with Trebuchet MS. You can see they're pretty different - well, most > of you, at least. Please open a bug report regarding this problem, with all the appropriate info: an aplication that shows the problem, the fonts used, etc. If you could add a test to the existing tests in the above mentioned commit that shows the problem that would be great. -- Dmitry. From wine.dev at web.de Tue Feb 27 10:41:01 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Tue Feb 27 10:41:40 2007 Subject: Make sure keyboard state is up to date before processing GetAsyncKeyState. In-Reply-To: <45E415DC.3030007@codeweavers.com> References: <45E415DC.3030007@codeweavers.com> Message-ID: <1172594461.7027.3.camel@p4> On Di, 2007-02-27 at 20:28 +0900, Aric Stewart wrote: > --- a/dlls/winex11.drv/keyboard.c > +++ b/dlls/winex11.drv/keyboard.c > @@ -94,6 +94,9 @@ static int kcControl, kcAlt, kcShift, kc > > static char KEYBOARD_MapDeadKeysym(KeySym keysym); > > +extern DWORD X11DRV_MsgWaitForMultipleObjectsEx( DWORD count, > + const HANDLE *handles, DWORD timeout, DWORD mask, > DWORD flags); I have no Idea about the code, but... IMHO, that declaration fit perfect into x11drv.h -- By by ... Detlef From wine.dev at web.de Tue Feb 27 11:29:39 2007 From: wine.dev at web.de (Detlef Riekenberg) Date: Tue Feb 27 11:30:20 2007 Subject: dplay: directplay should initialize session Guid patch + conformance tests In-Reply-To: <200702271315.52669.alex.pigna@inventati.org> References: <200702241725.49691.alex.pigna@inventati.org> <200702242211.02623.alex.pigna@inventati.org> <200702271137.02442.kai.blin@gmail.com> <200702271315.52669.alex.pigna@inventati.org> Message-ID: <1172597379.7027.9.camel@p4> On Di, 2007-02-27 at 13:15 +0100, Alessandro Pignotti wrote: > +dlls/dplayx/tests/Makefile That is will not work since today, as the format changed. The correct entry is created by "tools/make_makefiles" I updated the wiki, that autogenerated code should not be included in a Patch -- By by ... Detlef From Andrew.Talbot at talbotville.com Tue Feb 27 11:37:30 2007 From: Andrew.Talbot at talbotville.com (Andrew Talbot) Date: Tue Feb 27 11:37:51 2007 Subject: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend) References: <200702262128.09876.Andrew.Talbot@talbotville.com> <22821af30702261345n6d04c0c6me9d65b025470a246@mail.gmail.com> <22821af30702261527w5c70b3a4h7741241c9eebd204@mail.gmail.com> Message-ID: James Hawkins wrote: > #ifndef USE_FIXED_COMMIT_URL_CACHE_ENTRY > // Temporary state of affairs until we reconcile our apis. > Thanks, James. Maybe one day, then. :) -- Andy. From ehoover at mines.edu Mon Feb 26 20:23:35 2007 From: ehoover at mines.edu (Erich Hoover) Date: Tue Feb 27 12:01:55 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <45E35713.1090100@holycrap.org> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> <45E35713.1090100@holycrap.org> Message-ID: <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- /************************************************************************** * ReplaceFileW (KERNEL32.@) * ReplaceFile (KERNEL32.@) */ BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName,LPCWSTR lpReplacementFileName, LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, LPVOID lpExclude, LPVOID lpReserved) { HANDLE hReplaced, hReplacement; BOOL skipBackup = FALSE; if(dwReplaceFlags) FIXME("Ignoring flags %x\n", dwReplaceFlags); /* First two arguments are mandatory */ if(!lpReplacedFileName || !lpReplacementFileName) { SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } /* * Lock the "replacement" file, fail if it does not exist */ if((hReplacement = CreateFileW(lpReplacementFileName, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) { SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } if(!LockFile( hReplacement, 0, 0, 0, 0 )) { CloseHandle( hReplacement ); SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } /* * Lock the "replaced" file while we're working. */ if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) { /* If "replaced" does not exist then create it for the lock, but skip backup */ if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, 0, 0)) == INVALID_HANDLE_VALUE) { UnlockFile( hReplacement, 0, 0, 0, 0 ); CloseHandle( hReplacement ); SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } skipBackup = TRUE; } if(!LockFile( hReplaced, 0, 0, 0, 0 )) { UnlockFile( hReplacement, 0, 0, 0, 0 ); CloseHandle( hReplacement ); CloseHandle( hReplaced ); SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } /* * If the user wants a backup then that needs to be performed first */ if( lpBackupFileName && !skipBackup ) { /* If an existing backup exists then copy over it */ if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) { SetLastError( ERROR_INVALID_PARAMETER ); goto replace_fail; } } /* * Now that the backup has been performed (if requested), copy the replacement * into place */ if(!CopyFileW( lpReplacementFileName, lpReplacedFileName, FALSE )) { /* Assume that all access denied errors are a write problem. */ if(GetLastError() == ERROR_ACCESS_DENIED) SetLastError( ERROR_UNABLE_TO_REMOVE_REPLACED ); else SetLastError( ERROR_UNABLE_TO_MOVE_REPLACEMENT ); goto replace_fail; } /* Delete the replacement file */ if(!DeleteFileW( lpReplacementFileName )) { SetLastError( ERROR_INVALID_PARAMETER ); return FALSE; } /* Unlock the handles */ UnlockFile( hReplacement, 0, 0, 0, 0 ); CloseHandle( hReplacement ); UnlockFile( hReplaced, 0, 0, 0, 0 ); CloseHandle( hReplaced ); /* All done, file replacement successful */ return TRUE; replace_fail: UnlockFile( hReplacement, 0, 0, 0, 0 ); CloseHandle( hReplacement ); UnlockFile( hReplaced, 0, 0, 0, 0 ); CloseHandle( hReplaced ); return FALSE; } From inckie at gmail.com Tue Feb 27 13:02:41 2007 From: inckie at gmail.com (Pedro Araujo Chaves Jr.) Date: Tue Feb 27 13:02:59 2007 Subject: Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation In-Reply-To: <010201c75a84$438a79c0$0100a8c0@DMITRY> References: <010201c75a84$438a79c0$0100a8c0@DMITRY> Message-ID: On 2/27/07, Dmitry Timoshkov wrote: > Please open a bug report regarding this problem, with all the appropriate > info: an aplication that shows the problem, the fonts used, etc. If you > could add a test to the existing tests in the above mentioned commit that > shows the problem that would be great. Been there, done that: http://bugs.winehq.org/show_bug.cgi?id=7571 In order to clarify things, please see the attachment: http://bugs.winehq.org/attachment.cgi?id=5133&action=view There I provided links for many of the fonts I used (all legal, AFAIK). Cheers, Pedro. From paul at astro.gla.ac.uk Tue Feb 27 12:43:55 2007 From: paul at astro.gla.ac.uk (Paul Millar) Date: Tue Feb 27 13:40:30 2007 Subject: mingw linking problem In-Reply-To: <200702251913.23177.Stefan.Leichter@camline.com> References: <200702251913.23177.Stefan.Leichter@camline.com> Message-ID: <200702271844.01576.paul@astro.gla.ac.uk> Hi Stefan, On Sunday 25 February 2007 18:13, Stefan Leichter wrote: > This fail for some dlls at the linking, eg. comdlg32.dll misses the imports > > _IID_IContextMenu, _IID_IShellFolder, _IID_IPersistFolder2, > _IID_IShellBrowser, _IID_ICommDlgBrowser, _IID_IShellView, These are part of the MinGW's W32api v3.8. I don't know how long they've been in W32api, so you may need to upgrade to this version. > _SID_STopLevelBrowser The set of patches I have includes a definition for this GUID (as well as many, many others). The complete set of patches (against w32api v3.8) is available from: http://www.astro.gla.ac.uk/users/paulm/Cross/mingw-w32api-patches-2007-02-27.tar.gz Using a MinGW tool-chain (that has these patches) I was able to build comdlg32.dll N.B. The latest batch of patches (that fixed cross-compiling) are due to Stefan! Thanks! HTH, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070227/d82b9b67/attachment.pgp From us at edmeades.me.uk Tue Feb 27 14:34:24 2007 From: us at edmeades.me.uk (Ann & Jason Edmeades) Date: Tue Feb 27 14:34:56 2007 Subject: xcopy try 3 In-Reply-To: <874pp86b5c.fsf@wine.dyndns.org> Message-ID: <006401c75aae$ae350c70$1001a8c0@JasonsPC> >> diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in >> new file mode 100755 >All the files you create or modify are marked executable, could you >please fix that? Thanks for the heads up - I should have fixed it now, any problems please let me know. For reference, in case anyone else hits it, the problem here is I like my windows editor so generally edit over a samba share. (I've just found...) Samba by default 'maps' the archive bit on windows to the execute bit on unix, hence any time I modified the file it was turning the execute bit on. To remove it, add 'map archive no' to the share in smb.conf The things you learn! Jason From joris_huizer at yahoo.com Tue Feb 27 14:47:35 2007 From: joris_huizer at yahoo.com (Joris Huizer) Date: Tue Feb 27 14:48:21 2007 Subject: xcopy try 3 In-Reply-To: <006401c75aae$ae350c70$1001a8c0@JasonsPC> Message-ID: <856432.47432.qm@web52710.mail.yahoo.com> --- Ann & Jason Edmeades wrote: > > For reference, in case anyone else hits it, the > problem here is I like my > windows editor so generally edit over a samba share. > (I've just found...) Makes me feel like why not use wine to run it...? Oh well, just babbling, you must have a valid reason for that regards, Joris ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php From aric at codeweavers.com Tue Feb 27 19:50:12 2007 From: aric at codeweavers.com (Aric Stewart) Date: Tue Feb 27 19:51:08 2007 Subject: Make sure keyboard state is up to date before processing GetAsyncKeyState. In-Reply-To: <1172594461.7027.3.camel@p4> References: <45E415DC.3030007@codeweavers.com> <1172594461.7027.3.camel@p4> Message-ID: <45E4DFD4.4000809@codeweavers.com> That could be true. Since it was only used in this one place I was not sure the protocol for adding it to the header file or just as a prototype in this file. I will resubmit the patch -aric Detlef Riekenberg wrote: > On Di, 2007-02-27 at 20:28 +0900, Aric Stewart wrote: >> --- a/dlls/winex11.drv/keyboard.c >> +++ b/dlls/winex11.drv/keyboard.c >> @@ -94,6 +94,9 @@ static int kcControl, kcAlt, kcShift, kc >> >> static char KEYBOARD_MapDeadKeysym(KeySym keysym); >> >> +extern DWORD X11DRV_MsgWaitForMultipleObjectsEx( DWORD count, >> + const HANDLE *handles, DWORD timeout, DWORD mask, >> DWORD flags); > > I have no Idea about the code, but... > > IMHO, that declaration fit perfect into x11drv.h > > From billmedland at shaw.ca Tue Feb 27 20:17:04 2007 From: billmedland at shaw.ca (Bill Medland) Date: Tue Feb 27 20:17:11 2007 Subject: fc4 rpms Message-ID: <1172629024.25310.2.camel@medbi01-9.localdomain> Is there any chance that someone with the ability can create the fedora core 4 wine rpms for version 0.9.30? Bill Medland From dank at kegel.com Wed Feb 28 00:41:50 2007 From: dank at kegel.com (Dan Kegel) Date: Wed Feb 28 00:42:01 2007 Subject: Success story with Flash on Wine Message-ID: http://blog.brokenfunction.com/2007/02/27/debugging-flash-on-linux/ says "... How strange, the wine-powered standalone player is the most stable Flash player I've used yet. On Windows it would occasionally be unable to connect to the debugger until I restarted Eclipse, usually related to having to many players open at the same time. On Linux it will crash unexpectedly. Now I can have a dozen debuggers open at the same time with no crashes yet." Cool! From truiken at gmail.com Wed Feb 28 00:55:07 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 28 00:55:12 2007 Subject: msi: Expand OLE automation interface parameter handling. In-Reply-To: <1172640895.22804.2.camel@misha-laptop> References: <1172640895.22804.2.camel@misha-laptop> Message-ID: <22821af30702272255r7553ec7alac7c53e59c0ee48c@mail.gmail.com> On 2/27/07, Misha Koshelev wrote: > This applies on top of my other OLE automation patches. Added new > checks: > Why don't you wait until the other patches are committed before sending these new patches? It makes it hard to review, because I don't have your other patches applied. > - Parameter we are looking for is not passed? > - Only set puArgErr if it is passed > - Make sure pVarResult is valid before we write to it > - Don't return S_FAIL. MSDN doesn't mention it in the Invoke help, so we > won't use it. > You need to add tests for these items. -- James Hawkins From truiken at gmail.com Wed Feb 28 00:58:51 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 28 00:58:56 2007 Subject: msi: automation: clean up comments. In-Reply-To: <1172641029.22804.7.camel@misha-laptop> References: <1172641029.22804.7.camel@misha-laptop> Message-ID: <22821af30702272258t726db76eqc5d1da7723525bea@mail.gmail.com> On 2/27/07, Misha Koshelev wrote: > Looking back at James comments, maybe I did have a little too much > commenting there :) > You're sending patches that change code that hasn't been committed yet. Instead, you need to go back and change the original patch and resend. -- James Hawkins From thunder.m at czela.net Wed Feb 28 01:29:23 2007 From: thunder.m at czela.net (Mirek) Date: Wed Feb 28 01:29:29 2007 Subject: [8/12] WineD3D: Create multithreading contexts for swapchains In-Reply-To: <200702261350.32096.stefan@codeweavers.com> References: <200702261350.32096.stefan@codeweavers.com> Message-ID: <45E52F53.7030403@czela.net> Stefan D?singer napsal(a): > This patch finishes the opengl side of multithreaded direct3d, which was > started with the state management rewrite(well, almost, no offscreen rendering > yet) It does not make Direct3D thread safe, because there is no protection > against race conditions. > > This patch improves multithreaded games a bit. They do not crash any more in a > gl call, but running them is kinda like a lottery, especially on smp systems. > > Vitaly and Andras have reported success with Prince of Persia 3D: Sands of > Time and some other games, and on my laptop Empire Earth is running. Empire > Earth deadlocks regularly on my dual core system at ddraw creation. I can even run Tom Clancy's Rainbow Six Vegas, but there are still problems with offscreen rendering. Mirek > > > ------------------------------------------------------------------------ > > From 49cc9a0aa6e06f559540758d5b0ed2252208a0ad Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Sun, 25 Feb 2007 00:18:25 +0100 > Subject: [PATCH] WineD3D: Create multithreading contexts for swapchains > > This patch adds a routine to clone the main context of a swapchain to use it with a different thread on the > same drawable. This will enable multithreaded direct3d rendering, or better enable an attempt to do that. > From the opengl point of view it will work, but because concurrency control is not implemented yet(appart > of ENTER_GL() / LEAVE_GL() ) games may crash randomly, show strange behavior, ... > > The other problem is that this code was only tested with the open source radeon driver yet. While what > wined3d is doing here should be allowed by the spec, some drivers may have some bugs when using multiple > contexts on one drawable. > --- > dlls/wined3d/context.c | 4 ++-- > dlls/wined3d/swapchain.c | 30 ++++++++++++++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 2 ++ > 3 files changed, 34 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c > index 3a815b3..8545568 100644 > --- a/dlls/wined3d/context.c > +++ b/dlls/wined3d/context.c > @@ -626,8 +626,8 @@ void ActivateContext(IWineD3DDeviceImpl *This, IWineD3DSurface *target, ContextU > } > > if(!context) { > - /* TODO: Create a new context for the thread */ > - FIXME("Context creation for a new thread not implemented yet\n"); > + /* Create a new context for the thread */ > + context = IWineD3DSwapChainImpl_CreateContextForThread(swapchain); > } > } else { > context = ((IWineD3DSwapChainImpl *) swapchain)->context[0]; > diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c > index 2977a05..3b8e3e8 100644 > --- a/dlls/wined3d/swapchain.c > +++ b/dlls/wined3d/swapchain.c > @@ -510,3 +510,33 @@ const IWineD3DSwapChainVtbl IWineD3DSwapChain_Vtbl = > IWineD3DSwapChainImpl_SetGammaRamp, > IWineD3DSwapChainImpl_GetGammaRamp > }; > + > +WineD3DContext *IWineD3DSwapChainImpl_CreateContextForThread(IWineD3DSwapChain *iface) { > + WineD3DContext *ctx; > + IWineD3DSwapChainImpl *This = (IWineD3DSwapChainImpl *) iface; > + WineD3DContext **newArray; > + > + TRACE("Creating a new context for swapchain %p, thread %d\n", This, GetCurrentThreadId()); > + > + ctx = CreateContext(This->wineD3DDevice, (IWineD3DSurfaceImpl *) This->frontBuffer, > + This->context[0]->display, This->win); > + if(!ctx) { > + ERR("Failed to create a new context for the swapchain\n"); > + return NULL; > + } > + > + newArray = HeapAlloc(GetProcessHeap(), 0, sizeof(*newArray) * This->num_contexts + 1); > + if(!newArray) { > + ERR("Out of memory when trying to allocate a new context array\n"); > + DestroyContext(This->wineD3DDevice, ctx); > + return NULL; > + } > + memcpy(newArray, This->context, sizeof(*newArray) * This->num_contexts); > + HeapFree(GetProcessHeap(), 0, This->context); > + newArray[This->num_contexts] = ctx; > + This->context = newArray; > + This->num_contexts++; > + > + TRACE("Returning context %p\n", ctx); > + return ctx; > +} > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 45e69bf..fa4232c 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1341,6 +1341,8 @@ typedef struct IWineD3DSwapChainImpl > > extern const IWineD3DSwapChainVtbl IWineD3DSwapChain_Vtbl; > > +WineD3DContext *IWineD3DSwapChainImpl_CreateContextForThread(IWineD3DSwapChain *iface); > + > /***************************************************************************** > * Utility function prototypes > */ > > > ------------------------------------------------------------------------ > > From andreas.bierfert at lowlatency.de Wed Feb 28 02:43:02 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed Feb 28 02:43:36 2007 Subject: fc4 rpms In-Reply-To: <1172629024.25310.2.camel@medbi01-9.localdomain> References: <1172629024.25310.2.camel@medbi01-9.localdomain> Message-ID: <20070228094302.62bb299b@alkaid.a.lan> On Tue, 27 Feb 2007 18:17:04 -0800 Bill Medland wrote: > Is there any chance that someone with the ability can create the fedora > core 4 wine rpms for version 0.9.30? > > Bill Medland If you want to I can upgrade the spec in fedora cvs to the newest versions as well. It is sad that I cannot push builds for fc 3 and fc 4 anymore I might put builds on my webpage if the audience is big enough... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert@lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070228/01ae4213/signature.pgp From meissner at suse.de Wed Feb 28 03:41:48 2007 From: meissner at suse.de (Marcus Meissner) Date: Wed Feb 28 03:41:56 2007 Subject: fc4 rpms In-Reply-To: <20070228094302.62bb299b@alkaid.a.lan> References: <1172629024.25310.2.camel@medbi01-9.localdomain> <20070228094302.62bb299b@alkaid.a.lan> Message-ID: <20070228094148.GA31428@suse.de> On Wed, Feb 28, 2007 at 09:43:02AM +0100, Andreas Bierfert wrote: > On Tue, 27 Feb 2007 18:17:04 -0800 > Bill Medland wrote: > > > Is there any chance that someone with the ability can create the fedora > > core 4 wine rpms for version 0.9.30? > > > > Bill Medland > > If you want to I can upgrade the spec in fedora cvs to the newest versions as > well. It is sad that I cannot push builds for fc 3 and fc 4 anymore I might put > builds on my webpage if the audience is big enough... Fedora Core 4 RPMs are still available in the openSUSE buildservice. YUM base URL: http://software.opensuse.org/download/Emulators:/Wine/Fedora_Core_4/ Ciao, Marcus From rob at codeweavers.com Wed Feb 28 05:44:44 2007 From: rob at codeweavers.com (Robert Shearman) Date: Wed Feb 28 05:45:29 2007 Subject: msi: Add proper parameter handling to OLE automation interfaces. In-Reply-To: <1172615244.29404.3.camel@misha-laptop> References: <1172615244.29404.3.camel@misha-laptop> Message-ID: <45E56B2C.6070805@codeweavers.com> Misha Koshelev wrote: > +/* Macros for variant conversions */ > +#define V_DECLARE \ > + VARIANTARG vararg[pDispParams->cArgs]; \ > + int iVarCount; \ > + HRESULT hr = S_OK; \ > + memset(vararg, 0, sizeof(vararg)); > +#define V_PREPARE(n, type) \ > + VariantInit(&vararg[n]); \ > + hr = VariantChangeTypeEx(&vararg[n], &pDispParams->rgvarg[n], lcid, 0, VT_##type); \ > + if (FAILED(hr)) \ > + { \ > + *puArgErr = n; \ > + goto v_finish; \ > + } > +#define V_PREPAREOPT(n, type) \ > + VariantInit(&vararg[n]); \ > + if (FAILED(VariantChangeTypeEx(&vararg[n], &pDispParams->rgvarg[n], lcid, 0, VT_##type))) \ > + VariantClear(&vararg[n]); > +#define V_PREPARED(n) (V_VT(&vararg[n]) != VT_EMPTY) > +#define V(n, type) V_##type(&vararg[n]) > +#define V_RETURN(value, type) \ > + V_VT(pVarResult) = VT_##type; \ > + V_##type(pVarResult) = value; > +#define V_FAIL hr = E_FAIL; > +#define V_DEFAULT \ > + default: \ > + hr = DISP_E_MEMBERNOTFOUND; > +#define V_FINISH \ > + goto v_finish; /* suppress warnings about unused label v_free */ \ > +v_finish: \ > + for (iVarCount = 0; iVarCount < pDispParams->cArgs; iVarCount++) \ > + if (V_PREPARED(iVarCount)) \ > + VariantClear(&vararg[iVarCount]); \ > + return hr; > This is quite ugly. You can at replace at least some of this with calls to DispGetParam. A lot of the methods only have one parameter so will end up simpler without using these macros. -- Rob Shearman From julliard at winehq.org Wed Feb 28 07:02:43 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 28 07:02:51 2007 Subject: [6/6] d3d9: Add a mova rounding test In-Reply-To: (H. Verbeet's message of "Tue\, 27 Feb 2007 20\:52\:03 +0100") References: Message-ID: <87mz2y305o.fsf@wine.dyndns.org> "H. Verbeet" writes: > It should be noted that native d3d rounds to nearest even while Wine > doesn't. Applications are not supposed to depend on that though. > > Changelog: > - Add a mova rounding test The test fails here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -2.400000) visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -1.600000) visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input -0.400000) visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input 0.400000) visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 1.600000) visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 2.400000) make: *** [visual.ok] Error 6 -- Alexandre Julliard julliard@winehq.org From julliard at winehq.org Wed Feb 28 07:30:47 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 28 07:30:51 2007 Subject: [7/7] cmd.exe: Support rd dir1 dir2 dir3 etc In-Reply-To: <009301c75ac6$45440aa0$1001a8c0@JasonsPC> (Ann & Jason Edmeades's message of "Tue\, 27 Feb 2007 23\:23\:16 -0000") References: <009301c75ac6$45440aa0$1001a8c0@JasonsPC> Message-ID: <87irdm2yuw.fsf@wine.dyndns.org> "Ann & Jason Edmeades" writes: > diff --git a/programs/cmd/wcmd.h b/programs/cmd/wcmd.h > index d6357f0..a7a73ae 100644 > --- a/programs/cmd/wcmd.h > +++ b/programs/cmd/wcmd.h > @@ -27,6 +27,9 @@ > #include > #include > > +#include "wine/debug.h" > +WINE_DEFAULT_DEBUG_CHANNEL(cmd); Adding tracing is OK, but this should go in the C files that need it, not in a header. -- Alexandre Julliard julliard@winehq.org From stefandoesinger at gmx.at Wed Feb 28 09:57:39 2007 From: stefandoesinger at gmx.at (Stefan =?iso-8859-2?q?D=F6singer?=) Date: Wed Feb 28 09:58:22 2007 Subject: [8/12] WineD3D: Create multithreading contexts for swapchains In-Reply-To: <45E52F53.7030403@czela.net> References: <200702261350.32096.stefan@codeweavers.com> <45E52F53.7030403@czela.net> Message-ID: <200702281657.45619.stefandoesinger@gmx.at> Hi, > I can even run Tom Clancy's Rainbow Six Vegas, but there are still > problems with offscreen rendering. Yeah, offscreen rendering is unsupported with my multithreading patches. I have another patch to fix that, but I haven't tested it. I have a bit of a mess in my wine tree at the moment(2 sets of patches), I will clean that up, send a few non-multithreaded patches to wine-patches and the newest multithreading thing to wine-devel for testing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070228/6f76bda5/attachment.pgp From billmedland at shaw.ca Wed Feb 28 10:00:33 2007 From: billmedland at shaw.ca (Bill Medland) Date: Wed Feb 28 10:00:58 2007 Subject: fc4 rpms In-Reply-To: <20070228094302.62bb299b@alkaid.a.lan> References: <1172629024.25310.2.camel@medbi01-9.localdomain> <20070228094302.62bb299b@alkaid.a.lan> Message-ID: <1172678433.20792.5.camel@medbi01-9.localdomain> On Wed, 2007-28-02 at 09:43 +0100, Andreas Bierfert wrote: > On Tue, 27 Feb 2007 18:17:04 -0800 > Bill Medland wrote: > > > Is there any chance that someone with the ability can create the fedora > > core 4 wine rpms for version 0.9.30? > > > > Bill Medland > > If you want to I can upgrade the spec in fedora cvs to the newest versions as > well. It is sad that I cannot push builds for fc 3 and fc 4 anymore I might put > builds on my webpage if the audience is big enough... > > - Andreas > Thanks but that's no help for me; I guess I'll just build for myself. Actually it's for Red Hat Enterprise Linux 4 Server and Desktop for redistribution. I was hoping that I wouldn't have to become totally au fait with the more advanced stuff in the spec files, but I guess I need to bite the bullet. Thanks, anyway Bill From rw at bb-sw.de Wed Feb 28 10:49:05 2007 From: rw at bb-sw.de (Roger Wimbert) Date: Wed Feb 28 10:49:08 2007 Subject: Error Invalid EXE Format when executing a exe.so built with winelib Message-ID: <45E5B281.7070901@bb-sw.de> Here is the Debug output: warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b wine: could not load L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": Fehlerhaftes EXE-Format f?r It has something to do with TLS memory or threads, but the /lib/tls/libc.so is linked in: (rw 8 amd64) /bb/s/bc/wine 105>ldd dmsw.exe.so linux-gate.so.1 => (0xffffe000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0x557be000) libm.so.6 => /lib/tls/libm.so.6 (0x558e8000) libc.so.6 => /lib/tls/libc.so.6 (0x5590a000) libdl.so.2 => /lib/libdl.so.2 (0x55a1f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) Our system: (rw 8 amd64) /bb/s/bc/wine 106>uname -a Linux amd64 2.6.5-7.193-smp #1 SMP Wed Jul 20 14:39:18 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux glibc has version 2.3.3 A simple program does work, but no program which uses threads. wine is created with the 32 bit libraries. If I use the original exe of my program with wine, it does work. Does anyone has an idea what is going wrong? The makefile is attached. Thanks a lot. -------------- next part -------------- ### Generated by Winemaker TOPSRCDIR = /bb/s TOPOBJDIR = /bb/s/bc/wine SRCDIR = . SUBDIRS = DLLS = EXES = dmsw.exe ### Common settings CEXTRA = -mno-cygwin -fno-pic -fno-PIC CXXEXTRA = -mno-cygwin CFLAGS = -D_DMSW RCEXTRA = RCFLAGS = -DBB_WINE INCLUDE_PATH = -I. -I/bb/nt/wine -I/bb/s/i -I/bb/fg/i -I/bb/ze/i -I/bb/fe/i -I/bb/pbm/i -I/bb/wb1/i DLL_PATH = LIBRARY_PATH = LIBRARIES = -lmsvcrt40 -lws2_32 -lversion -lnetapi32 -liphlpapi -lcomctl32 -lshlwapi -lwinmm ### dmsw.exe sources and settings dmsw_exe_MODULE = dmsw.exe dmsw_exe_C_SRCS = /bb/s/c/bbcrypt.c \ /bb/s/c/bbdes.c \ /bb/s/c/bbmalloc.c \ /bb/s/c/bbmd5.c \ /bb/s/c/bbo.c \ /bb/s/c/bbtwofish.c \ /bb/s/c/cmp.c \ /bb/s/c/costri.c \ /bb/s/c/cpy.c \ /bb/s/c/datec.c \ /bb/s/c/dfa.c \ /bb/fg/c/dgcode.c \ /bb/fg/c/dgvar.c \ /bb/s/c/dhinfo.c \ /bb/s/c/dholz.c \ /bb/fg/c/digcte.c \ /bb/fg/c/digecm.c \ /bb/fg/c/digranox.c \ /bb/fg/c/digvec.c \ /bb/s/c/dirview.c \ /bb/s/c/dirwalk.c \ /bb/s/c/dmsb.c \ /bb/s/c/dmsc.c \ /bb/s/c/dmsca.c \ /bb/s/c/dmse.c \ /bb/s/c/dmsf.c \ /bb/s/c/dmsfr.c \ /bb/s/c/dmsg.c \ /bb/s/c/dmsh.c \ /bb/s/c/dmshc.c \ /bb/s/c/dmsl.c \ /bb/s/c/dmsliz.c \ /bb/s/c/dmsm.c \ /bb/s/c/dmsmv.c \ /bb/s/c/dmsp.c \ /bb/s/c/dmsr.c \ /bb/s/c/dmss.c \ /bb/s/c/dmssb.c \ /bb/s/c/dmst.c \ /bb/s/c/dmstast.c \ /bb/s/c/dmsw.c \ /bb/s/c/dmswf.c \ /bb/s/c/dmswicon.c \ /bb/s/c/dmsy.c \ /bb/s/c/encode.c \ /bb/s/c/fileleng.c \ /bb/s/c/fordat.c \ /bb/s/c/gtypes.c \ /bb/fg/c/image.c \ /bb/fg/c/imgprint.c \ /bb/s/c/itoa.c \ /bb/fg/c/jpegconv.c \ /bb/s/c/lru.c \ /bb/s/c/ltoa.c \ /bb/s/c/map.c \ /bb/s/c/msleep.c \ /bb/s/c/packbits.c \ /bb/s/c/packdiff.c \ /bb/s/c/pfad.c \ /bb/fg/c/rgbtools.c \ /bb/s/c/rtt.c \ /bb/s/c/scrinfo.c \ /bb/s/c/set.c \ /bb/s/c/sockcom.c \ /bb/s/c/softdum.c \ /bb/s/c/swap.c \ /bb/s/c/syslog.c \ /bb/s/c/textino.c \ /bb/fg/c/tiffconv.c \ /bb/s/c/udpcom.c \ /bb/s/c/utoa.c \ /bb/s/c/vgl.c \ /bb/s/c/w32argv.c \ /bb/fg/c/w32bmp.c \ /bb/s/c/w32error.c \ /bb/s/c/w32font.c \ /bb/fg/c/w32ico.c \ /bb/s/c/w32macadr.c \ /bb/s/c/w32pfad.c \ /bb/s/c/w32pipe.c \ /bb/s/c/w32print.c \ /bb/s/c/w32puts.c \ /bb/s/c/w32reg.c \ /bb/fg/c/w32scalebmp.c \ /bb/s/c/w32screen.c \ /bb/s/c/w32scroll.c \ /bb/s/c/w32toolbar.c \ /bb/s/c/w32tools.c \ /bb/s/c/w32winms.c \ /bb/s/c/wsinit.c \ /bb/s/c/zeitc.c dmsw_exe_CXX_SRCS= dmsw_exe_RC_SRCS = /bb/nt/rc/dmsw/dmsw_wine.rc dmsw_exe_LDFLAGS = -mwindows \ -mno-cygwin dmsw_exe_DLL_PATH= dmsw_exe_DLLS = odbc32 \ ole32 \ oleaut32 \ winspool dmsw_exe_LIBRARY_PATH= dmsw_exe_LIBRARIES= uuid dmsw_exe_OBJS = $(dmsw_exe_C_SRCS:.c=.o) \ $(dmsw_exe_CXX_SRCS:.cpp=.o) \ $(dmsw_exe_RC_SRCS:.rc=.res) ### Global source lists C_SRCS = $(dmsw_exe_C_SRCS) CXX_SRCS = $(dmsw_exe_CXX_SRCS) RC_SRCS = $(dmsw_exe_RC_SRCS) ### Tools CC = winegcc CXX = wineg++ RC = wrc ### Generic targets all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so) ### Build rules .PHONY: all clean dummy $(SUBDIRS): dummy @cd $@ && $(MAKE) # Implicit rules .SUFFIXES: .cpp .rc .res DEFINCL = $(INCLUDE_PATH) $(DEFINES) $(OPTIONS) .c.o: $(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o $@ $< .cpp.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .cxx.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .rc.res: $(RC) $(RCFLAGS) $(RCEXTRA) $(DEFINCL) -fo$@ $< # Rules for cleaning CLEAN_FILES = y.tab.c y.tab.h lex.yy.c core *.orig *.rej \ \\\#*\\\# *~ *% .\\\#* clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) $(RM) $(CLEAN_FILES) $(RC_SRCS:.rc=.res) $(C_SRCS:.c=.o) $(CXX_SRCS:.cpp=.o) $(RM) $(DLLS:%=%.so) $(EXES:%=%.so) $(EXES:%.exe=%) $(SUBDIRS:%=%/__clean__): dummy cd `dirname $@` && $(MAKE) clean $(EXTRASUBDIRS:%=%/__clean__): dummy -cd `dirname $@` && $(RM) $(CLEAN_FILES) ### Target specific build rules DEFLIB = $(LIBRARY_PATH) $(LIBRARIES) $(DLL_PATH) $(dmsw_exe_MODULE).so: $(dmsw_exe_OBJS) $(CC) $(dmsw_exe_LDFLAGS) -o $@ $(dmsw_exe_OBJS) $(dmsw_exe_LIBRARY_PATH) $(DEFLIB) $(dmsw_exe_DLLS:%=-l%) $(dmsw_exe_LIBRARIES:%=-l%) From flexo at holycrap.org Wed Feb 28 11:15:04 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 28 11:07:07 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <4c1ac96d0702262304v764f653dj3ca1ee96397f0b5a@mail.gmail.com> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> <45E35713.1090100@holycrap.org> <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> <45E3A5E1.90400@holycrap.org> <4c1ac96d0702262304v764f653dj3ca1ee96397f0b5a@mail.gmail.com> Message-ID: <45E5B898.6000604@holycrap.org> (CC-ing wine-devel again) Erich Hoover wrote: >> The "right" way would probably to do the copying yourself by >> read/write.. but I dunno. > Except that it would ignore the permissions issues that have already > been coded into the copy routines (and any updates that may eventually No, CreateFile (and friends) does the permissions checks (which you would still have to call). > be made to these routines). Also, it seems to me that MSDN is > describing the list of function calls that ReplaceFile actually makes. No it doesn't? Your other objections were right. Your last version follows for wine-devel. > ------------------------------------------------------------------------ > > /************************************************************************** > * ReplaceFileW (KERNEL32.@) > * ReplaceFile (KERNEL32.@) > */ > BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName,LPCWSTR lpReplacementFileName, > LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, > LPVOID lpExclude, LPVOID lpReserved) > { > HANDLE hReplaced, hReplacement; > BOOL skipBackup = FALSE; > > if(dwReplaceFlags) > FIXME("Ignoring flags %x\n", dwReplaceFlags); > /* First two arguments are mandatory */ > if(!lpReplacedFileName || !lpReplacementFileName) > { > SetLastError( ERROR_INVALID_PARAMETER ); > return FALSE; > } > /* > * Lock the "replacement" file, fail if it does not exist > */ > if((hReplacement = CreateFileW(lpReplacementFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > { > return FALSE; > } > if(!LockFile( hReplacement, 0, 0, 0, 0 )) > { > CloseHandle( hReplacement ); > return FALSE; > } > /* > * Lock the "replaced" file while we're working. > */ > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE, > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > { > /* If "replaced" does not exist then create it for the lock, but skip backup */ > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE, > NULL, CREATE_ALWAYS, 0, 0)) == INVALID_HANDLE_VALUE) > { > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > return FALSE; > } > skipBackup = TRUE; > } > if(!LockFile( hReplaced, 0, 0, 0, 0 )) > { > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > CloseHandle( hReplaced ); > return FALSE; > } > /* > * If the user wants a backup then that needs to be performed first > */ > if( lpBackupFileName && !skipBackup ) > { > /* If an existing backup exists then copy over it */ > if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) > goto replace_fail; > } > /* > * Now that the backup has been performed (if requested), copy the replacement > * into place > */ > if(!CopyFileW( lpReplacementFileName, lpReplacedFileName, FALSE )) > { > /* Assume that all access denied errors are a write problem. */ > if(GetLastError() == ERROR_ACCESS_DENIED) > SetLastError( ERROR_UNABLE_TO_REMOVE_REPLACED ); > else > SetLastError( ERROR_UNABLE_TO_MOVE_REPLACEMENT ); > goto replace_fail; > } > /* Delete the replacement file */ > if(!DeleteFileW( lpReplacementFileName )) > return FALSE; > /* Unlock the handles */ > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > UnlockFile( hReplaced, 0, 0, 0, 0 ); > CloseHandle( hReplaced ); > /* All done, file replacement successful */ > return TRUE; > > replace_fail: > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > UnlockFile( hReplaced, 0, 0, 0, 0 ); > CloseHandle( hReplaced ); > return FALSE; > } From flexo at holycrap.org Wed Feb 28 11:26:48 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 28 11:18:44 2007 Subject: Using ex-user32 controls from native comctl32 6 Message-ID: <45E5BB58.1070301@holycrap.org> (CC-ing to Frank Richter because I hope he knows the answer :) Hi. I've been trying to make wine use the ex-user32 controls (listbox, scrollbox, etc.) in comctl32 where Microsoft copied them to in version 6 to get message traces of those controls (I know I could use msg spy tools on Windows but comparing two Wine spy logs is way more straight forward, especially since those tools don't get you stuff like +win). You need a manifest file on Windows to get application to use comctl6 but we don't use that since we've chosen to theme the user controls via subclassing. I've tried to just remove registration of the classes from our user32 and use native comctl32 6 (which otherwise works nice) but no success. So, any idea how Windows makes comctl32 register the user classes? Felix From frank.richter at gmail.com Wed Feb 28 11:26:35 2007 From: frank.richter at gmail.com (Frank Richter) Date: Wed Feb 28 11:26:51 2007 Subject: Using ex-user32 controls from native comctl32 6 In-Reply-To: <45E5BB58.1070301@holycrap.org> References: <45E5BB58.1070301@holycrap.org> Message-ID: <45E5BB4B.8020404@gmail.com> On 28.02.2007 18:26, Felix Nawothnig wrote: > So, any idea how Windows makes comctl32 register the user classes? I think it just re-registered the classes, but I'm not sure. A trace with class registrations (ie +class) might give some hint at what native does. -f.r. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070228/6e71ec43/signature.pgp From hverbeet at gmail.com Wed Feb 28 11:36:50 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Wed Feb 28 11:37:09 2007 Subject: [4/8] WineD3D: Prepare only fixed function samplers for blit In-Reply-To: <200702281718.25105.stefan@codeweavers.com> References: <200702281718.25105.stefan@codeweavers.com> Message-ID: On 28/02/07, Stefan D?singer wrote: >+ /* The blitting code uses (for now) the fixed function pipeline, so make sure to reset all fixed >+ * function texture unit. No need to care for higher samplers >+ */ >+ for(i = GL_LIMITS(texture_stages) - 1; i > 0 ; i--) { You should use GL_LIMITS(textures) here, since that's the number of fixed function texture units. From paul.vriens.wine at gmail.com Wed Feb 28 11:44:00 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Wed Feb 28 11:44:17 2007 Subject: Unknown issue with test.winehq.org Message-ID: <45E5BF60.4020800@gmail.com> Hi, So finally we have a working winetest executable and the test.winehq.org scripts should be able to handle the new reports. Could someone have a look what the issue currently is on the webserver as I've sent several reports (a few hours ago) and they are not handled yet? Cheers, Paul. From hverbeet at gmail.com Wed Feb 28 11:46:00 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Wed Feb 28 11:46:08 2007 Subject: [8/8] WineD3D: Use the source surface's texture for writing the backup In-Reply-To: <200702281724.10299.stefan@codeweavers.com> References: <200702281724.10299.stefan@codeweavers.com> Message-ID: On 28/02/07, Stefan D?singer wrote: >The hwstretch blit code creates a new texture each time it is called to back up the back buffer and >releases it afterwards. It is more efficient to keep the texture and release it with the surface. This >patch uses the source surface's texture to do the job. Because the source surface is an active render >target its texture is either only needed for blitting(onscreen target) or will be completely overwritten >on the next render target change(offscreen target). Is this supposed to work with FBOs? From jcgarbage at comcast.net Tue Feb 27 20:54:43 2007 From: jcgarbage at comcast.net (Jeremy) Date: Wed Feb 28 12:18:58 2007 Subject: msiexec.exe service registration Message-ID: <45E4EEF3.2040408@comcast.net> In msiexec.c, the DoRegServer calls OpenSCManager, however, on a fresh installation, ie no ~/.wine, the HKLM\CurrentControlSet\Services does not yet exist, so that OpenSCManager fails. What is the correct way to guarantee that this key exists? Regards, Jeremy From jakob at vmlinux.org Wed Feb 28 06:05:07 2007 From: jakob at vmlinux.org (Jakob Eriksson) Date: Wed Feb 28 12:18:59 2007 Subject: wine and msys rxvt.exe In-Reply-To: References: <200702252052.44341.wes.parish@paradise.net.nz> <001f01c7596e$ea763b00$0100a8c0@DMITRY> Message-ID: <45E56FF3.90705@vmlinux.org> Phil Krylov wrote: > > AFAIR MSys's rxvt.exe uses libW11.dll, which implements Xlib API on > top of Win32 USER/GDI (no extra X server). However, it could be still > difficult (probably because of API name clashes?) > Not sure why the message is about libX11.dll - probably it sees > $DISPLAY and tries to use real X? AFAIR rxvt can be used both with and without X server, so that's probable. regards, Jakob From ehoover at mines.edu Wed Feb 28 11:36:44 2007 From: ehoover at mines.edu (Erich Hoover) Date: Wed Feb 28 12:19:03 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <45E5B898.6000604@holycrap.org> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> <45E35713.1090100@holycrap.org> <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> <45E3A5E1.90400@holycrap.org> <4c1ac96d0702262304v764f653dj3ca1ee96397f0b5a@mail.gmail.com> <45E5B898.6000604@holycrap.org> Message-ID: <4c1ac96d0702280936v5efa063eq5748b23cc9d660da@mail.gmail.com> Oops, I must have hit the wrong reply button. >>> The "right" way would probably to do the copying yourself by >>> read/write.. but I dunno. >> Except that it would ignore the permissions issues that have already >> been coded into the copy routines (and any updates that may eventually > No, CreateFile (and friends) does the permissions checks (which you > would still have to call). That was worded poorly, Copy/Move already handle copying file attributes and I imagine would eventually implement copying the access control list information. Implementing ReplaceFile as calls to either Copy or Move takes these issues into account. >> be made to these routines). Also, it seems to me that MSDN is >> describing the list of function calls that ReplaceFile actually makes. > No it doesn't? >From my perspective the "remarks" section discusses the implementation of ReplaceFile as calls to existing API functions (as a sort of macro) as a convenience. Granted, it discusses moving files instead of copying but that conflicted with the file locking. Should I make a new patch file with the previously attached changes or would you prefer that the function be implemented in the read/write manner? Re-implementing the function in such a fashion would make it possible to do a more move-like operation while maintaining the file locking, but would lose out on any future improvements to CopyFile. Erich Hoover ehoover@mines.edu On 2/28/07, Felix Nawothnig wrote: > > (CC-ing wine-devel again) > > Erich Hoover wrote: > >> The "right" way would probably to do the copying yourself by > >> read/write.. but I dunno. > > Except that it would ignore the permissions issues that have already > > been coded into the copy routines (and any updates that may eventually > > No, CreateFile (and friends) does the permissions checks (which you > would still have to call). > > > be made to these routines). Also, it seems to me that MSDN is > > describing the list of function calls that ReplaceFile actually makes. > > No it doesn't? > > Your other objections were right. Your last version follows for > wine-devel. > > > ------------------------------------------------------------------------ > > > > > /************************************************************************** > > * ReplaceFileW (KERNEL32.@) > > * ReplaceFile (KERNEL32.@) > > */ > > BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName,LPCWSTR > lpReplacementFileName, > > LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, > > LPVOID lpExclude, LPVOID lpReserved) > > { > > HANDLE hReplaced, hReplacement; > > BOOL skipBackup = FALSE; > > > > if(dwReplaceFlags) > > FIXME("Ignoring flags %x\n", dwReplaceFlags); > > /* First two arguments are mandatory */ > > if(!lpReplacedFileName || !lpReplacementFileName) > > { > > SetLastError( ERROR_INVALID_PARAMETER ); > > return FALSE; > > } > > /* > > * Lock the "replacement" file, fail if it does not exist > > */ > > if((hReplacement = CreateFileW(lpReplacementFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > return FALSE; > > } > > if(!LockFile( hReplacement, 0, 0, 0, 0 )) > > { > > CloseHandle( hReplacement ); > > return FALSE; > > } > > /* > > * Lock the "replaced" file while we're working. > > */ > > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE, > > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > /* If "replaced" does not exist then create it for the lock, but > skip backup */ > > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE, > > NULL, CREATE_ALWAYS, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > return FALSE; > > } > > skipBackup = TRUE; > > } > > if(!LockFile( hReplaced, 0, 0, 0, 0 )) > > { > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > CloseHandle( hReplaced ); > > return FALSE; > > } > > /* > > * If the user wants a backup then that needs to be performed first > > */ > > if( lpBackupFileName && !skipBackup ) > > { > > /* If an existing backup exists then copy over it */ > > if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) > > goto replace_fail; > > } > > /* > > * Now that the backup has been performed (if requested), copy the > replacement > > * into place > > */ > > if(!CopyFileW( lpReplacementFileName, lpReplacedFileName, FALSE )) > > { > > /* Assume that all access denied errors are a write problem. */ > > if(GetLastError() == ERROR_ACCESS_DENIED) > > SetLastError( ERROR_UNABLE_TO_REMOVE_REPLACED ); > > else > > SetLastError( ERROR_UNABLE_TO_MOVE_REPLACEMENT ); > > goto replace_fail; > > } > > /* Delete the replacement file */ > > if(!DeleteFileW( lpReplacementFileName )) > > return FALSE; > > /* Unlock the handles */ > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > UnlockFile( hReplaced, 0, 0, 0, 0 ); > > CloseHandle( hReplaced ); > > /* All done, file replacement successful */ > > return TRUE; > > > > replace_fail: > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > UnlockFile( hReplaced, 0, 0, 0, 0 ); > > CloseHandle( hReplaced ); > > return FALSE; > > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070228/eec44018/attachment.htm From flexo at holycrap.org Wed Feb 28 12:28:04 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 28 12:20:21 2007 Subject: kernel32: Implement ReplaceFileA/ReplaceFileW In-Reply-To: <4c1ac96d0702280936v5efa063eq5748b23cc9d660da@mail.gmail.com> References: <4c1ac96d0702252350td0f115ci3ef9aefcfc1240a3@mail.gmail.com> <45E33EF2.7070302@holycrap.org> <4c1ac96d0702261242v65cd483ch23f2170d5047b14f@mail.gmail.com> <45E35713.1090100@holycrap.org> <4c1ac96d0702261823o6e1ab065ka8b244062ad7e2cc@mail.gmail.com> <45E3A5E1.90400@holycrap.org> <4c1ac96d0702262304v764f653dj3ca1ee96397f0b5a@mail.gmail.com> <45E5B898.6000604@holycrap.org> <4c1ac96d0702280936v5efa063eq5748b23cc9d660da@mail.gmail.com> Message-ID: <45E5C9B4.4010707@holycrap.org> Erich Hoover wrote: >>>> The "right" way would probably to do the copying yourself by >>>> read/write.. but I dunno. >>> Except that it would ignore the permissions issues that have already >>> been coded into the copy routines (and any updates that may eventually >> No, CreateFile (and friends) does the permissions checks (which you >> would still have to call). > That was worded poorly, Copy/Move already handle copying file attributes > and I imagine would eventually implement copying the access control list > information. Implementing ReplaceFile as calls to either Copy or Move > takes these issues into account. I see your point. However, since the function you are implementing is in kernel32 anyway you could abstract it away and make both functions (CopyFile and ReplaceFile) call some internal function. That way you would get rid of the locking completly which is argueably somewhat ugly. Felix From paul.vriens.wine at gmail.com Wed Feb 28 13:15:55 2007 From: paul.vriens.wine at gmail.com (Paul Vriens) Date: Wed Feb 28 13:16:18 2007 Subject: Unknown issue with test.winehq.org In-Reply-To: <45E5BF60.4020800@gmail.com> References: <45E5BF60.4020800@gmail.com> Message-ID: <45E5D4EB.8090702@gmail.com> Paul Vriens wrote: > Hi, > > So finally we have a working winetest executable and the test.winehq.org > scripts should be able to handle the new reports. > > Could someone have a look what the issue currently is on the webserver > as I've sent several reports (a few hours ago) and they are not handled > yet? > > Cheers, > > Paul. > Hi, I think I've found the issue. The error dissect outputs is something like: /wine/winetest/queue/errAfg8T: no start line:4789: ntdll:exception done (5) when looking at the report file I see that with a newer version of the ntdll exception tests we suddenly have 2 lines: exception: 42 tests executed (0 marked as todo, 0 failures), 0 skipped. exception: 279 tests executed (0 marked as todo, 5 failures), 0 skipped. The first one triggers the 'end of this test' in dissect. The second one is thus not accepted as dissect expects a 'start' line (and a line in between actually). The question now is: should dissect handle these cases or is this particular test-case wrong? Cheers, Paul. From truiken at gmail.com Wed Feb 28 13:43:23 2007 From: truiken at gmail.com (James Hawkins) Date: Wed Feb 28 13:43:34 2007 Subject: msiexec.exe service registration In-Reply-To: <45E4EEF3.2040408@comcast.net> References: <45E4EEF3.2040408@comcast.net> Message-ID: <22821af30702281143p630843c2s4eb1f326890f84af@mail.gmail.com> On 2/27/07, Jeremy wrote: > In msiexec.c, the DoRegServer calls OpenSCManager, however, on a fresh > installation, ie no ~/.wine, the HKLM\CurrentControlSet\Services does > not yet exist, so that OpenSCManager fails. What is the correct way to > guarantee that this key exists? > See bug 7402. http://bugs.winehq.org/show_bug.cgi?id=7402 -- James Hawkins From mk144210 at bcm.tmc.edu Wed Feb 28 12:28:46 2007 From: mk144210 at bcm.tmc.edu (Misha Koshelev) Date: Wed Feb 28 15:00:46 2007 Subject: msi automation patches Message-ID: <1172687327.27209.6.camel@misha-laptop> Ok, so since my patches weren't commited to git yet, I've consolidated the new automation changes I've made in the attached patches. James and Rob, if they look good to you I will submit these version to wine-patches (so my total will once again be four patches, 1 is http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html , 2 and 3 attached, and 4 is http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html ) and wait to submit anything more for automation until all 4 patches are in. Please let me know Rob (I used DispGetParam, thanks a lot, so probably just need to look at my AutomationObject::Invoke and then the individual object Invoke handlers in the 0003 patch below) and James (I guess in regards to comments and formatting). Thanks a lot Misha -------------- next part -------------- From 7a26ec8da0ca6d2b031a35191a865882cf5a64b4 Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Wed, 28 Feb 2007 12:08:52 -0600 Subject: msi: Expand IDL file to contain all OLE automation interfaces. --- dlls/msi/msiserver.idl | 873 +++++++++++++++++++++++++++++++++++++++--- dlls/msi/msiserver_dispids.h | 180 +++++++++ 2 files changed, 993 insertions(+), 60 deletions(-) diff --git a/dlls/msi/msiserver.idl b/dlls/msi/msiserver.idl index 9966d90..8735b7c 100644 --- a/dlls/msi/msiserver.idl +++ b/dlls/msi/msiserver.idl @@ -1,5 +1,6 @@ /* * Copyright (C) 2007 Mike McCormack + * Copyright (C) 2007 Misha Koshelev * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -16,14 +17,21 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +#include "msiserver_dispids.h" import "unknwn.idl"; import "wtypes.idl"; import "objidl.idl"; import "oaidl.idl"; -[ uuid(000C1092-0000-0000-C000-000000000046), version(1.0) ] +[ + uuid(000C1092-0000-0000-C000-000000000046), + version(1.0), + helpstring("Microsoft Windows Installer Object Library") +] library WindowsInstaller { + /* TLib : + * Forward declare all types defined in this typelib */ dispinterface Installer; dispinterface Record; dispinterface Session; @@ -37,87 +45,832 @@ library WindowsInstaller dispinterface Product; dispinterface Patch; - [ uuid(000C1090-0000-0000-C000-000000000046) ] - dispinterface Installer - { - properties: - methods: - } - - [ uuid(000C1093-0000-0000-C000-000000000046) ] - dispinterface Record - { - properties: - methods: - } - - [ uuid(000C1095-0000-0000-C000-000000000046) ] - dispinterface StringList - { + typedef enum { + msiUILevelNoChange = 0, + msiUILevelDefault = 1, + msiUILevelNone = 2, + msiUILevelBasic = 3, + msiUILevelReduced = 4, + msiUILevelFull = 5, + msiUILevelHideCancel = 32, + msiUILevelProgressOnly = 64, + msiUILevelEndDialog = 128, + msiUILevelSourceResOnly = 256 + } MsiUILevel; + + typedef enum { + msiInstallStateNotUsed = -7, + msiInstallStateBadConfig = -6, + msiInstallStateIncomplete = -5, + msiInstallStateSourceAbsent = -4, + msiInstallStateInvalidArg = -2, + msiInstallStateUnknown = -1, + msiInstallStateBroken = 0, + msiInstallStateAdvertised = 1, + msiInstallStateRemoved = 1, + msiInstallStateAbsent = 2, + msiInstallStateLocal = 3, + msiInstallStateSource = 4, + msiInstallStateDefault = 5 + } MsiInstallState; + + typedef enum { + msiReinstallModeFileMissing = 2, + msiReinstallModeFileOlderVersion = 4, + msiReinstallModeFileEqualVersion = 8, + msiReinstallModeFileExact = 16, + msiReinstallModeFileVerify = 32, + msiReinstallModeFileReplace = 64, + msiReinstallModeMachineData = 128, + msiReinstallModeUserData = 256, + msiReinstallModeShortcut = 512, + msiReinstallModePackage = 1024 + } MsiReinstallMode; + + typedef enum { + msiInstallTypeDefault = 0, + msiInstallTypeNetworkImage = 1, + msiInstallTypeSingleInstance = 2 + } MsiInstallType; + + typedef enum { + msiInstallModeNoSourceResolution = -3, + msiInstallModeNoDetection = -2, + msiInstallModeExisting = -1, + msiInstallModeDefault = 0 + } MsiInstallMode; + + typedef enum { + msiSignatureInfoCertificate = 0, + msiSignatureInfoHash = 1 + } MsiSignatureInfo; + + typedef enum { + msiReadStreamInteger = 0, + msiReadStreamBytes = 1, + msiReadStreamAnsi = 2, + msiReadStreamDirect = 3 + } MsiReadStream; + + typedef enum { + msiRunModeAdmin = 0, + msiRunModeAdvertise = 1, + msiRunModeMaintenance = 2, + msiRunModeRollbackEnabled = 3, + msiRunModeLogEnabled = 4, + msiRunModeOperations = 5, + msiRunModeRebootAtEnd = 6, + msiRunModeRebootNow = 7, + msiRunModeCabinet = 8, + msiRunModeSourceShortNames = 9, + msiRunModeTargetShortNames = 10, + msiRunModeWindows9x = 12, + msiRunModeZawEnabled = 13, + msiRunModeScheduled = 16, + msiRunModeRollback = 17, + msiRunModeCommit = 18 + } MsiRunMode; + + typedef enum { + msiInstallContextFirstVisible = 0, + msiInstallContextUserManaged = 1, + msiInstallContextUser = 2, + msiInstallContextMachine = 4, + msiInstallContextAllUserManaged = 8 + } MsiInstallContext; + + [ + uuid(000C1090-0000-0000-C000-000000000046), + helpcontext(0x00002328) + ] + dispinterface Installer { properties: + [id(DISPID_INSTALLER_UILEVEL)] + MsiUILevel UILevel; methods: - } + [id(DISPID_INSTALLER_CREATERECORD)] + Record* CreateRecord([in] long Count); + [id(DISPID_INSTALLER_OPENPACKAGE)] + Session* OpenPackage( + [in] VARIANT PackagePath, + [in, optional, defaultvalue(0)] long Options); + [id(DISPID_INSTALLER_OPENPRODUCT)] + Session* OpenProduct([in] BSTR ProductCode); + [id(DISPID_INSTALLER_OPENDATABASE)] + Database* OpenDatabase( + [in] BSTR DatabasePath, + [in] VARIANT OpenMode); + [id(DISPID_INSTALLER_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation( + [in] BSTR PackagePath, + [in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_INSTALLER_ENABLELOG)] + void EnableLog( + [in] BSTR LogMode, + [in] BSTR LogFile); + [id(DISPID_INSTALLER_INSTALLPRODUCT)] + void InstallProduct( + [in] BSTR PackagePath, + [in, optional, defaultvalue("0")] BSTR PropertyValues); + [id(DISPID_INSTALLER_VERSION), propget] + BSTR Version(); + [id(DISPID_INSTALLER_LASTERRORRECORD)] + Record* LastErrorRecord(); + [id(DISPID_INSTALLER_REGISTRYVALUE)] + BSTR RegistryValue( + [in] VARIANT Root, + [in] BSTR Key, + [in, optional] VARIANT Value); + [id(DISPID_INSTALLER_FILEATTRIBUTES)] + long FileAttributes([in] BSTR FilePath); + [id(DISPID_INSTALLER_FILESIZE)] + long FileSize([in] BSTR FilePath); + [id(DISPID_INSTALLER_FILEVERSION)] + BSTR FileVersion( + [in] BSTR FilePath, + [in, optional] VARIANT Language); + [id(DISPID_INSTALLER_ENVIRONMENT), propget] + BSTR Environment([in] BSTR Variable); + [id(DISPID_INSTALLER_ENVIRONMENT), propput] + void Environment( + [in] BSTR Variable, + [in] BSTR rhs); + [id(DISPID_INSTALLER_PRODUCTSTATE), propget] + MsiInstallState ProductState([in] BSTR Product); + [id(DISPID_INSTALLER_PRODUCTINFO), propget] + BSTR ProductInfo( + [in] BSTR Product, + [in] BSTR Attribute); + [id(DISPID_INSTALLER_CONFIGUREPRODUCT)] + void ConfigureProduct( + [in] BSTR Product, + [in] long InstallLevel, + [in] MsiInstallState InstallState); + [id(DISPID_INSTALLER_REINSTALLPRODUCT)] + void ReinstallProduct( + [in] BSTR Product, + [in] MsiReinstallMode ReinstallMode); + [id(DISPID_INSTALLER_COLLECTUSERINFO)] + void CollectUserInfo([in] BSTR Product); + [id(DISPID_INSTALLER_APPLYPATCH)] + void ApplyPatch( + [in] BSTR PatchPackage, + [in] BSTR InstallPackage, + [in] MsiInstallType InstallType, + [in] BSTR CommandLine); + [id(DISPID_INSTALLER_FEATUREPARENT), propget] + BSTR FeatureParent( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_FEATURESTATE), propget] + MsiInstallState FeatureState( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_USEFEATURE)] + void UseFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallMode InstallMode); + [id(DISPID_INSTALLER_FEATUREUSAGECOUNT), propget] + long FeatureUsageCount( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_FEATUREUSAGEDATE), propget] + DATE FeatureUsageDate( + [in] BSTR Product, + [in] BSTR Feature); + [id(DISPID_INSTALLER_CONFIGUREFEATURE)] + void ConfigureFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiInstallState InstallState); + [id(DISPID_INSTALLER_REINSTALLFEATURE)] + void ReinstallFeature( + [in] BSTR Product, + [in] BSTR Feature, + [in] MsiReinstallMode ReinstallMode); + [id(DISPID_INSTALLER_PROVIDECOMPONENT)] + BSTR ProvideComponent( + [in] BSTR Product, + [in] BSTR Feature, + [in] BSTR Component, + [in] long InstallMode); + [id(DISPID_INSTALLER_COMPONENTPATH), propget] + BSTR ComponentPath( + [in] BSTR Product, + [in] BSTR Component); + [id(DISPID_INSTALLER_PROVIDEQUALIFIEDCOMPONENT)] + BSTR ProvideQualifiedComponent( + [in] BSTR Category, + [in] BSTR Qualifier, + [in] long InstallMode); + [id(DISPID_INSTALLER_QUALIFIERDESCRIPTION), propget] + BSTR QualifierDescription( + [in] BSTR Category, + [in] BSTR Qualifier); + [id(DISPID_INSTALLER_COMPONENTQUALIFIERS), propget] + StringList* ComponentQualifiers([in] BSTR Category); + [id(DISPID_INSTALLER_PRODUCTS), propget] + StringList* Products(); + [id(DISPID_INSTALLER_FEATURES), propget] + StringList* Features([in] BSTR Product); + [id(DISPID_INSTALLER_COMPONENTS), propget] + StringList* Components(); + [id(DISPID_INSTALLER_COMPONENTCLIENTS), propget] + StringList* ComponentClients([in] BSTR Component); + [id(DISPID_INSTALLER_PATCHES), propget] + StringList* Patches([in] BSTR Product); + [id(DISPID_INSTALLER_RELATEDPRODUCTS), propget] + StringList* RelatedProducts([in] BSTR UpgradeCode); + [id(DISPID_INSTALLER_PATCHINFO), propget] + BSTR PatchInfo( + [in] BSTR Patch, + [in] BSTR Attribute); + [id(DISPID_INSTALLER_PATCHTRANSFORMS), propget] + BSTR PatchTransforms( + [in] BSTR Product, + [in] BSTR Patch); + [id(DISPID_INSTALLER_ADDSOURCE)] + void AddSource( + [in] BSTR Product, + [in] BSTR User, + [in] BSTR Source); + [id(DISPID_INSTALLER_CLEARSOURCELIST)] + void ClearSourceList( + [in] BSTR Product, + [in] BSTR User); + [id(DISPID_INSTALLER_FORCESOURCELISTRESOLUTION)] + void ForceSourceListResolution( + [in] BSTR Product, + [in] BSTR User); + [id(DISPID_INSTALLER_GETSHORTCUTTARGET), propget] + Record* GetShortcutTarget([in] BSTR ShortcutPath); + [id(DISPID_INSTALLER_FILEHASH)] + Record* FileHash( + [in] BSTR FilePath, + [in] long Options); + [id(DISPID_INSTALLER_FILESIGNATUREINFO)] + SAFEARRAY(unsigned char) FileSignatureInfo( + [in] BSTR FilePath, + [in] long Options, + [in] MsiSignatureInfo Format); + [id(DISPID_INSTALLER_REMOVEPATCHES)] + void RemovePatches( + [in] BSTR PatchList, + [in] BSTR Product, + [in] MsiInstallType UninstallType, + [in, optional, defaultvalue("0")] BSTR PropertyList); + [id(DISPID_INSTALLER_APPLYMULTIPLEPATCHES)] + void ApplyMultiplePatches( + [in] BSTR PatchPackage, + [in] BSTR Product, + [in] BSTR PropertiesList); + [id(DISPID_INSTALLER_PRODUCT), propget] + Product* Product( + [in] BSTR Product, + [in] BSTR UserSid, + [in] MsiInstallContext iContext); + [id(DISPID_INSTALLER_PATCH), propget] + Patch* Patch( + [in] BSTR PatchCode, + [in] BSTR ProductCode, + [in] BSTR UserSid, + [in] MsiInstallContext iContext); + [id(DISPID_INSTALLER_PRODUCTSEX), propget] + RecordList* ProductsEx( + [in] BSTR Product, + [in] BSTR UserSid, + [in] long Contexts); + [id(DISPID_INSTALLER_PATCHESEX), propget] + RecordList* PatchesEx( + [in] BSTR Product, + [in] BSTR UserSid, + [in] long Contexts, + [in] long filter); + [id(DISPID_INSTALLER_EXTRACTPATCHXMLDATA)] + BSTR ExtractPatchXMLData([in] BSTR PatchPath); + }; - [ uuid(000C1096-0000-0000-C000-000000000046) ] - dispinterface RecordList - { + [ + uuid(000C1093-0000-0000-C000-000000000046), + helpcontext(0x00002454) + ] + dispinterface Record { properties: methods: - } + [id(DISPID_RECORD_STRINGDATA), propget] + BSTR StringData([in] long Field); + [id(DISPID_RECORD_STRINGDATA), propput] + void StringData( + [in] long Field, + [in] BSTR rhs); + [id(DISPID_RECORD_INTEGERDATA), propget] + long IntegerData([in] long Field); + [id(DISPID_RECORD_INTEGERDATA), propput] + void IntegerData( + [in] long Field, + [in] long rhs); + [id(DISPID_RECORD_SETSTREAM)] + void SetStream( + [in] long Field, + [in] BSTR FilePath); + [id(DISPID_RECORD_READSTREAM)] + BSTR ReadStream( + [in] long Field, + [in] long Length, + [in] MsiReadStream Format); + [id(DISPID_RECORD_FIELDCOUNT), propget] + long FieldCount(); + [id(DISPID_RECORD_ISNULL), propget] + VARIANT_BOOL IsNull([in] long Field); + [id(DISPID_RECORD_DATASIZE), propget] + long DataSize([in] long Field); + [id(DISPID_RECORD_CLEARDATA)] + void ClearData(); + [id(DISPID_RECORD_FORMATTEXT)] + BSTR FormatText(); + }; - [ uuid(000C109A-0000-0000-C000-000000000046) ] - dispinterface UIPreview - { + typedef enum { + msiDoActionStatusNoAction = 0, + msiDoActionStatusSuccess = 1, + msiDoActionStatusUserExit = 2, + msiDoActionStatusFailure = 3, + msiDoActionStatusSuspend = 4, + msiDoActionStatusFinished = 5, + msiDoActionStatusWrongState = 6, + msiDoActionStatusBadActionData = 7 + } MsiDoActionStatus; + + typedef enum { + msiEvaluateConditionFalse = 0, + msiEvaluateConditionTrue = 1, + msiEvaluateConditionNone = 2, + msiEvaluateConditionError = 3 + } _MsiEvaluateCondition; /* Added underscore to avoid conflict with function name */ + + typedef enum { + msiMessageStatusError = -1, + msiMessageStatusNone = 0, + msiMessageStatusOk = 1, + msiMessageStatusCancel = 2, + msiMessageStatusAbort = 3, + msiMessageStatusRetry = 4, + msiMessageStatusIgnore = 5, + msiMessageStatusYes = 6, + msiMessageStatusNo = 7 + } MsiMessageStatus; + + typedef enum { + msiMessageTypeFatalExit = 0, + msiMessageTypeError = 16777216, + msiMessageTypeWarning = 33554432, + msiMessageTypeUser = 50331648, + msiMessageTypeInfo = 67108864, + msiMessageTypeFilesInUse = 83886080, + msiMessageTypeResolveSource = 100663296, + msiMessageTypeOutOfDiskSpace = 117440512, + msiMessageTypeActionStart = 134217728, + msiMessageTypeActionData = 150994944, + msiMessageTypeProgress = 167772160, + msiMessageTypeCommonData = 184549376, + msiMessageTypeOk = 0, + msiMessageTypeOkCancel = 1, + msiMessageTypeAbortRetryIgnore = 2, + msiMessageTypeYesNoCancel = 3, + msiMessageTypeYesNo = 4, + msiMessageTypeRetryCancel = 5, + msiMessageTypeDefault1 = 0, + msiMessageTypeDefault2 = 256, + msiMessageTypeDefault3 = 512 + } MsiMessageType; + + typedef enum { + msiCostTreeSelfOnly = 0, + msiCostTreeChildren = 1, + msiCostTreeParents = 2 + } MsiCostTree; + + typedef enum { + msiDatabaseStateRead = 0, + msiDatabaseStateWrite = 1 + } MsiDatabaseState; + + [ + uuid(000C109E-0000-0000-C000-000000000046), + helpcontext(0x000025e4) + ] + dispinterface Session { properties: methods: - } + [id(DISPID_SESSION_INSTALLER), propget] + Installer* Installer(); + [id(DISPID_SESSION_PROPERTY), propget] + BSTR Property([in] BSTR Name); + [id(DISPID_SESSION_PROPERTY), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(DISPID_SESSION_LANGUAGE), propget] + long Language(); + [id(DISPID_SESSION_MODE), propget] + VARIANT_BOOL Mode([in] MsiRunMode Flag); + [id(DISPID_SESSION_MODE), propput] + void Mode( + [in] MsiRunMode Flag, + [in] VARIANT_BOOL rhs); + [id(DISPID_SESSION_DATABASE), propget] + Database* Database(); + [id(DISPID_SESSION_SOURCEPATH), propget] + BSTR SourcePath([in] BSTR Folder); + [id(DISPID_SESSION_TARGETPATH), propget] + BSTR TargetPath([in] BSTR Folder); + [id(DISPID_SESSION_TARGETPATH), propput] + void TargetPath( + [in] BSTR Folder, + [in] BSTR rhs); + [id(DISPID_SESSION_DOACTION)] + MsiDoActionStatus DoAction([in] BSTR Action); + [id(DISPID_SESSION_SEQUENCE)] + MsiDoActionStatus Sequence( + [in] BSTR Table, + [in, optional] VARIANT Mode); + [id(DISPID_SESSION_EVALUATECONDITION)] + _MsiEvaluateCondition EvaluateCondition([in] BSTR Expression); + [id(DISPID_SESSION_FORMATRECORD)] + BSTR FormatRecord([in] Record* Record); + [id(DISPID_SESSION_MESSAGE)] + MsiMessageStatus Message( + [in] MsiMessageType Kind, + [in] Record* Record); + [id(DISPID_SESSION_FEATURECURRENTSTATE), propget] + MsiInstallState FeatureCurrentState([in] BSTR Feature); + [id(DISPID_SESSION_FEATUREREQUESTSTATE), propget] + MsiInstallState FeatureRequestState([in] BSTR Feature); + [id(DISPID_SESSION_FEATUREREQUESTSTATE), propput] + void FeatureRequestState( + [in] BSTR Feature, + [in] MsiInstallState rhs); + [id(DISPID_SESSION_FEATUREVALIDSTATES), propget] + long FeatureValidStates([in] BSTR Feature); + [id(DISPID_SESSION_FEATURECOST), propget] + long FeatureCost( + [in] BSTR Feature, + [in] MsiCostTree CostTree, + [in] MsiInstallState State); + [id(DISPID_SESSION_COMPONENTCURRENTSTATE), propget] + MsiInstallState ComponentCurrentState([in] BSTR Component); + [id(DISPID_SESSION_COMPONENTREQUESTSTATE), propget] + MsiInstallState ComponentRequestState([in] BSTR Component); + [id(DISPID_SESSION_COMPONENTREQUESTSTATE), propput] + void ComponentRequestState( + [in] BSTR Component, + [in] MsiInstallState rhs); + [id(DISPID_SESSION_SETINSTALLLEVEL)] + void SetInstallLevel([in] long Level); + [id(DISPID_SESSION_VERIFYDISKSPACE), propget] + VARIANT_BOOL VerifyDiskSpace(); + [id(DISPID_SESSION_PRODUCTPROPERTY), propget] + BSTR ProductProperty([in] BSTR Property); + [id(DISPID_SESSION_FEATUREINFO), propget] + FeatureInfo* FeatureInfo([in] BSTR Feature); + [id(DISPID_SESSION_COMPONENTCOSTS), propget] + RecordList* ComponentCosts( + [in] BSTR Component, + [in] MsiInstallState State); + }; + + typedef enum { + msiTransformErrorNone = 0, + msiTransformErrorAddExistingRow = 1, + msiTransformErrorDeleteNonExistingRow = 2, + msiTransformErrorAddExistingTable = 4, + msiTransformErrorDeleteNonExistingTable = 8, + msiTransformErrorUpdateNonExistingRow = 16, + msiTransformErrorChangeCodePage = 32, + msiTransformErrorViewTransform = 256 + } MsiTransformError; + + typedef enum { + msiTransformValidationNone = 0, + msiTransformValidationLanguage = 1, + msiTransformValidationProduct = 2, + msiTransformValidationPlatform = 4, + msiTransformValidationMajorVer = 8, + msiTransformValidationMinorVer = 16, + msiTransformValidationUpdateVer = 32, + msiTransformValidationLess = 64, + msiTransformValidationLessOrEqual = 128, + msiTransformValidationEqual = 256, + msiTransformValidationGreaterOrEqual = 512, + msiTransformValidationGreater = 1024, + msiTransformValidationUpgradeCode = 2048 + } MsiTransformValidation; - [ uuid(000C109B-0000-0000-C000-000000000046) ] - dispinterface SummaryInfo - { + [ + uuid(000C109D-0000-0000-C000-000000000046), + helpcontext(0x0000251c) + ] + dispinterface Database { properties: methods: - } + [id(DISPID_DATABASE_DATABASESTATE), propget] + MsiDatabaseState DatabaseState(); + [id(DISPID_DATABASE_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation([in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_DATABASE_OPENVIEW)] + View* OpenView([in] BSTR Sql); + [id(DISPID_DATABASE_COMMIT)] + void Commit(); + [id(DISPID_DATABASE_PRIMARYKEYS), propget] + Record* PrimaryKeys([in] BSTR Table); + [id(DISPID_DATABASE_IMPORT)] + void Import( + [in] BSTR Folder, + [in] BSTR File); + [id(DISPID_DATABASE_EXPORT)] + void Export( + [in] BSTR Table, + [in] BSTR Folder, + [in] BSTR File); + [id(DISPID_DATABASE_MERGE)] + VARIANT_BOOL Merge( + [in] Database* Database, + [in, optional, defaultvalue("0")] BSTR ErrorTable); + [id(DISPID_DATABASE_GENERATETRANSFORM)] + VARIANT_BOOL GenerateTransform( + [in] Database* ReferenceDatabase, + [in, optional, defaultvalue("0")] BSTR TransformFile); + [id(DISPID_DATABASE_APPLYTRANSFORM)] + void ApplyTransform( + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions); + [id(DISPID_DATABASE_ENABLEUIPREVIEW)] + UIPreview* EnableUIPreview(); + [id(DISPID_DATABASE_TABLEPERSISTENT), propget] + _MsiEvaluateCondition TablePersistent([in] BSTR Table); + [id(DISPID_DATABASE_CREATETRANSFORMSUMMARYINFO)] + void CreateTransformSummaryInfo( + [in] Database* ReferenceDatabase, + [in] BSTR TransformFile, + [in] MsiTransformError ErrorConditions, + [in] MsiTransformValidation Validation); + }; - [ uuid(000C109C-0000-0000-C000-000000000046) ] - dispinterface View - { + [ + uuid(000C109B-0000-0000-C000-000000000046), + helpcontext(0x00002580) + ] + dispinterface SummaryInfo { properties: methods: - } + [id(DISPID_SUMMARYINFO_PROPERTY), propget] + VARIANT Property([in] long Pid); + [id(DISPID_SUMMARYINFO_PROPERTY), propput] + void Property( + [in] long Pid, + [in] VARIANT rhs); + [id(DISPID_SUMMARYINFO_PROPERTYCOUNT), propget] + long PropertyCount(); + [id(DISPID_SUMMARYINFO_PERSIST)] + void Persist(); + }; - [ uuid(000C109D-0000-0000-C000-000000000046) ] - dispinterface Database - { + typedef enum { + msiViewModifySeek = -1, + msiViewModifyRefresh = 0, + msiViewModifyInsert = 1, + msiViewModifyUpdate = 2, + msiViewModifyAssign = 3, + msiViewModifyReplace = 4, + msiViewModifyMerge = 5, + msiViewModifyDelete = 6, + msiViewModifyInsertTemporary = 7, + msiViewModifyValidate = 8, + msiViewModifyValidateNew = 9, + msiViewModifyValidateField = 10, + msiViewModifyValidateDelete = 11 + } _MsiViewModify; /* Added underscore to avoid conflict with MsiViewModify function in msiquery.h */ + + typedef enum { + msiColumnInfoNames = 0, + msiColumnInfoTypes = 1 + } MsiColumnInfo; + + [ + uuid(000C109C-0000-0000-C000-000000000046), + helpcontext(0x000024b8) + ] + dispinterface View { + properties: + methods: + [id(DISPID_VIEW_EXECUTE)] + void Execute([in, optional, defaultvalue(0)] Record* Params); + [id(DISPID_VIEW_FETCH)] + Record* Fetch(); + [id(DISPID_VIEW_MODIFY)] + void Modify( + [in] _MsiViewModify Mode, + Record* Record); + [id(DISPID_VIEW_COLUMNINFO), propget] + Record* ColumnInfo([in] MsiColumnInfo Info); + [id(DISPID_VIEW_CLOSE)] + void Close(); + [id(DISPID_VIEW_GETERROR)] + BSTR GetError(); + }; + + [ + uuid(000C109A-0000-0000-C000-000000000046), + helpcontext(0x00002648) + ] + dispinterface UIPreview { + properties: + methods: + [id(DISPID_UIPREVIEW_PROPERTY), propget] + BSTR Property([in] BSTR Name); + [id(DISPID_UIPREVIEW_PROPERTY), propput] + void Property( + [in] BSTR Name, + [in] BSTR rhs); + [id(DISPID_UIPREVIEW_VIEWDIALOG)] + void ViewDialog([in] BSTR Dialog); + [id(DISPID_UIPREVIEW_VIEWBILLBOARD)] + void ViewBillboard( + [in] BSTR Control, + [in] BSTR Billboard); + }; + + [ + uuid(000C109F-0000-0000-C000-000000000046), + helpcontext(0x0000238c) + ] + dispinterface FeatureInfo { properties: + [id(DISPID_FEATUREINFO_ATTRIBUTES)] + long Attributes; methods: - } - - [ uuid(000C109E-0000-0000-C000-000000000046) ] - dispinterface Session - { - properties: - methods: - } - - [ uuid(000C109F-0000-0000-C000-000000000046) ] - dispinterface FeatureInfo - { + [id(DISPID_FEATUREINFO_TITLE), propget] + BSTR Title(); + [id(DISPID_FEATUREINFO_DESCRIPTION), propget] + BSTR Description(); + }; + + [ + uuid(000C1096-0000-0000-C000-000000000046), + helpcontext(0x000023f3) + ] + dispinterface RecordList { + properties: + methods: + [id(DISPID_RECORDLIST__NEWENUM)] + IUnknown _NewEnum(); + [id(DISPID_RECORDLIST_ITEM), propget] + Record* Item(long Index); + [id(DISPID_RECORDLIST_COUNT), propget] + long Count(); + }; + + [ + uuid(000C1095-0000-0000-C000-000000000046), + helpcontext(0x000023f0) + ] + dispinterface StringList { properties: methods: - } + [id(DISPID_STRINGLIST__NEWENUM)] + IUnknown _NewEnum(); + [id(DISPID_STRINGLIST_ITEM), propget] + BSTR Item(long Index); + [id(DISPID_STRINGLIST_COUNT), propget] + long Count(); + }; - [ uuid(000C10A0-0000-0000-C000-000000000046) ] - dispinterface Product - { + typedef enum { + msiInstallSourceTypeUnknown = 0, + msiInstallSourceTypeNetwork = 1, + msiInstallSourceTypeURL = 2, + msiInstallSourceTypeMedia = 4 + } MsiInstallSourceType; + + [ + uuid(000C10A0-0000-0000-C000-000000000046), + helpcontext(0x00002396) + ] + dispinterface Product { properties: methods: - } + [id(DISPID_PRODUCT_PRODUCTCODE), propget] + BSTR ProductCode(); + [id(DISPID_PRODUCT_USERSID), propget] + BSTR UserSid(); + [id(DISPID_PRODUCT_CONTEXT), propget] + MsiInstallContext Context(); + [id(DISPID_PRODUCT_STATE), propget] + MsiInstallState State(); + [id(DISPID_PRODUCT_INSTALLPROPERTY), propget] + BSTR InstallProperty([in] BSTR Name); + [id(DISPID_PRODUCT_COMPONENTSTATE), propget] + MsiInstallState ComponentState([in] BSTR Component); + [id(DISPID_PRODUCT_FEATURESTATE), propget] + MsiInstallState FeatureState([in] BSTR Feature); + [id(DISPID_PRODUCT_SOURCES), propget] + StringList* Sources([in] long SourceType); + [id(DISPID_PRODUCT_MEDIADISKS), propget] + RecordList* MediaDisks(); + [id(DISPID_PRODUCT_SOURCELISTADDSOURCE)] + void SourceListAddSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source, + [in] long dwIndex); + [id(DISPID_PRODUCT_SOURCELISTADDMEDIADISK)] + void SourceListAddMediaDisk( + [in] long dwDiskId, + [in] BSTR VolumeLabel, + [in] BSTR DiskPrompt); + [id(DISPID_PRODUCT_SOURCELISTCLEARSOURCE)] + void SourceListClearSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source); + [id(DISPID_PRODUCT_SOURCELISTCLEARMEDIADISK)] + void SourceListClearMediaDisk([in] long iDiskId); + [id(DISPID_PRODUCT_SOURCELISTCLEARALL)] + void SourceListClearAll([in] MsiInstallSourceType iSourceType); + [id(DISPID_PRODUCT_SOURCELISTFORCERESOLUTION)] + void SourceListForceResolution(); + [id(DISPID_PRODUCT_SOURCELISTINFO), propget] + BSTR SourceListInfo([in] BSTR Property); + [id(DISPID_PRODUCT_SOURCELISTINFO), propput] + void SourceListInfo( + [in] BSTR Property, + [in] BSTR retval); + }; - [ uuid(000C10A1-0000-0000-C000-000000000046) ] - dispinterface Patch - { + [ + uuid(000C10A1-0000-0000-C000-000000000046), + helpcontext(0x000023aa) + ] + dispinterface Patch { properties: methods: - } -} + [id(DISPID_PATCH_PATCHCODE), propget] + BSTR PatchCode(); + [id(DISPID_PATCH_PRODUCTCODE), propget] + BSTR ProductCode(); + [id(DISPID_PATCH_USERSID), propget] + BSTR UserSid(); + [id(DISPID_PATCH_CONTEXT), propget] + MsiInstallContext Context(); + [id(DISPID_PATCH_STATE), propget] + MsiInstallState State(); + [id(DISPID_PATCH_SOURCES), propget] + StringList* Sources([in] long SourceType); + [id(DISPID_PATCH_MEDIADISKS), propget] + RecordList* MediaDisks(); + [id(DISPID_PATCH_SOURCELISTADDSOURCE)] + void SourceListAddSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source, + [in] long dwIndex); + [id(DISPID_PATCH_SOURCELISTADDMEDIADISK)] + void SourceListAddMediaDisk( + [in] long dwDiskId, + [in] BSTR VolumeLabel, + [in] BSTR DiskPrompt); + [id(DISPID_PATCH_SOURCELISTCLEARSOURCE)] + void SourceListClearSource( + [in] MsiInstallSourceType iSourceType, + [in] BSTR Source); + [id(DISPID_PATCH_SOURCELISTCLEARMEDIADISK)] + void SourceListClearMediaDisk([in] long iDiskId); + [id(DISPID_PATCH_SOURCELISTCLEARALL)] + void SourceListClearAll([in] MsiInstallSourceType iSourceType); + [id(DISPID_PATCH_SOURCELISTFORCERESOLUTION)] + void SourceListForceResolution(); + [id(DISPID_PATCH_SOURCELISTINFO), propget] + BSTR SourceListInfo([in] BSTR Property); + [id(DISPID_PATCH_SOURCELISTINFO), propput] + void SourceListInfo( + [in] BSTR Property, + [in] BSTR retval); + [id(DISPID_PATCH_PATCHPROPERTY), propget] + BSTR PatchProperty([in] BSTR Property); + }; + + typedef enum { + msiDatabaseNullInteger = -2147483648 + } Constants; + + typedef enum { + msiOpenDatabaseModeReadOnly = 0, + msiOpenDatabaseModeTransact = 1, + msiOpenDatabaseModeDirect = 2, + msiOpenDatabaseModeCreate = 3, + msiOpenDatabaseModeCreateDirect = 4, + msiOpenDatabaseModePatchFile = 32 + } MsiOpenDatabaseMode; + + typedef enum { + msiSignatureOptionInvalidHashFatal = 1 + } MsiSignatureOption; +}; diff --git a/dlls/msi/msiserver_dispids.h b/dlls/msi/msiserver_dispids.h new file mode 100644 index 0000000..093efb0 --- /dev/null +++ b/dlls/msi/msiserver_dispids.h @@ -0,0 +1,180 @@ +/* + * Copyright (C) 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define DISPID_INSTALLER_UILEVEL 6 +#define DISPID_INSTALLER_CREATERECORD 1 +#define DISPID_INSTALLER_OPENPACKAGE 2 +#define DISPID_INSTALLER_OPENPRODUCT 3 +#define DISPID_INSTALLER_OPENDATABASE 4 +#define DISPID_INSTALLER_SUMMARYINFORMATION 5 +#define DISPID_INSTALLER_ENABLELOG 7 +#define DISPID_INSTALLER_INSTALLPRODUCT 8 +#define DISPID_INSTALLER_VERSION 9 +#define DISPID_INSTALLER_LASTERRORRECORD 10 +#define DISPID_INSTALLER_REGISTRYVALUE 11 +#define DISPID_INSTALLER_FILEATTRIBUTES 13 +#define DISPID_INSTALLER_FILESIZE 15 +#define DISPID_INSTALLER_FILEVERSION 16 +#define DISPID_INSTALLER_ENVIRONMENT 12 +#define DISPID_INSTALLER_PRODUCTSTATE 17 +#define DISPID_INSTALLER_PRODUCTINFO 18 +#define DISPID_INSTALLER_CONFIGUREPRODUCT 19 +#define DISPID_INSTALLER_REINSTALLPRODUCT 20 +#define DISPID_INSTALLER_COLLECTUSERINFO 21 +#define DISPID_INSTALLER_APPLYPATCH 22 +#define DISPID_INSTALLER_FEATUREPARENT 23 +#define DISPID_INSTALLER_FEATURESTATE 24 +#define DISPID_INSTALLER_USEFEATURE 25 +#define DISPID_INSTALLER_FEATUREUSAGECOUNT 26 +#define DISPID_INSTALLER_FEATUREUSAGEDATE 27 +#define DISPID_INSTALLER_CONFIGUREFEATURE 28 +#define DISPID_INSTALLER_REINSTALLFEATURE 29 +#define DISPID_INSTALLER_PROVIDECOMPONENT 30 +#define DISPID_INSTALLER_COMPONENTPATH 31 +#define DISPID_INSTALLER_PROVIDEQUALIFIEDCOMPONENT 32 +#define DISPID_INSTALLER_QUALIFIERDESCRIPTION 33 +#define DISPID_INSTALLER_COMPONENTQUALIFIERS 34 +#define DISPID_INSTALLER_PRODUCTS 35 +#define DISPID_INSTALLER_FEATURES 36 +#define DISPID_INSTALLER_COMPONENTS 37 +#define DISPID_INSTALLER_COMPONENTCLIENTS 38 +#define DISPID_INSTALLER_PATCHES 39 +#define DISPID_INSTALLER_RELATEDPRODUCTS 40 +#define DISPID_INSTALLER_PATCHINFO 41 +#define DISPID_INSTALLER_PATCHTRANSFORMS 42 +#define DISPID_INSTALLER_ADDSOURCE 43 +#define DISPID_INSTALLER_CLEARSOURCELIST 44 +#define DISPID_INSTALLER_FORCESOURCELISTRESOLUTION 45 +#define DISPID_INSTALLER_GETSHORTCUTTARGET 46 +#define DISPID_INSTALLER_FILEHASH 47 +#define DISPID_INSTALLER_FILESIGNATUREINFO 48 +#define DISPID_INSTALLER_REMOVEPATCHES 49 +#define DISPID_INSTALLER_APPLYMULTIPLEPATCHES 51 +#define DISPID_INSTALLER_PRODUCT 53 +#define DISPID_INSTALLER_PATCH 56 +#define DISPID_INSTALLER_PRODUCTSEX 52 +#define DISPID_INSTALLER_PATCHESEX 55 +#define DISPID_INSTALLER_EXTRACTPATCHXMLDATA 57 + +#define DISPID_RECORD_STRINGDATA 1 +#define DISPID_RECORD_INTEGERDATA 2 +#define DISPID_RECORD_SETSTREAM 3 +#define DISPID_RECORD_READSTREAM 4 +#define DISPID_RECORD_FIELDCOUNT 0 +#define DISPID_RECORD_ISNULL 6 +#define DISPID_RECORD_DATASIZE 5 +#define DISPID_RECORD_CLEARDATA 7 +#define DISPID_RECORD_FORMATTEXT 8 + +#define DISPID_SESSION_INSTALLER 1 +#define DISPID_SESSION_PROPERTY 2 +#define DISPID_SESSION_LANGUAGE 3 +#define DISPID_SESSION_MODE 4 +#define DISPID_SESSION_DATABASE 5 +#define DISPID_SESSION_SOURCEPATH 6 +#define DISPID_SESSION_TARGETPATH 7 +#define DISPID_SESSION_DOACTION 8 +#define DISPID_SESSION_SEQUENCE 9 +#define DISPID_SESSION_EVALUATECONDITION 10 +#define DISPID_SESSION_FORMATRECORD 11 +#define DISPID_SESSION_MESSAGE 12 +#define DISPID_SESSION_FEATURECURRENTSTATE 13 +#define DISPID_SESSION_FEATUREREQUESTSTATE 14 +#define DISPID_SESSION_FEATUREVALIDSTATES 15 +#define DISPID_SESSION_FEATURECOST 16 +#define DISPID_SESSION_COMPONENTCURRENTSTATE 17 +#define DISPID_SESSION_COMPONENTREQUESTSTATE 18 +#define DISPID_SESSION_SETINSTALLLEVEL 19 +#define DISPID_SESSION_VERIFYDISKSPACE 20 +#define DISPID_SESSION_PRODUCTPROPERTY 21 +#define DISPID_SESSION_FEATUREINFO 22 +#define DISPID_SESSION_COMPONENTCOSTS 23 + +#define DISPID_DATABASE_DATABASESTATE 1 +#define DISPID_DATABASE_SUMMARYINFORMATION 2 +#define DISPID_DATABASE_OPENVIEW 3 +#define DISPID_DATABASE_COMMIT 4 +#define DISPID_DATABASE_PRIMARYKEYS 5 +#define DISPID_DATABASE_IMPORT 6 +#define DISPID_DATABASE_EXPORT 7 +#define DISPID_DATABASE_MERGE 8 +#define DISPID_DATABASE_GENERATETRANSFORM 9 +#define DISPID_DATABASE_APPLYTRANSFORM 10 +#define DISPID_DATABASE_ENABLEUIPREVIEW 11 +#define DISPID_DATABASE_TABLEPERSISTENT 12 +#define DISPID_DATABASE_CREATETRANSFORMSUMMARYINFO 13 + +#define DISPID_SUMMARYINFO_PROPERTY 1 +#define DISPID_SUMMARYINFO_PROPERTYCOUNT 2 +#define DISPID_SUMMARYINFO_PERSIST 3 + +#define DISPID_VIEW_EXECUTE 1 +#define DISPID_VIEW_FETCH 2 +#define DISPID_VIEW_MODIFY 3 +#define DISPID_VIEW_COLUMNINFO 5 +#define DISPID_VIEW_CLOSE 4 +#define DISPID_VIEW_GETERROR 6 + +#define DISPID_UIPREVIEW_PROPERTY 1 +#define DISPID_UIPREVIEW_VIEWDIALOG 2 +#define DISPID_UIPREVIEW_VIEWBILLBOARD 3 + +#define DISPID_FEATUREINFO_ATTRIBUTES 3 +#define DISPID_FEATUREINFO_TITLE 1 +#define DISPID_FEATUREINFO_DESCRIPTION 2 + +#define DISPID_RECORDLIST__NEWENUM -4 +#define DISPID_RECORDLIST_ITEM 0 +#define DISPID_RECORDLIST_COUNT 1 + +#define DISPID_STRINGLIST__NEWENUM -4 +#define DISPID_STRINGLIST_ITEM 0 +#define DISPID_STRINGLIST_COUNT 1 + +#define DISPID_PRODUCT_PRODUCTCODE 1 +#define DISPID_PRODUCT_USERSID 2 +#define DISPID_PRODUCT_CONTEXT 3 +#define DISPID_PRODUCT_STATE 4 +#define DISPID_PRODUCT_INSTALLPROPERTY 5 +#define DISPID_PRODUCT_COMPONENTSTATE 6 +#define DISPID_PRODUCT_FEATURESTATE 7 +#define DISPID_PRODUCT_SOURCES 14 +#define DISPID_PRODUCT_MEDIADISKS 15 +#define DISPID_PRODUCT_SOURCELISTADDSOURCE 8 +#define DISPID_PRODUCT_SOURCELISTADDMEDIADISK 9 +#define DISPID_PRODUCT_SOURCELISTCLEARSOURCE 10 +#define DISPID_PRODUCT_SOURCELISTCLEARMEDIADISK 11 +#define DISPID_PRODUCT_SOURCELISTCLEARALL 12 +#define DISPID_PRODUCT_SOURCELISTFORCERESOLUTION 13 +#define DISPID_PRODUCT_SOURCELISTINFO 16 + +#define DISPID_PATCH_PATCHCODE 1 +#define DISPID_PATCH_PRODUCTCODE 2 +#define DISPID_PATCH_USERSID 3 +#define DISPID_PATCH_CONTEXT 4 +#define DISPID_PATCH_STATE 5 +#define DISPID_PATCH_SOURCES 12 +#define DISPID_PATCH_MEDIADISKS 13 +#define DISPID_PATCH_SOURCELISTADDSOURCE 6 +#define DISPID_PATCH_SOURCELISTADDMEDIADISK 7 +#define DISPID_PATCH_SOURCELISTCLEARSOURCE 8 +#define DISPID_PATCH_SOURCELISTCLEARMEDIADISK 9 +#define DISPID_PATCH_SOURCELISTCLEARALL 10 +#define DISPID_PATCH_SOURCELISTFORCERESOLUTION 11 +#define DISPID_PATCH_SOURCELISTINFO 14 +#define DISPID_PATCH_PATCHPROPERTY 15 -- 1.4.1 -------------- next part -------------- From 5a41c336b7c27d70ce50bdc7e930a6bf6692c7ce Mon Sep 17 00:00:00 2001 From: Misha Koshelev Date: Wed, 28 Feb 2007 12:10:18 -0600 Subject: msi: Add partial, expandable OLE automation support. --- dlls/msi/Makefile.in | 3 dlls/msi/automation.c | 826 +++++++++++++++++++++++++++++++++++++++++++++++++ dlls/msi/msipriv.h | 4 3 files changed, 833 insertions(+), 0 deletions(-) diff --git a/dlls/msi/Makefile.in b/dlls/msi/Makefile.in index 5fb0941..3418fb5 100644 --- a/dlls/msi/Makefile.in +++ b/dlls/msi/Makefile.in @@ -12,6 +12,7 @@ C_SRCS = \ action.c \ alter.c \ appsearch.c \ + automation.c \ classes.c \ create.c \ custom.c \ @@ -47,6 +48,8 @@ C_SRCS = \ upgrade.c \ where.c +IDL_H_SRCS = msiserver.idl +IDL_I_SRCS = msiserver.idl IDL_TLB_SRCS = msiserver.idl BISON_SRCS = \ diff --git a/dlls/msi/automation.c b/dlls/msi/automation.c new file mode 100644 index 0000000..cfb2cf1 --- /dev/null +++ b/dlls/msi/automation.c @@ -0,0 +1,826 @@ +/* + * Implementation of OLE Automation for Microsoft Installer (msi.dll) + * + * Copyright 2007 Misha Koshelev + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define COBJMACROS + +#include +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winuser.h" +#include "msidefs.h" +#include "msipriv.h" +#include "activscp.h" +#include "oleauto.h" +#include "wine/debug.h" +#include "wine/unicode.h" + +#include "msiserver.h" +#include "msiserver_dispids.h" + +WINE_DEFAULT_DEBUG_CHANNEL(msi); + +/* FIXME: I don't know how big this should be */ +#define MAX_MSI_STRING 1000 + +/* + * AutomationObject - "base" class for all automation objects. For each interface, we implement Invoke function + * called from AutomationObject::Invoke, and pass this function to create_automation_object. + */ + +typedef interface AutomationObject AutomationObject; + +interface AutomationObject { + /* + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo + */ + const IDispatchVtbl *lpVtbl; + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; + + /* Object reference count */ + LONG ref; + + /* Clsid for this class and it's appropriate ITypeInfo object */ + LPCLSID clsid; + ITypeInfo *iTypeInfo; + + /* The MSI handle of the current object */ + MSIHANDLE msiHandle; + + /* A function that is called from AutomationObject::Invoke, specific to this type of object. */ + HRESULT (STDMETHODCALLTYPE *funcInvoke)( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr); +}; + +/* VTables */ +static const struct IDispatchVtbl AutomationObject_Vtbl; +static const struct IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl; +static const struct IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl; +static const struct IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl; + +/* Load type info so we don't have to process GetIDsOfNames */ +HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid) +{ + HRESULT hr; + LPTYPELIB pLib = NULL; + LPTYPEINFO pInfo = NULL; + WCHAR szMsiServer[] = {'m','s','i','s','e','r','v','e','r','.','t','l','b'}; + + TRACE("(%p)->(%s,%d)\n", iface, debugstr_guid(clsid), lcid); + + /* Load registered type library */ + hr = LoadRegTypeLib(&LIBID_WindowsInstaller, 1, 0, lcid, &pLib); + if (FAILED(hr)) { + hr = LoadTypeLib(szMsiServer, &pLib); + if (FAILED(hr)) { + ERR("Could not load msiserver.tlb\n"); + return hr; + } + } + + /* Get type information for object */ + hr = ITypeLib_GetTypeInfoOfGuid(pLib, clsid, &pInfo); + ITypeLib_Release(pLib); + if (FAILED(hr)) { + ERR("Could not load ITypeInfo for %s\n", debugstr_guid(clsid)); + return hr; + } + *pptinfo = pInfo; + return S_OK; +} + +/* Create the automation object, placing the result in the pointer ppObj. The automation object is created + * with the appropriate clsid and invocation function. */ +HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, + HRESULT (STDMETHODCALLTYPE *funcInvoke)(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*, + VARIANT*,EXCEPINFO*,UINT*)) +{ + AutomationObject *object; + HRESULT hr; + + TRACE("(%ld,%p,%p,%s,%p)\n", (unsigned long)msiHandle, pUnkOuter, ppObj, debugstr_guid(clsid), funcInvoke); + + if( pUnkOuter ) + return CLASS_E_NOAGGREGATION; + + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(AutomationObject)); + + /* Set all the VTable references */ + object->lpVtbl = &AutomationObject_Vtbl; + object->lpvtblIProvideClassInfo = &AutomationObject_IProvideClassInfo_Vtbl; + object->lpvtblIProvideClassInfo2 = &AutomationObject_IProvideClassInfo2_Vtbl; + object->lpvtblIProvideMultipleClassInfo = &AutomationObject_IProvideMultipleClassInfo_Vtbl; + object->ref = 1; + + /* Store data that was passed */ + object->msiHandle = msiHandle; + object->clsid = (LPCLSID)clsid; + object->funcInvoke = funcInvoke; + + /* Load our TypeInfo so we don't have to process GetIDsOfNames */ + object->iTypeInfo = NULL; + hr = LoadTypeInfo((IDispatch *)object, &object->iTypeInfo, clsid, 0x0); + if (FAILED(hr)) { + HeapFree(GetProcessHeap(), 0, object); + return hr; + } + + *ppObj = object; + + return S_OK; +} + +/* Macros to get pointer to AutomationObject from the other VTables. */ +static inline AutomationObject *obj_from_IProvideClassInfo( IProvideClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo)); +} + +static inline AutomationObject *obj_from_IProvideClassInfo2( IProvideClassInfo2 *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideClassInfo2)); +} + +static inline AutomationObject *obj_from_IProvideMultipleClassInfo( IProvideMultipleClassInfo *iface ) +{ + return (AutomationObject *)((char*)iface - FIELD_OFFSET(AutomationObject, lpvtblIProvideMultipleClassInfo)); +} + +/* + * AutomationObject methods + */ + +/*** IUnknown methods ***/ +static HRESULT WINAPI AutomationObject_QueryInterface(IDispatch* iface, REFIID riid, void** ppvObject) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppvObject); + + if ( (This==0) || (ppvObject==0) ) + return E_INVALIDARG; + + *ppvObject = 0; + + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IDispatch) || IsEqualGUID(riid, This->clsid)) + *ppvObject = This; + else if (IsEqualGUID(riid, &IID_IProvideClassInfo)) + *ppvObject = (IProvideClassInfo*)&(This->lpvtblIProvideClassInfo); + else if (IsEqualGUID(riid, &IID_IProvideClassInfo2)) + *ppvObject = (IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2); + else if (IsEqualGUID(riid, &IID_IProvideMultipleClassInfo)) + *ppvObject = (IProvideMultipleClassInfo*)&(This->lpvtblIProvideMultipleClassInfo); + + if ((*ppvObject)==0) + { + TRACE("() : asking for unsupported interface %s\n",debugstr_guid(riid)); + return E_NOINTERFACE; + } + + /* + * Query Interface always increases the reference count by one when it is + * successful + */ + IClassFactory_AddRef(iface); + + return S_OK; +} + +static ULONG WINAPI AutomationObject_AddRef(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)\n", iface, This); + + return InterlockedIncrement(&This->ref); +} + +static ULONG WINAPI AutomationObject_Release(IDispatch* iface) +{ + AutomationObject *This = (AutomationObject *)iface; + ULONG ref = InterlockedDecrement(&This->ref); + + TRACE("(%p/%p)\n", iface, This); + + if (!ref) + { + MsiCloseHandle(This->msiHandle); + HeapFree(GetProcessHeap(), 0, This); + } + + return ref; +} + +/*** IDispatch methods ***/ +static HRESULT WINAPI AutomationObject_GetTypeInfoCount( + IDispatch* iface, + UINT* pctinfo) +{ + AutomationObject *This = (AutomationObject *)iface; + + TRACE("(%p/%p)->(%p)\n", iface, This, pctinfo); + *pctinfo = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetTypeInfo( + IDispatch* iface, + UINT iTInfo, + LCID lcid, + ITypeInfo** ppTInfo) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%d,%d,%p)\n", iface, This, iTInfo, lcid, ppTInfo); + + ITypeInfo_AddRef(This->iTypeInfo); + *ppTInfo = This->iTypeInfo; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetIDsOfNames( + IDispatch* iface, + REFIID riid, + LPOLESTR* rgszNames, + UINT cNames, + LCID lcid, + DISPID* rgDispId) +{ + AutomationObject *This = (AutomationObject *)iface; + TRACE("(%p/%p)->(%p,%p,%d,%d,%p)\n", iface, This, riid, rgszNames, cNames, lcid, rgDispId); + + if (!IsEqualGUID(riid, &IID_NULL)) return E_INVALIDARG; + return ITypeInfo_GetIDsOfNames(This->iTypeInfo, rgszNames, cNames, rgDispId); +} + +/* Some error checking is done here to simplify individual object function invocation */ +static HRESULT WINAPI AutomationObject_Invoke( + IDispatch* iface, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + AutomationObject *This = (AutomationObject *)iface; + HRESULT hr; + unsigned int uArgErr; + VARIANT varResultDummy; + BSTR bstrName = NULL; + + TRACE("(%p/%p)->(%d,%p,%d,%d,%p,%p,%p,%p)\n", iface, This, dispIdMember, riid, lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); + + if (!IsEqualIID(riid, &IID_NULL)) + { + ERR("riid was %s instead of IID_NULL\n", debugstr_guid(riid)); + return DISP_E_UNKNOWNNAME; + } + + if (!pDispParams) + { + ERR("NULL pDispParams not allowed\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + if (wFlags & DISPATCH_PROPERTYGET && !pVarResult) + { + ERR("NULL pVarResult not allowed when DISPATCH_PROPERTYGET specified\n"); + return DISP_E_PARAMNOTOPTIONAL; + } + + /* This simplifies our individual object invocation functions */ + if (puArgErr == NULL) puArgErr = &uArgErr; + if (pVarResult == NULL) pVarResult = &varResultDummy; + + /* Assume return type is void unless determined otherwise */ + VariantInit(pVarResult); + + /* If we are tracing, we want to see the name of the member we are invoking */ + if (TRACE_ON(msi)) + { + ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + TRACE("Method %d, %s\n", dispIdMember, debugstr_w(bstrName)); + } + + hr = This->funcInvoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr); + + if (hr == DISP_E_MEMBERNOTFOUND) { + if (bstrName == NULL) ITypeInfo_GetDocumentation(This->iTypeInfo, dispIdMember, &bstrName, NULL, NULL, NULL); + FIXME("Method %d, %s wflags %d not implemented, clsid %s\n", dispIdMember, debugstr_w(bstrName), wFlags, debugstr_guid(This->clsid)); + } + + TRACE("Returning %d, %s\n", hr, hr == S_OK ? "ok" : "not ok"); + + return hr; +} + +static const struct IDispatchVtbl AutomationObject_Vtbl = +{ + AutomationObject_QueryInterface, + AutomationObject_AddRef, + AutomationObject_Release, + AutomationObject_GetTypeInfoCount, + AutomationObject_GetTypeInfo, + AutomationObject_GetIDsOfNames, + AutomationObject_Invoke +}; + +/* + * IProvideClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo_QueryInterface( + IProvideClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_AddRef(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo_Release(IProvideClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_GetClassInfo(IProvideClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, ppTI); + return LoadTypeInfo((IDispatch *)This, ppTI, This->clsid, 0); +} + +static const IProvideClassInfoVtbl AutomationObject_IProvideClassInfo_Vtbl = +{ + AutomationObject_IProvideClassInfo_QueryInterface, + AutomationObject_IProvideClassInfo_AddRef, + AutomationObject_IProvideClassInfo_Release, + AutomationObject_GetClassInfo +}; + +/* + * IProvideClassInfo2 methods + */ + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_QueryInterface( + IProvideClassInfo2* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_AddRef(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideClassInfo2_Release(IProvideClassInfo2* iface) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideClassInfo2_GetClassInfo(IProvideClassInfo2* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_GetGUID(IProvideClassInfo2* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideClassInfo2(iface); + TRACE("(%p/%p)->(%d,%s)\n", iface, This, dwGuidKind, debugstr_guid(pGUID)); + + if (dwGuidKind != GUIDKIND_DEFAULT_SOURCE_DISP_IID) + return E_INVALIDARG; + else { + *pGUID = *This->clsid; + return S_OK; + } +} + +static const IProvideClassInfo2Vtbl AutomationObject_IProvideClassInfo2_Vtbl = +{ + AutomationObject_IProvideClassInfo2_QueryInterface, + AutomationObject_IProvideClassInfo2_AddRef, + AutomationObject_IProvideClassInfo2_Release, + AutomationObject_IProvideClassInfo2_GetClassInfo, + AutomationObject_GetGUID +}; + +/* + * IProvideMultipleClassInfo methods + */ + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_QueryInterface( + IProvideMultipleClassInfo* iface, + REFIID riid, + VOID** ppvoid) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_QueryInterface((IDispatch *)This, riid, ppvoid); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_AddRef(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_AddRef((IDispatch *)This); +} + +static ULONG WINAPI AutomationObject_IProvideMultipleClassInfo_Release(IProvideMultipleClassInfo* iface) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_Release((IDispatch *)This); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetClassInfo(IProvideMultipleClassInfo* iface, ITypeInfo** ppTI) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetClassInfo((IProvideClassInfo*)&(This->lpvtblIProvideClassInfo), ppTI); +} + +static HRESULT WINAPI AutomationObject_IProvideMultipleClassInfo_GetGUID(IProvideMultipleClassInfo* iface, DWORD dwGuidKind, GUID* pGUID) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + return AutomationObject_GetGUID((IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2), dwGuidKind, pGUID); +} + +static HRESULT WINAPI AutomationObject_GetMultiTypeInfoCount(IProvideMultipleClassInfo* iface, ULONG* pcti) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%p)\n", iface, This, pcti); + *pcti = 1; + return S_OK; +} + +static HRESULT WINAPI AutomationObject_GetInfoOfIndex(IProvideMultipleClassInfo* iface, + ULONG iti, + DWORD dwFlags, + ITypeInfo** pptiCoClass, + DWORD* pdwTIFlags, + ULONG* pcdispidReserved, + IID* piidPrimary, + IID* piidSource) +{ + AutomationObject *This = obj_from_IProvideMultipleClassInfo(iface); + + TRACE("(%p/%p)->(%d,%d,%p,%p,%p,%p,%p)\n", iface, This, iti, dwFlags, pptiCoClass, pdwTIFlags, pcdispidReserved, piidPrimary, piidSource); + + if (iti != 0) + return E_INVALIDARG; + + if (dwFlags & MULTICLASSINFO_GETTYPEINFO) + LoadTypeInfo((IDispatch *)This, pptiCoClass, This->clsid, 0); + + if (dwFlags & MULTICLASSINFO_GETNUMRESERVEDDISPIDS) + { + *pdwTIFlags = 0; + *pcdispidReserved = 0; + } + + if (dwFlags & MULTICLASSINFO_GETIIDPRIMARY){ + *piidPrimary = *This->clsid; + } + + if (dwFlags & MULTICLASSINFO_GETIIDSOURCE){ + *piidSource = *This->clsid; + } + + return S_OK; +} + +static const IProvideMultipleClassInfoVtbl AutomationObject_IProvideMultipleClassInfo_Vtbl = +{ + AutomationObject_IProvideMultipleClassInfo_QueryInterface, + AutomationObject_IProvideMultipleClassInfo_AddRef, + AutomationObject_IProvideMultipleClassInfo_Release, + AutomationObject_IProvideMultipleClassInfo_GetClassInfo, + AutomationObject_IProvideMultipleClassInfo_GetGUID, + AutomationObject_GetMultiTypeInfoCount, + AutomationObject_GetInfoOfIndex +}; + +/* + * Individual Object Invocation Functions + */ + +HRESULT WINAPI RecordImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + UINT ret; + VARIANTARG varg0, varg1; + HRESULT hr; + + VariantInit(&varg0); + VariantInit(&varg1); + + switch (dispIdMember) + { + case DISPID_RECORD_STRINGDATA: + if (wFlags & DISPATCH_PROPERTYGET) { + hr = DispGetParam(pDispParams, 0, VT_I4, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_BSTR; + if ((ret = MsiRecordGetStringW(This->msiHandle, V_I4(&varg0), szString, &dwLen)) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + else + { + TRACE("MsiRecordGetString returned %d\n", ret); + V_BSTR(pVarResult) = NULL; + } + } else if (wFlags & DISPATCH_PROPERTYPUT) { + hr = DispGetParam(pDispParams, 0, VT_I4, &varg0, puArgErr); + if (hr != S_OK) return hr; + hr = DispGetParam(pDispParams, DISPID_PROPERTYPUT, VT_BSTR, &varg1, puArgErr); + if (hr != S_OK) return hr; + if ((ret = MsiRecordSetStringW(This->msiHandle, V_I4(&varg0), V_BSTR(&varg1))) != ERROR_SUCCESS) + TRACE("MsiRecordSetString returned %d\n", ret); + } + break; + + default: + return DISP_E_MEMBERNOTFOUND; + } + + return S_OK; +} + +HRESULT WINAPI ViewImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + IDispatch *iDispatch = NULL; + UINT ret; + VARIANTARG varg0, varg1; + HRESULT hr; + + VariantInit(&varg0); + VariantInit(&varg1); + + switch (dispIdMember) + { + case DISPID_VIEW_EXECUTE: + if (wFlags & DISPATCH_METHOD) + { + hr = DispGetParam(pDispParams, 0, VT_DISPATCH, &varg0, puArgErr); + if (hr == S_OK) + MsiViewExecute(This->msiHandle, ((AutomationObject *)V_DISPATCH(&varg0))->msiHandle); + else + MsiViewExecute(This->msiHandle, 0); + } + break; + + case DISPID_VIEW_FETCH: + if (wFlags & DISPATCH_METHOD) + { + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiViewFetch(This->msiHandle, &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Record, RecordImpl_Invoke); + else TRACE("MsiViewFetch returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + } + break; + + case DISPID_VIEW_CLOSE: + if (wFlags & DISPATCH_METHOD) + { + MsiViewClose(This->msiHandle); + } + break; + + default: + return DISP_E_MEMBERNOTFOUND; + } + + return S_OK; +} + +HRESULT WINAPI DatabaseImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + MSIHANDLE msiHandle; + IDispatch *iDispatch = NULL; + UINT ret; + VARIANTARG varg0, varg1; + HRESULT hr; + + VariantInit(&varg0); + VariantInit(&varg1); + + switch (dispIdMember) + { + case DISPID_DATABASE_OPENVIEW: + if (wFlags & DISPATCH_METHOD) + { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_DISPATCH; + if ((ret = MsiDatabaseOpenViewW(This->msiHandle, V_BSTR(&varg0), &msiHandle)) == ERROR_SUCCESS) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_View, ViewImpl_Invoke); + else TRACE("MsiDatabaseOpenView returned %d\n", ret); + V_DISPATCH(pVarResult) = iDispatch; + } + break; + + default: + return DISP_E_MEMBERNOTFOUND; + } + + return S_OK; +} + +HRESULT WINAPI SessionImpl_Invoke( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr) +{ + WCHAR szString[MAX_MSI_STRING]; + DWORD dwLen = MAX_MSI_STRING; + IDispatch *iDispatch = NULL; + MSIHANDLE msiHandle; + LANGID langId; + UINT ret; + INSTALLSTATE iInstalled, iAction; + VARIANTARG varg0, varg1; + HRESULT hr; + + VariantInit(&varg0); + VariantInit(&varg1); + + switch (dispIdMember) + { + case DISPID_SESSION_PROPERTY: + if (wFlags & DISPATCH_PROPERTYGET) { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_BSTR; + if (MsiGetPropertyW(This->msiHandle, V_BSTR(&varg0), szString, &dwLen) == ERROR_SUCCESS) + V_BSTR(pVarResult) = SysAllocString(szString); + else + V_BSTR(pVarResult) = NULL; + } else if (wFlags & DISPATCH_PROPERTYPUT) { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + hr = DispGetParam(pDispParams, DISPID_PROPERTYPUT, VT_BSTR, &varg1, puArgErr); + if (hr != S_OK) return hr; + if ((ret = MsiSetPropertyW(This->msiHandle, V_BSTR(&varg0), V_BSTR(&varg1))) != ERROR_SUCCESS) + TRACE("MsiSetProperty returned %d\n", ret); + } + break; + + case DISPID_SESSION_LANGUAGE: + if (wFlags & DISPATCH_PROPERTYGET) { + langId = MsiGetLanguage(This->msiHandle); + V_VT(pVarResult) = VT_I4; + V_I4(pVarResult) = langId; + } + break; + + case DISPID_SESSION_MODE: + if (wFlags & DISPATCH_PROPERTYGET) { + hr = DispGetParam(pDispParams, 0, VT_I4, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_BOOL; + V_BOOL(pVarResult) = MsiGetMode(This->msiHandle, V_I4(&varg0)); + } else if (wFlags & DISPATCH_PROPERTYPUT) { + hr = DispGetParam(pDispParams, 0, VT_I4, &varg0, puArgErr); + if (hr != S_OK) return hr; + hr = DispGetParam(pDispParams, DISPID_PROPERTYPUT, VT_BOOL, &varg1, puArgErr); + if (hr != S_OK) return hr; + if ((ret = MsiSetMode(This->msiHandle, V_I4(&varg0), V_BOOL(&varg1))) != ERROR_SUCCESS) + TRACE("MsiSetMode returned %d\n", ret); + } + break; + + case DISPID_SESSION_DATABASE: + if (wFlags & DISPATCH_PROPERTYGET) { + V_VT(pVarResult) = VT_DISPATCH; + if ((msiHandle = MsiGetActiveDatabase(This->msiHandle))) + create_automation_object(msiHandle, NULL, (LPVOID)&iDispatch, &DIID_Database, DatabaseImpl_Invoke); + else TRACE("MsiGetActiveDatabase failed\n"); + V_DISPATCH(pVarResult) = iDispatch; + } + break; + + case DISPID_SESSION_FEATURECURRENTSTATE: + if (wFlags & DISPATCH_PROPERTYGET) { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&varg0), &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iInstalled; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + } + break; + + case DISPID_SESSION_FEATUREREQUESTSTATE: + if (wFlags & DISPATCH_PROPERTYGET) { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + V_VT(pVarResult) = VT_I4; + if ((ret = MsiGetFeatureStateW(This->msiHandle, V_BSTR(&varg0), &iInstalled, &iAction)) == ERROR_SUCCESS) + V_I4(pVarResult) = iAction; + else + { + TRACE("MsiGetFeatureState returned %d\n", ret); + V_I4(pVarResult) = msiInstallStateUnknown; + } + } else if (wFlags & DISPATCH_PROPERTYPUT) { + hr = DispGetParam(pDispParams, 0, VT_BSTR, &varg0, puArgErr); + if (hr != S_OK) return hr; + hr = DispGetParam(pDispParams, DISPID_PROPERTYPUT, VT_I4, &varg1, puArgErr); + if (hr != S_OK) return hr; + if ((ret = MsiSetFeatureStateW(This->msiHandle, V_BSTR(&varg0), V_I4(&varg1))) != ERROR_SUCCESS) + TRACE("MsiSetFeatureState returned %d\n", ret); + } + break; + + default: + return DISP_E_MEMBERNOTFOUND; + } + + return S_OK; +} + +/* Wrapper around create_automation_object to create a session object. */ +HRESULT create_session(MSIHANDLE msiHandle, IDispatch **pDispatch) +{ + return create_automation_object(msiHandle, NULL, (LPVOID)pDispatch, &DIID_Session, SessionImpl_Invoke); +} diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h index 971f71e..23768c0 100644 --- a/dlls/msi/msipriv.h +++ b/dlls/msi/msipriv.h @@ -788,6 +788,10 @@ extern VOID ControlEvent_SubscribeToEven extern VOID ControlEvent_UnSubscribeToEvent( MSIPACKAGE *package, LPCWSTR event, LPCWSTR control, LPCWSTR attribute ); +/* OLE automation */ +extern HRESULT create_session(MSIHANDLE msiHandle, IDispatch **pDispatch); +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); + /* User Interface messages from the actions */ extern void ui_progress(MSIPACKAGE *, int, int, int, int); extern void ui_actiondata(MSIPACKAGE *, LPCWSTR, MSIRECORD *); -- 1.4.1 From julliard at winehq.org Wed Feb 28 15:11:17 2007 From: julliard at winehq.org (Alexandre Julliard) Date: Wed Feb 28 15:11:34 2007 Subject: Unknown issue with test.winehq.org In-Reply-To: <45E5D4EB.8090702@gmail.com> (Paul Vriens's message of "Wed\, 28 Feb 2007 20\:15\:55 +0100") References: <45E5BF60.4020800@gmail.com> <45E5D4EB.8090702@gmail.com> Message-ID: <877iu2xa16.fsf@wine.dyndns.org> Paul Vriens writes: > exception: 42 tests executed (0 marked as todo, 0 failures), 0 skipped. > exception: 279 tests executed (0 marked as todo, 5 failures), 0 skipped. > > The first one triggers the 'end of this test' in dissect. The second > one is thus not accepted as dissect expects a 'start' line (and a line > in between actually). > > The question now is: should dissect handle these cases or is this > particular test-case wrong? It's because some of the tests are run in a child process. dissect should probably handle it, ideally by reporting the sum of the test counts as the results for the whole test. -- Alexandre Julliard julliard@winehq.org From hverbeet at gmail.com Wed Feb 28 15:19:42 2007 From: hverbeet at gmail.com (H. Verbeet) Date: Wed Feb 28 15:20:19 2007 Subject: [6/6] d3d9: Add a mova rounding test In-Reply-To: <87mz2y305o.fsf@wine.dyndns.org> References: <87mz2y305o.fsf@wine.dyndns.org> Message-ID: On 28/02/07, Alexandre Julliard wrote: > The test fails here: > > ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok > visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -2.400000) > visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -1.600000) > visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input -0.400000) > visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input 0.400000) > visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 1.600000) > visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 2.400000) > make: *** [visual.ok] Error 6 > Could you run that with +d3d_caps and possibly dump the value of caps.VertexShaderVersion? On a default Wine install that test should be getting skipped because our ARB shader backend doesn't support vs_2_0. From fgouget at free.fr Wed Feb 28 17:14:48 2007 From: fgouget at free.fr (Francois Gouget) Date: Wed Feb 28 17:14:58 2007 Subject: Wine's Wiki Defaced Message-ID: Someone has defaced Wine's Wiki frontpage. Also I have either forgotten my password or the user accounts don't work anymore. Could someone look into this? -- Francois Gouget http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left. From flexo at holycrap.org Wed Feb 28 17:27:16 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 28 17:19:21 2007 Subject: Using ex-user32 controls from native comctl32 6 In-Reply-To: <45E5BB4B.8020404@gmail.com> References: <45E5BB58.1070301@holycrap.org> <45E5BB4B.8020404@gmail.com> Message-ID: <45E60FD4.6080607@holycrap.org> Frank Richter wrote: >>So, any idea how Windows makes comctl32 register the user classes? > I think it just re-registered the classes, but I'm not sure. > A trace with class registrations (ie +class) might give some hint at > what native does. Okay, I was stupid. I removed registration of all the user32 classes, only some were copied over to comctl32. Anyway, it works "fine" know. Well. Actually it doesn't even initialize without some stubs but it runs. I have a native edit control in wine for the first time since 9x times eh? :) Felix From flexo at holycrap.org Wed Feb 28 17:32:16 2007 From: flexo at holycrap.org (Felix Nawothnig) Date: Wed Feb 28 17:24:19 2007 Subject: Wine's Wiki Defaced In-Reply-To: References: Message-ID: <45E61100.6010303@holycrap.org> Francois Gouget wrote: > Someone has defaced Wine's Wiki frontpage. > Also I have either forgotten my password or the user accounts don't > work anymore. Could someone look into this? Reverted it (no idea about the accounts, I was still logged in). From dank at kegel.com Wed Feb 28 17:52:29 2007 From: dank at kegel.com (Dan Kegel) Date: Wed Feb 28 17:52:44 2007 Subject: One school's list of must-have apps Message-ID: Here's a school that actually did transition to Linux: http://searchopensource.techtarget.com/originalContent/0,289142,sid39_gci1245710,00.html They didn't use Wine. Here's what they said about legacy windows apps: "Using Wyse terminals, the district also planned to offer students and staff thin-client desktops running OpenOffice.org. Ericom software ? a Citrix alternative -- enabled the terminals to run the district's existing and irreplaceable Microsoft Windows educational applications, including Type to Learn, Reading Counts and Kid Pix." - Dan From ivg231 at gmail.com Wed Feb 28 19:59:41 2007 From: ivg231 at gmail.com (Ivan Gyurdiev) Date: Wed Feb 28 19:54:54 2007 Subject: [2/6] winex11.drv: Try to get an opengl visual with aux buffers In-Reply-To: <200703010147.53942.stefan@codeweavers.com> References: <200703010147.53942.stefan@codeweavers.com> Message-ID: <45E6338D.8090204@gmail.com> Something's wrong with this patch: it has more 2 nested if statements. I suggest early returns on negated condition, gotos, and subroutines to fix the problem :) > I don't know if that patch wasn't applied because other patches of my patchset > weren't applied, or because something is wrong with this patch. If something > is wrong with this patch please tell me > > ------------------------------------------------------------------------ > > From 029e9756abed6c2647950f86e9227ba47d366ebe Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger > Date: Tue, 27 Feb 2007 15:53:43 +0100 > Subject: [PATCH] winex11.drv: Try to get an opengl visual with aux buffers > > Applications may profit from auxilliary buffers. Because we have to find > the visual at initialization time try to find a visual with aux buffers > first, if none is found fall back to the usual default visual without > aux buffers > --- > dlls/winex11.drv/opengl.c | 35 +++++++++++++++++++++++------------ > 1 files changed, 23 insertions(+), 12 deletions(-) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index fdb92ae..9c1060a 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -3083,33 +3083,44 @@ BOOL X11DRV_SwapBuffers(X11DRV_PDEVICE *physDev) > XVisualInfo *X11DRV_setup_opengl_visual( Display *display ) > { > XVisualInfo *visual = NULL; > - /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, */ > - int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, > + * WineD3D and Some applications can make use of aux buffers > + */ > + int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_AUX_BUFFERS, 1, GLX_DOUBLEBUFFER, None}; > if (!has_opengl()) return NULL; > > wine_tsx11_lock(); > visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* fallback to 16 bits depth, no alpha */ > - int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; > - WARN("Failed to get a visual with at least 24 bits depth\n"); > + /* Try without aux buffers */ > + int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least one aux buffer\n"); > > wine_tsx11_lock(); > visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf2); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* fallback to no stencil */ > - int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None}; > - WARN("Failed to get a visual with at least 8 bits of stencil\n"); > + /* fallback to 16 bits depth, no alpha */ > + int dblBuf3[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least 24 bits depth\n"); > > wine_tsx11_lock(); > - visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf2); > + visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf3); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* This should only happen if we cannot find a match with a depth size 16 */ > - FIXME("Failed to find a suitable visual\n"); > - return visual; > + /* fallback to no stencil */ > + int dblBuf4[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least 8 bits of stencil\n"); > + > + wine_tsx11_lock(); > + visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf4); > + wine_tsx11_unlock(); > + if (visual == NULL) { > + /* This should only happen if we cannot find a match with a depth size 16 */ > + FIXME("Failed to find a suitable visual\n"); > + return visual; > + } > } > } > } > > ------------------------------------------------------------------------ > > > From dmitry at codeweavers.com Wed Feb 28 22:53:36 2007 From: dmitry at codeweavers.com (Dmitry Timoshkov) Date: Wed Feb 28 22:53:41 2007 Subject: kernel32: Remove server-call from ExitThread() References: <45E5D583.6040508@holycrap.org> Message-ID: <014401c75bbd$99e7cb80$0100a8c0@DMITRY> "Felix Nawothnig" wrote: > - if (last) > - { > - LdrShutdownProcess(); > - exit( code ); > - } > - else RtlExitUserThread( code ); > + TerminateThread( GetCurrentThread(), code ); > + exit(code); /* To avoid a compiler warning, never reached. */ > } New code now calls exit() unconditionally killing the whole process. If you follow the TerminateThread way you will notice that exit() is being already called on its time. -- Dmitry. From wine-devel at kievinfo.com Wed Feb 28 23:50:55 2007 From: wine-devel at kievinfo.com (Vitaliy Margolen) Date: Wed Feb 28 23:51:29 2007 Subject: ntdll: Some code cleanup Message-ID: <45E669BF.9000306@kievinfo.com> Felix Nawothnig wrote: > - if (last) > - { > - LdrShutdownProcess(); > - exit( exit_code ); > - } > - else > - { > - LdrShutdownThread(); > - server_exit_thread( exit_code ); > - } > + NtTerminateThread( GetCurrentThread(), func( arg ) ); > + exit(0); /* To avoid a compiler warning, never reached. */ server_exit_thread() and NtTerminateThread() (which calls server_abort_thread()) are not the same things! Former gracefully exits the current thread freeing it's memory. Later rips it out from the process without freeing any resources. Needless to say you can't do that. Vitaliy.