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

Re: How difficult would it be to make the equivalent of Windows Terminal Server with Wine?

by Boaz Harrosh

Andrew Quigley wrote: > What I would like to be able to deploy would be a system which runs > multiple Win32 compatible desktops and multiple logins on a server, > with the clients accessing the desktops via RDP or ICA protocols. How > many of the pieces required to accomplish that already exist, and what > pieces have yet to be built? A quick search on freshmeat shows me a > few different rdp clients, so it looks like the protocol spec is > known. What would be involved in creating a RDP server that shows up > as a video driver as far as the win32 programs are concerned? > > I did something similar. I used X, and have written an IE embeddable OCX that automatically Installs X-Server and connects to the X applications on the server, in my case they are Windows apps running under wine. So basically you set up a web server on your Linux machine. You put a page with the different apps you want to serve. The user uses IE to navigate to that page. When clicking, the App comes up as a window in his/her machine. First time visit Installs a 12M Cygwin/X server. I do intend to publish the OCX project as GPL. And the wise-script to package the Cygwin/X installation. And also have available the binary package. Hope that can help Free Life Boaz

Oct. 31, 2004

Interesting Installshield failure running Keyhole installer

by Dan Kegel

If you haven't tried the Keyhole demo on Windows yet, give it a shot. It's kind of fun to look at an aerial view of every place you've ever lived, say. You can download it from http://www.keyhole.com Unfortunately, the installer is a no-go under Wine (cvs as of a couple days ago). It puts up a dialog or two ("Starting InstallShield Wizard", "Preparing Setup"), and then stops with an Installshield dialog box "An error (-5006: 0x80004005) has occurred while running the setup..." There's a Report / Detail / OK choice, which is pretty cool. Choosing Detail shows: Error Code: -5006 : 0x80004005 Error Information: >Kernel\ServiceProvider.cpp (77) >Kernel\ObjectHolder.cpp (441) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >Kernel\FileGroup.cpp (398) >Kernel\ServiceProvider.cpp (77) >SetupDLL\SetupDLL.cpp (1375) pAPP:Keyhole 2 LT PVENDOR:Keyhole Corporation PGUID:036ABCF1-A419-4074-B35C-2C70592A0EBB $7.1.100.1248PAK @Windows 95 (67109814) IE 6.0.2800.1106 For what it's worth, here are the Wine console messages that were shown up to this point: Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x4024ce48): not verifying image fixme:crypt:RSA_CPCreateHash 4024ce48 32772 00000000 00000000 0x4024cd84 fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x4024c790): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x4024ef38): not verifying image fixme:crypt:RSA_CPCreateHash 4023d9c0 32772 00000000 00000000 0x4024eea4 fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects ... I'm not really trying to get it to run, just figured I'd post a note about its status while I had a free minute. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Oct. 31, 2004

Re: Wine on FreeBSD current

by Gerald Pfeifer

On Tue, 22 Jun 2004, Alexandre Julliard wrote: > Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: >> ...and in fact, Alexandre, wouldn't it be better to have _some_ apps >> broken under Wine on FreeBSD than a completely broken Wine on FreeBSD >> for all apps? > Nope. What matters is not so much how many apps run today, but that we > have a design that will allow at some point in the future to run all > possible apps. We shouldn't compromise on a design that guarantees > that some apps will *never* run just because it runs more apps today. > Besides, a completely broken Wine is the best way to ensure that > someone starts worrying about the issue <g> Sadly, that's not how it worked this time. Rather, FreeBSD users are still using an old version of Wine, and Wine mainline gets worse and worse on that platform. Would you mind considering the patch below, so that we can at least make some progress? Gerald ChangeLog: Disable memory reservation code on FreeBSD, where it just doesn't work? Index: libs/wine/mmap.c =================================================================== RCS file: /home/wine/wine/libs/wine/mmap.c,v retrieving revision 1.7 diff -u -3 -p -r1.7 mmap.c --- libs/wine/mmap.c 24 Jul 2004 02:30:09 -0000 1.7 +++ libs/wine/mmap.c 30 Oct 2004 20:04:47 -0000 @@ -254,6 +254,9 @@ void mmap_init(void) struct reserved_area *area; struct list *ptr; #ifdef __i386__ +#if ! defined(__FreeBSD__) + /* FIXME: this is broken on FreeBSD (verified on 4.10 and 5.2.1). */ + char stack; char * const stack_ptr = &stack; char *user_space_limit = (char *)0x80000000; @@ -280,6 +283,7 @@ void mmap_init(void) /* Linux heuristic: if the stack top is at c0000000, assume the address space */ /* ends there, this avoids a lot of futile allocation attempts */ if (base != (char *)0xc0000000) +#endif #endif reserve_area( base, 0 ); }

