November 2004 - Wine-Devel - list.winehq.org

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

Nov. 30, 2004

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 Nov. 30, 2004

Nov. 30, 2004

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 Nov. 29, 2004

Nov. 29, 2004

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 Nov. 29, 2004

Nov. 29, 2004

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 Nov. 29, 2004

Nov. 29, 2004

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 Nov. 29, 2004

Nov. 29, 2004

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 Nov. 28, 2004

Nov. 28, 2004

> 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 Nov. 28, 2004

Nov. 28, 2004

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 Nov. 28, 2004

Nov. 28, 2004

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 Nov. 28, 2004

Nov. 28, 2004

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 Nov. 28, 2004

Nov. 28, 2004

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 Nov. 28, 2004

Nov. 28, 2004

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 Nov. 28, 2004

Nov. 28, 2004

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

Re: Resend: Re-implement MSVCRT *printf functions
by Aneurin Price Nov. 28, 2004

Nov. 28, 2004

Any further comments on this?

4 6

Translate dir names into Spanish
by Joaquín Fernández Nov. 28, 2004

Nov. 28, 2004

Hi 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?? Can i translate Wine into spanish?? How? Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Unicodified fontdlg (next try)
by Robert Shearman Nov. 26, 2004

Nov. 26, 2004

Jacek Caban wrote: > Changelog: > Unicodified fontdlg > >------------------------------------------------------------------------ > >@@ -216,52 +213,60 @@ > */ > BOOL WINAPI ChooseFontA(LPCHOOSEFONTA lpChFont) > { >- LPCVOID template; >- HRSRC hResInfo; >- HINSTANCE hDlginst; >- HGLOBAL hDlgTmpl; >- >- if ( (lpChFont->Flags&CF_ENABLETEMPLATEHANDLE)!=0 ) >- { >- template=(LPCVOID)lpChFont->hInstance; >- } else >- { >- if ( (lpChFont->Flags&CF_ENABLETEMPLATE)!=0 ) >- { >- hDlginst=lpChFont->hInstance; >- if( !(hResInfo = FindResourceA(hDlginst, lpChFont->lpTemplateName, >- (LPSTR)RT_DIALOG))) >- { >- COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); >- return FALSE; >- } >- } else >- { >- hDlginst=COMDLG32_hInstance; >- if (!(hResInfo = FindResourceA(hDlginst, "CHOOSE_FONT", (LPSTR)RT_DIALOG))) >- { >- COMDLG32_SetCommDlgExtendedError(CDERR_FINDRESFAILURE); >- return FALSE; >- } >- } >- if (!(hDlgTmpl = LoadResource(hDlginst, hResInfo )) || >- !(template = LockResource( hDlgTmpl ))) >- { >- COMDLG32_SetCommDlgExtendedError(CDERR_LOADRESFAILURE); >- return FALSE; >- } >+ CHOOSEFONTW chFontw; >+ LOGFONTW logFontw; >+ LPLOGFONTA lpLogFonta; >+ int len; >+ BOOL ret; >+ LPSTR lpszStyle; >+ LPCSTR lpTemplateName; >+ >+ memcpy(&chFontw, lpChFont, sizeof(CHOOSEFONTW)); >+ memcpy(&logFontw, lpChFont->lpLogFont, sizeof(LOGFONTA)); >+ chFontw.lpLogFont = &logFontw; >+ >+ MultiByteToWideChar(CP_ACP, 0, lpChFont->lpLogFont->lfFaceName, >+ LF_FACESIZE, chFontw.lpLogFont->lfFaceName, LF_FACESIZE); >+ >+ if(lpChFont->lpszStyle) { >+ len = MultiByteToWideChar(CP_ACP, 0, lpChFont->lpszStyle, -1, NULL, 0); >+ chFontw.lpszStyle = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len*sizeof(WCHAR)); > > Initialising the whole string to zero just before it is about to be overwritten seems needlessly wasteful on CPU cycles and memory bandwidth. You seem to do this in a few places. Yes, MultiByteToWideChar can, in some cases, leave the string without a null terminator, but that only happens when there is insufficient buffer. In this case, the only way that can happen is if another thread modifies the buffer between the previous MultiByteToWideChar and the next one here. If you wanted to be really careful, you could always add "chFontw.lpszStyle[len-1] = '\0';" after to call to MultiByteToWideChar. >+ MultiByteToWideChar(CP_ACP, 0, lpChFont->lpszStyle, -1, chFontw.lpszStyle, len); >+ HeapFree(GetProcessHeap(), 0, lpChFont->lpszStyle); > > You seem to be freeing a buffer that the user passed in. How do you know it was allocated with HeapAlloc? >+ } >+ >+ if(lpChFont->lpTemplateName) { >+ len = MultiByteToWideChar(CP_ACP, 0, lpChFont->lpTemplateName, -1, NULL, 0); >+ chFontw.lpTemplateName = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len*sizeof(WCHAR)); >+ MultiByteToWideChar(CP_ACP, 0, lpChFont->lpTemplateName, >+ -1, (LPWSTR)chFontw.lpTemplateName, len); >+ } >+ >+ ret = ChooseFontW(&chFontw); >+ >+ lpLogFonta = lpChFont->lpLogFont; >+ lpszStyle = lpChFont->lpszStyle; >+ lpTemplateName = lpChFont->lpTemplateName; >+ memcpy(lpChFont, &chFontw, sizeof(CHOOSEFONTA)); >+ lpChFont->lpLogFont = lpLogFonta; >+ lpChFont->lpszStyle = lpszStyle; >+ lpChFont->lpTemplateName = lpTemplateName; >+ memcpy(lpChFont->lpLogFont, &logFontw, sizeof(LOGFONTA)); >+ WideCharToMultiByte(CP_ACP, 0, logFontw.lfFaceName, >+ LF_FACESIZE, lpChFont->lpLogFont->lfFaceName, LF_FACESIZE, 0, 0); >+ >+ if(chFontw.lpszStyle) { >+ len = WideCharToMultiByte(CP_ACP, 0, chFontw.lpszStyle, -1, NULL, -1, 0, 0);; >+ WideCharToMultiByte(CP_ACP, 0, chFontw.lpszStyle, -1, lpChFont->lpszStyle, len, 0, 0); >+ HeapFree(GetProcessHeap(), 0, chFontw.lpszStyle); > } >- if (TRACE_ON(commdlg)) >- _dump_cf_flags(lpChFont->Flags); > >- if (lpChFont->Flags & (CF_SELECTSCRIPT | CF_NOVERTFONTS )) >- FIXME(": unimplemented flag (ignored)\n"); >+ if(chFontw.lpTemplateName) >+ HeapFree(GetProcessHeap(), 0, (LPBYTE)chFontw.lpTemplateName); > > You shouldn't need a cast here, unless lpTemplateName is a const. > >- return DialogBoxIndirectParamA(COMDLG32_hInstance, template, >- lpChFont->hwndOwner, FormatCharDlgProcA, (LPARAM)lpChFont ); >+ return ret; > } > >- > #define TEXT_EXTRAS 4 > #define TEXT_COLORS 16 > > > ... >@@ -1072,34 +1083,34 @@ > } > > /*********************************************************************** >- * FormatCharDlgProcA [internal] >+ * FormatCharDlgProc [internal] > */ >-INT_PTR CALLBACK FormatCharDlgProcA(HWND hDlg, UINT uMsg, WPARAM wParam, >+INT_PTR CALLBACK FormatCharDlgProc(HWND hDlg, UINT uMsg, WPARAM wParam, > LPARAM lParam) > { >- LPCHOOSEFONTA lpcf; >+ LPCHOOSEFONTW lpcf; > INT_PTR res = FALSE; > > if (uMsg!=WM_INITDIALOG) > { >- lpcf=(LPCHOOSEFONTA)GetPropA(hDlg, WINE_FONTDATA); >- if (!lpcf && uMsg != WM_MEASUREITEM) >+ lpcf=(LPCHOOSEFONTW)GetPropW(hDlg, strWineFontData); >+ if (!lpcf) > return FALSE; > if (CFn_HookCallChk32(lpcf)) >- res=CallWindowProcA((WNDPROC)lpcf->lpfnHook, hDlg, uMsg, wParam, lParam); >+ res=CallWindowProcW((WNDPROC)lpcf->lpfnHook, hDlg, uMsg, wParam, lParam); > > This isn't something wrong with your patch, but is in the original code too. We shouldn't need to cast here, because if lpfnHook isn't using the right calling conventions or doesn't have the same number of parameters then we shouldn't be using CallWindowProc to start with. > if (res) > return res; > } > else > { >- lpcf=(LPCHOOSEFONTA)lParam; >+ lpcf=(LPCHOOSEFONTW)lParam; > if (!CFn_WMInitDialog(hDlg, wParam, lParam, lpcf)) > { > TRACE("CFn_WMInitDialog returned FALSE\n"); > return FALSE; > } > if (CFn_HookCallChk32(lpcf)) >- return CallWindowProcA((WNDPROC)lpcf->lpfnHook,hDlg,WM_INITDIALOG,wParam,lParam); >+ return CallWindowProcW((WNDPROC)lpcf->lpfnHook,hDlg,WM_INITDIALOG,wParam,lParam); > } > switch (uMsg) > { > > Rob

1 0

Re: profiling GTA4. question about polling
by Brian Gunlogson Nov. 26, 2004

Nov. 26, 2004

The patch you gave me is too incomplete to run GTA :( I can start a game, but once the loading screen says it is done, the game crashes. Looked at the console, it says, "fixme:drawStridedFast TODO". The crash happens at the end of drawStridedFast(), inside glDrawElements(). Your patch will really speed things up when it is finished. In a fresh CVS tree, I disabled drawStridedSlow and applied 2 polling patches submitted to wine-patches. The game works almost as fast as in Windows!! Brian G. --- Raphael <fenix(a)club-internet.fr> wrote: > Here is it. > > But i have some problems with hardware vertex buffers (using vbo extension) > i have some 'transparent" objects (ie graphics bugs) > Anyway, If you encounter same problems you can uncomment this line: > //useSoft |= (0 != (Usage & D3DUSAGE_WRITEONLY)); > (dls/d3d8/vertexbuffer.c at line 71) __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 2

Internet Explorer 6 Installer script
by Hajime Segawa Nov. 26, 2004

Nov. 26, 2004

I wrote a tiny shell script that can install IE6sp1 and WMP7. I hope this script can help you. RealPlayer 10, MSN Messenger 6.4, Yahoo!Japan Messenger seem to work with this configuration. http://sidenet.ddo.jp/winetips/config.html I took some screenshots. http://sidenet.ddo.jp/winetips/files/

2 2

dlls/mscms/profile.c breakage
by Gerald Pfeifer Nov. 25, 2004

Nov. 25, 2004

The following change to dlls/mscms/profile.c revision 1.6 date: 2004/11/21 15:48:18; author: julliard; state: Exp; lines: +135 -3 Implement and test GetColorProfileElementTag, GetCountColorProfileElements and IsColorProfileTagPresent. Stub GetStandardColorSpaceProfile{A,W}. breaks FreeBSD 4.10 (with XFree86-4.3.0) as follows: gmake[2]: Entering directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms' /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o profile.o profile.c profile.c: In function `GetColorProfileElementTag': profile.c:142: error: `LCMSICCPROFILE' undeclared (first use in this function) profile.c:142: error: (Each undeclared identifier is reported only once profile.c:142: error: for each function it appears in.) profile.c:142: error: `cmsprofile' undeclared (first use in this function) profile.c:142: error: parse error before ')' token profile.c: In function `GetCountColorProfileElements': profile.c:174: error: `LCMSICCPROFILE' undeclared (first use in this function) profile.c:174: error: `cmsprofile' undeclared (first use in this function) profile.c:174: error: parse error before ')' token gmake[2]: *** [profile.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms' Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

