- Wine-Devel - list.winehq.org

d3d8-18 patch doesn't compile on RedHat 9.0
by erwin wolff May 11, 2003

May 11, 2003

I have a problem with the d3d8 patch. First, the ./configure script skips the dlls/d3d8 and secondly, if I compile the files manually with the Makefile the source files do compile with almost no warnings, but when it is linked it to d3d8.dll.so complains about lots of GL definitions missing. An example: device.o(.text+0x44dc):/TOOLS/wine/dlls/d3d8/device.c:1770: undefined reference to "glGetError" with the configure command: ./configure --with-nptl --with-x All GL header files are at their correct place and are found by the configure script and makefiles.

3 2

DECIMAL struc
by Stefan Leichter May 11, 2003

May 11, 2003

Hello, i am currently trying to compile a source which uses the DECIMAL stuct with wine's headers and gcc 2.95.3 but i can not figure out how to access the members Mid32 and Lo32 of the struc. Can someone please tell me how to do this? Thanks Stefan

2 3

Re: winedos / Migrate current drive routines and add date conversions
by György 'Nog' Jeney May 11, 2003

May 11, 2003

> This patch migrates some int21 stuff to winedos and > adds implementation for long file name date conversion > functions. The patch makes kernel dll export current drive > routines, but using those routines it should be possible to > migrate many additional int21 subfunctions to winedos. > > > > > Changelog: > Move current drive subfunctions to winedos. > Add long file name date conversion subfunctions. > Could someone please explain to me why it is not possible to reimplement DRIVE_GetCurrentDrive in winedos like this, it looks quite simple and straight forward: int GetCurrentDrive() { char root[MAX_PATH]; GetCurrentDirectoryA(MAX_PATH, root); return toupper(*root) - 'A'; } and the same question for DRIVE_SetCurrentDrive: void SetCurrentDrive(int drive) { char drive[] = "A:"; *drive += drive; SetCurrentDirectoryA(drive); } nog.

1 0

patch for redhat spec file.
by Knut J Bjuland May 11, 2003

May 11, 2003

