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

Re: Wine download page usability problem

by Austin English

On Fri, Feb 20, 2009 at 11:24 AM, Dan Kegel <dank(a)kegel.com> wrote: > I got email from a friend who complained how > hard it was to install wine. Turns out he > assumed he had to go to winehq.org and > follow the download instructions there, > when all he needed to do was do > Applications / Add/Remove and pick Wine. > > Can we add in a line at the top saying > "Stable version 1.0.1 of Wine can usually be installed > just like any other Linux application using your > package manager (e.g. in Ubuntu, do Applications / Add/Remove, > select Wine, and click Apply Changes). Nitpick, but instead of 'Linux', use 'native'. FreeBSD's ports contains wine, as well as NetBSD's. > I think we should also move the text > "This endorsement is the primary recognition that CodeWeavers has > requested in exchange for hosting the Wine web site." > to the bottom of the page, and change it to read > "Thanks to CodeWeavers for hosting WineHQ.org". +1 -- -Austin

Feb. 20, 2009

Wine download page usability problem

by Dan Kegel

I got email from a friend who complained how hard it was to install wine. Turns out he assumed he had to go to winehq.org and follow the download instructions there, when all he needed to do was do Applications / Add/Remove and pick Wine. Can we add in a line at the top saying "Stable version 1.0.1 of Wine can usually be installed just like any other Linux application using your package manager (e.g. in Ubuntu, do Applications / Add/Remove, select Wine, and click Apply Changes). If that doesn't work, or if you need a newer version of Wine, here's how to get it." ? I know, that clutters things even more. Suggestions for achieving the same thing more concisely would be welcome. I think we should also move the text "This endorsement is the primary recognition that CodeWeavers has requested in exchange for hosting the Wine web site." to the bottom of the page, and change it to read "Thanks to CodeWeavers for hosting WineHQ.org". - Dan

Feb. 20, 2009

Re: TrainingPeaks WKO+ Version 22 build 105

by Juan Lang

Hi Chris! > I think I know how to implement this feature of Win32 serial comm, but > before I attempted I wanted to broadcast my intent to do so. Is > anyone else working on this, or in the serial.c area that would like > to discuss it? No one that I know of is working in this area. Periodically someone might work on serial comm stuff, particularly Uwe Bonnes, but in general this area languishes until someone motivated comes along. So please, work away :) Out of curiosity, which device are you playing with? Cheers, --Juan

Feb. 20, 2009

Re: msadp32.acm, winemp3.acm: Removed compiler warning

by Ricardo Filipe

you should send one patch per email, dan should have told you that :P good to see you guys on the project :) 2009/2/20 Adam Stoelting <astoelting(a)ucla.edu> > Hello, > > These are my first patches. I am graduate student at UCLA and am trying to > help with porting Wine to 64 bit. I haven't seen any Microsoft source code > or done any dll dissasembly on my own. > > Change Log: > Removed the compiler pointer cast warning for dlls/msadp32.acm/msadp32.c > and > dlls/winemp3.acm/mpegl3.c. > > Thanks, > Adam > > > >

Feb. 20, 2009

Re: msi: begin support for finding network last sources in find_published_source

by Aric Stewart

Hello, No i never saw the e-mail that you send to Jeremy. I will admit that i did not dig really deep for this patch as it appeared to me that the fix was obvious (there was even a fixme in the code saying we needed to do what the installer was asking for) There are about 4 CAB files that the service pack asks for to install (and only installs a few files out of each) that are accessed by this method. Each one does not exist on the original media at all and only seems accessable via the LastSource location. I am curious what tests you did to prove that you did not need the original media or even the copied cab files? Did you do a test on windows where you deleted them all and the upgrade worked? I will investigate some more, but i do not feel that this patch is incorrect, even if it should not be needed. Am I right there? thanks, -aric James Hawkins wrote: > On Thu, Feb 19, 2009 at 12:28 PM, Aric Stewart <aric(a)codeweavers.com> wrote: >> Fix for office 2007 sp 1 install. >> --- >> dlls/msi/media.c | 33 +++++++++++++++++++++++++++++++++ >> 1 files changed, 33 insertions(+), 0 deletions(-) >> > > I believe you're going down the wrong road with respect to the Office > 2007 SP1 installer. None of the files installed/patched by SP1 need > access to the original media, or stored local copies of the cab > archives. With the fullfile install (which I'm not sure there's > another version), you should be able to remove the original media, > erase the stored cab files, and successfully install SP1. The fact > that our implementation tries to access those cabs or the original > media is the bug. There are many conditions and variables that factor > in to whether a file should be reinstalled or not, and most of them > have been fixed, but this patch is hiding all of the rest of the bugs. > I'm not sure if you got the email I sent Jer about this problem, but > the real bug is that we aren't handling the REINSTALL variable > correctly (or REINSTALLMODE for that matter.) Can you please describe > the exact case for why this patch is needed? >

Feb. 20, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by Ben Klein

2009/2/20 Hans Leidekker <hans(a)codeweavers.com>: > On Friday 20 February 2009 08:38:09 James Hawkins wrote: > >> > It would hurt overall performance if we do it at the directory API >> > level, so the same logic does not apply. >> > >> >> I'm not advocating adding it to the directory API. I'm saying if we >> don't care about it at that level, then we shouldn't care about it in >> fusion, and we certainly shouldn't add that functionality to fusion >> where it doesn't exist in native fusion. > > Where that functionality exists in Windows is an implementation > detail, we don't have to copy that. I don't know the details, but this is not the mentality of Wine. The problem is if some application expects a particular behaviour, that behaviour needs to be replicated in Wine. Binary compatibility is important, so Wine tries to be bug-for-bug compatible. This might be off-topic for this thread, but I feel it is relevant. Feel free to ignore or correct me if I'm wrong here.

