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

RE: Excessive clipping of text in listview

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Medland, Bill wrote: > p.s. what is going on in DrawLargeItem with the ellipsification; it looks > like it ellipsifies it and then throws the result away. Bill, Can you try the attached (uncompiled, untested) patch? It simplifies the code quite a bit IMO. BTW, the previous code did not throw away the ellipsification since szDispText == lvItem.pszText. -- Dimi.

Jan. 25, 2002

RE: Excessive clipping of text in listview

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Medland, Bill wrote: > Do you have access to the Microsoft "rowlist" sample? If so then use that No, I don't. Can you send me a copy, or point me to a place where I can get it from? > but edit a couple of the labels to be longer than one line. It's the "being > longer than one line" that messes it up. Aha! That's a good tip -- I'll check it out soon, but right now I'm at work, and I don't have any Wine-related things around :) > Thanks for the rapid response No problem -- sorry for the screw up :) > p.s. what is going on in DrawLargeItem with the ellipsification; it looks > like it ellipsifies it and then throws the result away. No wonder -- that's the most obscure part of the code, and I had the most problems with debugging the thing... > I am currently working on DrawText which should provide everything needed to > draw the text properly. I am feeding it to Alexandre in small pieces so > that we don't break anything. Microsoft, as far as I can see, don't > actually use DrawText; they appear to reimplement all the ellipsification > but I don't see why. Cool. Given your knowladge of DrawText, should I just drop the ellipsification and simply let DrawText do it? -- Dimi.

Jan. 25, 2002

RE: Excessive clipping of text in listview

by Medland, Bill

Panic over; the 20020101 version will do for now. > -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi(a)cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. > > > -- > Dimi. >

Jan. 25, 2002

RE: Excessive clipping of text in listview

by Medland, Bill

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi(a)cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> I know the feeling. (not surprising given the size of the delta; you ought to see what my last big one would have screwed up). > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? ANSI Do you have access to the Microsoft "rowlist" sample? If so then use that but edit a couple of the labels to be longer than one line. It's the "being longer than one line" that messes it up. > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. It did work on 1/jan so it was probably your delta. > > > -- > Dimi. > Thanks for the rapid response Bill p.s. what is going on in DrawLargeItem with the ellipsification; it looks like it ellipsifies it and then throws the result away. I am currently working on DrawText which should provide everything needed to draw the text properly. I am feeding it to Alexandre in small pieces so that we don't break anything. Microsoft, as far as I can see, don't actually use DrawText; they appear to reimplement all the ellipsification but I don't see why.

Jan. 25, 2002

Re: Excessive clipping of text in listview

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Bill Medland wrote: > Does anyone know how we (again) broke the text in the large icon display of > listview? It seems to come and go as we develop. <blush>I probably broke it</blush> > The symptom. Our application has a ListView window. As of yesterday's cvs > most of the text only displays about 2 or 3 pixels wide, while a few are > readable. Are you using Unicode or ANSI? Can I get access to the code to test with? > I am just backtracking but I'm in a rush (I have to put together > a demo machine by yesterday) and I'd like to know how far back to go. Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. -- Dimi.

Jan. 25, 2002

Excessive clipping of text in listview

by Bill Medland

Does anyone know how we (again) broke the text in the large icon display of listview? It seems to come and go as we develop. The symptom. Our application has a ListView window. As of yesterday's cvs most of the text only displays about 2 or 3 pixels wide, while a few are readable. I am just backtracking but I'm in a rush (I have to put together a demo machine by yesterday) and I'd like to know how far back to go. Bill

Jan. 25, 2002

Re: Patch to improve Microsoft Office 2000 functionality

by Duane Clark

