January 2002 - Wine-Devel - list.winehq.org

Re: Microsoft's version of "WINE"

by Srdjan Matovina -- Customer Engineering

They use MainWin from MainSoft Inc. See http://www.mainsoft.com >To: wine-devel(a)winehq.com >From: "Sander Wichers" <wichers(a)usa.net> >Subject: Microsoft's version of "WINE" >X-Priority: 3 >X-MSMail-Priority: Normal >X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 >X-BeenThere: wine-devel(a)winehq.com >X-Mailman-Version: 2.0 >List-Help: <mailto:wine-devel-request(a)winehq.com?subject=help> >List-Post: <mailto:wine-devel(a)winehq.com> >List-Subscribe: <http://www.winehq.com/mailman/listinfo/wine-devel>, <mailto:wine-devel-request(a)winehq.com?subject=subscribe> >List-Id: Wine Developer's List <wine-devel.winehq.com> >List-Unsubscribe: <http://www.winehq.com/mailman/listinfo/wine-devel>, <mailto:wine-devel-request(a)winehq.com?subject=unsubscribe> >List-Archive: <http://www.winehq.com/hypermail/wine-devel/> >Date: Wed, 23 Jan 2002 16:20:35 +0100 > >Hi, > >Maybe you guys already seen this, and it's old news for you... but i'll post >this anyway in case you didn't know. It can be a good thing to learn from. > >I do not own a SUN or a HP-UX system. But I was just interested how >microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their >installation files to disk. It seems that microsoft made their own version >of wine. It's amazing that they didn't modified IE to run on unix. Instead >they made the choice to emulate all the windows functionality. And compile >IE on that. Microsoft is ready to run their applications on linux. They have >a complete "system" libary full of ported functionality to SUN and HP-UX... >all the libaries are there, libkernel32.so etc.... It's also nice to see how >they seperated the resources from the binaries. and let the kernel deal with >these resource files. > >Has any one of you looked into these system libaries? Is this information >relevant to anyone? > >bye, > >Sander Wichers > > > > > > ==== Srdjan Matovina Sun Microsystems Inc. SunPS Integration Services/ Americas Customer Engineering srdjan.matovina(a)sun.com Ph.(905) 415-2883 Fax.(905) 477-0217

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Sorry, maybe I miss something, but I don't understand why it wouldn't: > > BOOL WINAPI CopyFileA(LPCSTR,LPCSTR,BOOL); > BOOL WINAPI CopyFileW(LPCWSTR,LPCWSTR,BOOL); > #define CopyFile WINELIB_NAME_AW(CopyFile) > > which means that if we use the explicit A or W versions, it will compile > no matter what mode we're using. Sure, in isolation it will work, but try integrating that in a test using TCHARs. For instance: TSTR filename = _T("some_file"); handle = CreateFile(filename,...); WriteFile( handle, ...); etc. CopyFile( filename, _T("newfile"), FALSE ); /* now test some Unicode chars */ CopyFileW( filename, L"unicode_file_name", FALSE ); This won't work because you can't pass a TSTR to a W function. So you either need #ifdefs, or you need to use W functions and WCHAR throughout, which means you don't need TCHAR at all. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > I prefer all tests to succeed on all MS platforms. The > goal of the tests is to document Windows behavior and > by definition they should not fail on Windows. By definition they won't fail, if they do your test is broken. If calling some function on Win95 returns ERROR_CALL_NOT_IMPLEMENTED, the right thing is not to avoid calling the function, it's to call it and check for this error code. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Wed, 23 Jan 2002, Alexandre Julliard wrote: > In your version you need the #ifdefs, maybe not in this simple example > but in general as soon as you mix TCHAR and WCHAR, because otherwise > it won't compile in ASCII mode. Sorry, maybe I miss something, but I don't understand why it wouldn't: BOOL WINAPI CopyFileA(LPCSTR,LPCSTR,BOOL); BOOL WINAPI CopyFileW(LPCWSTR,LPCWSTR,BOOL); #define CopyFile WINELIB_NAME_AW(CopyFile) which means that if we use the explicit A or W versions, it will compile no matter what mode we're using. -- Dimi.

