wine-devel

wine-devel@winehq.org

11 participants
84462 discussions

Re: Always create a suspended thread in CreateThread and resume it if CREATE_SUSPENDED flag is not set as Windows does
by Robert Shearman 01 Dec '04

01 Dec '04

Dmitry Timoshkov wrote: >Hello, > >there is at least one application which crashes in CreateThread due >to a race between a creating thread and a newly created one. The problem >is that the tid address passed to CreateThread resides in the memory >block allocated with VirtualAlloc which gets freed once the newly created >thread starts running, and when CreateThread code attempts to store thread >id it crashes. > >It appears that Windows always creates suspended threads in CreateThread >and a created thread gets resumed later. Here is a snippet of the log >running a simple test program under NT strace (the test app just creates >a thread): > >hThread = CreateThread(NULL, 0, thread_proc, NULL, 0, &tid); >CloseHandle(hThread); > >... >117 796 792 NtCreateThread (0x1f03ff, 0x0, -1, 1243704, 1244568, 1, ... 60, {796, 800}, ) == 0x0 >118 796 792 NtRequestWaitReplyPort (40, {28, 52, new_msg, 0, 2013529912, 2147348480, 902, 2086471576} "\0\0\0\0\1\0\1\0x\1\23\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ... {28, 52, reply, 0, 796, 792, 2138, 0} "\0\0\0\0\1\0\1\0\0\0\0\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ) == 0x0 >119 796 792 NtResumeThread (60, ... 1, ) == 0x0 >120 796 792 NtClose (60, ... ) == 0x0 >... > >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Always create a suspended thread in CreateThread and resume it > if CREATE_SUSPENDED flag is not set as Windows does. > >--- cvs/hq/wine/dlls/kernel/thread.c 2004-09-22 16:48:59.000000000 +0900 >+++ wine/dlls/kernel/thread.c 2004-12-01 18:04:52.000000000 +0800 >@@ -164,7 +164,7 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (flags & STACK_SIZE_PARAM_IS_A_RESERVATION) stack_reserve = stack; > else stack_commit = stack; > >- status = RtlCreateUserThread( hProcess, NULL, (flags & CREATE_SUSPENDED) != 0, >+ status = RtlCreateUserThread( hProcess, NULL, TRUE, > NULL, stack_reserve, stack_commit, > THREAD_Start, info, &handle, &client_id ); > if (status == STATUS_SUCCESS) >@@ -172,6 +172,19 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (id) *id = (DWORD)client_id.UniqueThread; > if (sa && (sa->nLength >= sizeof(*sa)) && sa->bInheritHandle) > SetHandleInformation( handle, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT ); >+ if (!(flags & CREATE_SUSPENDED)) >+ { >+ DWORD ret; >+ >+ status = NtResumeThread( handle, &ret ); >+ if (status) >+ { >+ NtTerminateThread( handle, -1 ); >+ RtlFreeHeap( GetProcessHeap(), 0, info ); >+ SetLastError( RtlNtStatusToDosError(status) ); >+ handle = 0; >+ } >+ } > } > else > > I think you should close the thread handle in the error case, otherwise it will be leaked. Rob

1 0

Debian Packages Almost Ready
by Scott Ritchie 01 Dec '04

01 Dec '04

Debian packages are almost done. I have them up for testing. Add the following to /etc/apt/sources.list deb http://tuzakey.com/~scott/ binary/ deb-src http://tuzakey.com/~scott/ source/ My friend's webserver can't handle the huge bandwidth permanent hosting of packages like this will require, so if there's a way we could put them up on winehq it would be nice. I'd like to have an apt repository here, so installing the latest debian wine package would be as simple as adding something like the above line to sources.list and then doing things as normal. What would be ideal, of course, is if the package could be included in the Debian distribution itself. I've yet to hear back from Ove (the current maintainer of the package), and unless he's disappeared entirely there's really nothing that can be done until he decides to update the package or orphan it, as Debian maintainers have total control over their packages. Ubuntu is a different matter, however, and I may be able to get an Ubuntu version included much quicker. If you're a Debian/Ubuntu user, test out the packages and tell me if I left anything out. Thanks, Scott Ritchie

