wine-devel October 2003

wine-devel@winehq.org

166 participants
384 discussions

Start a nNew thread

Re: What does "still could not load module" mean?
by Ivan Leo Murray-Smith 19 Oct '03

19 Oct '03

>Anybody got ideas? You have winealsa.drv in your lib path and artsd is stoped, right?

1 0

Re: S3 texture compression patent
by Ivan Leo Murray-Smith 19 Oct '03

19 Oct '03

>hell, if MS can get a patent on NTFS they can get a >patent on anything. I do remember reading that the WTO decided that APIs aren't patentable.

1 0

PATCH: dlls/x11drv/wineclipsrv.c
by Gerald Pfeifer 19 Oct '03

19 Oct '03

This fixes another problem on my automatic tester's radar. The only user of this array is commented/disabled, so I suggest to either move the array or completely yank it. Gerald ChangeLog: Move event_names[] into EVENT_ProcessEvent(). Index: wineclipsrv.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/wineclipsrv.c,v retrieving revision 1.4 diff -u -3 -p -r1.4 wineclipsrv.c --- wineclipsrv.c 5 Jul 2002 21:22:09 -0000 1.4 +++ wineclipsrv.c 19 Oct 2003 20:04:32 -0000 @@ -174,20 +174,6 @@ static PCACHEENTRY g_pClipboardCache = N static unsigned long g_cPrimaryTargets = 0; /* Number of TARGETS reported by PRIMARY selection */ static unsigned long g_cClipboardTargets = 0; /* Number of TARGETS reported by CLIPBOARD selection */ -/* Event names */ -static const char * const event_names[] = -{ - "", "", "KeyPress", "KeyRelease", "ButtonPress", "ButtonRelease", - "MotionNotify", "EnterNotify", "LeaveNotify", "FocusIn", "FocusOut", - "KeymapNotify", "Expose", "GraphicsExpose", "NoExpose", "VisibilityNotify", - "CreateNotify", "DestroyNotify", "UnmapNotify", "MapNotify", "MapRequest", - "ReparentNotify", "ConfigureNotify", "ConfigureRequest", "GravityNotify", - "ResizeRequest", "CirculateNotify", "CirculateRequest", "PropertyNotify", - "SelectionClear", "SelectionRequest", "SelectionNotify", "ColormapNotify", - "ClientMessage", "MappingNotify" -}; - - /* * Prototypes */ @@ -805,6 +791,18 @@ void EmptyCache(PCACHEENTRY pCache, int void EVENT_ProcessEvent( XEvent *event ) { /* + static const char * const event_names[] = + { + "", "", "KeyPress", "KeyRelease", "ButtonPress", "ButtonRelease", + "MotionNotify", "EnterNotify", "LeaveNotify", "FocusIn", "FocusOut", + "KeymapNotify", "Expose", "GraphicsExpose", "NoExpose", "VisibilityNotify", + "CreateNotify", "DestroyNotify", "UnmapNotify", "MapNotify", "MapRequest", + "ReparentNotify", "ConfigureNotify", "ConfigureRequest", "GravityNotify", + "ResizeRequest", "CirculateNotify", "CirculateRequest", "PropertyNotify", + "SelectionClear", "SelectionRequest", "SelectionNotify", "ColormapNotify", + "ClientMessage", "MappingNotify" + }; + TRACE(" event %s for Window %08lx\n", event_names[event->type], event->xany.window ); */

1 0

tests for shlfileop.c xp comparsion was done
by Dietrich Teickner 19 Oct '03

19 Oct '03

Hello fellows, Rolf Kabermater (from wine) and I (from Odin) need help. Rolf has written a nice test-programm for many many test-cases (round (45*4+40*2)*8*4) for shlfileop, based on my test-scripts with a one-case test-program for shlfileop. With this faster program we had tested many more cases in w98se and w2k. The problem is, the output is different between w98se and w2k. I had rewritten the shlfileop, and we can simulate shlfileop.c as w98se or w2k. We will mad this test also with w-Me and w-Xp. Some test are also done with nt40 sp6, there works shfileoperation only in simpy cases without confusions. We will not emulate the many errors. We need one testoutput from Rolf's testshfop.exe produced in a w-Me and one in a w-Xp environment. The testprogamm is round 50k big and the log about stdout will be 2,1mb. for the test we need 2 drive-letters, Rolf assumed C:\t\ and D:\t\ for his tests. If anyone will know more about, he can mail me. I can send him\her the (w98se,w2k) logs and the progam, with a short description. I Runs this w-program also in Odin-environment. We need only the wMe log. Regards Dietrich