Jan. 23, 2002

Re: wine/windows dialog.c

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > for the encarta 99 setup this gives the same bad result as before. I have > attached a gif of the dialog in question. > > The manual calculation with the corrections in my resent patch gave better > results. But we shouldn't need to compute the average width again since this is done by the font driver. If that calculation is wrong it needs to be fixed, not bypassed. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Tue, 22 Jan 2002, Alexandre Julliard wrote: > Absolutely; but this has nothing to do with TCHAR at all, we need a > convenient way to specify Unicode strings in any case. Indeed, the two issues are orthogonal. Since my Linux box is down for a few days now, here is some untested code trying to implement the teststr() idea. wine/tests.h: /*-----------------------------------------------------------*/ /* The teststr() function iterates through a set of strings */ /* with a certain set of characteristics. When the set is */ /* exausted, it returns NULL. The sets are identified by a */ /* constants defined later in the header, with the prefix */ /* TSC_. Typical usage of the function is as follows: */ /* TCSTR tstr = TSC_XXX; */ /* while ( tstr = teststr(tstr) ) */ /* <code which uses tstr> */ /* Simply replate T with A/W for encoding specific code. */ /*-----------------------------------------------------------*/ LPCWSTR teststrW(LPCWSTR wstr); LPCSTR teststrA(LPCSTR astr); /* the TESTSTR.class field defines the class of strings */ /* in the future, we can have a union which holds additional */ /* parameters for the given class of strings. */ typedef struct tagTESTSTRW { int class; LPCWSTR str; } TESTSTRW, *LPTESTSTRW; typedef struct tagTESTSTRA { int class; LPCSTR str; } TESTSTRA, *LPTESTSTRA; #define _TSCT(cls, strtype, t) \ extern TESTSTR##t tsc_##cls##t; \ LPC##strtype const TSC_##cls##t = &(tsc_##cls##t.str) #define _TSC(cls) \ _TSCT(cls, WSTR, W); \ _TSCT(cls, STR, A) #define STR2TESTSTR(str) (LPTESTSTR)( ((void*)str) - \ ((void*)&tsc_ANYA.str) - ((void*)&tsc_ANYA) ) /* constants defining the test string sets #define TSC_ANY _TSC(ANY) #define TSC_XXX ..... teststr.c: #define BEGINA (LPCSTR)(-1) #define BEGINW (LPCWSTR)(-1) TESTSTRA tsc_ANYA = { 0, BEGINA }; TESTSTRW tsc_ANYW = { 0, BEGINW }; .... LPCSTR teststrA(LPCSTR str) { LPTESTSTR tstr = STR2TESTSTR(str); if (tstr.str == BEGINA) ... <here we can do a lot of things> } <similarly for teststrW> Now, should I go more into the details of the implementation? Is everyone convinced that the interface is (1) simple, (2) useful, (3) implementable? -- Dimi.

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Alexandre, you forgot conditional in your test example > and mentioned in mine ;-) With your permission I > rewrite your test: > > fooA("abc") > #ifdef UNICODE > fooW(L"some unicode chars here") > #endif No I didn't forget anything. There cannot be a #ifdef UNICODE in my version because we won't compile things twice, and UNICODE will never be defined, just like it's not defined when building Wine. In your version you need the #ifdefs, maybe not in this simple example but in general as soon as you mix TCHAR and WCHAR, because otherwise it won't compile in ASCII mode. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > > IMO unicode tests should be executed > > unconditionally, they just should > > be marked as "expected to fail". > > I prefer all tests to succeed on all MS platforms. The > goal of the tests is to document Windows behavior and > by definition they should not fail on Windows. In that case you are going to test only very small subset of win32 API. > Unicode tests, failing on Win95 may, or may not > succeed in other Win32 API implementations working in > win95 mode. There are no "Win32 API implementations working in win95 mode". At all. > This does not matter for these > implementations. You'll have some Unicode tests which > fail under Wine, others which succeed under Wine. We > are not going to change Wine because of this, but will > have to mark them differently, like > FAIL_MS_UNICODE(FAIL_WINE_UNICODE(test)). Now add to > this mess ODIN Unicode failed tests. > > Besides, it is more convenient to find out conditional > one time and go through block of tests than think > about each test conditional. It's more convenient IMO to not bother to limit ourself by any borders at all. Just do run all available tests and analyze the results. If something fails, find out why, and if needed mark it as "expected to fail". > > If you are going to > > conditionally run > > unicode tests, you eventually will come to a > > conclusion to conditionally > > run too much tests (native APIs, etc.) > > Yes, we document a few Windows platforms together and > conditionals indicate differences between them. This > is not my fault they are so different :-) I said it before: there is no different windows platforms from the Wine point of view. > Could you explain the problem of "conditionally > running too much tests"? What is bad about it? Same comment as above. There is no code branches in the Wine code if(win95) do something else if(nt40) do something else else do something else Conditional tests should not exist either. If tomorrow microsoft will invent "yet another win32 platform" are you going to add new conditional test suit? -- Dmitry.