This is a ugly fix, at least it correct the fault with unable to load libntdll.dll.so when starting wine from a installed Redhat RPM. This spec is made for Redhat 9. --- old.spec 2003-05-09 03:29:21.000000000 +0200 +++ wine-20030508-1rh8winehq.spec 2003-05-10 08:17:28.000000000 +0200 @@ -54,7 +54,8 @@ --with-x \ --libdir=%{_libdir}/wine \ --includedir=%{_includedir}/wine \ - --sysconfdir=%{_sysconfdir}/wine + --sysconfdir=%{_sysconfdir}/wine \ + --with-nptl %{__make} depend %{__make} @@ -67,7 +68,7 @@ includedir=%{?buildroot:%{buildroot}}%{_includedir}/wine \ libdir=%{?buildroot:%{buildroot}}%{_libdir}/wine \ sysconfdir=%{?buildroot:%{buildroot}}%{_sysconfdir}/wine \ - dlldir=%{?buildroot:%{buildroot}}%{_libdir}/wine/wine \ + dlldir=%{?buildroot:%{buildroot}}%{_libdir}/wine \ LDCONFIG=/bin/true install -c -m 0644 dlls/*.def $RPM_BUILD_ROOT%{_libdir}/wine @@ -103,22 +104,22 @@ rm -f documentation/samples/config.rh # Install link to windows applications replacements -ln -sf %{_libdir}/wine/wine/start.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/command/start.exe -ln -sf %{_libdir}/wine/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/notepad.exe -ln -sf %{_libdir}/wine/wine/regedit.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/regedit.exe -ln -sf %{_libdir}/wine/wine/rundll32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/rundll32.exe -ln -sf %{_libdir}/wine/wine/wcmd.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/cmd.exe -ln -sf %{_libdir}/wine/wine/control.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/control.exe -ln -sf %{_libdir}/wine/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/help.exe -ln -sf %{_libdir}/wine/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/notepad.exe -ln -sf %{_libdir}/wine/wine/progman.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/progman.exe -ln -sf %{_libdir}/wine/wine/regsvr32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/regsvr32.exe -ln -sf %{_libdir}/wine/wine/winemine.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winmine.exe -ln -sf %{_libdir}/wine/wine/winver.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winver.exe -ln -sf %{_libdir}/wine/wine/uninstaller.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/uninstaller.exe -ln -sf %{_libdir}/wine/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhelp.exe -ln -sf %{_libdir}/wine/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhlp32.exe - +ln -sf %{_libdir}/wine/start.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/command/start.exe +ln -sf %{_libdir}/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/notepad.exe +ln -sf %{_libdir}/wine/regedit.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/regedit.exe +ln -sf %{_libdir}/wine/rundll32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/rundll32.exe +ln -sf %{_libdir}/wine/wcmd.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/cmd.exe +ln -sf %{_libdir}/wine/control.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/control.exe +ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/help.exe +ln -sf %{_libdir}/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/notepad.exe +ln -sf %{_libdir}/wine/progman.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/progman.exe +ln -sf %{_libdir}/wine/regsvr32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/regsvr32.exe +ln -sf %{_libdir}/wine/winemine.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winmine.exe +ln -sf %{_libdir}/wine/winver.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winver.exe +ln -sf %{_libdir}/wine/uninstaller.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/uninstaller.exe +ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhelp.exe +ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhlp32.exe +ln -f $RPM_BUILD_ROOT/%{_libdir}/wine/ntdll.dll.so $RPM_BUILD_ROOT/%{_libdir}/wine/libntdll.dll.so for i in shell.dll shell32.dll winsock.dll wnsock32.dll; do touch $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/$i done @@ -202,10 +203,7 @@ %attr(0775, root, wine) %dir "%{_datadir}/wine-c/My Documents" %attr(0775, root, wine) %dir "%{_datadir}/wine-c/Program Files" %attr(0775, root, wine) %dir "%{_datadir}/wine-c/Program Files/Common Files" -%{_libdir}/wine/wine -%{_libdir}/wine/*.so -%{_libdir}/wine/*.so.1 -%{_libdir}/wine/*.a +%{_libdir}/wine/* %{_bindir}/* %{_mandir}/man?/* %{_datadir}/wine-c/windows/command/*.exe @@ -227,31 +225,31 @@ %files devel %defattr(-,root,root) %{_includedir}/* -%{_libdir}/wine/*.def +#%{_libdir}/wine/*.def %changelog -* Thu May 08 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030508-1 +* Thu May 08 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030508-1 - Add libraries definition files to devel package - Update to 20030508 -* Tue Apr 08 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030408-1 +* Tue Apr 08 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030408-1 - Update to 20030408 -* Tue Mar 18 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030318-1 +* Tue Mar 18 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030318-1 - Update to 20030318 -* Thu Mar 11 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030219-2 +* Thu Mar 11 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030219-2 - Fix the symlinks in wine-c. -* Wed Feb 19 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030219-1 +* Wed Feb 19 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030219-1 - Update to 20030129 - Various fixes in RPM build process -* Fri Jan 17 2003 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20030115-1 +* Fri Jan 17 2003 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20030115-1 - Update to 20030115 - fix to build problem -* Thu Nov 7 2002 Vincent Béron <vberon(a)mecano.gme.usherb.ca> 20021031-1 +* Thu Nov 7 2002 Vincent BÃ©ron <vberon(a)mecano.gme.usherb.ca> 20021031-1 - Update to 20021031 - Tweaks here and there

4 3

Agent opens on another desktop (revisited)
by Gerhard W. Gruber May 10, 2003

May 10, 2003

I just happend to install OpenOffice on my system and while the installation was running I switched to another desktop. When OO installation was finished, a dialog popped up, telling me so. The mahor difference to wine running Agent is, that Agent opened the new dialog on my current desktop, while the OO installer switched me back to the desktop where I launched the main program and showed me the dialog there. Either they did provide for this specifically or they use a different method. How does wine handle this? Could it be that wine retrieves the desktop info always anew and OO maybe only at startup and passes it on? My guess would be that this happens in OO, so I think it would be better to do this in wine as well. I think it is rather counterintutive when suddenly a messagebox or something pops up out of nowhere. Also there could be circumstances where a dialog or messagebox is hidden because the user just switched. These circumstances could be provided for if the windows for an application stay on the same desktop where the main app is running. This doesn't mean that wine should run entirely on the same desktop it started from, only indivudual applications should. I don't know enough of the X lower stuff, so maybe somebody who knows this area could comment on it. Thanks. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

W95INF32.DLL added to wine
by Gerhard W. Gruber May 10, 2003

May 10, 2003

I just sent the patch for adding the w95inf32 dll to the wine sources. I hope that the patch script is ok. I used diff -u for the tree, but I was not so sure about on how to do the new directory. I was following the instructions on WineHQ concerning the files, but it is nowhere mentioned if a new directory will be automatically created, so I trust this is enough. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

NPTL auto detection
by Mike Hearn May 10, 2003

May 10, 2003

Hi Alexandre, You said a few months ago Wine would soon detect whether to enable NPTL support at runtime rather than compile time. Presumably this will get in as part of the CodeWeavers merge. Do you know how long that might be? It seems every day people hit this problem and don't realise how to work around it. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

8 14

Progman DDE Server
by BiGgUn May 10, 2003

May 10, 2003

Hi, While installing, mIRC 6.0.3 (evaluation), the installer was unable to create some links for mirc. I got the following error: err:ddeml:DdeConnect Done with INITIATE, but no Server window available Obviously, it seems that the required DDE server is not up and runnning. By enabling tracing on ddeml channel, i have found the queried server; it's Progman DDE server. On win2k (and other windows platforms i think), it seems that this server is launched when the system starts up or when a user logs in (i don't really know). Nevertheless, on wine this DDE server is not currently launched. Although, the progman application exists, is there a DDE server version already present in wine source tree ? Other question, when a program requires the Progman DDE server , should wine launch it automatically ? The DDE server would shutdown itself when the last wine instance exits. Is it possible to associate this DDE server with wineserver ? Stéphan

2 1

Re: Listview: Implemented Get/SetToolTips functions (rewrite)
by Dimitrie O. Paun May 10, 2003

May 10, 2003

On May 10, 2003 03:51 am, BiGgUn wrote: > Hi, > > > > +static HWND LISTVIEW_SetToolTips( LISTVIEW_INFO *, HWND); > > > > I don't think you need these here. > > Dimitry, should i inline LISTVIEW_SetToolTips also ? Hey, my name is Dimitrie or Dimi :) > In this patch, LISTVIEW_SetToolTips is not inlined. No, that's fine, setters are not inlined currently. > static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *); > static BOOL LISTVIEW_EnsureVisible(LISTVIEW_INFO *, INT, BOOL); > static HWND CreateEditLabelT(LISTVIEW_INFO *, LPCWSTR, DWORD, INT, INT, INT, INT, BOOL); > +static HWND LISTVIEW_SetToolTips( LISTVIEW_INFO *, HWND); Why do you need this prototype here? I don't think it's needed, you don't use the function before the definition. > > +static HWND LISTVIEW_SetToolTips( LISTVIEW_INFO *infoPtr, HWND hwndNewToolTip) > +{ > + HWND hwndOldToolTip = infoPtr->hwndToolTip; Indentation seems to be hosed here, no? > + infoPtr->hwndToolTip = hwndNewToolTip; > + return hwndOldToolTip; > +} > + > /* LISTVIEW_SetUnicodeFormat */ > /* LISTVIEW_SetWorkAreas */ > > @@ -7214,7 +7241,7 @@ > GetWindowLongW(infoPtr->hwndHeader, GWL_STYLE) | HDS_HIDDEN); > } > } > - > + Please avoid such no-op changes, they make the patch longer for no good reason. I'm kinda picky, right? :) -- Dimi.

