wine-devel December 2004

wine-devel@winehq.org

127 participants
276 discussions

Re: Janitorial: WinMM conversion of 32 bit low level drivers to Unicode interface
by Eric Pouech 05 Dec '04

05 Dec '04

Eric Pouech a écrit : > This patch is based on work by Filip Navara from ReactOS. > He did the Winmm part (+wave & midi mapper), I did the rest (+ 16 > message mapping) > A+ well, another take (I forgot a couple of places...) I also removed the SB related code. What's missing it's the proper registry settings when a device is chosen, and we'd better do it either in winecfg or wine.inf, but not in the drivers themselves A+

1 0

Problem to draw a bitmap
by Rémi Assailly 05 Dec '04

05 Dec '04

I tested a program ( an other one, with source code this time ) On my Windows XP system I have no problem. When I use Wine I just get a window. ( where is my bitmap ? ) Then I tried this : "WINEDEBUG=gdi wine progtest" and as Wine is slower I could see my bitmap, which disappeared as fast as it appeared... Here the source code : > #include <windows.h> > #include <wingdi.h> > > void PrintBmp(HWND hWnd, char *filename) > { > HBITMAP hBmp; > HDC hDC; > hBmp=(HBITMAP)LoadImage(NULL,filename,IMAGE_BITMAP,0,0,LR_LOADFROMFILE); > hDC=GetDC(hWnd); > DrawState(hDC,NULL,NULL,(LPARAM)hBmp,NULL,0,0,0,0,DST_BITMAP); > DeleteObject(hBmp); > ReleaseDC(hWnd,hDC); > } > > /* Declare Windows procedure */ > LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); > > /* Make the class name into a global variable */ > char szClassName[ ] = "WindowsApp"; > > > int WINAPI > WinMain (HINSTANCE hThisInstance, > HINSTANCE hPrevInstance, > LPSTR lpszArgument, > int nFunsterStil) > > { > HWND hwnd; /* This is the handle for our window */ > MSG messages; /* Here messages to the application are saved */ > WNDCLASSEX wincl; /* Data structure for the windowclass */ > > /* The Window structure */ > wincl.hInstance = hThisInstance; > wincl.lpszClassName = szClassName; > wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ > wincl.style = CS_DBLCLKS; /* Catch double-clicks */ > wincl.cbSize = sizeof (WNDCLASSEX); > > /* Use default icon and mouse-pointer */ > wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); > wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); > wincl.hCursor = LoadCursor (NULL, IDC_ARROW); > wincl.lpszMenuName = NULL; /* No menu */ > wincl.cbClsExtra = 0; /* No extra bytes after the window class */ > wincl.cbWndExtra = 0; /* structure or the window instance */ > /* Use Windows's default color as the background of the window */ > wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; > > /* Register the window class, and if it fails quit the program */ > if (!RegisterClassEx (&wincl)) > return 0; > > /* The class is registered, let's create the program*/ > hwnd = CreateWindowEx ( > 0, /* Extended possibilites for variation */ > szClassName, /* Classname */ > "Windows App", /* Title Text */ > WS_OVERLAPPEDWINDOW, /* default window */ > CW_USEDEFAULT, /* Windows decides the position */ > CW_USEDEFAULT, /* where the window ends up on the screen */ > 544, /* The programs width */ > 375, /* and height in pixels */ > HWND_DESKTOP, /* The window is a child-window to desktop */ > NULL, /* No menu */ > hThisInstance, /* Program Instance handler */ > NULL /* No Window Creation data */ > ); > > > /* Make the window visible on the screen */ > ShowWindow (hwnd, nFunsterStil); > PrintBmp(hwnd, "BOARD.bmp"); > /* Run the message loop. It will run until GetMessage() returns 0 */ > while (GetMessage (&messages, NULL, 0, 0)) > { > /* Translate virtual-key messages into character messages */ > TranslateMessage(&messages); > /* Send message to WindowProcedure */ > DispatchMessage(&messages); > } > > /* The program return-value is 0 - The value that PostQuitMessage() gave */ > return messages.wParam; > } > > > /* This function is called by the Windows function DispatchMessage() */ > > LRESULT CALLBACK > WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) > { > switch (message) /* handle the messages */ > { > case WM_DESTROY: > PostQuitMessage (0); /* send a WM_QUIT to the message queue */ > break; > default: /* for messages that we don't deal with */ > return DefWindowProc (hwnd, message, wParam, lParam); > } > > return 0; > }

