wine-devel

wine-devel@winehq.org

3 participants
84432 discussions

Question about "undefined" functions
by Sylvain Petreolle 16 Sep '02

16 Sep '02

Hi, I have problems with the following functions: 17 0x4073bf2f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405c24d0) 18 0x4073bfa3 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405c2508) 19 0x40742936 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405c253c) 20 0x4071c21b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405c2570 In some programs this call stack appears when going to debugger and is causing 0x0 read acess.Digging in the source shows that these functions are only defined by a stdcall in the spec file of user32. the result is a return '0x0000' in the user32.spec.c: "\tjmp GetTaskmanWindow\n" "\tret $0x0000\n" Are these functions intended to return 0x0 ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: winedump: selective search also by name
by Eric Pouech 16 Sep '02

16 Sep '02

> > I am missing some general utility library such as GLib, Qt, NSPR or APR to > > provide general datastructures such as hashes etc. Maybe it is provided by W32? > > Therefore /* FIXME: Replace with some hash such as GHashTable */. it'll be a bad idea to use extra libs like Qt or Glib in Wine, just for that (note also, that in your case, a simple binary search would be enough IMO (compared to the current linear search) A+

2 1

Re: Shell icons - legal
by Jeff Smith 16 Sep '02

16 Sep '02

1 0

DefineDosDevice - ??
by Martin Wilck 16 Sep '02

16 Sep '02

This function is currently a stub - are there any major problems supporting it, i.e. supporting dynamic creation and deletion of DOS drives? Does Wine have a notion of Device paths that look like "\\Device\\Harddisk2\\Partition1" at all? Thinking about it, does something like this make sense at all in the Wine context? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

winebuild/main.c: Include ctype
by Uwe Bonnes 16 Sep '02

16 Sep '02

Changelog: tools/winebuild/main.c Include ctype.h as isdigit is used -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/tools/winebuild/main.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/main.c,v retrieving revision 1.37 diff -u -w -r1.37 main.c --- wine/tools/winebuild/main.c 12 Sep 2002 22:51:20 -0000 1.37 +++ wine/tools/winebuild/main.c 16 Sep 2002 16:00:04 -0000 @@ -26,6 +26,7 @@ #include "wine/port.h" #include <assert.h> +#include <ctype.h> #include <stdio.h> #include <errno.h> #include <string.h>

1 0

Re: Fixed selecting multiple files in common file dialog 95-style
by Huw Davies 16 Sep '02

16 Sep '02

On Sun, Sep 15, 2002 at 08:31:27PM +0200, Josef Meixner wrote: > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.80 > diff -r1.80 filedlg95.c [snip] > 1457c1464,1466 > < memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); > --- > > memset( ofn->lpstrFile + nSizePath, 0, sizeof(WCHAR) ); > > memcpy( ofn->lpstrFile + nSizePath + sizeof(WCHAR), lpstrFileList, > > sizeUsed*sizeof(WCHAR) ); > 1463,1466c1472,1483 > < WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > < ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > < WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > < &ofn->lpstrFile[nSizePath], ofn->nMaxFile - nSizePath, NULL, NULL); > --- > > if (ofn->lpstrFile != NULL) > > { > > WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > > ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > > if (ofn->nMaxFile > nSizePath + 1) > > { > > ofn->lpstrFile[nSizePath] = '\0'; > > WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > > ofn->lpstrFile + nSizePath + 1, > > ofn->nMaxFile - nSizePath, NULL, NULL); > > } > > } > The last two hunks of this patch aren't right. Alexandre, please use this one instead. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

PATCH: Fix MoveFileEx() flags in MSVCRT rename()
by Martin Wilck 16 Sep '02

16 Sep '02

