wine-devel March 2004

wine-devel@winehq.org

128 participants
264 discussions

Re: Warn If GetProcAddress Fails
by Kevin Koltzau 09 Mar '04

09 Mar '04

Many apps dynamically bind to entry points to determine if features in Windows are available as well, This may cause quite a few apps to report huge numbers of warnings when there is actually nothing wrong On Monday 08 March 2004 08:44 pm, Robert Shearman wrote: > Many applications dynamically bind to entry points and can fail in > strange ways if they are not found. This patch enables users to see any > failing GetProcAddress calls that could be responsible for bad > behaviour.

2 1

vsnprintf: glibc and win32 not compatible
by Jesse Allen 09 Mar '04

09 Mar '04

Hi, Here I have filed a bug on vsnprintf: http://bugs.winehq.org/show_bug.cgi?id=2075 Basically it says, without repeating, that vsnprintf called from glibc is not quite a suitable replacement for an actual msvcrt vsnprintf. An example is given to highlight a specific issue. I have a question on how should one approach fixing this? I have thought of two different ways: 1) Create our own vsnprintf version from scratch (fairly difficult) or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance. The issue intrigues me, and I find that it should be resolved at some point. I'd like to get on the right path, so I'd at least start on something that will later be accepted. Thanks, Jesse

7 9

Cygwin under Wine
by Erik de Castro Lopo 08 Mar '04

08 Mar '04

Hi all, I'm interested in running Cygwin under Wine. When trying to run the cygwin bash.exe I get the following: fixme:console:SetConsoleCtrlHandler (0x61025d10,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x61025d10,1) - no error checking or testing yet fixme:ntdll:NtQueryInformationToken (0x60,5,0x6167010c,44,0x4078ef5c): stub fixme:ntdll:NtQueryInformationToken (0x60,1,0x616700a4,44,0x4078ef5c): stub fixme:advapi:SetTokenInformation (0x60, TokenOwner, 0x616700a4, 44): stub fixme:ntdll:NtQueryInformationToken (0x60,6,0x4078ef68,3076,0x4078ef5c): stub fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:psapi:GetProcessMemoryInfo (hProcess=0x30, 0x4078ecb0, 40): stub I've tried hacking the Wine version of GetProcessMemoryInfo and I've had a look at the Cygwin sources to see what they are actually doing with this function. Unfortunately, I am still at a loss as to whay Cygwin expects. Anybody got any ideas on how to fix this? Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Linux: Because rebooting is for adding new hardware

1 0

Re: Contribution offer: Localization work
by Ivan Leo Murray-Smith 08 Mar '04

08 Mar '04

Look at the programs directory, most programs can be translated. You're usually looking for a De.rc file, if it's missing, make a second copy of the En.rc file, and call it De.rc. Now translate the strings in the file. You then have to edit the header file, this may be another rc file. In can case you can find the file by running grep En.rc * in the programs directory. Open the file, and add #include "De.rc" in alphabetical order in the list of language rc files. Once you've done this, make a patch, so your work can be easily applied to the wine source tree, a howto is at http://www.winehq.com/site/sending_patches. Also note that quite a few dlls need translating too. The file may not always be En.rc, for example in dlls/commdlg it's called cdlg_En.rc Finally, one important thing is keeping the translations up to date, so you should update the translation every time there is a change in the english resource file. Don't forget to check that the existing translations are up to date and correct. Once you've done a patch, send it, in the email body or as an attachment, to wine-patches(a)winehq.com This should give you plenty of work for now :-) Ivan.

3 2

Re: _ftime patch
by Hans Leidekker 08 Mar '04

08 Mar '04

On Monday 08 March 2004 07:56, Johannes Gajdosik wrote: > I found that the _ftime-function only returns seconds, not milliseconds. > Therefore I would like to send you a patch that uses gettimeofday(). Your efforts are appreciated but an implementation that uses Win32 API's would be better since that would make msvcrt (and thus Wine) more portable. Right now msvcrt uses only two unix API's, times() and localtime(), and I was planning to get rid of those in order to make it build on MinGW. -Hans

2 1

RtlGetDaclSecurityDescriptor crash on NULL pointer
by Bobby Bingham 08 Mar '04

08 Mar '04

Installing winamp5 with winver=winxp reveals that the wma installer calls GetSecurityDescriptorDacl with pSecurityDescriptor == NULL, which then calls RtlGetDaclSecurityDescriptor, which immediately dereferences it and crashes. Reading MSDN indicates that pSecurityDescriptor may be NULL, but I don't know the first thing about NT security descriptors, and so I'm not sure what the right way to handle it is. But I thought I'd at least point it out so someone who does know could take a look. -- Bobby Bingham

1 0

ccache gives winebuild errors?
by Rein Klazes 08 Mar '04

08 Mar '04

Hallo, Since a couple of days make fails without giving much reason why: | make[3]: Entering directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | WINEBUILD=../../../tools/winebuild/winebuild ../../../tools/winegcc/winegcc -mconsole ddrawmodes.o testlist.o -o ddraw_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lddraw -luser32 -lgdi32 -lkernel32 -lm | Error: ccache gcc failed. | make[3]: *** [ddraw_test.exe.so] Error 2 | make[3]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | make[2]: *** [tests] Error 2 | make[2]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw' | make[1]: *** [ddraw] Error 2 | make[1]: Leaving directory `/usr/home/projects/wine/mywine/dlls' | make: *** [dlls] Error 2 This is after a "make clean". Wine is configured to use ccache by setting CC="ccache gcc" before the ./configure && make depend && make. After another make clean and setting CC=gcc, the make succeeds. Any idea? Rein. -- Rein Klazes rklazes(a)xs4all.nl

