- Wine-Devel - list.winehq.org

Re: Fix for winedbg; disassemble range was flawed
by Jeremy White Dec. 5, 2004

Dec. 5, 2004

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 Dec. 5, 2004

Dec. 5, 2004

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 Dec. 4, 2004

Dec. 4, 2004

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 Dec. 4, 2004

Dec. 4, 2004

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 Dec. 4, 2004

Dec. 4, 2004

"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 Dec. 4, 2004

Dec. 4, 2004

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

Wine book
by Brian Vincent Dec. 4, 2004

Dec. 4, 2004

Just wanted to give everyone a heads up.. I followed up with Jeremy's email a few months ago about a publisher wanting to put together a book on Wine. Yep, I have no life and 400 pages can't be that hard to write. Well, we started the ball rolling and now it looks like it's going to happen. I should be signing the contract in a few days. There's lots of details I thought you guys might be interested in. You'll find the chapter outlines[1] at the bottom of this email. This book is oriented at users and Winelib developers. It's not a book about how to hack Wine internals. One thing I'll try to keep in mind as I'm writing is how to entice people to get involved with development. I think it's important to try to get people involved in the community. I'm not going to be writing this alone. Ira Krakow, a Boston native, will be writing the Winelib parts. I didn't feel comfortable doing those and Ira had approached the publisher separately about doing a book on porting Windows apps. We've chatted a few times and I'm confident that given his experience he'll do well. I'm cc:ing him on this email by way of introduction and I'm sure at some point in the future he'll have a question or two (or 50.) The publisher is Prentice-Hall. Thus far they've been excellent to work with and they really seem to just "get it" when it comes to open source projects. Specifically, this book will fall into their Bruce Perens' Open Source Series [2]. After the book is published, it will be available for a short time only in a dead tree version. After a few months it will be available under the Open Publication License [3]. It's a good license and contains many things I think are important. Also, I'd like to thank everyone who reviewed the initial proposal. That process happened really fast and I wasn't even aware it had been sent out for review until after you guys got the emails. There was lots of good feedback in there and I incorporated a lot of it in the final proposal that got approved (you may even notice some changes in the chapters below as a result.) Some other things you guys mentioned aren't specifically in this chapter outline, but I made some notes as to what needs to be addressed. Thanks again. Anyone who didn't see that proposal, you didn't miss much. It was lots of marketspeak. The key is the chapter outline below, so if you have any comments about what I'm overlooking, _please_ let me know. [1] Chapter outlines: Title: "Wine: Running Windows Applications on Linux" [4] 1. Wine Introduction[15 pages] What is Wine? How Can Wine Help You? An Introduction to Windows Components Overview of Wine's Components Recent Changes to Wine A History of the Wine Project How Can You Get Wine? 2. Installing Wine [20 pages] System Requirements Bundled Versions Downloading Packaged Versions Accessing CVS Compiling and Installing Wine Uninstalling Wine 3. Configuring Wine [35 pages] Introduction to Winecfg Windows Versions Libraries: Native vs. Builtin Application Settings Drive Configuration Serial and Parallel Ports Network Shares Fonts Printing Database Access 4. Installing Applications [35 pages] Basic Installation Common Installation Pitfalls Resources to Help With Installation Adding Native Libraries Installing Games Copy Protection Pitfalls Using Native DirectX 5. Installing Common Programs [35 pages] Microsoft Office Adobe Photoshop File Utilities Peer-to-Peer Applications Further Help: The Wine Application Database 6. Linux, Wine, and Windows Integration [40 pages] Integrating with Desktop Environments KDE and GNOME Integration Wine Tools Introduction Wineshelllink Wineprefixcreate Regedit Understanding the Wine Registry Changing the Registry Importing an Existing Registry Using an Existing Windows Partition 7. Enterprise Deployment [30 pages] Licensing Considerations Understanding Windows and Wine Security Automating Deployment of Applications Scripting Wine Citrix Killer: Wine and the Linux Terminal Server Project Performance Tweaks Reporting Bugs and Working with Developers 8. Commercial Alternatives: CodeWeaver's CrossOver Office [25 pages] Introduction to CrossOver Office Downloading and Installing CrossOver Configuring CrossOver Installing Applications with CrossOver 9. Commercial Alternatives: TransGaming's Cedega [25 pages] Introduction to Cedega Downloading and Installing Cedega Configuring Cedega Installing Games with Cedega 10. Introduction to Winelib [20 pages] Introduction to Winelib Licensing Considerations Portability Considerations Getting Started Understanding the Winelib toolkit A Roadmap for Porting Installation of the MinGW Compiler 11. Using Winelib for Porting [45 pages] Installation of the MinGW compiler Moving From Visual Studio to MinGW Tips and Tricks for Changing Compilers Moving Development to Linux Using Winemaker Using the Wine Resource Compiler Using the Wine Message Compiler Linking it Together: winegcc Debugging with the Wine debugger 12. Case Study: Porting a To-Be-Determined Application [30 pages] 13. Advanced Porting Techniques [25 pages] C++ Problems Working with Microsoft Foundation Classes Working with Templates Moving From Visual Studio to MinGW 14. dvanced Library Techniques [20 pages] Getting Started: Why Share Libraries? Using Linux Libraries with Winelib Applications Using Windows Libraries with Winelib Applications Why Wine is not a Shared Library [2] Peren's Open Source Series info: http://phptr.com/promotion/1484?redir=1 [3] OPL license: http://www.opencontent.org/openpub/ a good discussion of it: http://lwn.net/Articles/108250/ [4] With regards to the title, I'll be sure to mention in Wine runs on other operating systems. PS. This still leaves the door open for someone to write an O'Reilly book. PPS. I'd like to think this won't affect WWN because I really have no life. However, that's not too realistic. Hopefully WWN won't suffer too much. - Brian Vincent