1 0

Small WinMM janitorial project
by Steven Edwards 01 Dec '04

01 Dec '04

Hi, With this patch it is possible to use a few Windows sound drivers under ReactOS but I have only submitted patches for one small part of this because its going to require a bit of rework of the existing WinMM code. This should fix 2 of the existing W->A CrossCall issues # dlls/winmm/winmm.c: winmm: waveInGetDevCapsW: illegal call to waveInGetDevCapsA # dlls/winmm/winmm.c: winmm: waveOutGetDevCapsW: illegal call to waveOutGetDevCapsA but before it can be merged we have to rewrite the Wine drivers to accept Unicode. I am planing on adding this as a subproject to the Janitorial page. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0

Debugging of Windows App
by Bernard Gallet 30 Nov '04

30 Nov '04

I am trying to debug a Windows app on Wine. I have the source code, it is compiled with Visual Studio 2002. I have not yet been able to get Line/File info. It is my understanding that winedbg does not recognize pdb, however, I am unable to link without one! Can somebody help? T IA, - Bernard GALLET -

2 1

Re: wine/dlls/shell32 tests/shellpath.c version.h - IE6 breakage
by Mike McCormack 30 Nov '04

30 Nov '04

The following seemingly simple and harmless change caused a regression in IE6. The toolbar icons are no longer displayed and the error message below appears in the log. err:imagelist:ImageList_LoadImageW Error loading image! Mike Alexandre Julliard wrote: > ChangeSet ID: 14326 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/10/26 16:17:50 > > Modified files: > dlls/shell32/tests: shellpath.c > dlls/shell32 : version.h > > Log message: > Juan Lang <juan_lang(a)yahoo.com> > Update shell32's version to WinXP level. > > Patch: http://cvs.winehq.org/patch.py?id=14326 > > Old revision New revision Changes Path > 1.3 1.4 +0 -2 wine/dlls/shell32/tests/shellpath.c > 1.1 1.2 +4 -4 wine/dlls/shell32/version.h

6 6

Re: acmstream mem leak fix
by MichaelGuennewig＠gmx.de 30 Nov '04

30 Nov '04

James Hawkins <truiken(a)gmail.com> writes: > Unless I'm mistaken, we don't want to free allocated memory only when > the call fails. Sorry, but you are wrong. When you always free the memory you will run into a segmentation fault when the application uses the returned stream. The problem is the same as with the icmstream patch you made. The current implementation will work correctly in all cases although it doesn't look very COM-like as Mike already pointed out for the icmstream patch. The methods you analyzed are only called internally from IClassFactory_fnCreateInstance in the factory.c file. The memory block which is allocated by LocalAlloc in the AVIFILE_CreateICMStream and AVIFILE_CreateACMStream is only returned to the application if the IAVIStream_QueryInterface call doesn't return an error. So when you always free the memory block you will most probably run into a segmentation fault. The proposed patch from Mike for the icmstream.c file should be adapted to this file when you don't like the LocalFree call there, but I'm sure that then people will ask why we don't call LocalFree in this method. So it would be perhaps fine when also some comments would be added to prevent another discussion about what's wrong or correct. When you don't understand the code feel free to write me as I'm the one who has produced it. Regards Michael Günnewig

1 0

<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive
by Robert van Herk 30 Nov '04

30 Nov '04

Changes: Added functionality to browse for a UNIX folder. This is done by making two new funtions in dlls/shell32/brsfolder.c, namely wine_shell_browse_for_UNIX_directoryA wine_shell_browse_for_UNIX_directoryW These functions are exported in shlobj.h. The original code that allowed just for picking a Windows folder, was split up. It was to be found in brsfolder.c, but I split this in: brsfolder.c brsfolder.h brsfolder_windows.c brsfolder_windows.h brsfolder_unix.c brsfolder_unix.h unixTools.c unixTools.h, Otherwise I found the code to be incomprehendible. Furthermore, winecfg now uses the wine_shell_browse_for_UNIX_directoryA to let the user pick a UNIX directory as root for his virtual drive mappings. Regards, Robert van Herk