Jan. 23, 2002

Microsoft's version of "WINE"

by Sander Wichers

Hi, Maybe you guys already seen this, and it's old news for you... but i'll post this anyway in case you didn't know. It can be a good thing to learn from. I do not own a SUN or a HP-UX system. But I was just interested how microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their installation files to disk. It seems that microsoft made their own version of wine. It's amazing that they didn't modified IE to run on unix. Instead they made the choice to emulate all the windows functionality. And compile IE on that. Microsoft is ready to run their applications on linux. They have a complete "system" libary full of ported functionality to SUN and HP-UX... all the libaries are there, libkernel32.so etc.... It's also nice to see how they seperated the resources from the binaries. and let the kernel deal with these resource files. Has any one of you looked into these system libaries? Is this information relevant to anyone? bye, Sander Wichers

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > IMO unicode tests should be executed > unconditionally, they just should > be marked as "expected to fail". I prefer all tests to succeed on all MS platforms. The goal of the tests is to document Windows behavior and by definition they should not fail on Windows. Unicode tests, failing on Win95 may, or may not succeed in other Win32 API implementations working in win95 mode. This does not matter for these implementations. You'll have some Unicode tests which fail under Wine, others which succeed under Wine. We are not going to change Wine because of this, but will have to mark them differently, like FAIL_MS_UNICODE(FAIL_WINE_UNICODE(test)). Now add to this mess ODIN Unicode failed tests. Besides, it is more convenient to find out conditional one time and go through block of tests than think about each test conditional. > If you are going to > conditionally run > unicode tests, you eventually will come to a > conclusion to conditionally > run too much tests (native APIs, etc.) Yes, we document a few Windows platforms together and conditionals indicate differences between them. This is not my fault they are so different :-) Could you explain the problem of "conditionally running too much tests"? What is bad about it? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > If your test does: > > foo(_T("abc")) > > it essentially does: > > fooA("abc") > fooW(L"abc") > > but in most cases since fooA converts the string and > calls fooW > already you are not really testing anything more > than by simply > calling fooA. This doesn't mean that you shouldn't > test fooW at all, > but the interesting thing to do is to test fooW with > Unicode input. So > you should do something like: > > fooA("abc") > fooW(L"some unicode chars here") > > Now with your solution: > > foo(_T("abc")) > #ifdef UNICODE > fooW(L"some unicode chars here") > #endif > > the test is more complex to write, it takes twice as > long to compile > and run, and it doesn't test more than my version. Alexandre, you forgot conditional in your test example and mentioned in mine ;-) With your permission I rewrite your test: fooA("abc") #ifdef UNICODE fooW(L"some unicode chars here") #endif The only differences are that with TCHAR version I have additional fooW(L"abc") test and have to use different names. Having at least simple test for Unicode API is better than having nothing at all. I don't see how using TCHAR will prevent you from writing Unicode-specific tests. > You will never test interesting combinations like > CreateEventA/OpenEventW > because it's a big pain to write. Exactly the same for your tests. See above. > > Using TCHAR insures that A and W functions have > the > > same behaviour. > > Why you are against using the same code for this > and > > using encoding-specific code to check the > differences? > > Because it makes writing a small subset of tests > slightly easier at > the cost of making the really interesting tests much > more painful to > write. Not a good trade-off. IMHO we don't have this issue. As you agreed we have advantages with simple boring tests, but complexity writing "really interesting tests" is exactly the same. However, I agree that we have different tradoff with TCHAR - more complex build process, but this is not such a big problem. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > There was a few objections to have ugly conditionals > for Unicode-specific tests, like > #ifdef _UNICODE > ... unicode-specific tests ... > #endif > > This problem can be resolved by using instead function > or macro as Unicode indicator. Value of this indicator > will be defined, basing on presence of _UNICODE macro. > > Now we'll have better-looking check, like: > if (TEST_UNICODE) > { > ... unicode-specific tests ... > } IMO unicode tests should be executed unconditionally, they just should be marked as "expected to fail". If you are going to conditionally run unicode tests, you eventually will come to a conclusion to conditionally run too much tests (native APIs, etc.) -- Dmitry.

