EA Durbin wrote: Your patch caused the regression tests to fail, and Hans' did not. err:msi:msi_get_dialog_record query failed for dialog L"boo" fixme:msi:ACTION_PerformUIAction unhandled msi action L"boo" package.c:618: Test failed: wrong return val make[1]: *** [package.ok] Error 1 You seem to have a different theory of what's causing the failure every day. I'm somewhat disappointed that you refuse to write a regression test to show what you've found. It would give me confidence in what your analysis of the problem, assist me in fixing the problem, and prevent it from happening again. Mike

EA Durbin wrote: I haven't seen any patch for the Wine regression test suite as yet, and that is what I have been asking you to write. You patch is wrong because the value you are printing is an INT, so using %d is correct, and using %u will print the wrong thing when the INT is less than zero. Mike

Why would you add all your findings and "test cases" into the Wine's test suite? Until then you should stop flaming list. With all the energy you spent writing these e-mails BACKWARDS as I might add. And you outright IGNORED my suggestions on the IRC chat room. So until you show us some code that verifies what you are talking about, please stay away from the e-mail clinet. Vitaliy. Monday, June 5, 2006, 10:05:39 AM, EA Durbin wrote:

Monday, June 5, 2006, 11:02:38 AM, EA Durbin wrote: Both of those depend on the type and not on what it "should be". And the type is INT it's a "signed int". Vitaliy. PS: PLEASE PLEASE PLEASE ADD YOU COMMENTS BELOW THIS LINE NOT ABOVE. IT'S IMPOSSIBLE TO READ.

Am Montag, den 05.06.2006, 14:01 -0500 schrieb EA Durbin: Welcome to the World of Microsoft. Another Example from MS: A Function is declared to return a BOOL and documented to return '0', '1' or '2' We are Compatible, so our Declaration is also a BOOL. -- By By ... ... Detlef

Can you 100% guarantee that documentation is correct? And that there are no broken apps that will try to pass negative number? Vitaliy. Okay, i guess I see your point, but if the broken app passes a negative number its not going to work correctly anyway, as it will read from the wrong Disk medium when it encounters the query, once that works correctly.

Just because billions of flies eat sh*t every day, so should we all do too? But seriously, does top posting make sense to you?! If you're replying to something, you either thread it into the discussion, editing and amending the cited context as appropriate, or you simply make everyone's life miserable. Try reading one of your posts, from later into the discussion where there's a lot of context. Do it in a few months -- you'll see what I mean. You'll have to read them backwards *yourself*, just in order to understand what it was all about. Cheers, Kuba

I've decided to concentrate my efforts in another area, so I won't be looking at msi any longer. I admit I 'm no C expert, I'm a web developer by trade. Though I started to look at the C code to get away from php/perl/ruby and get aquainted with the language in my leisure time, I need no assitance with web development. As I would still like to contribute to the wine project I will be focusing my efforts on Appdb and Bugzilla. But thanks for understanding my intentions Mike.

EA Durbin wrote: Unfortunately your lack of understanding of C lets you down here. Mike

Okay what am i misunderstanding?, explain it to me as its imperative I learn, and I'd love to learn. %u is an unsigned integer which is 0 to +32,767. %i is a signed integer –32,767 to +32,767. If the sequence number is always going to be a positive number why should we allot it the extra 32,767 value range?

EA Durbin wrote: "A signed int can hold all the values between *INT_MIN* and *INT_MAX* inclusive. *INT_MIN* is required to be -32767 or less, *INT_MAX* must be at least 32767. Again, many 2's complement implementations will define *INT_MIN* to be -32768 but this is not required. An unsigned int can hold all the values between 0 and *UINT_MAX * inclusive. *UINT_MAX* must be at least 65535. The int types must contain *at least* 16 bits to hold the required range of values. *NOTE:* /The required ranges for signed and unsigned int are identical to those for signed and unsigned short. On compilers for 8 and 16 bit processors (including Intel x86 processors executing in 16 bit mode, such as under MS-DOS), an int is usually 16 bits and has exactly the same representation as a short. On compilers for 32 bit and larger processors (including Intel x86 processors executing in 32 bit mode, such as Win32 or Linux) an int is usually 32 bits long and has exactly the same representation as a long."/ AFAIK, all signed and unsigned versions of the same type actually use the same number of bits, it's just that by using one of those bits as the 'sign' bit, the signed version seems to only be able to hold values half as big as the unsigned version (in fact, they're both capable of storing the same number of unique values, it's just that for the signed version half of the 65535 values are below zero). As a tip to remember this, consider for example an unsigned char. A char is just a byte, which is the smallest unit of memory most computers can address. An 'unsigned' char wouldn't yield any space savings because the minimum you can allocate at once is a byte anyway (in fact on most modern systems much larger than that, a page, but C is abstracted away from that). So unsigned/signed types must take up the same amount of memory. (we could concoct our own language where unsigned ints are actually shorts, but we'd be going out of our way)