wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Wine and the fonts
by Spanke, Alexander 19 Aug '02

19 Aug '02

Hi, Ii try to start an application with wine, but the fonts used by the application are terrible. So i changed the default - entry in the config - file to change the font. Nothing changed :( I don't want any special font, only a simple mono font, how can i get it ? Reagrds Alex

1 0

[breakage] Set the correct permissions on the PE image sections.
by Uwe Bonnes 18 Aug '02

18 Aug '02

Hallo, the patch http://cvs.winehq.com/patch.py?id=1027987166850574216879071 "Set the correct permissions on the PE image sections" breaks the propsheet handling on the xilinx webpack suite. When a propsheet should be opened, appended backtrace appears. PROPSHEET_CreatePage writes to ppshpage->u.pResource when PSP_DLGINDIRECT is set. MSDN also tells that applications will break if pResource is not writable. It seems that above patch maps the resource section write protected. Info segments doesn't tell about a range including 0x00467390, info maps tells about VirtualQueryEx Unsupported . Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- First chance exception: page fault on write access to 0x00467390 in 32-bit code (0x408c888c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:408c888c ESP:405c6080 EBP:405c60c4 EFLAGS:00010202( R- 00 I - - 1 ) EAX:40000440 EBX:409203dc ECX:00000000 EDX:4092021d ESI:00467390 EDI:41552098 Stack dump: 0x405c6080 (_end+0x117800): 409203dc 00000000 00000000 00010056 0x405c6090 (_end+0x117810): 405c60c4 00000000 00010056 0000130c 0x405c60a0 (_end+0x117820): 00000000 41552070 00000000 ffffffff 0x405c60b0 (_end+0x117830): 405c60c0 409203dc 4092021d 00000000 0x405c60c0 (_end+0x117840): 00000000 405c6108 408c9587 00020051 0x405c60d0 (_end+0x117850): 00000000 40400788 41552098 409203dc 0x405c60e0 (_end+0x117860): 0011: sel=008f base=4010f1c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x408c888c (PROPSHEET_CreatePage+0xec(hwndParent=0x20051, index=0x0, psInfo=0x40400788, ppshpage=0x41552098) [propsheet.c:1239] in comctl32.dll.so) (ebp=405c60c4) 1 0x408c9587 (PROPSHEET_SetCurSel+0x127(hwndDlg=0x20051, index=0x0, skipdir=0x1, hpage=0x41552098) [propsheet.c:1773] in comctl32.dll.so) (ebp=405c6108) 2 0x408cabc0 (PROPSHEET_DialogProc+0x320(hwnd=0x20051, uMsg=0x110, wParam=0x10052, lParam=0x40400788) [propsheet.c:2591] in comctl32.dll.so) (ebp=405c6330) 3 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c6354) 4 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x408ca8a0, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c6384) 5 0x4075c3b7 (CallWindowProcW+0xa7(func=0x414012f8, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2836] in user32.dll.so) (ebp=405c63ac) 6 0x4072ce71 (DefDlgProcW+0x51(hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788, hwnd=0x20051) [defdlg.c:405] in user32.dll.so) (ebp=405c63d8) 7 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c63fc) 8 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x4072ce20, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c642c) 9 0x4075bd26 (WINPROC_CallProc32ATo32W+0xc6(func=0x4072ce20, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2592] in user32.dll.so) (ebp=405c6458) 10 0x4075c2d7 (CallWindowProcA+0xa7(func=0x414001f6, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2800] in user32.dll.so) (ebp=405c6480) 11 0x5f446f6b (MFC42.DLL.?DefWindowProcA@CWnd@@MAEJIIJ@Z+0x42 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c64a0) 12 0x5f446603 (MFC42.DLL.?Default@CWnd@@IAEJXZ+0x25 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c64f4) 13 0x0042b8ef (_pn.exe.??4RticStore@@QAEAAV0@ABV0@@Z+0xa8af in I:\xilinx\bin\nt\_pn.exe) (ebp=405c6594) 14 0x5f447664 (MFC42.DLL.?WindowProc@CWnd@@MAEJIIJ@Z+0x45 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c65bc) 15 0x5f446546 (MFC42.DLL.?AfxCallWndProc@@YGJPAVCWnd@@PAUHWND__@@IIJ@Z+0x90 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c661c) 16 0x5f446749 (MFC42.DLL.?AfxWndProc@@YGJPAUHWND__@@IIJ@Z+0x2b in I:\XILINX\MFC\MFC42.DLL) (ebp=405c6638) 17 0x5f46f12b (MFC42.DLL.?AfxWndProcBase@@YGJPAUHWND__@@IIJ@Z+0x39 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c6664) 18 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c6688) 19 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x5f46f0f2, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c66b8) 20 0x4075c26b (CallWindowProcA+0x3b(func=0x5f46f0f2, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2781] in user32.dll.so) (ebp=405c66e0) 21 0x4076bd00 (call_window_proc+0x100(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405c6730) 22 0x4076c9d9 (SendMessageTimeoutA+0xe9(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788, flags=0x0, timeout=0xffffffff, res_ptr=0x405c67b8, hwnd=0x20051) [message.c:1784] in user32.dll.so) (ebp=405c6788) 23 0x4076cb59 (SendMessageA+0x39(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788) [message.c:1829] in user32.dll.so) (ebp=405c67bc) 24 0x40730695 (DIALOG_CreateIndirect+0x525(hInst=0x0, dlgTemplate=0x41552244, owner=0x20025, dlgProc=0x408ca8a0, param=0x40400788, procType=0x3, modal=0x0, hwnd=0x20025) [dialog.c:860] in user32.dll.so) (ebp=405c683c) 25 0x40730a6f (CreateDialogIndirectParamW+0x2f(hInst=0x0, dlgTemplate=0x415521e8, owner=0x20025, dlgProc=0x408ca8a0, param=0x40400788) [dialog.c:1011] in user32.dll.so) (ebp=405c686c) 26 0x408c7adc (PROPSHEET_CreateDialog+0xfc(psInfo=0x40400788) [propsheet.c:581] in comctl32.dll.so) (ebp=405c6898) 27 0x408ca21c (PropertySheetA+0x11c(lppsh=0x4113d250) [propsheet.c:2245] in comctl32.dll.so) (ebp=405c68bc) 28 0x5f4661eb (MFC42.DLL.?DoModal@CPropertySheet@@UAEHXZ+0xbc in I:\XILINX\MFC\MFC42.DLL) (ebp=00000000)

3 5

Re: AutoCAD2000 again and CreateFiber
by Matts 18 Aug '02

18 Aug '02

Hi! Does this mean that AutoCad 2000 works good in wine, if I set window version to win95 (which I dont see a problem with right now)? Regards Matts >Well, after the patch-hack-or whatever on VirtualQuery, AutoCAD2000 >began >coming alive ! Some problems yet, but one wonders me in particular : >setting window version as win98 or winnt40, app shows an exception >stating >that CreateFiber function is not implemented; setting as win95 the apps >starts quite well. >Any idea ? Is there some plan to implement xxxxxFiber functions, or >it's too >difficult ? >BTW, looking for help on the net, i haven't really understood the >difference >between a regular thread and a fiber (only caught that use of fibers >instead >of threads is somehow discouraged...) >Regards >Max _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net _____________________________________________________________ Promote your group and strengthen ties to your members with email(a)yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag

3 2

gdbproxy
by Robert Lunnon 18 Aug '02

18 Aug '02

On solaris gdbproxy doesn't compile because S_un is not defined, S_un is only defined on SOlaris for XPG 4 applications. The header file however exposed _S_un so should this be _S_un or do I have to invent a new test for these features. Grabbed these comments off the net POSIX Applications that are intended to be conforming POSIX.1 applications must define the feature test macros specified by the standard before including any headers. For the stan- dards listed below, applications must define the feature test macros listed. Application writers must check the corresponding standards for other macros that can be queried to determine if desired options are supported by the imple- mentation. POSIX Standard Feature Test Macros POSIX.1-1990 _POSIX_SOURCE POSIX.1-1990 and _POSIX_SOURCE and POSIX.2-1992 C-Language _POSIX_C_SOURCE=2 Bindings Option POSIX.1b-1993 _POSIX_C_SOURCE=199309L POSIX.1c-1996 _POSIX_C_SOURCE=199506L X/Open CAE To build or compile an application that conforms to one of the X/Open CAE specifications, use the following guidelines. Applications need not set the POSIX feature test macros if they require both CAE and POSIX functionality. XPG3 The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1). XPG4 The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1) and set _XOPEN_VERSION=4. SUS (XPG4v2) The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1) and set _XOPEN_SOURCE_EXTENDED=1. SUSv2 The application must define _XOPEN_SOURCE=500.

1 1

WINE fork and Win32api implementation
by Steven Edwards 18 Aug '02

18 Aug '02

Hola Everyone, I'm CC'ing this to wine-devel so all of the WINE devs know whats going on as they have been very nice and supporting of my work so far. As everyone knows I've been doing a lot of work with Casper, James and Jurgan on the WINE fork to windows. I've had a lot of luck and been learning alot along the way but I dont think I can contribute much more the WINE porting work at this point from the ReactOS side. As David, Eugene and Jason are makeing lots of progress on the Windowing are just a few days/weeks(?) away from having Winhello working with the new Region code, I think someone needs to take over merging and maintaining the WINE dlls. I talked to Jason about it today and we thought that Robert might want to take over for a while if he is interested because he seems to like doing a lot of the Win32 side of things. If he is not interested does anyone else want to do it? IMHO the "right" way to fork the WINE code to best suite both projects is going to have to work like this: 1. We make a set policy of when to merge. I know Jason was wanting to change the release cycle times so the merging should be cordinated with that. Mabey like 2 weeks before a new release? 2. Whoever wants to try and maintain the fork is going to need to work with Capser on keeping the w32api headers up to date. I have submitted a few minor patches but I dont have the time to do the work that is really needed. This has been one of the biggest problems so far. Having 3 sets of headers is just a pain and all of the projects seem interested in moving to one common include system. I did a little bit of work trying to get some of the WINE dlls to compile with only the mingw headers but I didnt have the time to do to much with it. 3. Keep from forking/redunancy as much as possible. It bothers me when as small as our projects are we have already manged to have so much forking in WINE, mingw and ReactOS. How many registry editors do we need? How many filemanamgers? Once again the header thing bothers me. Sorry I'm ranting. Anyways, as things move along it should get better as we will be able to share the headers, programs, and librarys with WINE and Mingw. As of right now though I dont know how much more I can do with my limited skill. So who wants to do it? In another few weeks/month we are going to need to to try and get WINEmine, notepad and win/winefile working and import shell32, comctl32 and comdlg32. I'm going to keep submitting patches to the winehq.com tree as I find fun and interesting stuff. I still want to work toward having a drop in replacement with the "bleeding edge". My hope is that ReactOS will one day work off of the stable wine 1.0 if it is ever released =) and people that want the cutting edge can build wine 1.x dlls/programs for a ReactOS system. Most of my work from now on though is going to focus documentation, testing and spreeding the word about OpenSource, ReactOS, Wine and Mingw. Thanks Steven __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com