Jan. 23, 2002

Beautifying of Unicode mode check in tests

by Andriy Palamarchuk

There was a few objections to have ugly conditionals for Unicode-specific tests, like #ifdef _UNICODE ... unicode-specific tests ... #endif This problem can be resolved by using instead function or macro as Unicode indicator. Value of this indicator will be defined, basing on presence of _UNICODE macro. Now we'll have better-looking check, like: if (TEST_UNICODE) { ... unicode-specific tests ... } Hope now we'll have one less thing to argue about ;-) Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002

Re: Verbose tests ?

by Andriy Palamarchuk

--- Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: > running programs/winetest/runtest -v -v -v -v -v > tests/wine.pl > or programs/winetest/runtest -vvvvv only reports : > > tests/wine.pl: 22 tests executed, 2 marked as todo, > 0 > failures. > > Is this the normal behavior or have I made something > wrong ? Yes, this is normal behavior. Nobody bothered to add reports for higher verbosity levels. The test report has all the information I need, but you are welcome to suggest improvements. Thank you, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002

Re: wine/windows dialog.c

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ChangeSet ID: 1011730184150795614346862 CVSROOT: Alexandre> /opt/cvs-commit Module name: wine Changes by: Alexandre> julliard(a)wine2. 02/01/22 15:09:44 Alexandre> Modified files: windows : dialog.c Alexandre> Log message: Removed no longer used average width Alexandre> calculation. Well, for the encarta 99 setup this gives the same bad result as before. I have attached a gif of the dialog in question. The manual calculation with the corrections in my resent patch gave better results. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 23, 2002

Verbose tests ?

by Sylvain Petreolle

Hi, running programs/winetest/runtest -v -v -v -v -v tests/wine.pl or programs/winetest/runtest -vvvvv only reports : tests/wine.pl: 22 tests executed, 2 marked as todo, 0 failures. Is this the normal behavior or have I made something wrong ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > This is why we _need_ to abstract constant strings out of the tests with > something like the teststr() function I was advocating. This is the only > way to get things like surrogates, etc. reliably used in tests. Absolutely; but this has nothing to do with TCHAR at all, we need a convenient way to specify Unicode strings in any case. And it's easier to do if you don't have to mess with TCHAR at the same time, you can simply provide a bunch of Unicode constants. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002

Re: C++ Winelib problems

by Alexandre Julliard

"Peter Hunnisett" <peter(a)transgaming.com> writes: > I've attached a patch which removes the recursive dep search from > MODULE_DllProcessAttach and moves MODULE_DllProcessAttach from LoadLibraryExA > into MODULE_LoadLibraryExA. Does this seem like a reasonable approach to take? > Any problems with the patch? I think the current order is correct, and it needs to be done this way because of circular dependencies. The problem is that you need to delay calling constructors until the DLL entry point is called. This probably requires some compiler/linker magic. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002

Re: Open Letter to DOJ re Microsoft Settlement

by Dan Kegel