Dimitrie O. Paun wrote: > On Fri, 25 Jan 2002, Duane Clark wrote: > > >>That would be fine. It looked like a few pieces of the listview code >>might still be needed, but definitely most of it is duplicated by the >>recent changes. >> > > Indeed -- I glanced over the patch myself, and it seems some things do > still apply. At the moment I am working on the Common Controls > (dlls/comctl32), so you can just forward me all the dlls/comctl32/* > chunks if you want. So, I have to know: > 1. Do you want me to deal with dlls/comctl32? > 2. If so, should I extract the relevant parts, or are you gonna send them > to me when you disect the patch? You are welcome to the comctl32 stuff. It looks like their is plenty more to keep me occupied:-) I only got as far as the listview so far, so I really don't have the other parts split out yet. It will probably be just as easy to let you do that.

Jan. 25, 2002

Re: Patch to improve Microsoft Office 2000 functionality

by Dimitrie O. Paun

On Fri, 25 Jan 2002, Duane Clark wrote: > That would be fine. It looked like a few pieces of the listview code > might still be needed, but definitely most of it is duplicated by the > recent changes. Indeed -- I glanced over the patch myself, and it seems some things do still apply. At the moment I am working on the Common Controls (dlls/comctl32), so you can just forward me all the dlls/comctl32/* chunks if you want. So, I have to know: 1. Do you want me to deal with dlls/comctl32? 2. If so, should I extract the relevant parts, or are you gonna send them to me when you disect the patch? -- Dimi.

Jan. 25, 2002

Re: Patch to improve Microsoft Office 2000 functionality

by Duane Clark

Dimitrie O. Paun wrote: > On Thu, 24 Jan 2002, Duane Clark wrote: > > >>I'll be happy to sync this to the current CVS, test it out with the apps >>I have, and chop it up into a series of patches, if no one else wants to >>take that on. >> > > I suggest you pass the listview.c chucks over to me. I've just completed a > major update to the ListView ctrl, and (a) none of the updates in the > patch will apply, and (b) I have the code fresh in my mind. That would be fine. It looked like a few pieces of the listview code might still be needed, but definitely most of it is duplicated by the recent changes.

Jan. 25, 2002

Re: C++ Winelib problems

by Peter Hunnisett

On 22 Jan 2002 15:23:34 -0800, Alexandre Julliard said: > "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. Ok. This is about the best voodo I can chant up at this point in time. I'm not terribly fond of it but I didn't have a chicken, or chicken substitute, around to sacrifice for extra coding power. It's not tested with unicode stuff and on any platforms other than x86, but it appears to have the semblance of a solution. The basic concept is that you must link the 32 bit spec file last among the spec files, but before any object files. We short circuit the normal way to build the ELF init section by starting a new function __wine_dllname_deferred_init which should end up containing any special init section code from the object files and the standard ELF initialization stuff. We then bind in an entry point for the builtin dll which invokes the deferred initialization code and then run the actual initialization entry point if there is one. It requires a little bit of grease since ntdll can't be called until the ctor stuff is invoked so it gets special permission to be built the old way but of course, wine wants to call it early on in life. Other than that, basically everything is limited to making winebuild produce even more stuff. How does this seem? On the right track? Suggestions for improvement? Am I missing anything with the assembler? > > -- > Alexandre Julliard > julliard(a)winehq.com Ciao, Peter

Jan. 25, 2002

Word97 (winver win95) - no luck with wine

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I have problems starting Word97 using wine-20020122. I use the following command line: env LANG=de_DE LD_LIBRARY_PATH=/opt/wine-20020122/lib:$LD_LIBRARY_PATH /opt/wine-20020122/bin/wine --winver=win95 winword.exe The working directory is: /usr/Windows_NT_Files/Programs/Office/Word Inside this directory there are the following files: - -rwxr----- 1 nardmann users 1108752 Jun 23 2001 MSO7DEU.DLL - -rwxr--r-- 1 nardmann users 3792896 Aug 18 2000 mso97.dll - -rw-r--r-- 1 nardmann users 31232 Jun 29 2001 Normal.dot - -rwxr--r-- 1 nardmann users 5337088 Mai 8 2001 winword.exe - -rwxr--r-- 1 nardmann users 1724416 Aug 18 2000 wwintl32.dll I do not use an installed Windows, only these files! I use Wine on SuSE Linux 7.1 remote using Exceed on Windows NT 4.0. Some time ago I got Word97 running using a CVS version but now I get the following: For language 'german' several language ids were found: de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407; Instead of using first in the list, suggest to define your LANG environment variable like this: LANG=de_DE fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. wine: Unhandled exception, starting debugger... And nothing happens then ... I could add '--debugmsg +all' and provide gzipped file if necessary. How can I locate the problem? I tried to run Wine at the console of the Linux machine logged in as root instead of user nardmann. Then I see the splash screen and get a message box saying that my registry is corrupted and that I should restart the Word setup program. I cannot click the button in this message box. I am going to check the '--debugmsg +reg' output during the next week and compare it with the contents of the registry in the .wine directory and the registry on my local WinNT machine. Running Wine remote using Exceed but being root gives me the following in the shell: snsrv053:root[Word]#env LANG=de_DE LD_LIBRARY_PATH=/opt/wine-20020122/lib:$LD_LIBRARY_PATH /opt/wine-20020122/bin/wine --winver=nt40 winword.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 27 Current serial number in output stream: 37 The display variable is set correctly. How can I debug this bug? - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8URippm53PRScYygRAnAZAJ4tAWZzU+QnKaChlXFZtyvJJkLwhQCgsoUG WwRlq+Fb46jaQuZ7s0kHbAI= =ObqT -----END PGP SIGNATURE-----

Jan. 25, 2002

Re: Patch to improve Microsoft Office 2000 functionality

by Dimitrie O. Paun

On Thu, 24 Jan 2002, Duane Clark wrote: > I'll be happy to sync this to the current CVS, test it out with the apps > I have, and chop it up into a series of patches, if no one else wants to > take that on. I suggest you pass the listview.c chucks over to me. I've just completed a major update to the ListView ctrl, and (a) none of the updates in the patch will apply, and (b) I have the code fresh in my mind. -- Dimi.

Jan. 24, 2002

Re: Patch to improve Microsoft Office 2000 functionality

by Duane Clark

Jeremy White wrote: > ... > by getting it out now, maybe some other folks will help out <grin>. > I'll be happy to sync this to the current CVS, test it out with the apps I have, and chop it up into a series of patches, if no one else wants to take that on.

Jan. 24, 2002

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Now, on a different note, you pointed out an interesting thing: we need to > test mixed A/W cases. We thus have four possible cases: > (A,A), (A,W), (W,A), (W,W) > Should we test all of them? We must test everything that is part of the expected behavior of the function. What this means depends on what the function does. In some cases we have to test combinations, in other cases we don't. <rant> Writing tests is not simply a matter of taking a template and filling in the name of the function you are testing; it requires studying the API documentation, investigating the function behavior, and then devising ways to test that behavior. These ways will likely be different for just about every function. It requires thought and creativity, not simply applying a recipe. </rant> > What is supposed to happen when we have a W->A conversion involving > Unicode char which so not map to A? They get mapped to the default char, usually '?'. -- Alexandre Julliard julliard(a)winehq.com

Jan. 24, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Wed, 23 Jan 2002, Alexandre Julliard wrote: > Sure, I don't doubt that by spending enough time and energy we'll > someday have a solution for all the problems caused by wanting to add > the TCHAR stuff in the first place. It's a bit like adding cushions on > the wall so you can keep banging your head on it without getting hurt > too much. :) Somehow I was expecting this :) But you are correct, the problem is not as simple as it seems, and is hard to see, without code, which approach is more preferable. I don't want to use the TCHAR stuff just because I can, but because I think we can solve some real problems with a little added complexity. The code will prove with tradeoff is better. Now, on a different note, you pointed out an interesting thing: we need to test mixed A/W cases. We thus have four possible cases: (A,A), (A,W), (W,A), (W,W) Should we test all of them? What is supposed to happen when we have a W->A conversion involving Unicode char which so not map to A? -- Dimi.

Jan. 23, 2002

Re: Microsoft's version of "WINE"

by Uwe Bonnes

>>>>> "Srdjan" == Srdjan Matovina <-- Customer Engineering <srdjan(a)scot.canada.sun.com>> writes: Srdjan> They use MainWin from MainSoft Inc. See http://www.mainsoft.com To my knowledge, a run-time licence (!) is in the price order of a normal windows license. This makes it prohibitive for other companies to use... 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

Re: C testing framework. ASCII/Unicode portable version

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Ah, I see. We certainly need to get from generic to specific. So we can > have a bunch of funtions which do just that: > > LPCSTR strTtoA(LPCWSTR); // converts the string to ANSI > LPCWSTR strTtoW(LPCSTR); // converts the string to Unicode > LPCXSTR strTtoX(LPCTSTR); // if T=A, convert to W, else convert to A > > So the above example becomes: > CopyFileW( strTtoW(filename), L"unicode_file_name", FALSE ); Sure, I don't doubt that by spending enough time and energy we'll someday have a solution for all the problems caused by wanting to add the TCHAR stuff in the first place. It's a bit like adding cushions on the wall so you can keep banging your head on it without getting hurt too much. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Re: Privaleged instruction

by Ove Kaaven

On Wed, 23 Jan 2002, Nog wrote: > Just for the fun of it I tried to run the dos installer of Mechwarrior > 2: Mercenaries. It didn't get too far as the installer crashed on an > unhandeled Privileged instruction. According to winedbg the instruction > is 0x0002:0x10000 push %cs. To see what the opcode of this instruction > might be, I added a trace to the INSTR_EmulateInstruction. Looking at > the trace I found that the instruction it was having to emulate was 0x00 > which looks very wrong to me. Yes... 0x00 is an "add" opcode, not a push. > But just to check I simply made that > function return true if the instruction was 0x00 but this only seemed to > make things worse, the exception still occured but the debugger didn't > launch. What I would like to know is, is push %cs realy a Privileged > instruction (which I think it might be)? No, it isn't (unless the stack segment is invalid or something). > Looking into why > INSTR_EmulateInstruction doesn't get the right pointer, the offset > looked too big to me. Shouldn't it roll over to the next segment after > 0xffff? In 16-bit mode, no, the address should roll back to the beginning of the segment... and this is taken care of in INSTR_EmulateInstruction (which I consider to be a bug for 32-bit DPMI segments) > The problem with the way that it is now is that the following > macro, which converts the segment offset pair to linear addresses cuts > off the upper bits, which looks correct. > > #define PTR_REAL_TO_LIN(seg,off) \ > ((void*)(((unsigned int)(seg) << 4) + LOWORD(off))) > > What I want to know is why the offset is so high? The offset can be high if the app uses DPMI to create a 32-bit code segment, but if I remember right, DPMI is currently disabled for DOS apps. But don't worry too much about that offset, because that segment also looks wrong (0x0002 is invalid in protected mode, and in real mode it points to BIOS areas and interrupt tables, no code can live there).

Jan. 23, 2002

Re: C testing framework. ASCII/Unicode portable version

by Dimitrie O. Paun

On Wed, 23 Jan 2002, Alexandre Julliard wrote: [snip] > 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. Ah, I see. We certainly need to get from generic to specific. So we can have a bunch of funtions which do just that: LPCSTR strTtoA(LPCWSTR); // converts the string to ANSI LPCWSTR strTtoW(LPCSTR); // converts the string to Unicode LPCXSTR strTtoX(LPCTSTR); // if T=A, convert to W, else convert to A So the above example becomes: CopyFileW( strTtoW(filename), L"unicode_file_name", FALSE ); -- Dimi.

Jan. 23, 2002

RE: runtest: new option -M for testing current module as builtin

by Patrik Stridvall

> On Wed, 23 Jan 2002, Patrik Stridvall wrote: > [...] > > BEGIN { > > require wine; > > &wine::module_native("wininet"); > > &wine::module_builtin("imm32", "msacm32"); > > } > > I am not sure any test should require the native version > of any dll. > > We cannot ship native dlls with Wine for obvious reasons, so requiring > the native dll would force Wine developpers to have a Windows > partition > installation around, and one configured for use in the tests. > Otherwise > they would not be able to run the tests, would they? > > I don't think that's good. Of course it shouldn't require it. It should simply skip parts of the test if the native version is not available. if(&wine::is_native("wininet")) { # Do native wininet tests } > Choosing to use a native dll is more up to the developper > to debug a > test. And then modifying the configuration file, as we usually do to > debug applications, should be simple and familiar enough. > > But maybe I misunderstood something. Well it allows us to automatically test a non-developer Windows installation directly under Linux without requiring him to reboot. Even developers make find it useful to quickly be able to modify the loadorder without having to modify his configuration. Sometimes what you want to test is quite subtle, like you have a function A in module B that calls function C in module D. Perhaps you want to test the robustness of Wines implementation of function A by testing it both with the native and the builtin version of D. If you have many such tests it would be a lot of unnessary manual work to switch D between native and builtin while testing B as builtin. Then perhaps somebody else have some use I haven't even though of. The main use will be I think to force tests to as the default test the builtin version since if you type "make test" in a directory you really expect to test the files in THAT directory, not the native version even if your ~/.wine/config specifies that.

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > Are we going to make Wine to confirm MS > > implementations to up to this level? > > No but we don't have to if the test is done right. > Something like: > > ret = fooW(...); > if (!ret) /* failed */ > ok( GetLastError() == ERROR_CALL_NOT_IMPLEMENTED > ); > else /* success */ > ok( check for successful result ); > > This will work on all platforms, no matter whether > they support > Unicode or not. Do you suggest to do this for each W call? Isn't it too difficult, even if we are going to wrap the call in some macro, like: CHECK_UNICODE( fooW(...) ): ok( check for successful result ); Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002