1 0

Re: Listview: Implemented Get/SetToolTips functions
by Dimitrie O. Paun May 9, 2003

May 9, 2003

On May 9, 2003 02:45 pm, BiGgUn wrote: > static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *); > static BOOL LISTVIEW_EnsureVisible(LISTVIEW_INFO *, INT, BOOL); > static HWND CreateEditLabelT(LISTVIEW_INFO *, LPCWSTR, DWORD, INT, INT,INT, INT, BOOL); > +static HWND LISTVIEW_GetToolTips( LISTVIEW_INFO *); > +static HWND LISTVIEW_SetToolTips( LISTVIEW_INFO *, HWND); I don't think you need these here. > /******** Text handling functions *************************************/ > > @@ -5729,6 +5741,20 @@ > > /*** > * DESCRIPTION: > + * Returns tooltip associated to the listview > + * > + * PARAMETER(S): > + * [I] infoPtr : valid pointer to the listview structure > + * > + * RETURN: > + * Handle on listview tooltip > + */ > +static HWND LISTVIEW_GetToolTips( LISTVIEW_INFO *infoPtr) { > + return infoPtr->hwndToolTip; > +} Please just inline this one in the WinProc, the file is already too big and hard to maintain. > +/*** > + * DESCRIPTION: > + * Determines which listview item is located at the specified position. > + * > + * PARAMETER(S): > + * [I] infoPtr : valid pointer to the listview structure > + * [I] hwndNewToolTip : handle to new ToolTip > + * > + * RETURN: > + * old tool tip > + */ > +static HWND LISTVIEW_SetToolTips( LISTVIEW_INFO *infoPtr, HWND hwndNewToolTip) { Please follow the bracket convention used in the rest of the file. Indentation is currently mixed 2 or 4 space, please use 4 going forward. > + HWND hwndOldToolTip = infoPtr->hwndToolTip; > + infoPtr->hwndToolTip = hwndNewToolTip; > + return hwndOldToolTip; > +} Don't we need to do something with the new tool tip? I guess it's not part of this patch... :) > + /* init ToolTip */ > + infoPtr->hwndToolTip = NULL; Is this needed? Isn't the info structure initialized to 0? > > case LVM_GETTOOLTIPS: > - FIXME("LVM_GETTOOLTIPS: unimplemented\n"); > - return FALSE; > + return (LRESULT)LISTVIEW_GetToolTips(infoPtr); Yeah, just make this one: + return (LRESULT)infoPtr->hwndToolTip; -- Dimi.

1 0