wine-devel

wine-devel@winehq.org

84463 discussions

Does Windows have one of these?
by Bill Medland 25 Jan '02

25 Jan '02

As I look deeper into the DrawText boundary behaviour it becomes clear to me that the Microsoft version must actually keep the & symbols in the string until the very last moment. In particular it looks to me like they actually measure strings that contain them. I can't see how they can do that with GetTextExtent and its relatives; I can't see where to hide a flag as to whether to interpret the & or not. Does anyone know if there are Microsoft undocumented functions or undocumented ways to measure and output a text that includes & symbols with a way of specifying whether they count as prefix characters or not? Personally it seems silly to me and I don't intend doing so myself unless there is a good reason to duplicate all of Microsoft's weird bugs. Bill

1 0

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@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.

3 6

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

Panic over; the 20020101 version will do for now. > -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@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. >

1 0

Excessive clipping of text in listview
by Bill Medland 25 Jan '02

25 Jan '02

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

2 1

Re: Patch to improve Microsoft Office 2000 functionality
by Duane Clark 25 Jan '02

25 Jan '02

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.

2 4

C++ Winelib problems
by Peter Hunnisett 25 Jan '02

25 Jan '02

Hello all, I've been tooling around with building a C++ application using Winelib and I've come across a couple of problems resulting from the use of global constructors. The problems can be reproduced with a simple C++ application which from a constructor calls a method which is resolved through a dll import. 1) If this program is the main program, wine_dll_set_callback has not yet been invoked so the __wine_dll_register call doesn't resolve the import list. The problem is that the constructors of the program are run immediately after the dll is registered which results in calling a non resolved import. This can be worked around by simply creating a non C++ stub which does a LoadLibrary/GetProcAddress on the real main exe. However I'm wondering if there is a good reason for needing to wait until after the main exe is loaded before being able to resolve imports? I must be missing something from my quick view of the code. 2) The order of running constructor execution and DLL entry point is incorrect. To show the problem assume you have foo.dll which imports bar.dll Present order for builtins: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run bar.dll DLL entry point Run foo.dll DLL entry point I actually haven't checked if PE images presently have the same problem since I don't know what triggers the ctor execution for a PE image. I assume that it's the running of the DLL entry point, but I don't know for sure. Hopefully I'll find the time at some point this week to whip up a test. The correct order: Load foo.dll Start to resolve foo.dll dependencies Start to resolve bar.dll dependencies Finsh resolving bar.dll dependencies Run bar.dll C++ constructors Run bar.dll DLL entry point Finish resolving foo.dll dependencies Run foo.dll C++ constructors Run foo.dll DLL entry point The problem seems reasonably simple enough to resolve but I'm sure that I'm missing something since my patch doesn't work for the present version of wine :(. I think that the problem is that there's an issue with inter DLL dependencies somewhere as it dies in SYSMETRICS_Init with a bad hdc. 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? Ciao, Peter

2 2

Word97 (winver win95) - no luck with wine
by Heiko Nardmann 25 Jan '02

25 Jan '02

-----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-----

1 0

C testing framework. ASCII/Unicode portable version
by Andriy Palamarchuk 24 Jan '02

24 Jan '02

Attached version of the C testing framework, which is implemented with using TCHAR.H macros, so it is portable between ASCII and Unicode platforms. Also implemented test which can be used to test ASCII and Unicode API. As I found out creating ASCII/Unicode portable code requires much more attention than creating plain ASCII-only code, probably the same level of difficulty as creation Unicode-only code. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

5 33

Re: Microsoft's version of "WINE"
by Srdjan Matovina -- Customer Engineering 23 Jan '02

23 Jan '02

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@winehq.com?subject=help> >List-Post: <mailto:wine-devel@winehq.com> >List-Subscribe: <http://www.winehq.com/mailman/listinfo/wine-devel>, <mailto:wine-devel-request@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@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

2 1

Privaleged instruction
by Nog 23 Jan '02

23 Jan '02

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.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel