October 2003 - Wine-Devel - list.winehq.org

Regression in lstrcmpiA (occurred in late June, NLS related)
by Troy Rollo Oct. 8, 2003

Oct. 8, 2003

When lstrcmpiA was moved from ole2nls.c to locale.c, (around 28th June) the results of comparisons in some cases became reversed. For example, the underscore now returns as greater than alphabetic characters, whereas it used to return as less than alphabetic characters. The older behaviour was consistent with Win2k. The output below is from the following source: ---begin test program--- #include <windows.h> #include <stdio.h> char *test_strings[] = { "_", "A", "a", "z", "Z", 0 }; void test_string(char *pch) { char **ppch = test_strings; while (*ppch) { printf("%s\t%s\t%d\n", pch, *ppch, lstrcmpiA(pch, *ppch)); ++ppch; } } int main(int argc, char **argv) { char **ppch = test_strings; while (*ppch) test_string(*ppch++); return 0; } ---end test program--- ---Wine output from immediately before the change--- _ _ 0sorts _ A -1 _ a -1 _ z -1 _ Z -1 A _ 1 A A 0 A a 0 A z -1 A Z -1 a _ 1 a A 0 a a 0 a z -1 a Z -1 z _ 1 z A 1 z a 1 z z 0 z Z 0 Z _ 1 Z A 1 Z a 1 Z z 0 Z Z 0 ---End--- ---Wine output from immediately after the change--- _ _ 0 _ A 1 _ a 1 _ z 1 _ Z 1 A _ -1 A A 0 A a 0 A z -1 A Z -1 a _ -1 a A 0 a a 0 a z -1 a Z -1 z _ -1 z A 1 z a 1 z z 0 z Z 0 Z _ -1 Z A 1 Z a 1 Z z 0 Z Z 0 ~---End---

8 26

Re: winebuild: small docu update
by Alexandre Julliard Oct. 8, 2003

Oct. 8, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Since these are internal use only, let's not document them > for external people, it will just cause problems. I disagree, it's much better to have documentation stating that they are internal than not to have any documentation at all. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Move actual code out of assert statements
by Alexandre Julliard Oct. 8, 2003

Oct. 8, 2003

Warren_Baird(a)cimmetry.com writes: > (See attached file: patch_code_out_of_asserts.txt) The indentation is messed up. You should set your editor tab width to 8 instead of 4. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Abort glyph rendering if everything is clipped
by Alexandre Julliard Oct. 8, 2003

Oct. 8, 2003

Warren_Baird(a)cimmetry.com writes: > (See attached file: patch_xrender_abort_if_clipped.txt) It would be better IMO to do that as part of the clip rectangle calculation a few lines below. -- Alexandre Julliard julliard(a)winehq.com

1 0

GDI and DirectX test suite
by Steven Edwards Oct. 7, 2003

Oct. 7, 2003

Hello, I have post a collection of tests with source code for the GDI and DirectDraw 7 interfaces at http://mail.gleneagle.net/sedwards/gdi/ The authors of the Windows2000 API Blackbook have aggreed to license the tests as public domain with a request for advertising. The ReactOS project has already started using these tests to help in our implementation and they may make a good test for WINE and Winelib. Thanks Steven __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

2 1

Re: wine/ windows/winpos.c server/window.c server/ ...
by Martin Fuchs Oct. 7, 2003

Oct. 7, 2003

Hello Alexandre, I see, you implemented storage of the four global shell and takman windows. Btw.: great unified aproach, this single get/set server call. :) But you did not yet insert the altered focus handling in set_active_window() from my patch. Is this just comming next, or is there another particular reason for not doing this? Martin On 07.10.2003 05:40:24 Alexandre Julliard wrote: > ChangeSet ID: 9656 > CVSROOT: /home/winehq/opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/10/06 22:40:24 > > Modified files: > windows : winpos.c > server : window.c trace.c request.h protocol.def > include/wine : server_protocol.h > dlls/user : focus.c > > Log message: > Store the global shell, progman and taskman windows in the server > (based on a patch by Martin Fuchs). > > Patch: > http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=9656 > > Old revision New revision Changes Path > 1.147 1.148 +0 -81 wine/windows/winpos.c > 1.23 1.24 +61 -0 wine/server/window.c > 1.182 1.183 +20 -0 wine/server/trace.c > 1.88 1.89 +2 -0 wine/server/request.h > 1.84 1.85 +18 -0 wine/server/protocol.def > 1.85 1.86 +27 -1 wine/include/wine/server_protocol.h > 1.5 1.6 +131 -0 wine/dlls/user/focus.c

2 5

Re: Abort glyph rendering if everything is clipped
by Dimitrie O. Paun Oct. 7, 2003

Oct. 7, 2003

On Tue, 7 Oct 2003 Warren_Baird(a)cimmetry.com wrote: Nit: why not use IsRectEmpty() ? -- Dimi.

1 0

Re: libs/unicode new conversions
by Alexandre Julliard Oct. 7, 2003

Oct. 7, 2003

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > This patch adds two new conversions to libs/unicode, in preparation > for their > use by an upcoming patch adding FoldStringA/W. The first converts > from any > unicode number into its unicode 0-9 representation. The second maps > from > compatibility characters to unicode. > > The rationale for placing them in libs/unicode is that both these > conversions > may be required by calls other than FoldString (at least the numeric > mapping > will be used to parse native language digits in oleaut32). IMO you should export the FoldString functionality from libs/unicode, not the tables. Also I'm not sure how you built the tables, but they need to be generated from the Unicode standard data, and the code to do that should be added to cpmap.pl. -- Alexandre Julliard julliard(a)winehq.com

2 2

cdrom problem? winefile crash
by Moreno Oct. 7, 2003

Oct. 7, 2003

Hi, fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported what it mean? this is my cd is (11, 0) and then? brw-rw---- 1 moreno cdwriter 11, 0 gen 1 1970 /dev/scsi/host0/bus0/target0/lun0/cd i don't know if is for that but winefile crash!! fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported err:dosfs:DRIVE_GetLabel Invalid or unreadable superblock on /dev/fd0 (A:). Invalid or unreadable superblock on /dev/fd0 (A:). Maybe not FAT? fixme:bitmap:CreateBitmap planes = 35 wine: Unhandled exception (thread 0009), starting debugger... fixme:cdrom:CDROM_GetInterfaceInfo CD-ROM device (11, 0) not supported WineDbg starting on pid 8 thx -- Moreno <morenoca(a)freemail.it>

2 1

Re: Oleaut32 3
by Dimitrie O. Paun Oct. 7, 2003

Oct. 7, 2003

On Mon, 6 Oct 2003, Jon Griffiths wrote: > Hi, > > Part 3 of oleaut32 updates. Hi Jon, Cool stuff, but I don't understand why we have all these forwards: +HRESULT WINAPI VarDecFromUI1(BYTE bIn, DECIMAL* pDecOut) +{ + return _VarDecFromUI1(bIn, pDecOut); +} We don't seem to pass any additional info to _VarDecFromUI1, why not simply get rid of it, and implement stuff in the real VarDecFromUI1? -- Dimi.

3 4

Focus problems
by Pavel Roskin Oct. 6, 2003

Oct. 6, 2003

Hello! My patch for fixing the focus of some programs (notepad, winecfg) on startup hasn't been applied, so I'm guessing what the reason might be. One reason may be that the testing could have found another bug that might seem to be related. When Wine uses non-managed windows without desktop, they don't get the keyboard focus initially. It affects even programs what show active captions, such as Winemine. When Winemine is started, the keyboard events go to the original window. The same happens after the "About" dialog is run. But when the "About" dialog is dismissed, the main window of Winemine gets keyboard focus. It seems to be another example of not doing something because the initial window is "already focused". This is a separate problem, it affects a wider class of programs and doesn't affect Wine in the desktop mode. If fixing this is considered precondition to fixing all other focus problems, I'd like to know that. Another possible reason I can think of is because SetFocus is supposed to affect widgets before the application window is shown. That's something that needs testing. I've made a patch that only disables activation of the parent window if it's invisible, but still focuses the window for which SetFocus() was called. The patch is attached. Before I start time-consuming verification, I'd like to know if I going in the right direction. There is another, third focus problem. Windows should not cover modal dialogs. Shareware Windows Commander 5.0 is useless in the desktop mode because the main window covers the "nag screen" on startup. The workaround is to enter "foo" in the command line and press Enter - there will be an error message, and after it's dismissed, the "nag screen" will pop up. Again, it's a separate problem that I'm not trying to solve at this point. I'll appreciate an advise in which order to proceed and what kind of verification is expected for the changes in the focus code. -- Regards, Pavel Roskin

2 1

Protected mode interrupt problem
by Mike McCormack Oct. 6, 2003

