wine-devel

wine-devel@winehq.org

7 participants
84405 discussions

Direct3D v8
by Ann and Jason Edmeades 16 Sep '02

16 Sep '02

Hello, What is the current state of affairs regarding DirectX (8) support in wine. With Transgaming producing a version which appears to work well from what I read on the Internet, what is happening about getting support for it in the wine tree - Is the intention to wait and see what Transgaming do? The reason I ask - Not to start a political debate with pros and cons of Transgaming, but more because as a learning exercise with regard to 3d graphics, I started fiddling with Direct X 8 support and have some sample code which runs some simple Direct3D samples and most of a sequence of tutorials. (9 out of 11 work reasonably well). I dont have a problem with the code remaining personal to me and probably archived, as I have learnt a lot by doing it (which was my original aim), but if it is agreed that adding directx 8 support completely different to the Transgaming code is ok, then I may try to submit some patches. Note the current code is nowhere near ideal, so dont get your hopes up. Specifically, it exports X11DRV_get_client_window from X11DRV as a means of getting the X window from the HWND, which is not clean. It does not use a HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the d3d8 directory, completely seperate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily used the highest performing code everywhere, I have done the best I could with my limited knowledge. The way I look at it would be a starting point for others to work from. I could make a drop of the code on a website if anyone wants to see how bad it is first :-) Anyway, thoughts please? Jason

8 17

Re: memory/virtual.c: ROUND_SIZE() bugfix + .SYS loading
by Alexandre Julliard 16 Sep '02

16 Sep '02

Jan Kratochvil <short(a)ucw.cz> writes: > I had incorrect warnings "Section %.8s too large (%lx+%lx/%lx)" during loading > of some low-level system libraries. It got fixed by the attached > "wine-memory-virtual.c-too_large_section.diff" which changes (I think fixes) > ROUND_SIZE() behaviour. It also comments ROUND_ADDR() and ROUND_SIZE(), I hope > I guessed its intended description from the style of its usage around the code. No, ROUND_SIZE is supposed to return an aligned size, which you use together with an aligned address. The normal pattern is to use ROUND_SIZE and ROUND_ADDR together. We don't bother to round addresses in image mapping because all the code assumes the image has correct section alignment already. > Attached "wine-memory-virtual.c-mmap_cache-preliminary.diff" is just a RFC as > I found out that I was unable to load some .SYS files as they were being > attempted to be loaded with page-overlapping sections, unaligned offsets and > incompatible protections. Therefore I had to implement my own mapping cache and > handle the overlapping/merging myself. It would be more simple/clean to use > Linux /proc/$$/maps mmap map but it would be probably no-no as it is > Linux-dependent. I think this is complete overkill. Mapping unaligned binaries is a very unusual case and should be treated as such. There's no need to maintain such a complex structure, or add support for non page aligned mmaps, for such an exotic feature. Probably what you want is to create a separate map_image_unaligned function to map images that don't have a proper section alignment, using read() and not worrying about protections at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

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

16 Sep '02

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, your patch committed at 02/08/14 16:09:55 (Builtin modules > must be aligned on 64K boundary) completely kills any attempts to > minimize sizes of winelib executables. Is it really necessary? Yes, some apps need modules to be properly aligned. Note that this stuff will never be paged in so it only wastes a bit of disk space. -- Alexandre Julliard julliard(a)winehq.com

1 0

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

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