Re: runtest: new option -M for testing current module as builtin

by Francois Gouget

On Wed, 23 Jan 2002, Patrik Stridvall wrote: [...] > BEGIN { > require wine; > &wine::module_native("wininet"); > &wine::module_builtin("imm32", "msacm32"); > } I am not sure any test should require the native version of any dll. We cannot ship native dlls with Wine for obvious reasons, so requiring the native dll would force Wine developpers to have a Windows partition installation around, and one configured for use in the tests. Otherwise they would not be able to run the tests, would they? I don't think that's good. Choosing to use a native dll is more up to the developper to debug a test. And then modifying the configuration file, as we usually do to debug applications, should be simple and familiar enough. But maybe I misunderstood something. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > 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. > > Are we going to make Wine to confirm MS > implementations to up to this level? No but we don't have to if the test is done right. Something like: ret = fooW(...); if (!ret) /* failed */ ok( GetLastError() == ERROR_CALL_NOT_IMPLEMENTED ); else /* success */ ok( check for successful result ); This will work on all platforms, no matter whether they support Unicode or not. -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2002

Privaleged instruction

by Nog

Hi, Just for the fun of it I tried to run the dos installer of Mechwarrior 2: Mercenaries. It didn't get too far as the installer crashed on an unhandeled Privileged instruction. According to winedbg the instruction is 0x0002:0x10000 push %cs. To see what the opcode of this instruction might be, I added a trace to the INSTR_EmulateInstruction. Looking at the trace I found that the instruction it was having to emulate was 0x00 which looks very wrong to me. But just to check I simply made that function return true if the instruction was 0x00 but this only seemed to make things worse, the exception still occured but the debugger didn't launch. What I would like to know is, is push %cs realy a Privileged instruction (which I think it might be)? Looking into why INSTR_EmulateInstruction doesn't get the right pointer, the offset looked too big to me. Shouldn't it roll over to the next segment after 0xffff? The problem with the way that it is now is that the following macro, which converts the segment offset pair to linear addresses cuts off the upper bits, which looks correct. #define PTR_REAL_TO_LIN(seg,off) \ ((void*)(((unsigned int)(seg) << 4) + LOWORD(off))) What I want to know is why the offset is so high? nog.

Jan. 23, 2002

Re: Beautifying of Unicode mode check in tests

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > 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. Are we going to make Wine to confirm MS implementations to up to this level? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 23, 2002