1 0

Compilation errors when using CFLAGS=-g
by Shachar Shemesh 17 Aug '02

17 Aug '02

I did the following: make dist-clean CFLAGS=-g ./configure make depend make For some strange reason, I get the following errors: make[2]: Entering directory `/home/sun/sources/wine/wine/programs/winhelp' gcc -o hlp2sgml hlp2sgml.o hlpfile.o hlpfile.o: In function `HLPFILE_ReadHlpFile': /home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:205: undefined reference to `GetProcessHeap' /home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:238: undefined reference to `GetProcessHeap' /home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:239: undefined reference to `GetProcessHeap' /home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:240: undefined reference to `GetProcessHeap' /home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:241: undefined reference to `GetProcessHeap' hlpfile.o:/home/sun/sources/wine/wine/programs/winhelp/hlpfile.c:337: more undefined references to `GetProcessHeap' follow collect2: ld returned 1 exit status make[2]: *** [hlp2sgml] Error 1 make[2]: Leaving directory `/home/sun/sources/wine/wine/programs/winhelp' make[1]: *** [winhelp] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/wine/programs' make: *** [programs] Error 2 The exact same line of code failing in this file works without a problem in a hundred other places throughout the code, and when not overriding the flags (that is, if I understand correctly, when -g -O2 is used), everything is fine. Now, I don't need this file for my tests, so I just skip compiling it, but the problem is .... wierd. Anyone has any insight into it? sun@sun:~/sources/wine/wine/programs/winhelp$ cvs stat hlpfile.c =================================================================== File: hlpfile.c Status: Up-to-date Working revision: 1.9 Tue Jul 16 01:46:29 2002 Repository revision: 1.9 /home/sun/sources/wine/cvs/wine/programs/winhelp/hlpfile.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)