Oct. 6, 2003

Hi All, I've run into an interrupt related problem with Quicken 2002's installer. Two 16bit programs launch, one after the other. Each program hooks INT 0, however since our interrupt tables are global to all tasks, the second task retrieves the interrupt vector that the first task set. The first task exits, and restores the original INT 0 vector. When the second task exits, tries to restore the INT 0 vector set by the first task, which now has an invalid selector, so it crashes. After a bit of discussion and writing a test program, we discovered that it appears that some interrupt vectors are task local, and some are global. The local ones appear to be stored in the TDB (task descriptor block), in offsets 0x26 - 0x4a. The attached patch fixes this, though we're not sure that it is correct for DOS programs. I have enclosed a test program that shows the problem. Mike Index: include/task.h =================================================================== RCS file: /cvstrees/crossover/office/wine/include/task.h,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 task.h --- include/task.h 12 Sep 2003 18:37:36 -0000 1.1.1.5 +++ include/task.h 7 Oct 2003 06:29:43 -0000 @@ -98,13 +98,13 @@ FARPROC16 sighandler WINE_PACKED; /* 26 Signal handler */ FARPROC16 userhandler WINE_PACKED; /* 2a USER signal handler */ FARPROC16 discardhandler WINE_PACKED; /* 2e Handler for GlobalNotify() */ - DWORD int0 WINE_PACKED; /* 32 int 0 (divide by 0) handler */ - DWORD int2 WINE_PACKED; /* 36 int 2 (NMI) handler */ - DWORD int4 WINE_PACKED; /* 3a int 4 (INTO) handler */ - DWORD int6 WINE_PACKED; /* 3e int 6 (invalid opc) handler */ - DWORD int7 WINE_PACKED; /* 42 int 7 (coprocessor) handler */ - DWORD int3e WINE_PACKED; /* 46 int 3e (80x87 emu) handler */ - DWORD int75 WINE_PACKED; /* 4a int 75 (80x87 error) handler */ + FARPROC16 int0 WINE_PACKED; /* 32 int 0 (divide by 0) handler */ + FARPROC16 int2 WINE_PACKED; /* 36 int 2 (NMI) handler */ + FARPROC16 int4 WINE_PACKED; /* 3a int 4 (INTO) handler */ + FARPROC16 int6 WINE_PACKED; /* 3e int 6 (invalid opc) handler */ + FARPROC16 int7 WINE_PACKED; /* 42 int 7 (coprocessor) handler */ + FARPROC16 int3e WINE_PACKED; /* 46 int 3e (80x87 emu) handler */ + FARPROC16 int75 WINE_PACKED; /* 4a int 75 (80x87 error) handler */ DWORD compat_flags WINE_PACKED; /* 4e Compatibility flags */ BYTE unused4[2]; /* 52 */ struct _TEB *teb; /* 54 Pointer to thread database */ Index: dlls/winedos/interrupts.c =================================================================== RCS file: /cvstrees/crossover/office/wine/dlls/winedos/interrupts.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 interrupts.c --- dlls/winedos/interrupts.c 12 Sep 2003 18:37:31 -0000 1.1.1.8 +++ dlls/winedos/interrupts.c 7 Oct 2003 06:29:47 -0000 @@ -25,6 +25,7 @@ #include "wine/winbase16.h" #include "thread.h" +#include "task.h" WINE_DEFAULT_DEBUG_CHANNEL(int); WINE_DECLARE_DEBUG_CHANNEL(relay); @@ -541,9 +542,42 @@ */ FARPROC16 DOSVM_GetPMHandler16( BYTE intnum ) { + TDB *pTask; + FARPROC16 proc = 0; + + pTask = TASK_GetCurrent(); + if (pTask) + { + switch( intnum ) + { + case 0x00: + proc = pTask->int0; + break; + case 0x02: + proc = pTask->int2; + break; + case 0x04: + proc = pTask->int4; + break; + case 0x06: + proc = pTask->int6; + break; + case 0x07: + proc = pTask->int7; + break; + case 0x3e: + proc = pTask->int3e; + break; + case 0x75: + proc = pTask->int75; + break; + } + if( proc ) + return proc; + } if (!DOSVM_Vectors16[intnum]) { - FARPROC16 proc = (FARPROC16)MAKESEGPTR( DOSVM_dpmi_segments->int16_sel, + proc = (FARPROC16)MAKESEGPTR( DOSVM_dpmi_segments->int16_sel, DOSVM_STUB_PM16 * intnum ); DOSVM_Vectors16[intnum] = proc; } @@ -558,9 +592,41 @@ */ void DOSVM_SetPMHandler16( BYTE intnum, FARPROC16 handler ) { + TDB *pTask; + TRACE("Set protected mode interrupt vector %02x <- %04x:%04x\n", intnum, HIWORD(handler), LOWORD(handler) ); - DOSVM_Vectors16[intnum] = handler; + + pTask = TASK_GetCurrent(); + if (!pTask) + return; + switch( intnum ) + { + case 0x00: + pTask->int0 = handler; + break; + case 0x02: + pTask->int2 = handler; + break; + case 0x04: + pTask->int4 = handler; + break; + case 0x06: + pTask->int6 = handler; + break; + case 0x07: + pTask->int7 = handler; + break; + case 0x3e: + pTask->int3e = handler; + break; + case 0x75: + pTask->int75 = handler; + break; + default: + DOSVM_Vectors16[intnum] = handler; + break; + } } #include <stdio.h> #include <windows.h> void myintfn(void) { } int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { int old_seg, old_ofs, new_seg, new_ofs; char str[16]; /* get the old interrupt handler for int 0 */ _asm { push bx push es mov ax,0x3502 int 21h mov old_seg, es mov old_ofs, bx pop es pop bx } /* print it in a message box */ sprintf(str, "old %04x:%04x", old_seg, old_ofs ); MessageBox( 0, str, "Int 02", MB_OK); /* set the new interrupt handler */ _asm { push ds push dx mov ax,0x2502 push cs pop ds mov dx, offset myintfn int 21h pop dx pop ds } if( !hPrevInstance) WinExec("taskint.exe",SW_SHOW); /* fetch it back again */ _asm { push bx push es mov ax,0x3502 int 21h mov new_seg, es mov new_ofs, bx pop es pop bx } sprintf(str, "new %04x:%04x", new_seg, new_ofs ); MessageBox( 0, str, "Int 02", MB_OK); /* now set the original back again */ _asm { push ds push dx mov ax,0x2502 mov ds, old_seg mov dx, old_ofs int 21h pop dx pop ds } return 0; }