1 0

Re: Partially implement advapi.ReportEvent
by Dimitrie O. Paun 19 Oct '03

19 Oct '03

On October 19, 2003 07:58 am, Mike Hearn wrote: > This implementation is obviously not complete, but it prints out the > event log strings using MESSAGE, which is good enough for now. Another option is to create a new debug channel (call it eventlog) and output to it. This way we give people a bit more control over it, and it fits a bit better with the rest of the messages. -- Dimi.

1 0

soldat
by Pavel S. Khmelinsky 19 Oct '03

19 Oct '03

Hi! I try to run Soldat by wine and failed ( strange isn't it? :) ) U can found this game at http://www.soldat.prv.pl/ . Thats some listing: --------------------------------------------------------------- $ winedbg --debugmsg +loaddll Soldat.exe fixme:win32:PE_CreateModule Unknown directory 15 ignored trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\advapi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\rpcrt4.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\ole32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\oleaut32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\comctl32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\shlwapi.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\shell32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\winspool.drv' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\comdlg32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\ddraw.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\d3d8.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Soldat\D3DX81ab.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\winmm.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\msacm32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\msvcrt.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Soldat\fmod.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\ws2_32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\winnt\system32\wsock32.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'wprocs' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin err:font:AddFontFileToList Unable to load font file "/usr/sto/wine/winnt/Fonts/desktop.ini" err = 55 err:font:AddFontFileToList Unable to load font file "/usr/sto/wine/winnt/Fonts/modern.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/usr/sto/wine/winnt/Fonts/roman.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/usr/sto/wine/winnt/Fonts/script.fon" err = 2 trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINNT\SYSTEM32\x11drv.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'display' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINNT\SYSTEM32\WINEPS.dll' : builtin fixme:psdrv:PSDRV_BITMAP_SelectObject stub fixme:psdrv:PSDRV_BITMAP_SelectObject stub fixme:psdrv:PSDRV_BITMAP_SelectObject stub trace:loaddll:MODULE_LoadModule16 Loaded module 'commdlg.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINNT\SYSTEM32\d3dgl.dll' : builtin wine: Unhandled exception, starting debugger... --------------------------------------------------------------- This is that I cut from listing when try +relay: --------------------------------------------------------------- 08075ee8:Call(1) kernel32.VirtualAlloc(019f0000,00010000,00001000,00000004) ret=779bd4e5 08075ee8:Ret (1) kernel32.VirtualAlloc() retval=019f0000 ret=779bd4e5 08075ee8:Call(1) kernel32.InitializeCriticalSection(77a39098) ret=779bd60a 08075ee8:Ret (1) kernel32.InitializeCriticalSection() retval=00000000 ret=779bd60a 08075ee8:Call(1) kernel32.InitializeCriticalSection(77a390c8) ret=779bd613 08075ee8:Ret (1) kernel32.InitializeCriticalSection() retval=00000000 ret=779bd613 08075ee8:Call(1) kernel32.InitializeCriticalSection(77a390b0) ret=779bd61c 08075ee8:Ret (1) kernel32.InitializeCriticalSection() retval=00000000 ret=779bd61c 08075ee8:Call(1) kernel32.InitializeCriticalSection(77a39080) ret=779bd624 08075ee8:Ret (1) kernel32.InitializeCriticalSection() retval=00000000 ret=779bd624 08075ee8:Call(1) kernel32.TlsAlloc() ret=779bd5a3 08075ee8:Ret (1) kernel32.TlsAlloc() retval=00000002 ret=779bd5a3 08075ee8:Call(1) ntdll.RtlEnterCriticalSection(77a390b0) ret=779bcf26 08075ee8:Ret (1) ntdll.RtlEnterCriticalSection() retval=00000000 ret=779bcf26 08075ee8:Call(1) ntdll.RtlLeaveCriticalSection(77a390b0) ret=779bd059 08075ee8:Ret (1) ntdll.RtlLeaveCriticalSection() retval=00000000 ret=779bd059 08075ee8:Call(1) kernel32.TlsSetValue(00000002,019f0100) ret=779bd5d4 08075ee8:Ret (1) kernel32.TlsSetValue() retval=00000001 ret=779bd5d4 08075ee8:Call(1) kernel32.GetCurrentThreadId() ret=779bd5eb wine: Unhandled exception, starting debugger... --------------------------------------------------------------- Does it mean that expeption is generatated by any command in GetCurrentThreadId() or not? Then I try to debug it I see someting like that: --------------------------------------------------------------- WineDbg starting on pid 8072568 Unhandled exception: page fault on read access to 0x00000076 in 32-bit code (0x0021b960). In 32-bit mode. 0x0021b960 (KERNEL32.DLL.SetComputerNameA+0x2c): arpl 0x75(%edi),%bp --------------------------------------------------------------- Is it mean that I should to search problem in SetComputerNameA or not? Can you give me some advice how to gather some more information and there I should to search in wine source to solve my problem. And I want to learn how to debug wine may be you can advice me some articles, that I should to read? P.S.: Sorry for my English, I try to state understandable.

2 1

a proposal that will affect MingW-Runtime, w32api, ReactOS and WINE
by Jonathan Wilson 19 Oct '03

19 Oct '03

Currently, we have 3 different projects that are working towards windows "compatibility". We have ReactOS We have WINE and We have MingW-Runtime and w32Api (refered to as just MingW from now on) The 3 projects have different goals but the same target. Microsoft Windows and the Microsoft SDK, DDK and compiler. All 3 projects are working in some way to be compatible with those. All 3 projects have their own set of header & library files including windows SDK headers like windows.h, MSVCRT headers like stdlib.h or stdio.h and (to some extent) ddk headers like ntddk.h The first part of what I am proposing is that the 3 sets of headers be "merged" to create a new "SDK/DDK" for building windows apps. This SDK would contain: 1.a new set of windows headers and libraries (windows.h and friends) built up from a combination of ReactOS headers, WINE headers and w32api headers. They would be (with the help of MSDN) designed to be as close to the microsoft headers as possible (in so far as where things are declared e.g. if abc is in def.h on MS SDK, put it in def.h in this new SDK). This set of headers and libraries would be used: A.by MingW users for windows programming and development B.by the reactos team to build ReactOS C.by the WINE team to build WINE and D.by people building apps with WINELIB. 2.same as 1 but for MSVCRT.dll/MSVCRT.lib and would be used by WINE, MingW and ReactOS. It would endevour to provide 100% coverage of what the MS runtime provides in its MSVCRT.dll as well as all the glue code in MSVCRT.lib (like the Thread Local Storage stuff I made) It would be used by MingW developers to write for win32, by ReactOS to build their OS and their clone of msvcrt.dll and by WINE to build WINE and its clone of msvcrt.dll (which would be the same one as the ReactOS clone, see below) 3.same as 1 but for winddk.h & friends (i.e. kernel mode ddk). Would be used by MingW for kernel-mode development should anyone want to do that. Also, it would be used by WINE for anything kernel-mode that is needed And by ReactOS to build the kernel and kernel drivers. In addition, there would be additions to the libraries plus new header files for all 3 items (SDK, MSVCRT and DDK) that would include any "undocumented by MS but documented by someone else" functions. One thing to remember is that just because they are undocumented doesnt mean that Microsoft (or even 3rd parties that have documentation/headers/code that isnt "genreally available) hasnt used them. The new "SDK" could contain features designed with the different projects in mind. For example, ReactOS core modules could be built with a flag that would tell the headers not to define the "generic" versions of ansi/unicode functions. But application developers could build with this flag off. And so on. A specific "ReactOS SDK" wouldnt exist since this new SDK would do it all. The 3 existing sets of header/library files (i.e. WINE headers, MingW-Rintime/W32api and ReactOS headers) would be thrown away and replaced with this new SDK. Internal stuff (i.e. stuff thats internal to ReactOS or internal to WINE and is not visible to userland apps or to kernel drivers) would go in their own internal header files, as needed by each project. Also, Now on to the other part of my proposal, code sharing between ReactOS and WINE. Basicly, ReactOS (and to some extent WINE) is divided up into 5 parts: 1.kernel (ntoskrnl.exe, hal.dll, win32k.sys etc) 2.kernel drivers (mouclass.sys, ndis.sys, vga.sys, videoprt.sys etc) 3.userland core (user32.dll, gdi32.dll, kernel32.dll, ntdll.dll and any other userland dll that makes calls to kernel-mode without going via one of those 4 dlls) 4.support components (the system services etc) and 5.other dlls and apps (like comctl32.dll, comdlg32.dll, shell32.dll, msvcrt.dll, crtdll.dll, ole32.dll etc) My view is that: A.where possible components 2 and 4 should be designed to work on windows as well as on ReactOS B.sharing parts of component 3 (specificly some of the user32 stuff) does make sense and should be done in a way thats clean in that the "shared" code doesnt rely on any of the internals of WINE or ReactOS and only calls "published" APIs (i.e. regular user32 or gdi32 calls). For example, the MessageBox code can be implemented on top of the Dialog Box api and so on. C.as for component 5, we should implement one and only one copy of those dlls. They should only use published APIs and should work "out of the box" on Windows, ReactOS and WINE when compiled with the new "SDK" mentioned above. DLLs that talk to kernel mode (such as winmm talking to the sound driver or winsock talking to networking) should certainly be implemented so that they will work OOB on both windows and ReactOS (since we are supporting 3rd party drivers in ReactOS anyway we need to implement the "glue" between e.g. winmm and the driver in the same way MS did). WINE is a different issue, mabie they can just implement something in their kernel/ntdll that "appears" to e.g. winmm like the sound driver, I dont know. Ideally, WINE, ReactOS and w32api/MingW-Runtime should be designed to be as alike to Windows and Microsoft SDK as possible. (including those bits of code that are shared between the projects)

3 3

Re: [ros-kernel] Proposed ReactOS headers and code sharing policy
by Eric Kohl 19 Oct '03

19 Oct '03

"Vizzini" <vizzini(a)plasmic.com> wrote: > Executive Summary > ----------------- > - Use MinGW for all public interface headers, i.e. everything that > MinGW supports > - Use non-OS-specific Wine libraries unmodified > - Use portions of OS-specific Wine libraries (e.g. user32) > - Keep it all straight with CVS vendor branches > > Details > ------- > For headers, we will use MinGW as our external interface in all cases > that MinGW supports, including kernel-mode code (i.e. the DDK). We will > submit patches to MinGW when we find problems with the public > interfaces. There is the added benefit of having a compatibility check > against our public interface. One important detail was missing from the discussion. Kernel-mode and native code (ntdll, smss, etc.) does _not_ know about Win32 types, like BYTE, WORD, DWORD, INT, UINT or the LP* types. Unfortunately, the use of these types does not cause any trouble because of the braindead mix of SDK and DDK headers. Actually, we need three different sets of headers: Kernel-mode headers which include all definitions used in ntoskrnl and drivers, native-mode headers which include only the Nt/Zw/Rtl functions used in ntdll and other native components and finally Win32 headers which include the remaining stuff. > We will continue to maintain our own internal headers for anything that > doesn't belong in the public headers. We will begin to port our > kernel-mode code to use the MinGW DDK headers, maintaining our internal > headers for non-public things. Component-internal headers should be moved into the component directory (<component_path>/<header_name>.h) or into a component-specific include directory (<component_path>/include/<header_name>.h). They should always be added to a .c file by using '#include "..."'. Non-public headers which are shared by components (the csrss-subsystem communication protocol for example) should be treated as public headers, they become part of the SDK, DDK or native headers but are not shared between projects. > The first class of libraries is more difficult. Some chunks of code > will be used unmodified, ideally on a file-by-file basis. Other chunks > of code will have to be ReactOS-specific, and we will maintain those in > our local tree. If Wine ever chooses to merge our changes, that's fine > too, but it certainly won't be required. If code is ported from Wine to ReactOS, we have to make sure it will be adjusted to the ReactOS/MS style. I do not like to see any Wine-isms/Unix-isms in ntdll/ntoskrnl or a driver because this will become a portability issue sooner or later. Another issues are licenses and copyrights. IMO, public headers and import libraries should not be licensed or copyrighted at all. They should be in the public domain, so anybody can use them the way they want. Wine code is published under the LGPL, which is important because of Winelib. ReactOS on the other hand should use a clean mix of licenses: GFDL for the documentation, public domain for public headers and import libraries and GPL for the internal code. We should establish a GPL/LGPL dual-license agreement so that shared code automatically changes its license when it is moved from ReactOS to Wine or vice versa. Regards, Eric Kohl

2 1

Re: [ComCtl32] Fix ownerdraw tab width
by Maxime Bellengé 19 Oct '03

19 Oct '03

Alexandre, please don't apply this patch (but you can apply my previous one). After talking with Vitaliy, it seems this patch is not the right fix. I'll send a new one later. Max On Sat, 2003-10-18 at 11:57, Maxime Bellengé wrote: > This patch fixes a regression introduced by last Vitaliy Margolen patch. > The ownerdraw tabs were no longer sized correctly. > > Changelog: > * Fix ownerdraw tabs sizing. -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

1 0

Fwd: Re: [ros-kernel] Re: WINE porting templates
by Steven Edwards 18 Oct '03

18 Oct '03

So are you interested in helping to implement this? The WINE project has started a uxtheme.dll It would be nice if we could agree on a common theme system for both projects. Thanks Steven Note: forwarded message attached. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
39
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 October 2003