[ Forwarding to wine-devel because it may be controversial, please see comments below. ] Patch: rename.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-16 Modified files: - wine/dlls/msvcrt: file.c Log Message: * Fix MoveFileEx() flags in MSVCRT rename()/_wrename() Comment: >From MSDN docs for rename()/_wrename(): "The new name must not be the name of an existing file or directory. You can use rename to move a file from one directory or device to another by giving a different path in the newname argument." This clearly says that MOVEFILE_REPLACE_EXISTING should _not_ be set, while MOVEFILE_COPY_ALLOWED is necessary to allow moving files between drives. I have verified that windows actually behaves as stated in the MSDN excerpt above. Perhaps someone knows why the flags have been set this way - is it a workaround for some hidden feature in some Windows version? Index: dlls/msvcrt/file.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/file.c,v retrieving revision 1.37 diff -u -r1.37 file.c --- dlls/msvcrt/file.c 12 Sep 2002 22:28:01 -0000 1.37 +++ dlls/msvcrt/file.c 16 Sep 2002 09:16:07 -0000 @@ -2107,7 +2107,7 @@ int MSVCRT_rename(const char *oldpath,const char *newpath) { TRACE(":from %s to %s\n",oldpath,newpath); - if (MoveFileExA(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExA(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); @@ -2120,7 +2120,7 @@ int _wrename(const WCHAR *oldpath,const WCHAR *newpath) { TRACE(":from %s to %s\n",debugstr_w(oldpath),debugstr_w(newpath)); - if (MoveFileExW(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExW(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: Replace static initializers with a proper #define in .h files
by Francois Gouget 16 Sep '02

16 Sep '02

On Sat, 14 Sep 2002, Dmitry Timoshkov wrote: > Hello. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Replace static initializers with a proper #define in .h files. Are defines really better? It seemed to me that they had at least one disadvantage: the value is duplicated each time the define is used. Hmmm, I just retested and it looks as if I was wrong. Anyway, what are the pros and cons? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

3 5

Strange behaviour in directory/drive traversal
by Sylvain Petreolle 16 Sep '02

16 Sep '02

I installed a program and want to launch it. Configuration : ls -ld /c lrwxrwxrwx 1 root root 7 déc 21 2001 /c -> /home/c ls -ld /c/Program\ Files/Yahoo\!/Messenger/YPager.exe -rwxr-xr-x 1 syl wine 1044480 mai 28 17:52 /c/Program Files/Yahoo\!/Messenger/YPager.exe C drive is set to : [Drive C] "Path" = "/home/c" "Type" = "hd" "Filesystem" = "win95" I got: [syl@snoop syl]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I go to drive C: [syl@snoop syl]$ cd /c [syl@snoop c]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I finally go to the program directory: [syl@snoop c]$ cd /c/Program\ Files/Yahoo\!/Messenger/ [syl@snoop Messenger]$ wine YPager.exe and it launches ... Comments ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Wine Hides On-board RAM
by Ian D. Stewart 16 Sep '02

16 Sep '02

On 2002.08.18 12:21 Andreas Mohr wrote: > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > I have recently noticed an unusual side-effect of running Wine. > When I > > first start up my system, /proc/meminfo reports MemTotal as 256892 > kb. > > After running Wine for awhile, /proc/meminfo reports MemTotal as > 32680 > > kb. The system performs as if it only had 32 MB of RAM. A reboot > of > > the system resets total memory to the proper value. > > > > My question is: > > > > 1) Has anybody else encountered this? > > 2) Does anyone know what causes this, or better yet how to avoid it? > > 3) Is there anyway to recover the lost RAM short of a reboot? > > Huh ? This is very, very, VERY strange ! > Something like this should never happen. > Are you sure it's caused by Wine only, or maybe it is due to faulty > memory > instead ? (and thus the board/Linux notices that only 32MB are useable > and resorts to accessing 32MB only). Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine. I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot. > > Again, I'm utterly puzzled when hearing such a story. > Or maybe Wine accesses some Linux memory management function in some > way > that causes Linux to tamper with the value for some reason ? > This wouldn't be the first time that Wine is the only program to > reveal > some severe bug in Linux memory management... > > Definitely try upgrading your kernel, too. I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens. Thanx for the input, Andreas. Ian

5 8

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