Bernhard Rosenkraenzer wrote: > > On Tue, 22 Jan 2002, Dan Kegel wrote: > > > I've drafted an open letter to the Department of Justice to explain why > > the proposed settlement should not be accepted; it's at > > http://www.kegel.com/remedy/letter.html > > Just read it - I like it, but IMO it's missing a couple of important > points: > > * Opening the APIs and some file formats will not help at all if they are > protected by restrictive patents. It is vital that Microsoft must be > prevented from using those patents against potential competitors. > This applies in particular to the "ASF" format Microsoft is pushing as > a standard format for video distribution, but preventing anyone else > from using through patent #6,041,345. The proposed settlement does provide for some access to patents on a 'reasonable and non-discriminatory basis'. The States' proposal goes further, and proposes a 'royalty-free' basis. I regret that I have not yet had time to dig into this interesting issue. I encourage individuals to mention it in their own notes to the DOJ, though. > * Microsoft uses OEM deals that prevent OEMs from shipping computers > pre-loaded with a "dual boot" configuration that would allow users to > use both Windows and a competing operating system, such as Linux. The proposed settlement actually does prohibit that particular practice, so I didn't need to cover it. (I did cover the related one of discriminating against OEMs who ship *non-windows* computers, though.) > If you think having a non-US citizen signing the letter, feel free to add > me (Software Developer, Red Hat, Inc.). I don't think it would carry any weight in this case, but thanks, otherwise I'd love to! Maybe you could discuss this with your coworkers in the US, though. - Dan

Jan. 22, 2002

Re: Open Letter to DOJ re Microsoft Settlement

by Bernhard Rosenkraenzer

On Tue, 22 Jan 2002, Dan Kegel wrote: > I've drafted an open letter to the Department of Justice to explain why > the proposed settlement should not be accepted; it's at > http://www.kegel.com/remedy/letter.html Just read it - I like it, but IMO it's missing a couple of important points: * Opening the APIs and some file formats will not help at all if they are protected by restrictive patents. It is vital that Microsoft must be prevented from using those patents against potential competitors. This applies in particular to the "ASF" format Microsoft is pushing as a standard format for video distribution, but preventing anyone else from using through patent #6,041,345. * Microsoft uses OEM deals that prevent OEMs from shipping computers pre-loaded with a "dual boot" configuration that would allow users to use both Windows and a competing operating system, such as Linux. If you think having a non-US citizen signing the letter, feel free to add me (Software Developer, Red Hat, Inc.). LLaP bero -- This message is provided to you under the terms outlined at http://www.bero.org/terms.html

Jan. 22, 2002

Open Letter to DOJ re Microsoft Settlement

by Dan Kegel

The proposed settlement in the Microsoft antitrust trial will probably be accepted by the judge unless a lot of people complain soon, even though it lacks any useful enforcement provisions and fails to prohibit many of Microsoft's anticompetitive practices. I've drafted an open letter to the Department of Justice to explain why the proposed settlement should not be accepted; it's at http://www.kegel.com/remedy/letter.html I'd be honored if you would read it, and consider signing it with me, or submitting your own comment to the DOJ. Either way, the federal deadline for public comment is Monday the 28th. For more information, see http://www.kegel.com/remedy/ See also Jeremy White's page http://www.codeweavers.com/~jwhite/tunney.html Sincerely, Dan Kegel

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Tue, 22 Jan 2002, Alexandre Julliard wrote: > but the interesting thing to do is to test fooW with Unicode input. So > you should do something like: > > fooA("abc") > fooW(L"some unicode chars here") But notice that this is a problem independent of wether or not we write the tests encoding independent. Even if we go with you version writen above, is still not gonna work because people will not write "interesting" Unicode strings. Period. If I was to write a test now, I have no idea how to write non-pseudo-ASCII Unicode strings anyway. This is why we _need_ to abstract constant strings out of the tests with something like the teststr() function I was advocating. This is the only way to get things like surrogates, etc. reliably used in tests. The only hardcoded strings that can reside in tests are set-in-stone paths in the registry (or what have) which we might as well code using the (ugly) _T macro, but these should be just a minority of cases anyway. -- Dimi.

Jan. 22, 2002

Re: sparc solaris build

by Hetz Ben Hamo