4 13

Major Winelib Problems
by Sam Lauber Nov. 25, 2004

Nov. 25, 2004

I followed the tutorial for Winelib on my Linux system, building notepad. I examined the file "./notepad2" with readelf, and it said "Not an ELF file", and I do not have an a.out system. I opened it with my text editor (attached is the text I saw) and I was disappointed. Instead of a real "port", it was just a shell script that launches wine on a Windows program encapsulated in a ELF shared object file. I'm not happy. Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

5 5

Wineconf committee
by Jeremy White Nov. 25, 2004

Nov. 25, 2004

Hey folks, Brian, Alexandre, and I have been talking with some kind folks that are volunteering to help host Wineconf in Stuttgart; we're thinking late spring for Stuttgart. We've also had a generous offer to help set up a meeting in conjunction with LinuxTag in Karlruhe in mid to late June. This is all great, but I realized suddenly that the three of us were starting to consider things and make decisions on behalf of the broader Wine community. While I enjoy exercising dictatorial impunity, I prefer to have a cover group to make my imperiousness less obvious <grin>. Seriously, I'd like to ask for volunteers to serve on a Wineconf planning committee. I think the requirements for the position are as follows: 1. Able and willing to attend the next Wineconf in Germany 2. Able and willing to engage in and follow the planning and decision making process 3. Have a credible background in the Wine community (or live in the right part of Germany <grin>). 4. Be willing to help in ways that may be required, such as showing up a day early to help prepare, or bringing A/V equipment, or whatever way makes sense. (This isn't a requirement, but I really would like folks that are at least willing to contribute a little extra, if they are able.) To volunteer, please email me privately, and I'll build a chain of emails. If we don't get any volunteers, then Brian, Alexandre, and I will consider ourselves empowered, and will dictate that Marcus does all the work <grin>. Cheers, Jeremy