1 0

Re: misc. crypt test mem leak fixes
by Dmitry Timoshkov 30 Nov '04

30 Nov '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * misc. crypt test mem leak fixes Apparently lines with LocalAlloc were added by mistake instead of LocalFree. -- Dmitry.

2 1

Problem with file dialog
by Stefan Dösinger 30 Nov '04

30 Nov '04

Hello, This patch breakes the file open/save dialog for me: http://www.winehq.org/hypermail/wine-cvs/2004/11/0086.html The 5 buttons(go up one folder, go to desktop, new folder, ...) appear above the directory selektor and have a height of only a few pixels, so the icons are not visible and it's hard to click the buttons(see the attached screenshot). Reversing lines 89-96 of the patch solves the problem. I don't send a patch, because I don't think simply reversing the lines is the correct solution. What is a correct fix for this? Cheers, Stefan

2 2

Porting SmartWin a Windows API GUI library...
by Thomas Hansen 30 Nov '04

30 Nov '04

I'm the admin of http://smartwin.sourceforge.net and I've been thinking that if this library (SmartWin) could be ported to WineLib that would be really awesome... I would definitely take it right into the CVS (unless it breaks everything) and I'd make it a definitely focus trying to keep the compatibility towards WineLib in later releases... I assume it would be a nice project to do too. (not too much code, only about 15 000 lines with LOTS of comments) Not to mention the benefit it would give the community having a Windows API library being ported to Wine... Comments sombody...? Thomas Hansen -- http://smartwin.sourceforge.net THE template based C++ Windows API GUI Abstraction Library

2 1

Re: icmstream mem leak fix
by Mike McCormack 30 Nov '04

30 Nov '04

Hi James, That looks kind of wrong, both the before and after... Interfaces should be released, not free'd... Secondly, freeing the interface if the Query works is almost definitely wrong, because ppv will likely point to the same memory as pstream. Mike James Hawkins wrote: > hr = IAVIStream_QueryInterface((IAVIStream*)pstream, riid, ppv); > - if (FAILED(hr)) > - LocalFree((HLOCAL)pstream); > + > + LocalFree((HLOCAL)pstream); > > return hr; > }

2 4

Re: Systray rewrite
by Grant Williamson 30 Nov '04

30 Nov '04

Hi Mike, patching is clean on 20041019, however .. fails with make[2]: Entering directory `/tmp/wine-20041019/dlls/shell32' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./shell32.spec shell.spec.o shell.o authors.o autocomplete.o brsfolder.o changenotify.o classes.o clipboard.o control.o cpanelfolder.o dataobject.o debughlp.o dialogs.o dragdrophelper.o enumidlist.o folders.o iconcache.o memorystream.o pidl.o regsvr.o shell32_main.o shelllink.o shellole.o shellord.o shellpath.o shellreg.o shellstring.o shfldr_desktop.o shfldr_fs.o shfldr_mycomp.o shlexec.o shlfileop.o shlfolder.o shlfsbind.o shlmenu.o shlview.o shpolicy.o shv_bg_cmenu.o shv_item_cmenu.o systray.o shell32.dll.dbg.o shres.res version.res -o shell32.dll.so -L../../dlls -Wb,-dole32 -lshlwapi -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../libs/wine -lwine -luuid -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port shell32_main.o(.text+0x23c6): In function `DllMain': /usr/src/redhat/BUILD/wine-20041019/dlls/shell32/shell32_main.c:962: undefined reference to `SYSTRAY_Init' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [shell32.dll.so] Error 2 make[2]: Leaving directory `/tmp/wine-20041019/dlls/shell32' make[1]: *** [shell32] Error 2 make[1]: Leaving directory `/tmp/wine-20041019/dlls' make: *** [dlls] Error 2 Mike Hearn wrote: >Here it is, at last, just what the doctor ordered. All in a separate >wineshell process, and with cleaner code to boot. No thread safety >needed. Hopefully this is now satisfactory and can go in. > >The intention is that wineshell becomes a generic explorer-alike process >in terms of responsibility. For now, I have it being started >automatically by shell32 (to avoid the startup penalty), and shutting >down a few seconds after the last icon is gone like the wineserver. If >we start putting more stuff in there like a DDE server, we may have to >rethink that strategy. > >ChangeLog: >- Add a new wineshell process, and put system tray handling in there >- Rewrite the shell32 systray handling to be out of process >- Support the freedesktop.org XEMBED protocol > > > >