7 9

Re: [resend] shell32 tests
by Rolf Kalbermatter Dec. 4, 2004

Dec. 4, 2004

>+static HMODULE hshell32; >+static int (WINAPI *pSHCreateDirectoryExA)(HWND, LPCSTR, LPSECURITY_ATTRIBUTES); >+ >+static void InitFunctionPointers(void) >+{ >+ hshell32 = GetModuleHandleA("shell32.dll"); >+ >+ if(hshell32) >+ pSHCreateDirectoryExA = (void*)GetProcAddress(hshell32, "SHCreateDirectoryExA"); >+} >+ > /* creates a file with the specified name for tests */ > void createTestFile(CHAR *name) > { >@@ -398,17 +409,19 @@ > int ret; > > set_curr_dir_path(path, "testdir2\\test4.txt\0"); >- ret = SHCreateDirectoryExA(NULL, path, NULL); >+ ret = pSHCreateDirectoryExA(NULL, path, NULL); I think this is not right. Implementing dynamic loading of functions in tests is supposedly because that function may not be available on some systems. But here you invoke the (maybe uninitialized, or NULL assigned) function pointer nevertheless without protecting for this. As such your patch does only allow loading the test on such systems but will create a nice crash when run. Rolf Kalbermatter

1 0

2nd attemp at DllCanUnloadNow
by James Hawkins Dec. 3, 2004

Dec. 3, 2004

This time I respect heap-based objects, leaving there internal ref counts and respective HeapFree's. I also took Alexandre's suggestions and changed Un/LockServer to DMCOMPOS_LockServer etc and change cLocks to refCount. Let me know if this is any closer to what it needs to be. Thanks. -- James Hawkins

2 1

Re: Wine book
by Ivan Leo Puoti Dec. 3, 2004

Dec. 3, 2004

> The 'high level' parts (like d3drm) should work too, No program or sdk sample I know of and uses this dll currently works on wine. Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

2 1