February 2009 - Wine-Devel - list.winehq.org

Re: 1.1.15 failing to build -- what changed?

by Ben Klein

2009/2/14 Scott Ritchie <scott(a)open-vote.org>: > 1.1.15 fails to build using an identical layout to 1.1.14, which means > something has changed with either the build dependencies or the way > configure is working. Worked for me on my Debian build environments. No changes required ... > Here's the build failure I'm getting on amd64, but it fails on all > arches: > http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_… This is the snippet that includes the failure: make[3]: Entering directory `/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/dlls/acledit' x86_64-linux-gnu-gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -Wall -g -O2 -o main.o main.c ../../tools/winegcc/winegcc -b x86_64-linux-gnu -m32 -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/debian/libtmp sh: x86_64-linux-gnu-as: not found winebuild: x86_64-linux-gnu-as --32 failed with status 32512 winegcc: ../../tools/winebuild/winebuild failed Looks like a broken build environment to me. > I'm going to sleep now, but hopefully I'll figure this out Valentine's > day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages > just yet. > > Thanks, > Scott Ritchie

Feb. 14, 2009

1.1.15 failing to build -- what changed?

by Scott Ritchie

1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working. Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_… I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet. Thanks, Scott Ritchie

Feb. 14, 2009

Re: GSoC 2009 coming up

by nn

Would it also be possible for someone to revisit the past GSOC's ( http://wiki.winehq.org/SummerOfCode/PreviousProjects ) and state what happened with each projects contributions in relation to being added to Wine, etc.. - Nat --- On Sat, 14/2/09, Kai Blin <kai.blin(a)gmail.com> wrote: > From: Kai Blin <kai.blin(a)gmail.com> > Subject: GSoC 2009 coming up > To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Received: Saturday, 14 February, 2009, 8:39 PM > Hi folks, > > the organization application period for GSoC 2009 is > starting on March 9th, so > it's time to get our > http://wiki.winehq.org/SummerOfCode wiki page in shape > again. Detlef Riekenberg and Roderick Colenbrander made a > good start, so if > the rest of you could check and make sure that all the > projects on there > still make sense? > > We should also investigate possible changes to the > requirements (weekly > reports to the mailing list come to mind). Maarten, any > comments? > > Cheers, > Kai > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more

Feb. 14, 2009

Re: Proposal: put Winetricks into Wine menu

by nn

How about help in a .chm file :) --- On Sat, 14/2/09, Dan Kegel <dank(a)kegel.com> wrote: > From: Dan Kegel <dank(a)kegel.com> > Subject: Proposal: put Winetricks into Wine menu > To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Received: Saturday, 14 February, 2009, 4:42 PM > I know, when I wrote Winetricks, I meant it as a > developers' > tool only. But... then... people started using it, and > it made sense to provide it as a way to download missing > visual C++ runtimes etc. for average users. > > Quite a few newbies trip over the fact that it > needs cabextract installed. Let's make it easy > for folks, actually package it up along with > Wine (SuSE does this already), and put it > in the Wine menu right beneath "Uninstall Windows > Software". > > What do people think? It might make life easier for a lot > of folks. > > (And, come to think of it, we should include some > documentation > in that menu. "man wine" just doesn't cut it > for the average > gui user, and "wine manual page" in the gnome > help browser is a broken link. But that's a separate > issue.) > - Dan Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more

Feb. 14, 2009

GSoC 2009 coming up

by Kai Blin

Hi folks, the organization application period for GSoC 2009 is starting on March 9th, so it's time to get our http://wiki.winehq.org/SummerOfCode wiki page in shape again. Detlef Riekenberg and Roderick Colenbrander made a good start, so if the rest of you could check and make sure that all the projects on there still make sense? We should also investigate possible changes to the requirements (weekly reports to the mailing list come to mind). Maarten, any comments? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 14, 2009

Re: Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows

by Kai Blin

On Friday 13 February 2009 18:54:23 Reece Dunn wrote: > The real benefit in terms of speed for Wine would be not to use msvc, > but to hand-optimise specific algorithms to take advantage of faster > assembly instructions. This would likely be for the cryptographic > algorithms (SHA1, MD5, etc), I doubt that'll be worth it. the crypto routines shouldn't be called that often, as opposed to say.. the DX math functions or the like. Of course as you said, this would only matter if any of these turn out to be performance hogs anyway. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 14, 2009

Re: mshtml: allow REG_EXPAND_SZ values for GeckoCabDir

by Christoph von Wittich

Hi Juan, No, I used RegGetValue which expands them for me. Christoph Juan Lang schrieb: > Hi Christoph, > > - /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ > - res = RegOpenKeyW(HKEY_CURRENT_USER, mshtml_keyW, &hkey); > - if(res != ERROR_SUCCESS) > - return FALSE; > - > file_name = heap_alloc(size+sizeof(GECKO_FILE_NAME)); > - res = RegQueryValueExA(hkey, "GeckoCabDir", NULL, &type, > (PBYTE)file_name, &size); > + /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ > + res = RegGetValueA(HKEY_CURRENT_USER, mshtml_keyA, "GeckoCabDir", > RRF_RT_ANY, &type, (PBYTE)file_name, &size); > > This change is unrelated to the subject. One change per patch, please. > > + if(res != ERROR_SUCCESS || (type != REG_SZ && type != REG_EXPAND_SZ)) { > heap_free(file_name); > return FALSE; > } > > If you're allowing REG_EXPAND_SZ, oughtn't you call > ExpandEnvironmentVariablesA as well? > --Juan >

Feb. 14, 2009

re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Dan Kegel

Very interesting. I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative. I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do. btw nice name, but it pulls up 7 million hits for me, not sure what you mean by "google doesn't reveal any other uses of the name". - Dan

Feb. 14, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Ben Klein

2009/2/14 Martin Hinner <martin(a)hinner.info>: > Hi, > > On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> 2009/2/14 Martin Hinner <martin(a)hinner.info>: >>> Purpose of this Wine DLL is to allow Windows applications to use >>> directly Unix library functions. This is useful for example for >>> applications which talk to specific drivers and it's not >>> efficient/possible to create system native DLL for such driver or >>> library. Win32 app. vendor is required only to detect execution under >>> Wine and load proper native library. >> >> Windows apps don't call *nix libraries directly as is, so I'm not sure >> I understand the purpose here. I can see it could potentially be >> useful for porting apps using winelib, but I don't see how it can be >> useful for full win32 apps precompiled for Windows systems. > > It is very useful for win32 apps in case you are dealing with hardware > or some specific stuff. I am not talking about using this to fix wine > bugs (i.e. creating a broken app). > > Think about application that is used for some industrial control, uses > some USB device with vendor-specific driver (no hid, CDC, mass > storage, etc). If you want to get it working on Linux, you have to > either create complicated wrapper for your Windows drivers (which is > in many cases impossible, btw) or you can use native linux driver, > libusb, etc. Another good example is automotive diagnostics. And > another example is FTDI FTD2xx drivers (although they have tried to > maintain compatibility between Win/Linux/Mac versions, you have to use > different routines on each system). Wine is (or has been) working on a driver system to handle native Windows USB device drivers via libusb, for things like printers and scanners where there are no Linux-native drivers. This is a better solution. > All this is what WINEGATE.DLL sovles with minimum possible effort. You > simply create class "CWin32Driver" "CLinuxWineDriver" and you're done. Only when a suitable native Linux library already exists, correct? There aren't many cases of this, from what I understand. >>> I agree that in most cases it's better to fix Wine than applications, >>> but there are real world problems that cannot be efficiently solved >>> outside the application. One good example is when Win32 app has to >>> talk to custom hardware. In many cases there are native Linux drivers >>> that have different API/etc and it is very very difficult to create >>> wrapper library between Windows-style and Linux/Unix-style drivers. In >>> such cases it's much easier to modify source code of Windows app to >>> use either Linux or Windows drivers/DLLs/etc. >> >> Why not use winelib for these cases if *nix support is important >> enough to modify the source so it works nicer in Wine? > > Because sometimes you don't get enough customers to get paid for > native Linux version and it's quite complicated to port even mid-sized > projects using winelib. For example try to compile MFC ... Given that for your system to work there has to be a Linux-native library for winegate to hook into, the effort involved in porting to Linux via winelib would likely be equal.

Feb. 14, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

Hi, On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/14 Martin Hinner <martin(a)hinner.info>: >> Purpose of this Wine DLL is to allow Windows applications to use >> directly Unix library functions. This is useful for example for >> applications which talk to specific drivers and it's not >> efficient/possible to create system native DLL for such driver or >> library. Win32 app. vendor is required only to detect execution under >> Wine and load proper native library. > > Windows apps don't call *nix libraries directly as is, so I'm not sure > I understand the purpose here. I can see it could potentially be > useful for porting apps using winelib, but I don't see how it can be > useful for full win32 apps precompiled for Windows systems. It is very useful for win32 apps in case you are dealing with hardware or some specific stuff. I am not talking about using this to fix wine bugs (i.e. creating a broken app). Think about application that is used for some industrial control, uses some USB device with vendor-specific driver (no hid, CDC, mass storage, etc). If you want to get it working on Linux, you have to either create complicated wrapper for your Windows drivers (which is in many cases impossible, btw) or you can use native linux driver, libusb, etc. Another good example is automotive diagnostics. And another example is FTDI FTD2xx drivers (although they have tried to maintain compatibility between Win/Linux/Mac versions, you have to use different routines on each system). All this is what WINEGATE.DLL sovles with minimum possible effort. You simply create class "CWin32Driver" "CLinuxWineDriver" and you're done. >> I agree that in most cases it's better to fix Wine than applications, >> but there are real world problems that cannot be efficiently solved >> outside the application. One good example is when Win32 app has to >> talk to custom hardware. In many cases there are native Linux drivers >> that have different API/etc and it is very very difficult to create >> wrapper library between Windows-style and Linux/Unix-style drivers. In >> such cases it's much easier to modify source code of Windows app to >> use either Linux or Windows drivers/DLLs/etc. > > Why not use winelib for these cases if *nix support is important > enough to modify the source so it works nicer in Wine? Because sometimes you don't get enough customers to get paid for native Linux version and it's quite complicated to port even mid-sized projects using winelib. For example try to compile MFC ... Martin

Feb. 14, 2009