1 0

Re: Agent crashes on accessing Disk
by Rein Klazes 17 Aug '02

17 Aug '02

On Wed, 14 Aug 2002 20:40:10 +0200, you wrote: > On Mon, 12 Aug 2002 20:45:10 +0200, Rein Klazes <rklazes(a)xs4all.nl> > wrote: > > >On Mon, 12 Aug 2002 13:49:45 +0200, you wrote: > > > > > >> The output from the relay messages, although voluminous, didn't > >> contain a "starting debugger" message. > > > >Probably the way I've set up the debugger here. Still you should be > >able to find the spot, accompanied by "EXC_RtlRaiseException" and > >"UnhandledExceptionFilter". I see those in the backtrace. > > hi, > Did you (or the list) get enough information from what I posted to > begin looking at the problem? Do you need a more info? > Oliver, you gave an good backtrace showing where the application crashed (function TOOLBAR_Referesh in toolbar.c around line 976). It looks like some part of the data concerning the toolbar buttons is not properly initialised (or got corrupted). Unfortunately it does not show why this happened (and why it happens with not you and not anyone else). Therefore you should try to produce the --debugmsg +relay output, and while you are at it better the --debugmsg +relay,+toolbar output. If you cannot cut this log to the interesting part, then zip or bzip2 the complete output, put it somewere on the net and give us the URL or mail it to me. I will compare your output with a similar one here, perhaps that gives some insight. When did this problem start? If by upgrading wine, which versions. Anything else changed on your system? The file dialog that crashes for you opens the last used directory. This directory can be found/inspected/changed in agent.ini. Try to change it, see if that makes a difference. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