Feb. 20, 2009

Re: Status of USB driver support?

by Alexander Morozov

On Thursday 19 February 2009 16:55:20 emiliano esposito wrote: > Unhandled exception: unimplemented function > usbd.sys.USBD_GetUSBDIVersion called in 32-bit code (0x7ee2e923) You can try attached patch >From b7fad82130608126244ba2aee3f91b3337229fb3 Mon Sep 17 00:00:00 2001 From: Alexander Morozov <amorozov(a)etersoft.ru> Date: Fri, 20 Feb 2009 12:14:33 +0300 Subject: [PATCH 3/3] usbd.sys: Implement USBD_GetUSBDIVersion. --- dlls/usbd.sys/usbd.c | 7 +++++++ dlls/usbd.sys/usbd.sys.spec | 2 +- include/ddk/usb.h | 6 ++++++ 3 files changed, 14 insertions(+), 1 deletions(-) diff --git a/dlls/usbd.sys/usbd.c b/dlls/usbd.sys/usbd.c index 8c2a8f9..c7c8fab 100644 --- a/dlls/usbd.sys/usbd.c +++ b/dlls/usbd.sys/usbd.c @@ -132,6 +132,13 @@ PURB WINAPI USBD_CreateConfigurationRequest( return urb; } +void WINAPI USBD_GetUSBDIVersion( PUSBD_VERSION_INFORMATION VersionInformation ) +{ + TRACE( "%p\n", VersionInformation ); + VersionInformation->USBDI_Version = 0x300; + VersionInformation->Supported_USB_Version = 0x100; +} + NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) { return STATUS_SUCCESS; diff --git a/dlls/usbd.sys/usbd.sys.spec b/dlls/usbd.sys/usbd.sys.spec index 5d0377c..a18bbf8 100644 --- a/dlls/usbd.sys/usbd.sys.spec +++ b/dlls/usbd.sys/usbd.sys.spec @@ -19,7 +19,7 @@ @ stub USBD_GetInterfaceLength @ stub USBD_GetPdoRegistryParameter @ stub USBD_GetSuspendPowerState -@ stub USBD_GetUSBDIVersion +@ stdcall USBD_GetUSBDIVersion(ptr) @ stub USBD_InitializeDevice @ stub USBD_MakePdoName @ stub USBD_ParseConfigurationDescriptor diff --git a/include/ddk/usb.h b/include/ddk/usb.h index b8f5f3f..a5db726 100644 --- a/include/ddk/usb.h +++ b/include/ddk/usb.h @@ -82,6 +82,12 @@ typedef PVOID USBD_PIPE_HANDLE; typedef PVOID USBD_CONFIGURATION_HANDLE; typedef PVOID USBD_INTERFACE_HANDLE; +typedef struct _USBD_VERSION_INFORMATION { + ULONG USBDI_Version; + ULONG Supported_USB_Version; +} USBD_VERSION_INFORMATION; +typedef struct _USBD_VERSION_INFORMATION *PUSBD_VERSION_INFORMATION; + typedef enum _USBD_PIPE_TYPE { UsbdPipeTypeControl, UsbdPipeTypeIsochronous, -- 1.6.1.3.GIT

Feb. 20, 2009

TrainingPeaks WKO+ Version 22 build 105

by Chris Teague

I'm trying to use WKO, it is software which communicates via USB to an external device (watch/heart rate monitor/bike odometer) using FTDI drivers. When I plug in the device dmesg tells me it's recognized and placed on /dev/ttyUSB0. I've put a link to that inside of .wine/dosdevices/com1. I still can't get communication to work, on stdout I get the following message repeated many times: fixme:comm:wait_on EV_RXFLAG not handled I think I know how to implement this feature of Win32 serial comm, but before I attempted I wanted to broadcast my intent to do so. Is anyone else working on this, or in the serial.c area that would like to discuss it? Software is available as demo here: http://home.trainingpeaks.com/wko-desktop-software/download.aspx

Feb. 20, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by Hans Leidekker

On Friday 20 February 2009 08:38:09 James Hawkins wrote: > > It would hurt overall performance if we do it at the directory API > > level, so the same logic does not apply. > > > > I'm not advocating adding it to the directory API. I'm saying if we > don't care about it at that level, then we shouldn't care about it in > fusion, and we certainly shouldn't add that functionality to fusion > where it doesn't exist in native fusion. Where that functionality exists in Windows is an implementation detail, we don't have to copy that. -Hans

Feb. 20, 2009

Re: revert of a6c07ffba4b2b37d01affb4c39f032bb5f8d34bf

by Francois Gouget

On Fri, 20 Feb 2009, Francois Gouget wrote: [...] > Well, since Cygwin is a Unix platform after a fashion (iirc), I don't > think you need to check with MSVC (with MinGW it would be different). So > I think your patch is ok. You should add a comment in the port.h file saying that this define is needed for Cygwin though (so the next one who stumbles on this suspicious define knows why it was put there). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Feb. 20, 2009