Hi Srdjan, Few weeks ago I asked for a friend of mine which wanted to do exactly what you're trying to do - so I suggest you browse the archive to read those old emails.. Also, could you (when you're reaching some milestone in this port) give back the diffs please? or is this a closed source project? I know lots of people who got those blade machines who would love to run Wine. Thanks, Hetz On Tuesday 22 January 2002 21:54, Srdjan Matovina -- Customer Engineering wrote: > Hi, > > I've built wine-20011226 on sparc with the only one issue left open: > > The resource compiler wrc core dumps when hit the bitmap (BINRES) part of > .rc file. > There is an alignment problem inside convert_bitmap() in newstruc.c file. > The alignment problem came out from BITMAPINFOHEADER struct. > > But this was just the beginning! > > I've commented out body of convert_bitmap() just to see what will happen > when run libtest/hello test case. After running wineserver, the > libtest/hello core with the same problem: Program terminated by signal BUS > (invalid address alignment). This time at different place: > RtlSecondsSince1970ToTime from ntdll.so (time.c) struct FILETIME. > > Obviously I'll have an alignment problem with every structure in general. > > Is there any guideline for this kind of problem? > > Thanks Srdjan

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Tue, 22 Jan 2002, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > > > With all due respect Alexandre, I can't understand your point. When does > > the _semantics_ of the function differ based on the string > > encoding??? > > Functions that take strings usually do something with them, so this is > part of the function semantics, and it differs between ASCII and > Unicode. A fundamental part of that is making sure that all characters > are preserved correctly (no W->A->W round-trip) and it's precisely the > thing that will never get tested with the TCHAR stuff. And this is precisly where I can not understand you. When we test stuff, we need to worry mainly about 2 things: 1. function semantics 2. W->A->W conversions, etc (1) devides nicely into 1.A functions which don't care much about what the string is, it just gets passed around -- this case would benefit from TCHAR 1.B functions which deal with characters (length, possitions, etc) -- these are defined in terms of characters, so again TCHAR is OK That is, TCHAR is beneficial in testing the semantics of the function, save a few freak cases. (2) is orthogonal to (1) Now it seems that you consider that having encoding-independent tests would completely miss this case, where as I find myself at the exactly opposite end. Truth be told, I am not 100% in the "TCHAR" camp either. I need to see some code to be convinced either way, as you probably do too. So let me produce some code so that we can argue on something more concrete. That being told, I am truely interested to understand your reasoning. From previous experience, you have solid reasons for arguing something, and given that I fail completely to see your side of the story, I must miss something rather important. > If all you want is to call the function with some random string, then > you don't really need to call both A and W since they usually use the > same code anyway. But then we would have failed to test the (very important) W->A->W aspect, and it seems you contradict your previous statement... -- Dimi.

Jan. 22, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Alexandre, one time you were saying than W and A > functions can't be tested by the same code because > they are completely different. > Now you are saying that we don't need to test W > function because they are no more than conversion to > ASCII, calling A function, converting results back to > Unicode and it is sufficient to test A function and > check the conversions. No, I'm not saying this is what we should do, I'm saying this is what you are doing with your TCHAR stuff. If your test does: foo(_T("abc")) it essentially does: fooA("abc") fooW(L"abc") but in most cases since fooA converts the string and calls fooW already you are not really testing anything more than by simply calling fooA. This doesn't mean that you shouldn't test fooW at all, but the interesting thing to do is to test fooW with Unicode input. So you should do something like: fooA("abc") fooW(L"some unicode chars here") Now with your solution: foo(_T("abc")) #ifdef UNICODE fooW(L"some unicode chars here") #endif the test is more complex to write, it takes twice as long to compile and run, and it doesn't test more than my version. And this doesn't even get into testing behavior with mixed A/W calls. To take a random example, to test CreateEvent you'll want to use OpenEvent to verify that the event was created. With TCHAR all you will ever test is that OpenEventA finds an event created by CreateEventA, and OpenEventW finds one created by CreateEventW. You will never test interesting combinations like CreateEventA/OpenEventW because it's a big pain to write. > Using TCHAR insures that A and W functions have the > same behaviour. > Why you are against using the same code for this and > using encoding-specific code to check the differences? Because it makes writing a small subset of tests slightly easier at the cost of making the really interesting tests much more painful to write. Not a good trade-off. -- Alexandre Julliard julliard(a)winehq.com

Jan. 22, 2002