1 0

Re: working together on stdole.tlb and a end to dcom9x
by Sam Lauber 30 Nov '04

30 Nov '04

Sure, send me both. The precompiled one would be useful to test OLE, and the source would be useful to test OLE, Winelib, and the Wine DLLs. Also, a few months ago, I did a web search for the OLE problem, and turned up an old thread on the Wine mailing list that actually had stdole32.odl. The URL is http://www.winehq.org/hypermail/wine-devel/2003/01/0858.html. I tried it with MS mktyplib (with Wine DLLs). Strangly, it produced the exact same FIXMEs that the C program generated, but generated a diffrent typelib. And more then two bytes differed. The two typelibs are attached. I'll try it with InstallShield. Samuel Lauber ----- Original Message ----- From: "Boaz Harrosh" <boaz(a)moeg.org> To: "Sam Lauber" <sam124(a)operamail.com> Subject: Re: working together on stdole.tlb and a end to dcom9x Date: Mon, 29 Nov 2004 10:18:43 +0200 > > Sam Lauber wrote: > > > Someone should develop a Wine testcase that tests typelibs. Does anyone know of a typelib testcase? > > > > > > > Last I checked wine with native ole would crash on any simple WTL > project hosting an OCX. It would crash at the point it was trying to > query for the typelibs and interface info inside the typelib. So first > thing I'd do is Just compile a simple WTL app hosting any OCX. > > Do you need that I send you one? Compiled on VC6 on windows? What OCX > can one use that would work with native ole? > Is source OK? or you also need a compiled exe with debug info (.pdb)? > > Free Life > Boaz > -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

Changed IE6 install script to run IE6 completely out-of-box
by Hajime Segawa 30 Nov '04

30 Nov '04

As mentioned in WWN #250 : >If you dissect the script you'll notice a lot of what it does is install some proprietary DLL's. Specifically, DCOM98, MFC 4.0, >and Microsoft Installer. So yes, it's cheating and Wine isn't running these completely out of the box. However, you can run them. I changed the install script a bit and it does not depend on DCOM98, MFC4.0, etc... anymore. So, you can run IE6 completely out-of-box. New script is here : http://sidenet.ddo.jp/winetips/files/wine-config-sidenet-1.5.3.tgz

3 6

Re: Moved dll list from DEVELOPERS-HINTS into separated file
by Jon Griffiths 29 Nov '04

29 Nov '04

Hi, >I personally don't think it's really useful without more detailed >information on each dll, but in any case this belongs to one of the >sgml documents, not a stand-alone ASCII file. c2man.pl will generate a blurb for each dll in the source tree when building API docs, if one of the dlls source files contain a supplimental comment named after the dll. IMHO this is the best place to put a description of the dll. It appears in the generated docs above the list of exported functions and makes a natural lead-in to the dlls documentation page. The info is then also available by "man dllname" if the generated docs are installed. See the top comment in dlls/shlwapi/shlwapi_main.c for an example. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

Re: Translate dir names into Spanish
by Juan Lang 29 Nov '04

29 Nov '04