3 4

RFC: Use editline in winedbg
by Jeremy White 05 Dec '04

05 Dec '04

Hi folks, The attached patch dynamically detects and uses the BSD licensed editline library (a pretty close replacement for readline), if it's available. This gives winedbg command line recall. This gets around readline's license requirements. I'm nervous because I wasn't sure if that was the only issue with readline, or if there were further issues. Wack me with a clue bat if this is wrong, otw, I'll submit it. Cheers, Jeremy

5 6

Re: Janitorial: WinMM conversion of 32 bit low level drivers to Unicode interface
by Steven Edwards 05 Dec '04

05 Dec '04

--- Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: > This patch is based on work by Filip Navara from ReactOS. > He did the Winmm part (+wave & midi mapper), I did the rest (+ 16 message mapping) > A+ Eric I just want you to know you are my personal hero. Someday they will write songs about you that I will listen to under ReactOS <g>. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0

Re: Fix for winedbg; disassemble range was flawed
by Jeremy White 05 Dec '04

05 Dec '04

This updated version prevents an infinite loop in the (currently impossible) case of a poorly specified disassembly range. Truth is, this functions interface is a bit awkward. Jeremy White wrote: > Changelog: > Properly respect a disassemble x,y command > (prior behavior would do y-x instructions, no matter > how wide each instruction was) > > > ------------------------------------------------------------------------ > > Index: programs/winedbg/debugger.h > =================================================================== > RCS file: /cvstrees/crossover/office/wine/programs/winedbg/debugger.h,v > retrieving revision 1.17 > diff -u -r1.17 debugger.h > --- programs/winedbg/debugger.h 28 Nov 2004 16:23:50 -0000 1.17 > +++ programs/winedbg/debugger.h 5 Dec 2004 04:30:24 -0000 > @@ -317,7 +317,7 @@ > extern BOOL memory_get_current_frame(ADDRESS* address); > extern BOOL memory_get_string(HANDLE hp, void* addr, BOOL in_debuggee, BOOL unicode, char* buffer, int size); > extern BOOL memory_get_string_indirect(HANDLE hp, void* addr, BOOL unicode, char* buffer, int size); > -extern void memory_disassemble(const struct dbg_lvalue*, const struct dbg_lvalue*, int offset); > +extern void memory_disassemble(const struct dbg_lvalue*, const struct dbg_lvalue*, int instruction_count); > extern BOOL memory_disasm_one_insn(ADDRESS* addr); > extern void print_bare_address(const ADDRESS* addr); > extern void print_address(const ADDRESS* addr, BOOLEAN with_line); > Index: programs/winedbg/memory.c > =================================================================== > RCS file: /cvstrees/crossover/office/wine/programs/winedbg/memory.c,v > retrieving revision 1.1.1.13 > diff -u -r1.1.1.13 memory.c > --- programs/winedbg/memory.c 28 Nov 2004 15:36:39 -0000 1.1.1.13 > +++ programs/winedbg/memory.c 5 Dec 2004 04:30:24 -0000 > @@ -598,9 +598,11 @@ > } > > void memory_disassemble(const struct dbg_lvalue* xstart, > - const struct dbg_lvalue* xend, int offset) > + const struct dbg_lvalue* xend, int instruction_count) > { > static ADDRESS last = {0,0,0}; > + int stop = 0; > + int i; > > if (!xstart && !xend) > { > @@ -613,7 +615,10 @@ > last.Mode = AddrModeFlat; > last.Offset = types_extract_as_integer(xstart); > } > - if (xend) offset = types_extract_as_integer(xend) - last.Offset + 1; > + if (xend) > + stop = types_extract_as_integer(xend); > } > - while (offset-- > 0 && memory_disasm_one_insn(&last)); > + for (i = 0; (instruction_count == 0 || i < instruction_count) && > + (stop == 0 || last.Offset <= stop); i++) > + memory_disasm_one_insn(&last); > }