[Fwd: Re: New user/developer has questions ...]
by Vincent Béron 16 Aug '02

16 Aug '02

Crispen, I think the list will appreciate your reply as well :) Vincent

1 0

rhlx01 cvs mirror "downtime"
by Andreas Mohr 16 Aug '02

16 Aug '02

Hi all, unfortunately the rhlx01 cvs mirror has been "down" for some days (no cvs syncs) due to a mail loop and thus the main admin having disabled the procmail processing. It should be properly updating the mirror again now that I've fixed my BROKEN mail processing ;-) Let me know if it's still broken for some reason. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

right way to compile wine with a "buildroot" DESTDIR is missing
by Raul Dias 16 Aug '02

16 Aug '02

Hi, I have been building wine RPMs for some time now. The way I do is to specify the correct paths to ./configure script (like prefix, mandir, bindir, ...). After building I have to use an ugly make install in orther to install it into another dir that is different from the one. However, talking to some wine developers on #winehq in openprojects network. They state that a ./configure --prefix=<you buildroot>/prefix was enough. That's because wine does not hardcode any %prefix related path. This would simplify a lot the process. However I just checked that wine does hardcode the %prefix dir in the binaries. This is done in dlls/ntdll/ntdll.dll.so and possible at miscemu/wine . AFAIU, this is done to keep the path to the global registries which is the Right Thing to do. So what I really would like to know is which way is the right way to install wine in a dir different than %prefix or /usr/local (default %prefix)? Is there any chance to get a DESTDIR implemented in the Makefiles? []'s Raul Dias

4 12

microsoft CFileDialog problem
by mayonaise＠beer.com 16 Aug '02

16 Aug '02

hi everybody, i am currently working on making a windows program function in wine. it works for the most part, so i'm trying to iron out a few critical bugs. first off... i'm looking at microsoft's CFileDialog class - it is what the standard windows 'open file' and 'save file' dialog windows use. the problem is this: CFileDialog has a built in function called OnFolderChange, that is used to determine whether the user has changed folders in the dialog, whether by double click or what not.. the program i'm working on overrides the CFileDialog class, and includes more code for the OnFolderChange function (and for other functions) for its own purposes. the new OnFolderChange function works perfectly fine in windows, but is completely ignored when using wine - it never even gets called, while the rest of the dialog window retains all of its intended functionality. as a reference, the built in functions OnFileNameChange, GetFolderPath, and others gets overridden successfully. as far as i can tell, the only function that is not working properly is the OnFolderChange function. the overriding of CFileDialog was accomplished by using a hooking procedure provided in the MSDN library. i hope this is enough information, however i don't expect anyone to fully be able to address this issue without seeing the code i'm working on first.thank you for your time! -kyle

2 1

note to packagers (new optional dependancy)
by Shachar Shemesh 16 Aug '02

16 Aug '02

Hi all, A patch just submitted to wine-patches changes the rules when building binary packages of WINE for distributions. This is an optional change, so ignoring this email will not break anything, but will result in decreased functionality. During the configure phase ./configure will now check for the availability of the libfribidi header files. These are typically distributed in a package called "libfribidi-dev". I would highly recommend installing this library on the machine you compile the package on, so as to include the option for BiDi support in the resulting binary. If the headers are found during compile time, a run time check is performed whether the libfribidi library is available. If it is not, Wine will continue without BiDi support. If it is, BiDi support will (at some future date, admitably) be enabled. In .deb speak, libfribidi-dev is build recommended for wine src. libfribidi is suggested for wine. Shachar