Oct. 30, 2004

Re: Gradient Color for Caption Bar

by William Poetra Yoga H

My patch didn't get merged... :( Anything wrong with it? Maybe I should make NC_DrawCaption() call DrawCaption() instead? Otherwise I think it's good enough. Any ideas why my patch wasn't merged? Lack of testsuite? Thanks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Oct. 30, 2004

Default System Colors

by William Poetra Yoga H

The last time I submitted a patch to change the default system colors from win95 to winxp (classic), it wasn't merged. I think this was because I didn't discuss it here. So now, should we change the default system colors for WINE, from win95 to winxp (classic)? I really think it looks a lot better with the new colors, as the win95 colors are too dull (MS certainly must have done a lot of research into this). Opinions, please. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Oct. 30, 2004

Re: Listview: Fix notify_dispinfoT for Unicode Parent

by Dimitrie O. Paun

On Sat, Oct 30, 2004 at 02:16:09PM +0100, Robert Shearman wrote: > + /* > + only need to convert to string from Unicode to Ansi if we expect a > + valid pointer > + */ > + if ((infoPtr->notifyFormat == NFR_ANSI) && (pdi->item.mask & LVIF_TEXT) && is_textT(pdi->item.pszText, FALSE)) > + convertToAnsi = TRUE; This can't be right -- what if the data is already in ASCII format? I think we need to take isW into account. -- Dimi.

Oct. 30, 2004

Re: Listview notify_dispinfoT Messageformat

by Dimitrie O. Paun

On Wed, Oct 27, 2004 at 09:28:33PM +0100, Robert Shearman wrote: > To summarise: *all* common control notifications should be sent in the > same format (ANSI/Unicode) as their parent (except if overriden by the > CCS_SETUNICODEFORMAT message). It should not be based on the message > sent to the control. Just to be 100% clear: -- what do you mean by "in the same format as their parent"? From your patch, it seems that: 1. In WM_CREATE, we have to query the notify format as such: infoPtr->hwndNotify = lpcs->hwndParent; infoPtr->notifyFormat = SendMessageW(infoPtr->hwndNotify, WM_NOTIFYFORMAT, (WPARAM)infoPtr->hwndSelf, (LPARAM)NF_QUERY); 2. Handle WM_NOTIFYFORMAT, by querying the parent again: infoPtr->notifyFormat = SendMessageW(hwndFrom, WM_NOTIFYFORMAT, (WPARAM)infoPtr->hwndSelf, NF_QUERY); 3. When sending notifications, convert to ASCII iff infoPtr->notifyFormat == NFR_ANSI If so, this is what we had before Aric did this change: http://cvs.winehq.org/cvsweb/wine/dlls/comctl32/listview.c.diff?r1=1.330&r2… What was wrong with the code before? It tried to send the notification in the format specified by infoPtr->notifyFormat. The dependance on the the type of message that was sent to the control is just to do the conversion when we have to. That is: fmt-of-msg-sent-to-ctrl infoPtr->notifyFormat conversion-required !isW (ASCII) NFR_ANSI no isW (Unicode) NFR_ANSI yes !isW (ASCII) NFR_UNICODE yes isW (Unicode) NFR_UNICODE no The old code looked as isW only to determine if any conversion was required (which I think you have to), but the format of the actual notification was strictly determined by infoPtr->notifyFormat: if (infoPtr->notifyFormat == NFR_ANSI) realNotifCode = get_ansi_notification(notificationCode); else realNotifCode = notificationCode; bResult = notify_hdr(infoPtr, realNotifCode, (LPNMHDR)pdi); So, what was wrong with the original code? -- CCS_SETUNICODEFORMAT message: this is a flag, not a message, no? If so, what is its semantics? If set, we have to ignore infoPtr->notifyFormat, and always send notifications in Unicode format? It's important to figure this one once and for all, so that we can fix all the controls properly. -- Dimi.