1 0

Wineconf - survey
by Jeremy White Oct. 6, 2003

Oct. 6, 2003

Hi everyone, I've put up a survey page here: http://www.winehq.org/wineconf/ I'd like to ask everyone who would come to Wineconf to go and enter their preferences. If you would not come to Wineconf regardless of where it was held, please do not fill out the survey. Let's hold this open through Friday, and then let's consider it final. Sound reasonable? Cheers, Jer

1 0

Re: Problem into the mail server ?
by Hannu Valtonen Oct. 6, 2003

Oct. 6, 2003

Duane Clark wrote: > If you don't want the emails sent to you, subscribe and then turn on the > option to "Disable mail delivery". No need, I subscribed to a bunch of lists and finally configured my Mozilla Mail's filters. Took me a grand total of five minutes. The traffic is hardly a problem since I'm sitting behind a cablemodem and would've read the posts on the mailinglists anyway. But thanks for the suggestion. - Hannu Valtonen Hannu.Valtonen(a)hut.fi

1 0

Unicode strings
by Kevin Koltzau Oct. 6, 2003

Oct. 6, 2003

I've come upon an instance where I need to create a large lookup table of unicode strings, and was curious what the recommended way to handle this was. Using MSVC I would simply declare the string as L"Text" I only see two options currently, either declare the string as (const WCHAR[]){'T','e','x','t'} or store as non-unicode and use WideCharToMultiByte/MultiByteToWideChar as appropriate As this is being implemented for a unicode-only function, it seems silly to convert the string, but declaring it as (const WCHAR[]){'T','e','x','t'} is a little unwieldy for the quantity of data that I need to declare

3 2

Re: Oleaut32 7
by Alexandre Julliard Oct. 6, 2003