2 1

RE: New user/developer has questions ...
by Medland, Bill 16 Aug '02

16 Aug '02

> -----Original Message----- > From: Crispen Scott [mailto:C.Scott@astronautics.com] > Sent: Friday, August 16, 2002 6:56 AM > To: wine-devel(a)winehq.com > Subject: New user/developer has questions ... > > > I have just RPMed wine-20020512-1.i386.rpm and attempted to > run several WIN > programs (to wit: sol.exe and a proprietary package). > Both fail. I am including the entire run/error message from > my attempt to run > sol.exe below. Being new to WINE, I have no idea where > to begin to find the problem. I have annotated the error > message with notes. > All notes are separated by a > > <NOTE - TEXT> then a CR and follows the line(s) that the NOTE > applies to. > > [root@localhost root]# wine /mnt/windows/windows/system32/sol.exe > <NOTE - This is the command line entry > > > err:reg:_convert_win95_registry_to_wine_format unable to load > native win95 > registry file C:\WINDOWS\system.dat: unknown signature. > err:reg:_convert_win95_registry_to_wine_format Unable to load > native win95 > registry file C:\WINDOWS\system.dat. > err:reg:_convert_win95_registry_to_wine_format Please report to > a.mohr(a)mailto.de. > err:reg:_convert_win95_registry_to_wine_format Make a backup > of the file, run > a good reg cleaner program and try again! > <NOTE - The SYSTEM.DAT file located in the windows SUBDIR was > exported from > regedit.exe. This is from a WIN2K OS > That's your mistake. You shouldn't export it. reg_convert_win95_registry_to_wine_format actually reads the files that store a Win95 registry (the actual files, not exports). > > fixme:win32:PE_CreateModule Security directory ignored > <NOTE - I assume this is a FIXME in the SRC> True > > err:font:AddFontFileToList Unable to load font file > "/mnt/windows/windows/Fonts/desktop.ini" err = 55 > <NOTE - This file exists in the proper location so what is the error?> I don't know the font stuff; someone else maybe will help here. > > err:font:AddFontFileToList Already loaded font L"Garamond" L"Bold" > err:font:AddFontFileToList Already loaded font L"Garamond" L"Italic" > err:font:AddFontFileToList Already loaded font L"Garamond" L"Regular" > > err:font:AddFontFileToList Unable to load font file > "/mnt/windows/windows/Fonts/modern.fon" err = 2 > err:font:AddFontFileToList Unable to load font file > "/mnt/windows/windows/Fonts/mtsorts.ttf" err = 2 > err:font:AddFontFileToList Unable to load font file > "/mnt/windows/windows/Fonts/roman.fon" err = 2 > err:font:AddFontFileToList Unable to load font file > "/mnt/windows/windows/Fonts/script.fon" err = 2 > <NOTE - These files exist so why are they able to be loaded?> > > X Error of failed request: XF86DGANoDirectVideoMode > Major opcode of failed request: 136 (XFree86-DGA) > Minor opcode of failed request: 22 (XDGAOpenFramebuffer) > Serial number of failed request: 181 > Current serial number in output stream: 181 > <NOTE - What does this indicate?> > > I am trying to come up to speed on the use of WINE but, as > everyone knows, > the documentation is a little light > as is the commenting of the source code. If someone could > please head me in > the right direction, I would greatly appreciate it. > > Once I have gained some additional expertise in WINE I will > use my 15+ years > of Windows development experience and knowledge > to try and resolve some of the issues and bugs that are > reported. This may > take me several more weeks. > > I am also intending to write a technical book on WINE so will > submit chapters > for review to the community as the become available. > Much of the information will deal with the issues the I, as a > newbie, am > encountering. > > I await the response. > > Crispen Scott > > BTW: I downloaded the source for 20020804 and, after fixing > several build > related problems (incorrect build order, root objections, & > eliminating > programs with build problems I couldn't readily resolve, i.e. > widl), I had > even worse problems with trying to get that version of wine > to run. That is > why I reverted to the latest RPM version. Some of the > problems with the > 20020804 build might be resolved after I see the answers to > the problems I > stated above. > > I am excited about becoming an integral part of this > community but need some > start-up help! > Thanks! > > -- > Crispen Scott > Engineer - Software > Astronautics.com > 4115 Teutonia Road > Milwaukee, WI 53209 > Tel: 414-447-8200 x4434 > C.Scott(a)Astronautics.com > What is your environment; you shouldn't have had all those build problems. Bill

4 3

RFC: winedefault.reg
by lawson_whitney＠juno.com 16 Aug '02