Joaqu�n wrote: > I have some programs in spanish for windows but when i install it i have > problems with dir names, for example "Program Files" is "Archivos de > programa", "Common Files" is "Archivos comunes", and so. > > Can i translate this names in source and compiling without problem?? > which files i need update?? Yes, you can. You need to modify the file dlls/shell32/shell32_Es.rc. Look at dlls/shell32/shell32_En.rc. The end of the file as a stringtable with the comment /* shell folder path default values */. Copy this stringtable to shell32_Es.rc, and translate the names appropriately. Recompile and reinstall. Please send a patch with the updated translations to wine-patches(a)winehq.org, too. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

1 0

Re: working together on stdole.tlb and a end to dcom9x
by Sam Lauber 29 Nov '04

29 Nov '04

No. I used the InstallShield program for Flash MX, and it didn't work. Without stdole32.tlb, it whined like a baby about OLE. With stdole32.tlb, it (not the whole system) froze up during the "preparing" stage when it hit 100% and left a phantom window that was blank when and after I quit Wine. I think, for InstallShield, someone has to implement a special trap(s) for OLE calls. Also, a stdole32.tlb copied from a real Windows system didn't work. Clearly, it isn't a hole in InstallShield, but in Wine's typelib support. Someone should develop a Wine testcase that tests typelibs. Does anyone know of a typelib testcase? Samuel Lauber ----- Original Message ----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: "Vincent "Béron"" <vberon(a)mecano.gme.usherb.ca>, "Filip Navara" <xnavara(a)volny.cz> Subject: Re: working together on stdole.tlb and a end to dcom9x Date: Sun, 28 Nov 2004 17:54:48 -0800 (PST) > > Hi Vincent, > > --- Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > > Was the resulting stdole32.tlb file (generated on Wine) a suitable > > replacement for Microsoft's? IE, does InstallShield works better with > > this file than without any stdole32.tlb file? > > I think it will work. One thing we have discussed in ReactOS was using > the tools as part of our stage2 setup. If there is not a easy way to > implement these tools in WIDL like Alexandre wanted maybe making them > tools that are run via wineprefixcreate on first run is a acceptable > solution? > > Thanks > Steven > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > > -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

working together on stdole.tlb and a end to dcom9x
by Steven Edwards 29 Nov '04

29 Nov '04

Hello, Once again cross-posting because I would like to see if this is something we can work together on. What is left to do for us to be able to build and have a working implementation of stdole.tlb or any other type libs? I ask because it seems Wines DCOM implementaton is almost good enough for most apps except for this file and ReactOS is quickly getting to the point that it can run most of the same stuff Wine can without DCOM9x installed. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

7 14

Re: Winecfg -> browse for folder
by Ivan Leo Puoti 28 Nov '04

28 Nov '04

> Also runned ldconfig (don't know if that is > a must). It isn't, expecially if you run out of the source tree. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

Re: Fun desktop integration tasks
by Ivan Leo Puoti 28 Nov '04

28 Nov '04

Another task: Get xscreensaver to respect the registry LowPowerActive setting. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

listbox: selecting items
by Lauri Tulmin 28 Nov '04

28 Nov '04

I would like to know why http://www.winehq.com/hypermail/wine-patches/2004/11/0171.html hasn't been accepted.

1 0

No RichEdit20A window class
by Krzysztof Foltman 28 Nov '04

28 Nov '04

Just for the record, I'm still trying to develop a "proper" RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think. If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at: http://foltman.com/riched.zip I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable. What IS done: - basic text wrapping with support for proportional fonts and character formatting, no major known bugs (the only supported attribute is Bold, but the rest will be relatively easy to add) - simple editing (typing text, backspace, delete, no overwrite mode yet) - a very incomplete implementation of Shift-arrow selection (done in a few hours yesterday :-) ), mouse operations don't support selection yet - per-paragraph alignment - pitiful low-level style management - bold attribute - some basic optimizations (avoiding rewrapping unmodified paragraphs unless editor window is resized) - uses UNICODE internally (not necessarily a good thing) What isn't done: - RichEdit API (which is a mess; I'm taking care of it in order to ensure compatibility wrt how editing functions work, however, basic editing functionality is the number one priority, as it's more difficult to achieve) - RTF interface - Undo - Clipboard - tabs - bulleted lists - setting paragraph attributes (margins are implemented internally but can't be changed with current interface, setting alignment by Ctrl+L/E/R works) - all RichEdit f3 functionality - MBCS support (and it would be very hard to add) - BiDi and CTL support (ditto) - everything not mentioned in the first list Krzysztof