Oct. 6, 2003

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +/* The list of localised text data */ > +const VARIANT_TEXT VARIANT_LocalisedTextList[NUM_LOCALISED_LANGS] = > +{ > + { szCzechStrings, LANG_CZECH, 7, 16, 24, 32, 36 }, > + { szDanishStrings, LANG_DANISH, 5, 11, 14, 18, 22 }, > + { szGermanStrings, LANG_GERMAN, 5, 12, 15, 20, 24 }, > + { szEnglishStrings, LANG_ENGLISH, 5, 11, 14, 18, 22 }, > + { szSpanishStrings, LANG_SPANISH, 10, 16, 19, 22, 31 }, > + { szFinnishStrings, LANG_FINNISH, 5, 13, 19, 22, 31 }, > + { szFrenchStrings, LANG_FRENCH, 5, 10, 16, 24, 28 }, > + { szHungarianStrings,LANG_HUNGARIAN, 5, 11, 16, 20, 23 }, > + { szItalianStrings, LANG_ITALIAN, 5, 11, 14, 17, 20 }, > + { szDutchStrings, LANG_DUTCH, 5, 12, 15, 19, 24 }, > + { szNorseStrings, LANG_NORWEGIAN, 5, 11, 14, 18, 21 }, > + { szPolishStrings, LANG_POLISH, 7, 13, 17, 21, 24 }, > + { szSwedishStrings, LANG_SWEDISH, 5, 12, 15, 19, 22 } > +}; It would be better IMO to store that as string resources; you then get all the localisation mechanism for free, and people can translate them without digging into the code. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Oleaut32 4
by Alexandre Julliard Oct. 6, 2003

Oct. 6, 2003

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > Changelog: > > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > +dlls/oleaut32/i1.c dlls/oleaut32/i2.c dlls/oleaut32/i4.c > dlls/oleaut32/r4.c dlls/oleaut32/Makefile.in > dlls/oleaut32/oleaut32.spec > dlls/oleaut32/variant.c > Implement/document i1/ui1/i2/ui2/i4/ui4/r4 low-level calls I don't think we want to create a separate file for every variant type, especially since most of the functions are just one line. A single file with all the "simple" conversion functions would be enough. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: handle quoting on the command line in uninstaller
by Alexandre Julliard Oct. 6, 2003

Oct. 6, 2003

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * handle quoting on the command line in uninstaller Is there any reason we can't use argv[] here instead? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Oleaut32 7
by Gregory M. Turner Oct. 6, 2003

Oct. 6, 2003

On Monday 06 October 2003 10:32 am, Jon Griffiths wrote: > Hi, > > Part 7 of oleaut32 updates. > > Cheers, > Jon > > License: X11 > > Changelog: > > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > +dlls/oleaut32/bool.c dlls/oleaut32/oleaut32.spec > dlls/oleaut32/variant.c > Implement the boolean low-level calls Nice patch-set. I see there were some surprises, but good job nevertheless... extra kudos for doing laborious "boring" stuff and for providing in-source doc! Wish I was so prolific, as I am a no-patch bum lately.... -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis

1 0

Re: What does it take to run a third-party DLL under Wine?
by Dimitrie O. Paun Oct. 6, 2003

Oct. 6, 2003

On Mon, 6 Oct 2003, John Conneely wrote: > Hey, any ideas of where I might be able to hire a WINE guru to help with > this stuff? I haven't even used Wine before, and I'm looking for someone > that can help us set up our WINE environment, test to see if the DLL we are > trying to use will run under WINE, then create a wrapper for the DLL that is > created with WineLib. Using an RPC mechanism is fine, as long as it doesn't > involve a Windows OS box. Might you be available for a little moonlighting? > I don't think we're talking about a huge amount of work here... mostly the > feasibility analysis work and some pointers on how to setup the environment. > If not you, know any other WINE hackers that might be? Sure, I can take a look. I would also recommend the CodeWeavers guys (http://www.codeweavers.com) they've done this before a number of times, it should be an easy task for them. I'm not affiliated with them, but they are great folks! If you want me to help you get started, email me off the list. -- Dimi.

1 0

patch for font glyph transformation in freetype.c (take II)
by Dave_Belanger＠cimmetry.com Oct. 6, 2003

Oct. 6, 2003

I'm resubmitting this patch after applying an important correction on it. Thanks to Dmitry. Dave Belanger Cimmetry Systems Inc. dave.belanger(a)cimmetry.com (514) 735-3219 (ext. 204) ------------------------------------ (See attached file: patch_glyphtransform.txt)

1 0

sparc solaris changes in wine
by Juraj Hercek Oct. 6, 2003

Oct. 6, 2003