16 Aug '02

Good day! Should we maybe install it somewhere in --prefix so it has a chance to get included in binary packages? I have one in /usr/local, but it is from April 19, 2001 and not much use... Lawson ---oops---

2 1

RE: window parent/owner handling
by Medland, Bill 16 Aug '02

16 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Thursday, August 15, 2002 8:22 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: window parent/owner handling > > > "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > > Includes my previous patch for SetWindowLong (for Bug 825) > > Seems that your investigations are correct, at least test succeeds > under win2000. I would suggest to apply tiny patch (attached) to catch > some additional problems. Thanks Dmitry; for all your help on this. p.s. I suddenly realised I'd put only my name on the copyright in the test. It's based on your code; You want to be mentioned? (Or is this sufficient ackowledgement?). > > -- > Dmitry. > Bill

2 1

FW: what's with WS_OVERLAPPED?
by Medland, Bill 16 Aug '02

16 Aug '02

(Damn; Outlook bugs me) -----Original Message----- From: Medland, Bill Sent: Friday, August 16, 2002 8:19 AM To: 'rolf.kalbermatter(a)citeng.com' Subject: RE: what's with WS_OVERLAPPED? > -----Original Message----- > From: Rolf Kalbermatter [mailto:r.kalbermatter@hccnet.nl] > Sent: Thursday, August 15, 2002 11:31 PM > To: Bill.Medland(a)accpac.com > Cc: wine-devel(a)winehq.com > Subject: RE: what's with WS_OVERLAPPED? > > > On Thu, 15 Aug 2002 "Medland, Bill" <Bill.Medland(a)accpac.com> wrote > > > >> On Wednesday, August 14, 2002 Ove Kaaven [mailto:ovehk@ping.uio.no] > wrote: > > <snip> > > >> WS_OVERLAPPED is in practice considered the absence of the > >> WS_POPUP and > >> WS_CHILD flags, I believe. > > > >Thanks Ove; that'll do for a working hypothesis. (I wish > Microsoft would > be > >consistant) > > > >Just for the record it is clearly more complex than that. I > guess since > >Microsoft wrote it we can trust Spy++ a little. I have seen > spy++ declare > >that a "tooltips" class window (style 0x84800000/00000088) has style > >WS_OVERLAPPED whereas a "tooltips_class32" class window (style > >0x84800003/00000088) doesn't. > > Hmm, this is just a wild guess but couldn't it be that the > WS_OVERLAPPED > style applies only to the lower word of the windows style. > Windows coming > from 16bit DOS it wouldn't be surprising if the original > windows style was > 16 bit only as well. Either that or Spy++ has a bug, even > though you trust > it so much ;-). Except all the general style stuff is in the top word; the only difference between the two styles, the 3, is two TTS_* toolbar style; generally the stuff in the low word is, I believe, control-specific. I honestly think that it is not so much that Spy++ has a bug as that it is based on some knowledge within Microsoft that describes how they have worked around the mess they have generated over the years. > > Rolf Kalbermatter > mailto:rolf.kalbermatter@citeng.com > > Bill

1 0

New user/developer has questions ...
by Crispen Scott 16 Aug '02

16 Aug '02