4 5

Fun desktop integration tasks
by Mike Hearn 28 Nov '04

28 Nov '04

Hi everybody, I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop. None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved. As usual no guarantees these patches would be accepted, that's Alexandres call. But they probably would be, and you'll learn something while doing them! :) Task 1: Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this. I think it'd be ok to grab $HOME using the UNIX getenv() and then using the libwine APIs to map them to a Win32 path. If the mapping fails (ie $HOME is not accessible given the users dosdevices) then just fail with a WARN(). Task 2: This is similar to above but with some extra work. Map the contents of the ~/Desktop directory to the Windows virtual Desktop folder. In file pickers and Explorer, the filesystem root is represented by a magic Desktop folder. In real Windows this reflects the icons that are on the desktop and is mapped to a real directory at some arbitrary point in the filing system. On Linux we have no such virtual root, however it'd be nice if icons that appeared in the KDE/GNOME desktop were put in their proper place. That way users won't be confused by the file being on their desktop but unavailable from their Windows applications file picker. This should not be too hard. The Desktop folder is implemented by a COM object in dlls/shell32/shfldr_desktop.c. You just need to read the $HOME/Desktop folder and put the items you find in there inside. Ignore .desktop files for now, they are a bit tricker to map and aren't especially useful for us anyway. You also want to map CSIDL_DESKTOP in dlls/shell32/shellpath.c, _SHGetDefaultValue. See above. Bonus points for fixing the desktop icon while you're at it (an arrow??!) Task 3: The freedesktop.org icon theme specification shows us how to find icons for many different types of thing. Implement support for loading and using the following icons from the icon theme (it should be OK to use native libraries for this like GdkPixbuf, just fall back to the compiled in defaults if it's missing): - folder - desktop - computer - unknown document - any others?? Don't do file types, as native icon<->file type association is done by mime types not extensions, and it'd make our file dialogs even slower than they already are. You may be tempted to use eg, libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG. Task 4: Try updating the menu mapping code to support the new XDG menu specification. Don't bother trying to make this work everywhere, it's a total nightmare. Just try supporting the new standards. Be warned: not every desktop/distro supports this yet! This one might be quite hard. Task 5: Try improving the winebrowser script to take into account the users preferred applications. At the moment it just tries every browser it knows about in a hard coded order. Hint: in modern GNOME desktops you can use the "gnome-open" program to make this automatic. There is a KDE equivalent. Task 6: Integrate Wine with XScreensaver, so installing Win32 screensavers makes them automatically appear in the list. You may need to write patches for xscreensaver to make this really slick. Have fun! thanks -mike

6 8

Re: Moved dll list from DEVELOPERS-HINTS into separated file
by Dimitrie O. Paun 28 Nov '04

28 Nov '04

On Fri, Nov 26, 2004 at 10:04:49PM -0500, Jacek Caban wrote: > I saw in TODO list "Get rid of the list of DLLs, it's too big, and adds > too little information", > so I thought it could be moved into separated file dlls/DLL-LIST. I think this is a good idea: while I agree that the list is a bit much for DEVELOPERS-HINTS, it's still a nice overview of the dlls we have, and it would be a real pitty to lose. -- Dimi.

2 1

Adding debuginfo Support to Wine Makefiles
by Robert Shearman 28 Nov '04

28 Nov '04

Hi, I want to add support generating .debug files that are linked from .so files so that we can have one set of binaries, no matter whether a person is a developer or end-user and yet have no additional disk space or bandwidth costs. This is really just a RFC about changes I've made to the DLL makefiles, before I start copying and pasting them to the other areas. Am I on the right lines here? Do I need to add a configure check for objcopy? Do I need a configure check for the --add-gnu-debuglink option? Rob

3 5

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