Hello, We've done couple of changes in wine in order to compile with gcc-3.3.1 using binutils-2.14 and run on solaris --- mercy% uname -a SunOS mercy 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Blade-1000 --- I'm not posting this patch to wine-patch yet, since there are couple of things I'm not sure are solved in "correct" way. Diff file made on 2003-10-06 06:13 EST is attached. I've configured wine this way: "./configure --without-opengl CFLAGS="-g3 -O0"" Here go my questions regarding to this files: * dlls/x11drv/xvidmode.c I've been just ifdeffing out anything I couldn't compile because of missing LIBXXF86VM. Maybe original author of the code knows what *exactly* should be ifdeffed out. * libs/wine/port.c Hm, good old wine_switch_to_stack() I've been changing aproximately one year ago was changed a lot from that time. Anyways current change I've done in this file prevents crash caused by instruction "0xfed9d100 <start_process+16>: st %i0, [%fp +0x44]" (unused function argument arg resolves to %fp+0x44 address... (why? it's not used in that function, maybe -g3 -O0 flags?)). Substracting 96 bytes from original stack "emulates" ommited save instruction in wine_switch_to_stack() and ensures, that store instruction doesn't crash. Well, I guess original wine_switch_to_stack() code could work with older versions of gcc (very probably with gcc-3.2)... * programs/Makefile.in Just removed winegdb from building - we still don't have sparc register map (and related) defined. * tools/bin2res.c include <limits.h> ensures PATH_MAX used later is defined. * tools/winebuild/import.c This is another hack needed because of gcc-3.3.1 I guess. I don't know if this would work also on x86 platform, but on solaris fixes gas's "Error: operation combines symbols in different segments". Gcc-3.3.1 compiles imports and delayed_imports into the different sections (.data.rel.local, .data.rel), thus gas threw the error mentioned above. * windows/winproc.c Finally, allignment problem on sparc platform - I've just ifdeffed out packing includes, so structs are alligned to (default) 4 byte boundary. I'd appreciate any comments - especially those related to gcc-3.3.1. Regards ;-), Juraj ? output.txt ? wine-solaris-20031006.diff ? dlls/comctl32/a.out ? dlls/comctl32/comctl32.spec.s ? dlls/ddraw/a.out ? dlls/ddraw/ddraw.spec.s ? tools/makedep.o.aBaiw5 ? tools/winebuild.tar.gz ? tools/winebuild/ddraw.spec.s ? tools/winebuild/out.txt ? windows/winproc.ii Index: dlls/iphlpapi/ifenum.c =================================================================== RCS file: /home/wine/wine/dlls/iphlpapi/ifenum.c,v retrieving revision 1.6 diff -u -r1.6 ifenum.c --- dlls/iphlpapi/ifenum.c 5 Sep 2003 23:08:37 -0000 1.6 +++ dlls/iphlpapi/ifenum.c 6 Oct 2003 10:13:07 -0000 @@ -785,14 +785,27 @@ fd = socket(PF_INET, SOCK_DGRAM, 0); if (fd != -1) { +#if defined(__sparc__) + struct lifreq ifr; +#else struct ifreq ifr; +#endif +#if defined(__sparc__) + strncpy(ifr.lifr_name, name, IFNAMSIZ); + ifr.lifr_name[IFNAMSIZ-1] = '\0'; +#else strncpy(ifr.ifr_name, name, IFNAMSIZ); ifr.ifr_name[IFNAMSIZ-1] = '\0'; +#endif if ((ioctl(fd, SIOCGIFMTU, &ifr))) ret = ERROR_INVALID_DATA; else { +#if defined(__sparc__) + *mtu = ifr.lifr_mtu; +#else *mtu = ifr.ifr_mtu; +#endif ret = NO_ERROR; } } Index: dlls/x11drv/xvidmode.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/xvidmode.c,v retrieving revision 1.23 diff -u -r1.23 xvidmode.c --- dlls/x11drv/xvidmode.c 30 Sep 2003 00:31:42 -0000 1.23 +++ dlls/x11drv/xvidmode.c 6 Oct 2003 10:13:07 -0000 @@ -101,7 +101,7 @@ return 1; } -static Bool in_desktop_mode; +static Bool in_desktop_mode = 0; static const unsigned int depths[] = {8, 16, 32}; void X11DRV_XF86VM_Init(void) @@ -454,6 +454,7 @@ #endif } +#ifdef HAVE_LIBXXF86VM /* implementation of EnumDisplaySettings for XF86VM */ BOOL X11DRV_XF86VM_EnumDisplaySettingsExW( LPCWSTR name, DWORD n, LPDEVMODEW devmode, DWORD flags) { @@ -492,6 +493,7 @@ TRACE("mode %ld -- not present\n", n); return FALSE; } +#endif /* implementation of ChangeDisplaySettings for XF86VM */ LONG X11DRV_XF86VM_ChangeDisplaySettingsExW( LPCWSTR devname, LPDEVMODEW devmode, @@ -612,17 +614,20 @@ */ BOOL X11DRV_EnumDisplaySettingsExW( LPCWSTR name, DWORD n, LPDEVMODEW devmode, DWORD flags) { +#ifdef HAVE_LIBXXF86VM if (dd_modes) { /* XVidMode */ return X11DRV_XF86VM_EnumDisplaySettingsExW(name, n, devmode, flags); } - else if (in_desktop_mode) + else + if (in_desktop_mode) { /* desktop */ return X11DRV_desktop_EnumDisplaySettingsExW(name, n, devmode, flags); } else +#endif { /* no resolution changing */ return X11DRV_nores_EnumDisplaySettingsExW(name, n, devmode, flags); @@ -674,6 +679,7 @@ { TRACE("Return to original display mode\n"); } +#ifdef HAVE_LIBXXF86VM if (dd_modes) { /* XVidMode */ @@ -687,6 +693,7 @@ hwnd, flags, lpvoid ); } else +#endif { /* no resolution changing */ return X11DRV_nores_ChangeDisplaySettingsExW( devname, devmode, Index: libs/wine/port.c =================================================================== RCS file: /home/wine/wine/libs/wine/port.c,v retrieving revision 1.1 diff -u -r1.1 port.c --- libs/wine/port.c 29 Aug 2003 22:23:42 -0000 1.1 +++ libs/wine/port.c 6 Oct 2003 10:13:07 -0000 @@ -69,7 +69,7 @@ __ASM_GLOBAL_FUNC( wine_switch_to_stack, "mov %o0, %l0\n\t" /* store first argument */ "mov %o1, %l1\n\t" /* store second argument */ - "mov %o2, %sp\n\t" /* store stack */ + "sub %o2, 96, %sp\n\t" /* store stack */ "call %l0, 0\n\t" /* call func */ "mov %l1, %o0\n\t" /* delay slot: arg for func */ "ta 0x01"); /* breakpoint - we never get here */ Index: programs/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/Makefile.in,v retrieving revision 1.39 diff -u -r1.39 Makefile.in --- programs/Makefile.in 23 Jun 2003 19:51:21 -0000 1.39 +++ programs/Makefile.in 6 Oct 2003 10:13:07 -0000 @@ -26,7 +26,6 @@ wineboot \ winecfg \ wineconsole \ - winedbg \ winefile \ winemenubuilder \ winemine \ @@ -53,7 +52,6 @@ wineboot \ winecfg \ wineconsole \ - winedbg \ winefile \ winemenubuilder \ winemine \ @@ -74,7 +72,6 @@ wineboot \ winecfg \ wineconsole \ - winedbg \ winefile \ winemine \ winepath \ @@ -85,7 +82,6 @@ rpcss.exe \ wcmd.exe \ wineconsole.exe \ - winedbg.exe \ winemenubuilder.exe \ winevdm.exe \ winhelp.exe Index: tools/bin2res.c =================================================================== RCS file: /home/wine/wine/tools/bin2res.c,v retrieving revision 1.18 diff -u -r1.18 bin2res.c --- tools/bin2res.c 3 Oct 2003 03:34:10 -0000 1.18 +++ tools/bin2res.c 6 Oct 2003 10:13:07 -0000 @@ -24,6 +24,7 @@ #include "wine/port.h" #include <stdio.h> +#include <limits.h> #include <stdlib.h> #include <ctype.h> #include <string.h> Index: tools/winebuild/import.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/import.c,v retrieving revision 1.52 diff -u -r1.52 import.c --- tools/winebuild/import.c 13 Aug 2003 21:57:42 -0000 1.52 +++ tools/winebuild/import.c 6 Oct 2003 10:13:07 -0000 @@ -806,7 +806,7 @@ fprintf( outfile, "#ifndef __GNUC__\nstatic void __asm__dummy_import(void) {\n#endif\n\n" ); pos = 20 * (nb_imm + 1); /* offset of imports.data from start of imports */ - fprintf( outfile, "asm(\".data\\n\\t.align %d\\n\"\n", get_alignment(8) ); + fprintf( outfile, "asm(\".section\\t\\\".data.rel.local\\\"\\n\\t.align %d\\n\"\n", get_alignment(8) ); for (i = 0; i < nb_imports; i++) { if (dll_imports[i]->delay) continue; @@ -1082,7 +1082,7 @@ idx++; } - fprintf( outfile, "\n \".data\\n\\t.align %d\\n\"\n", get_alignment(8) ); + fprintf( outfile, "\n \".section\\t\\\".data.rel\\\"\\n\\t.align %d\\n\"\n", get_alignment(8) ); pos = nb_delayed * 32; for (i = 0; i < nb_imports; i++) { Index: windows/winproc.c =================================================================== RCS file: /home/wine/wine/windows/winproc.c,v retrieving revision 1.108 diff -u -r1.108 winproc.c --- windows/winproc.c 5 Sep 2003 23:15:39 -0000 1.108 +++ windows/winproc.c 6 Oct 2003 10:13:07 -0000 @@ -47,7 +47,9 @@ WINE_DECLARE_DEBUG_CHANNEL(relay); WINE_DEFAULT_DEBUG_CHANNEL(win); -#include "pshpack1.h" +#if !defined(__sparc__) +# include "pshpack1.h" +#endif /* Window procedure 16-to-32-bit thunk */ typedef struct @@ -78,7 +80,10 @@ BYTE jmp; /* jmp proc (relative jump) */ WNDPROC proc; } WINPROC_JUMP; -#include "poppack.h" + +#if !defined(__sparc__) +# include "poppack.h" +#endif typedef union {

2 3

Re: patch for font glyph transformation in freetype.c
by Dave_Belanger＠cimmetry.com Oct. 6, 2003

Oct. 6, 2003

Dmitry, I'll resubmit the patch taking into account your suggestion about the transformation matrix. It makes sense; I recall experiencing the same problem for the rotation matrix. It shouldn't break anything in our application since we were only using the extra transformation matrix to do flipping which only implies e11 and e22. Thanks for the correction. Dave "Dmitry Timoshkov" <dmitry(a)baikal.ru> on 10/06/2003 11:17:42 AM To: Dave Belanger/CSI(a)CSIDomain cc: wine-devel(a)winehq.com Subject: Re: patch for font glyph transformation in freetype.c [cc'ed to wine-devel] <Dave_Belanger(a)cimmetry.com> wrote: > We are developing a visualization and markup application called AutoVue for most > CAD and ECAD file formats as well as raster, document and spreadsheet formats. > We used wine to port our server from Windows to Solaris. I've been debugging > wine for more than a year now and we improved the font handling quite a bit > since it was critical for us that the text show up the same as on Windows. > > Btw, do I need to resubmit that patch? We are trying to get most of our wine > changes in, since our wine updates are getting quite tricky. If you can't test the proposed change in your environment or you don't care about the change at all there is no need to resend it. I'll send the proposed patch separately after the commit. Just say it clearly, whether the proposed change is ok or it will break your application, in the latter case we will have to find the source of breakage. -- Dmitry.

1 0

Re: patch for font glyph transformation in freetype.c
by Dmitry Timoshkov Oct. 6, 2003

Oct. 6, 2003

[cc'ed to wine-devel] <Dave_Belanger(a)cimmetry.com> wrote: > We are developing a visualization and markup application called AutoVue for most > CAD and ECAD file formats as well as raster, document and spreadsheet formats. > We used wine to port our server from Windows to Solaris. I've been debugging > wine for more than a year now and we improved the font handling quite a bit > since it was critical for us that the text show up the same as on Windows. > > Btw, do I need to resubmit that patch? We are trying to get most of our wine > changes in, since our wine updates are getting quite tricky. If you can't test the proposed change in your environment or you don't care about the change at all there is no need to resend it. I'll send the proposed patch separately after the commit. Just say it clearly, whether the proposed change is ok or it will break your application, in the latter case we will have to find the source of breakage. -- Dmitry.

1 0

Re: WineHQ: add the HeapReAlloc() task to the Janitorial list
by Oleg Prokhorov Oct. 6, 2003

Oct. 6, 2003

Hello Dimitrie, Thursday, September 25, 2003, 11:51:37 AM, you wrote: DOP> ChangeLog DOP> Add the HeapReAlloc() task to the Janitorial list. What about (undocumented ? ) ntdll/RtlReAllocateHeap ? It suffers the identical problem. Calling it with NULL as previously allocated memory heap block will return NULL. -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

1 0