2 2

Re: SetForegroundWindow() from WM_ACTIVATE broken
by Jon Griffiths Nov. 25, 2004

Nov. 25, 2004

Hi, More on this problem ... here what happens under native when the back window is clicked: Order of trace below is (msg, hwnd, wparam,lparam) The app is started, click on the client area of the background window WM_MOUSEACTIVATE back 001203aa 02010001 (MA_ACTIVATE) Front window is told its going inactive WM_NCACTIVATE front 00000000 back WM_ACTIVATE front WA_INACTIVE back SetWindowPos() is called to raise back window to the front of the zorder, nc client and background told to paint WM_WINDOWPOSCHANGING back 00000000 0012fea8 WM_NCPAINT back 00000001 00000000 WM_ERASEBKGND back 0101005a 00000000 WM_WINDOWPOSCHANGED back 00000000 0012fea8 Back window is told its going active WM_NCACTIVATE back 00000001 front WM_ACTIVATE back WA_CLICKACTIVE front Now the back window calls SetForegroundWindow(front), within its WM_ACTIVATE handler Back window is told its going inactive WM_NCACTIVATE back 00000000 front WM_ACTIVATE back 00000000 front Front window brought to the top of the z-order w/SetWindowPos WM_WINDOWPOSCHANGING front 00000000 0012fd0c WM_NCPAINT front 00000001 00000000 WM_ERASEBKGND front 0101005a 00000000 WM_WINDOWPOSCHANGED front 00000000 0012fd0c Front window is told its going active WM_NCACTIVATE front 00000001 back WM_ACTIVATE front 00000001 back Under wine the message stream doesn't have the SetWindowPos calls, and there are several hundred activate/ncactivate messages, ending with the back window in the front of the z-order, activated with the focus. Looking at the logic in dlls/user/focus.c, in set_active_window(), it seems that SetWindowPos() was not being called because the windows both have the WS_EX_MANAGED style set. Commenting out the line if (!(GetWindowLongW( hwnd, GWL_EXSTYLE ) & WS_EX_MANAGED)) Caused the front window to remain on top after clicking on the back window, as desired. However it did then not get the focus as it should, and titlebar clicks and double clicks in the client area still allow the back window to rise to the top of the z-order. I added a test to check if the window is the foreground window (i.e. that some other window hasn't been set in the interim) before setting the focus. This means my test app now appears to work just like native. The attached patch makes both of these changes. I'd be interested in any comments regarding whether the above is correct. 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!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0