4 6

RE: Wine as shared library patch
by Robert Shearman 08 Mar '04

08 Mar '04

Peter Dennis Bartok wrote: > This patch allows to use Wine as a shared library. It will allow the > Mono project to use Wine as the backend for it's System.Windows.Forms > implementation. It looks as though Alexandre has done a good job with kernel32 and ntdll since the last time using Wine with Mono was mentioned on this list. > ChangeLog: > * Alters initialization code to return control to caller instead of > executing application if __wine_shared_lib flag is set. Perhaps this could be changed to a static variable in process.c > * Adds winelib executable (wine-sharedlib) that a consumer can use > to initialize Wine as a shared library, to load Wine DLLs and to import > functions from DLLs. wine-sharedlib doesn't look very clean at the moment. Tabs are inconsistent and you forgot to change MonoWineInit to SharedWineInit in one of the comments. Why do you link to kernel32 and user32 and then use dlsym to get the function address? What is VideoDLL supposed to be for? Why does the comment for WinMain say it is never called and then have a load of junk in it? If you can resolve these issues then we can have a single Wine for Win32 and S.W.F! Rob

4 7

RE: Add support for TB_GETMETRICS and TB_SETMETRICS messages
by Robert Shearman 07 Mar '04

07 Mar '04

Dmitry Timoshkov wrote: > > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add support for TB_GETMETRICS and TB_SETMETRICS messages. > > diff -u cvs/hq/wine/dlls/comctl32/toolbar.c wine/dlls/comctl32/toolbar.c > --- cvs/hq/wine/dlls/comctl32/toolbar.c 2004-03-07 > 17:24:46.000000000 +0800 > +++ wine/dlls/comctl32/toolbar.c 2004-03-07 18:12:44.000000000 +0800 > @@ -5871,6 +5871,60 @@ TOOLBAR_SysColorChange (HWND hwnd) > } > > > +static LRESULT TOOLBAR_GetMetrics(HWND hwnd, LPTBMETRICS lpMetrics) > +{ > + TOOLBAR_INFO *infoPtr = TOOLBAR_GetInfoPtr (hwnd); > + > + if (lpMetrics->cbSize != sizeof(TBMETRICS)) > + return 0; > + > + if (lpMetrics->dwMask & TBMF_PAD) > + { > + lpMetrics->cxPad = infoPtr->nButtonWidth; > + lpMetrics->cyPad = infoPtr->nButtonHeight; > + } > + if (lpMetrics->dwMask & TBMF_BARPAD) > + { > + lpMetrics->cxBarPad = infoPtr->nWidth; > + lpMetrics->cyBarPad = infoPtr->nHeight; > + } > + if (lpMetrics->dwMask & TBMF_BUTTONSPACING) > + { > + lpMetrics->cxButtonSpacing = infoPtr->szPadding.cx; > + lpMetrics->cyButtonSpacing = infoPtr->szPadding.cy; I don't think this is quite right. MSDN says that cxButtonSpacing is "Width of the space between toolbar buttons", where as padding is "used to create a blank area between the edge of the button and the button's image and/or text". If experimentation proves that they are the same then a nice comment saying MSDN is wrong would be appropriate. Rob

2 4

wine-20040213 doesn't compile on Linux w/ 2.6.3 kernel and gcc-3.3.3
by Tom Williams 07 Mar '04

07 Mar '04

I had successfully built wine-20040213 before upgrading to the 2.6.3 Linux kernel and XFree86 4.4.0. After upgrading to XFree86 4.4.0 (from source distribution), wine would crash when I would try to run a Windows app so I decided to rebuild wine so it would use the XFree86 4.4.0 headers and libs, etc. Now, when I compile wine-20040213, it stops with this compile error: make[2]: Leaving directory `/build/wine-20040213/dlls/newdev' make[2]: Entering directory `/build/wine-20040213/dlls/ntdll' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cdrom.o cdrom.c In file included from /usr/include/linux/cdrom.h:14, from cdrom.c:63: /usr/include/asm/byteorder.h:14: error: syntax error before "__u32" /usr/include/asm/byteorder.h:28: error: syntax error before "__u64" In file included from /usr/include/linux/byteorder/little_endian.h:11, from /usr/include/asm/byteorder.h:57, from /usr/include/linux/cdrom.h:14, from cdrom.c:63: /usr/include/linux/byteorder/swab.h:133: error: syntax error before "__u16" /usr/include/linux/byteorder/swab.h:146: error: syntax error before "__u32" /usr/include/linux/byteorder/swab.h:160: error: syntax error before "__u64" make[2]: *** [cdrom.o] Error 1 make[2]: Leaving directory `/build/wine-20040213/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/build/wine-20040213/dlls' make: *** [dlls] Error 2 tom@linux:~/build/wine-20040213$ Based on this discussion on the gcc-help mailing list: http://gcc.gnu.org/ml/gcc-help/2004-03/msg00057.html it looks like the "__KERNEL__" option needs to be specified so that __attribute_const__ can be properly defined and cdrom.c can then be compiled. I haven't tried it yet but I'm guessing adding __KERNEL__ to the "extradefs" macro in the dlls/ntdll/Makefile.in file might do the trick. I'm going to try that now and see what happens. Has this problem already been encountered and addressed? Thanks... Peace... Tom

2 2

← Newer
1
...
19
20
21
22
23
24
25
26
27
Older →

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