Oct. 30, 2004

CurrentVersion missing

by James Hawkins

The string HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion is missing from a normal wine install. When installing gmail notifier, the installer checks to make sure the OS version is NT or greater, but the installer calls GetVersion(), and after that succeeds, it then queries the CurrentVersion string above from the registry, but doesnt find it. After I added the key manually and set it to an arbitrary "1", the install proceeds (it only checks the length of the string not the actual data). Shouldn't this string always be a part of the registry anyway? And if so, how would I go about making sure that it is a part of the standard registry that ships with wine? -- James Hawkins

Oct. 30, 2004

Re: Countering arguments against Wine

by Holly Bostick

Dan Kegel wrote: > I've run into people several times who dislike the > fact that I advocate or even work on the Wine project, > because they feel that it takes focus away from > working on the Linux desktop. I beg to differ, but > I've never had a really snappy comeback for them. > It happened again today, and this time it occurred > to me I should write a page on the topic to organize > my thoughts. Here it is: > http://www.kegel.com/wine/why.html > Comments welcome. > > Thanks, > Dan > Dan, first of all, thanks for writing that dowm. I agree with what you say, until you reach the "But doesn't Wine take away the incentive for native ports?" section. I actually appreciate this reason, as it clarifies a 'feeling' that I've been unable to clearly express about this issue: 2. once Linux's market share is above 20%, there will be a strong economic incentive to do native Linux ports anyway, because running a Windows app under Linux will always feel strange. But I wonder if this is in fact true. I am a pure Linux user; I began my migration a year and a half ago, moving from a dual-boot, to a multi-boot (2 versions of Windows and 5 distributions of Linux on one system), and finally ditched all alternate boots except the Linux a few months ago. So I'm not all that far from the migration mindset, since I used Windows for over 10 years, but as a pure Linux user, I'm not all that close to it anymore, either. I've got Wine running, and installed several programs I was familiar with under Windows, mostly to perform tasks that I couldn't figure out how to do under Linux, but which I either knew how to perform using Windows apps, or could find HOW-TOs for that specified Windows apps. I find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine <program_name> from a terminal, or having to write a little start script in order to make a panel shortcut to it). Once the program is running, though, it doesn't "feel" strange at all; after all, the reason I'm running it is most likely because I'm familiar with it. This of course, assumes that the program in question runs well under Wine, which we will assume for the sake of this discussion, if you don't mind ;-) . I have admittedly found that it's ultimately "easier" (for me) to re-encode a video with transcode and mplex than it is to do so using TMPGEnc under Wine, which was a surprise given that I know squat about re-encoding video (I know somewhat more, now, though). I also found that given a choice between equivalent Linux native programs and Windows programs under Wine (Aisle Riot and Pretty Good Solitaire), I'll often choose the Linux native program simply because it's easier to *start* (not because I prefer it, per se). Maybe that's what you (and I) mean by "feeling strange", but since I'm not sure what causes this feeling, I am not certain that migrating XP users, who are used to and have no complaints with XP functionality but rather are migrating because they don't like the Windows security model (or lack therof)-- meaning, for practical reasons such as increasing cost for less value, rather than philosophical ones such as a deep objection to Windows' design philosophy or business practices-- would feel the same way after switching to Linux. All of those "a computer is just a tool" people who find it more strange and painful to use the command-line, or get confused if they have to read --help output or a man page "just to get something done" may well find that their relief at having these familiar tools available swamps any "strange" feelings of (guilt,irritation?) that they may (or may not) experience when running Windows programs under Linux. After all, you'll only have those feelings if you *care*-- and many, many users don't. If I come up with a "better" reason #2, I'll let you know ;-) . Holly

Oct. 30, 2004

Re: Countering arguments against Wine

by Dan Kegel

Brian Vincent wrote: > On Fri, 29 Oct 2004 23:40:38 -0700, Dan Kegel <dank(a)kegel.com> wrote: >> http://www.kegel.com/wine/why.html > > These aren't exactly buried, but they're not obvious either: > > http://www.winehq.com/site/myths > http://www.winehq.com/site/why I had a link to the 2nd one, now I've got a link to the 1st one, thanks. Those pages are good, but I wanted one that focused in on just this one question. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Oct. 30, 2004