I have just RPMed wine-20020512-1.i386.rpm and attempted to run several WIN programs (to wit: sol.exe and a proprietary package). Both fail. I am including the entire run/error message from my attempt to run sol.exe below. Being new to WINE, I have no idea where to begin to find the problem. I have annotated the error message with notes. All notes are separated by a <NOTE - TEXT> then a CR and follows the line(s) that the NOTE applies to. [root@localhost root]# wine /mnt/windows/windows/system32/sol.exe <NOTE - This is the command line entry > err:reg:_convert_win95_registry_to_wine_format unable to load native win95 registry file C:\WINDOWS\system.dat: unknown signature. err:reg:_convert_win95_registry_to_wine_format Unable to load native win95 registry file C:\WINDOWS\system.dat. err:reg:_convert_win95_registry_to_wine_format Please report to a.mohr(a)mailto.de. err:reg:_convert_win95_registry_to_wine_format Make a backup of the file, run a good reg cleaner program and try again! <NOTE - The SYSTEM.DAT file located in the windows SUBDIR was exported from regedit.exe. This is from a WIN2K OS > fixme:win32:PE_CreateModule Security directory ignored <NOTE - I assume this is a FIXME in the SRC> err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/desktop.ini" err = 55 <NOTE - This file exists in the proper location so what is the error?> err:font:AddFontFileToList Already loaded font L"Garamond" L"Bold" err:font:AddFontFileToList Already loaded font L"Garamond" L"Italic" err:font:AddFontFileToList Already loaded font L"Garamond" L"Regular" err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/modern.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/mtsorts.ttf" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/roman.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/script.fon" err = 2 <NOTE - These files exist so why are they able to be loaded?> X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 136 (XFree86-DGA) Minor opcode of failed request: 22 (XDGAOpenFramebuffer) Serial number of failed request: 181 Current serial number in output stream: 181 <NOTE - What does this indicate?> I am trying to come up to speed on the use of WINE but, as everyone knows, the documentation is a little light as is the commenting of the source code. If someone could please head me in the right direction, I would greatly appreciate it. Once I have gained some additional expertise in WINE I will use my 15+ years of Windows development experience and knowledge to try and resolve some of the issues and bugs that are reported. This may take me several more weeks. I am also intending to write a technical book on WINE so will submit chapters for review to the community as the become available. Much of the information will deal with the issues the I, as a newbie, am encountering. I await the response. Crispen Scott BTW: I downloaded the source for 20020804 and, after fixing several build related problems (incorrect build order, root objections, & eliminating programs with build problems I couldn't readily resolve, i.e. widl), I had even worse problems with trying to get that version of wine to run. That is why I reverted to the latest RPM version. Some of the problems with the 20020804 build might be resolved after I see the answers to the problems I stated above. I am excited about becoming an integral part of this community but need some start-up help! Thanks! -- Crispen Scott Engineer - Software Astronautics.com 4115 Teutonia Road Milwaukee, WI 53209 Tel: 414-447-8200 x4434 C.Scott(a)Astronautics.com

2 1

RE: what's with WS_OVERLAPPED?
by Rolf Kalbermatter 16 Aug '02

16 Aug '02

On Thu, 15 Aug 2002 "Medland, Bill" <Bill.Medland(a)accpac.com> wrote > >> On Wednesday, August 14, 2002 Ove Kaaven [mailto:ovehk@ping.uio.no] wrote: <snip> >> WS_OVERLAPPED is in practice considered the absence of the >> WS_POPUP and >> WS_CHILD flags, I believe. > >Thanks Ove; that'll do for a working hypothesis. (I wish Microsoft would be >consistant) > >Just for the record it is clearly more complex than that. I guess since >Microsoft wrote it we can trust Spy++ a little. I have seen spy++ declare >that a "tooltips" class window (style 0x84800000/00000088) has style >WS_OVERLAPPED whereas a "tooltips_class32" class window (style >0x84800003/00000088) doesn't. Hmm, this is just a wild guess but couldn't it be that the WS_OVERLAPPED style applies only to the lower word of the windows style. Windows coming from 16bit DOS it wouldn't be surprising if the original windows style was 16 bit only as well. Either that or Spy++ has a bug, even though you trust it so much ;-). Rolf Kalbermatter mailto:rolf.kalbermatter@citeng.com

1 0

Re: wine/ dlls/gdi/Makefile.in dlls/gdi/bidi16.c d ...
by Dimitrie O. Paun 16 Aug '02

16 Aug '02

On August 15, 2002 08:42 pm, Alexandre Julliard wrote: [...] > Log message: > Moved a large number of 16-bit functions to a separate gdi16.c file. This is a great idea that I've been advocating for a loooong time now <g>. I think moving 16 bit code into separate files is cool: -- runtime efficiency: If 16 bit code is not invoked, it's not going to be paged in during execution -- code neatness: developers working on the 32-bit code (which is _the_ code in Wine) will not get distracted by silly 16-to-32-to-16 bit conversions. -- helps correctness: 16-bit code is in general a simple: 16-to-32 bit conversion call the 32-bit equivalent function 32-to-16 bit conversion Which means there is a lot of repetition, template-like coding. Any departure from the usual pattern is a *lot* more easily spotted by the naked eye if it's present in a file that does just that. -- 16-to-32 bit: we can more easily see (and fix) cases where 32 bit code calls 16 bit code. For all these reasons, I think we should have _all_ 16-bit code into separate files. Always. Who knows, maybe we can have makefiles done such a way that we can avoid compiling 16 bit code altogether! :) Even if only as a simple check that no 32 bit code calls down to 16 bit... And again, the _same_ rationale applies to xxxW & xxxA functions, but I'll not pursue this point for now ;). -- Dimi.

1 0

Re: window parent/owner handling
by Dmitry Timoshkov 16 Aug '02

16 Aug '02

"Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > Includes my previous patch for SetWindowLong (for Bug 825) Seems that your investigations are correct, at least test succeeds under win2000. I would suggest to apply tiny patch (attached) to catch some additional problems. -- Dmitry.

1 0

RE: Some observations on window parentage etc.
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland@accpac.com] > Sent: Thursday, August 15, 2002 8:59 AM > To: Wine devel (E-mail) > Subject: Some observations on window parentage etc. > > > Here are some observations with regard to Window > parentage/ownership etc. snip > > More to follow. > > Bill > OK guys; who can justify the claim in the server (set_window_owner) that the owner and the window must have the same parent? I think it is untrue, but I don't know what it should be. I believe we need to extend the WIN_SetOwner to return the previous owner. Should we take that out of the structure on the user side or should we modify the server reply to return it? I guess modifying the server reply is the safer option and should have no performance penalty. So here is what I am looking at doing. (I'd prefer comments here rather than after I submit the patch) 1. Modify the set_window_owner reply to return both the new full handle and the previous full handle. (p.s. what is this full handle anyway? Why is it different from the one passed in the request?) 2. Modify the set_window_owner handler to fill in the reply and also remove the parent test (or replace it with anything you guys think makes sense) 3. Modify WIN_SetOwner to return the value 4. Leave GetParent as it is 5. Modify GetWindowLong (GWL_HWNDPARENT to return the parent if a WS_CHILD and the owner otherwise (even if not a WS_POPUP) 6. Modify GetAncestor (GA_ROOTWINDOW) to return the same as recursing on GetParent. 7. Write a test set. Comments? Bill

1 0

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Thursday, August 15, 2002 10:00 AM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > > > "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > > (Do you want the test case code?) > > Why not? :-) > > -- > Dmitry. > > > First is without WS_POPUP, second is with

1 0

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Thursday, August 15, 2002 9:17 AM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > > > "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > > Honest question : how do you know the parent is changing? > by calling > > GetWindowLong (GWL_HWNDPARENT)? > > Yes, and verifying the result in Spy++. (As discussed in my other email) I guess Spy++ is displaying the result of GetWindowLong > > > I believe that it is the owner that is changing and the > parent (as returned > > by getAncestor (GA_PARENT) willl be unchanged. > > Hmm, I didn't try GetAncestor(), only GetWindowLong() and GetParent(). (Do you want the test case code?) > > -- > Dmitry. > > >

2 1

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Tuesday, August 13, 2002 6:33 PM > To: us(a)the-edmeades.demon.co.uk > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > snip > Could you please test patch posted by Bill Medland to > wine-patches today? It's > not entirely correct though. My tests show that > SetWindowLong(GWL_HWNDPARENT) > call changes simultaneously both parent and owner for top > level windows and > returns old value (not sure old owner or parent it is). Honest question : how do you know the parent is changing? by calling GetWindowLong (GWL_HWNDPARENT)? I believe that it is the owner that is changing and the parent (as returned by getAncestor (GA_PARENT) willl be unchanged. snip Bill

2 1

Some observations on window parentage etc.
by Medland, Bill 15 Aug '02

15 Aug '02

Here are some observations with regard to Window parentage/ownership etc. Clearlt Microsoft documentation is quite out of date and contradictory on the subject these days so we are going to have to experiment and find out what actually happens. We also are going to have to be careful about terminology and not jumping to conclusions. I mean what ther heck are we supposed to think when Spy++ shows a window as a top-level window (by which I mean just below the desktop in the listview that Spy++ uses), tells us that its parent is its owner (a different top-level window) but that "parent" says it has no children. So. 1. GetParent does not necessarily return the same value as GetWindowLong (GWL_HWNDPARENT). I have seen GetParent returning 0 while GetWindowLong returns the same non zero value as GetWindow (GW_OWNER). 2. GetAncestor (GA_PARENT) seems to be the best way to get the "true parent". 3. WIN_CreateWindowEx is currently slightly wrong. I know MSDN says don't mix WS_POPUP and WS_CHILD but if you do then the result is wrong, I believe. However I am loth to fix it and submit the patch because that really messes everything else up so I guess we need a bigger patch first. (Heck, even under windows 98 you can get the kernel to fall over rather easily this way). 4. I don't like the look of GetAncestor (GA_ROOTOWNER). The MSDN documentation suggests that it should return the result of recursively calling GetParent (or should it be recursively calling GetWindowLong (GWL_HWNDPARENT) whereas GetAncestor (GA_ROOT) should return the result of recursively calling GetAncestor (GA_PARENT) (each stopping just before the desktop, of course). (And of course that is definition, not necessarily mechanism) More to follow. Bill

1 0

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