1 0

Re: COMCTL32: Minor corrections
by Robert Shearman 05 Dec '04

05 Dec '04

Filip Navara wrote: > Changelog: > - Tooltip icons must be destroyed with DestroyIcon and not with > DeleteObject. > - Don't use DrawEdge with NULL device context, it's invalid call and > sets last error. > >------------------------------------------------------------------------ > >Index: lib/comctl32/datetime.c >=================================================================== >RCS file: /CVS/ReactOS/reactos/lib/comctl32/datetime.c,v >retrieving revision 1.5 >diff -u -r1.5 datetime.c >--- lib/comctl32/datetime.c 19 Sep 2004 09:50:06 -0000 1.5 >+++ lib/comctl32/datetime.c 4 Dec 2004 22:59:42 -0000 >@@ -1170,10 +1170,10 @@ > > TRACE("Height=%ld, Width=%ld\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); > >- /* use DrawEdge to adjust the size of rcEdge to get rcDraw */ > memcpy((&infoPtr->rcDraw), (&infoPtr->rcClient), sizeof(infoPtr->rcDraw)); > >- DrawEdge(NULL, &(infoPtr->rcDraw), EDGE_SUNKEN, BF_RECT | BF_ADJUST); >+ /* subract the size of the edge drawn by DrawEdge */ >+ InflateRect(&infoPtr->rcDraw, -2, -2); > > Please use GetSystemMetrics(SM_CXEDGE) and GetSystemMetrics(SM_CYEDGE). > > /* set the size of the button that drops the calendar down */ > /* FIXME: account for style that allows button on left side */ >Index: lib/comctl32/tooltips.c >=================================================================== >RCS file: /CVS/ReactOS/reactos/lib/comctl32/tooltips.c,v >retrieving revision 1.9 >diff -u -r1.9 tooltips.c >--- lib/comctl32/tooltips.c 20 Oct 2004 08:36:55 -0000 1.9 >+++ lib/comctl32/tooltips.c 4 Dec 2004 23:18:56 -0000 >@@ -2818,7 +2818,7 @@ > TOOLTIPS_Unregister (void) > { > int i; >- for (i = 0; i < TTI_ERROR+1; i++) >- DeleteObject(hTooltipIcons[i]); >+ for (i = TTI_INFO; i <= TTI_ERROR; i++) >+ DestroyIcon(hTooltipIcons[i]); > UnregisterClassW (TOOLTIPS_CLASSW, NULL); > } > > Someone already sent a patch for this (and it is my buggy code, sorry). Not sure why it didn't go in, but it should. Rob

3 2

Re: implement DllCanUnloadNow for dmusic
by Robert Shearman 04 Dec '04

04 Dec '04

James Hawkins wrote: >Changelog > * properly implement DllCanUnloadNow ref counting > > > Sorry, still isn't correct. Please see my comments below. >------------------------------------------------------------------------ > >Index: dlls/dmusic/buffer.c >=================================================================== >RCS file: /home/wine/wine/dlls/dmusic/buffer.c,v >retrieving revision 1.8 >diff -u -r1.8 buffer.c >--- dlls/dmusic/buffer.c 6 Sep 2004 21:34:25 -0000 1.8 >+++ dlls/dmusic/buffer.c 4 Dec 2004 20:52:16 -0000 >@@ -38,6 +38,9 @@ > ULONG WINAPI IDirectMusicBufferImpl_AddRef (LPDIRECTMUSICBUFFER iface) { > IDirectMusicBufferImpl *This = (IDirectMusicBufferImpl *)iface; > TRACE("(%p): AddRef from %ld\n", This, This->ref); >+ >+ DMUSIC_LockModule(); >+ > return ++(This->ref); > } > >@@ -45,9 +48,13 @@ > IDirectMusicBufferImpl *This = (IDirectMusicBufferImpl *)iface; > ULONG ref = --This->ref; > TRACE("(%p): ReleaseRef to %ld\n", This, This->ref); >+ > if (ref == 0) { > HeapFree(GetProcessHeap(), 0, This); > } >+ >+ DMUSIC_UnlockModule(); >+ > return ref; > } > >@@ -160,6 +167,8 @@ > } > dmbuff->lpVtbl = &DirectMusicBuffer_Vtbl; > dmbuff->ref = 0; /* will be inited by QueryInterface */ >+ >+ DMUSIC_LockModule(); > > return IDirectMusicBufferImpl_QueryInterface ((LPDIRECTMUSICBUFFER)dmbuff, lpcGUID, ppobj); > } > > Ok, think about this sequence of events that should leave the DLL ref count at 0: 1. Create an IDirectMusicBufferImpl object. 1a. Calls LockModule. 1b. Calls QueryInterface which calls LockModule. 2. Call Release, which calls LockModule. The solution is to either remove the LockModule from the constructor, or to remove the LockModule from the AddRef and only call UnlockModule in the destructor part of Release. This issue is also present in the other files in your patch (not quoted here). I should have thought about this before when I commented on your last patch. I guess I need to put some tests together for this feature. Rob

2 2

DInput has been broken for about 6 months now
by Scott Ritchie 04 Dec '04

04 Dec '04

Well, one of my favorite games, Fallout 2, didn't work when I tried it. This is strange though, as it was working about 3 years ago. Looking through the AppDB page, http://appdb.winehq.org/appview.php?appId=194&versionId=319 - it looks like it's been broken since June. Specifically, here's the symptoms: "DXGRAB" = "Y" will cause the app to completely takeover and lockup the system, except no input into the app (mouse or keyboard) works. I have to ctrl-alt-f2 and killall -9 wine-preloader to get back to work. Turning off DXGRAB causes the app to respond to keyboard input, but the mouse still doesn't work. Some very strange things happened in gnome when I brought my email window in front of the app (the mouse would skip from the edge of the gnome window past the app, making it impossible to click on, and other wierdness. However, none of this translated into the in-game cursor moving) I'm running the app in Desktop=640x480 mode. Furthermore, it appears that some of the old problems listed in the AppsDB page are still there - the game is very slow at certain points (well, the loading and unloading I can do with the keyboard...), and I'm running a computer roughly 10 times as fast as was designed for the game. After asking about on the channel a bit, the finger was pointed at DINPUT. I think some of the problems with DINPUT would make a fairly good candidate for something to tackle on Sunday, although doing a >6 month regression test could be annoying. I personally know about 3 people I could get to switch to Wine entirely if we could get this working :) I haven't filed a bugzilla report yet, but if it helps I will. Thoughts? -Scott Ritchie