Breakage on Debian Sarge
by Michael Jung Nov. 25, 2004

Nov. 25, 2004

Hi, this patch (http://cvs.winehq.org/patch.py?id=14575) broke wine on a current Debian Sarge. Tested this on two machines. GUI applications do not respond any longer to mouse events. Tested regedit and winemine. Removing the patch solves the problem. Bye, Michael

3 2

Re: Adding debuginfo Support to Wine Makefiles
by Ivan Leo Puoti Nov. 25, 2004

Nov. 25, 2004

> It is already there. I added support for it a few months ago. I've did debug packages for mdk the day after AJ commited your patch, but is there any easy way I can test to see if the debug info works with winedbg? 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: Winecfg -> browse for folder
by Rolf Kalbermatter Nov. 24, 2004

Nov. 24, 2004

Robert van Herk <robert(a)robertvanherk.nl> wrote: >Also, I am having some troubles into tricking the SHBrowseForFolder >thingy into using a different root folder, since I guess I need to use >SHParseDisplayName >(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl…) >for that, but that doesn't seem to be implemented in Wine. This shouldn't be to difficult I guess. There are helper functions in shell32.pidl.c which should be close to what this function does actually. Something like this in pidl.c should do the trick: HRESULT WINAPI SHParseDisplayNameW(LPCWSTR pszName, IBindCtx *pbc, LPITEMIDLIST *ppidl, SFGAOF sfgaoIn, SFGAOF *psfgaoOut) { LPSHELLFOLDER sf; HRESULT ret = E_FAIL; TRACE("%s %p 0x%08lx\n", debugstr_w(pszName), ppidl, attributes ? *attributes : 0); if (SUCCEEDED (SHGetDesktopFolder(&sf))) { ret = IShellFolder_ParseDisplayName(sf, 0, pbc, (LPOLESTR)pszName, NULL, ppidl, &sfgaoIn); if (succeeded && psfgaoOut) *psfgaoOut = sfgaoIn; IShellFolder_Release(sf); } return ret; } Or you could probably use SHILCreateFromPathW() too for your purposes, which is similar. >Finally, I don't know how to free PIDLS. In the MSDN documentation they >use C++ calls for that, but I don't know how to port that to C. ILFree() exported as ordinal 155 from shell32 should be the function to use. It was undocumented in Windows for a long time but exists in shell32 since at least Win95. Rolf Kalbermatter

1 0