1 0

Re: New Canadian keyboard layout
by Dmitry Timoshkov 04 Dec '04

04 Dec '04

"Jean-Michel Dault" <jmdault(a)revolutionlinux.com> wrote: > I'm doing a pilot project for the Quebec government, and we have one > major problem: they have a keyboard layout that's unsupported by Wine, > though it was commited to XFree about 3 years ago. What do you mean by "unsupported by Wine", is that just a warning that you see? What exactly doesn't work without this patch? -- Dmitry.

4 4

Making the Documentation into help files
by Scott Ritchie 04 Dec '04

04 Dec '04

While making the Debian package, I had to do a special hack to compile wine's documentation because it's made seperately. This isn't a really big deal, but what I did realize is that Wine's documentation doesn't get installed to the help menu now coming standard on systems. When I select Applications->Help from the menu in Ubuntu, there's a whole list of documentation for available installed applications. I managed to get the install script to copy txt versions of the stuff in the documentation folder to the standard /usr/share/doc/wine, but this place remains bereft of wine documentation. So, how is this done? I presume there's a freedesktop.org standard for these things, as both Gnome and KDE have them in the same way, but currently we're not converting the documentation sgml files into these help files. Coincidentally, this might tie in very well to the desktop integration tasks suggested this week. Perhaps we should create a desktop integration tasklist or even append it onto the 1.0 todo? Trying to further improve usability, Scott Ritchie

3 2

← Newer
1
...
21
22
23
24
25
26
27
28
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 December 2004