March 2005 - Wine-Devel - list.winehq.org

Re: [Wine]specified Windows directory not accessible

by Joachim von Thadden

Am Wed, Mar 30, 2005 at 11:34:59PM +1200 schrieb Wesley Parish: > I get this response when I try to install the VCToolkit. > > [wparish(a)localhost wine-hdd]$ wine ./VCToolkitSetup.exe > Warning: the specified Windows directory L"C:\\windows" is not accessible. > Warning: the specified System directory L"C:\\windows\\system" is not > accessible. > Warning: could not find DOS drive for current working directory > '/home/wparish/wine-hdd', starting in the Windows directory. > wine: cannot find './VCToolkitSetup.exe' > > What have I missed, or misconfigured? Wine tries to resolve your /home/wparish/wine-hdd to a mapped directory. You should make a link in ~/.wine/dosdevices like ln -s /home/wparish/wine-hdd ~/.wine/dosdevices/h: to have your directory mapped as a drive H:. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 30, 2005

specified Windows directory not accessible

by Wesley Parish

I get this response when I try to install the VCToolkit. [wparish(a)localhost wine-hdd]$ wine ./VCToolkitSetup.exe Warning: the specified Windows directory L"C:\\windows" is not accessible. Warning: the specified System directory L"C:\\windows\\system" is not accessible. Warning: could not find DOS drive for current working directory '/home/wparish/wine-hdd', starting in the Windows directory. wine: cannot find './VCToolkitSetup.exe' What have I missed, or misconfigured? (I'm officially running 20040813, though I compiled and installed 20050211 over it - I hadn't read that I should uninstall the previous wine installation before installing a new one. :) Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

March 30, 2005

Re: wine/dlls wininet/netconnection.c user/text.c ...

by Dimitrie O. Paun

On Tue, Mar 29, 2005 at 01:49:22PM -0600, Alexandre Julliard wrote: > Log message: > Peter Berg Larsen <pebl(a)math.ku.dk> > Janitorial: Get rid of strncpy/strncpyW. This is cool stuff. Now it would be nice if someone hacks winapi_check to ... check for strncpy() business so it doesn't sneak back in. Other than that, are all strncpy() instances gone? If so we should also nuke strncpyW() from wine/unicode.h too. -- Dimi.

March 30, 2005

WineConf Agenda

by Brian Vincent

I'm going to start this off with a huge apology - there's a very real chance I've asked someone to do a presentation and it's not on this list. If so, you need to email me to remind me. If you were definitely planning on presenting something because I emailed you, let me know - there's lots of space available. I know this only affects 2 or 3 people, but I tossed around a few ideas and didn't want to leave any loose ends. (Any of those items would make nice topics.) This is the initial agenda for WineConf. I hope to add a few more items, but Jeremy suggested I pull the trigger and announce it. I agree - there's enough here to fill two days and leave a lot of time for people to get together in small groups. Only the first two items are in any formal order: Alexandre - Keynote (He said he's reusing last year's slides.) Dimi - to do list / status update Steven Edwards and the ReactOS crew Charles W Stevenson - Winelib / Winelib porting / and a commercial perspective Andrew Barlett / Samba team? - Samba 4, authentication, lots of intelligent ideas Juan Lang - Wine's RPC + Samba or something like that :) Jeremy White - CXTest Jason Edmeades - DirectX 9 / wined3d / eye candy I think a full agenda would be about 11 items. If you would like to present something let me know - there's definitely space available. If you've been wondering, "There's a neat project I'd like to do if I could only get a few more people interested", well, this is the perfect time to bring it up. If there's something strategic to Wine development, this is a great time to discuss it. For example, we've had mixed feelings regarding revision control and its been suggested to bring it up as a topic. Would anyone find it useful to discuss subversion vs. arch vs. cvs? We could probably get Mike Hearn to show off how he manages patches with SVK and then let him arm wrestle Alexandre about whether arch is better. Friday night we will have an informal dinner after meeting up at the hotel. The conference will kick off Saturday morning on campus around 8am. Lunch will be provided on Saturday and Sunday as well as dinner on Saturday. There will definitely be a lot of time for informal discussion. For the Samba guys - I think there's a great opportunity to share some knowledge to prevent anyone from reinventing the wheel. If there's any topic you'd find interesting, let me know. If you'd just like to hear a specific topic from the Wine folks, we can arrange that. For travel arrangements, please join wineconf(a)winehq.org ( http://www.winehq.org/mailman/listinfo/wineconf ) For instance, I'm actually flying into Frankfurt on April 23rd and it'd be cool to hang out with anyone arriving early. If you haven't made reservations at a hotel, don't worry too much. There's still rooms available as Mr. Schmid described here: http://www.winehq.com/hypermail/wine-devel/2005/03/1119.html If you haven't signed up on the RSVP list, please do so. It can be found on the WineConf page: http://www.winehq.com/site/wineconf Lastly, if you have any questions / comments / criticisms let me know. -Brian PS. Dimi owes me a beer from last year, so we're all obligated to go out Friday night. I'm looking forward to seeing everyone in Stuttgart!

March 30, 2005

Re: KERNEL: Implement undocumented SetCPGlobal API call

by Dmitry Timoshkov

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > > What app does depend on it? > > I can't name a specific app that depends on it already (other than Windows > login management processes), I wonder then how did you discover its existence and syntax and how did you test its real behaviour? > but: > > - the call has some fairly obvious uses such that it is not out of the > question for an app to use it; I'd say that an obvious one is SetThreadLocale. > - similar API calls to change the OEM code page are documented; What are they? Could you list that API calls? > - documented facilities in the API necessarily imply the existence of this API > call; and this API has enough power to break an app without a notice. > and > - I am considering using it myself. > > While the MultiByteToWideChar API can have its behaviour varied by changing > the first parameter from CP_ACP to some global, the *A calls cannot. Thus > this API call may be important for a server app not compiled for Unicode (or > which uses C libraries without a Unicode interface) which receives, for > example, file names from a client application. Do you have an evidence that Windows does it in the same way? > In fact I had an enquiry a week or so ago from our London office which > involved a problem for which the use of this API call is the only reasonable > solution. > > Ideally the altered code page setting would be inherited by any child process > created by the parent. No. It's better to change the locale of your system to an appropriate one. -- Dmitry.

March 30, 2005

Re: Autopackage 1.0

by Mike Hearn

On Tue, 29 Mar 2005 11:06:57 +0200, Boaz Harrosh wrote: > now that Autopackage 1.0 is out does any one plan on a Wine Autopackage > installer. In case anybody is waiting, I'm not planning on this anytime soon. I have enough to do just supporting other projects that need it much more (because they don't have [m]any distro specific packages etc). If somebody wants to do it though, go for it. I'm happy to answer questions.

March 29, 2005

Re: Regression in winealsa (message only?)

by Jeremy White

Hey James, > > I am an alsa developer, what exactly is the problem? > For normal stereo playback use: "plug:front" > For 5.1 playback use: "plug:surround51" > For stereo capture (record) use: "plug:front" > For mixer control interface use: "hw" Robert has tweaked the code so that the user can specify what device name to use for Playback or for Capture; the default value is "plug:hw" (and he then iterates over multiple cards, adding a :n where n is the device number). He does a snd_pcm_open with STREAM_PLAYBACK on the playback device, and a STREAM_CAPTURE on the capture device. To manage volume, I've got it using an snd_hctl_open, using the same device name as that used by either Playback or Capture (the old behavior was to always use a device of "hw"). It sounds like the volume control should just always use hw:n, where n is the device number. Does that sound right? Cheers, Jeremy

March 29, 2005

Progress of work on MSHTML

by Jacek Caban

Hi. I decided that it's time to write here about my work. I'm working on an implementation of MSHTML using Gecko (Mozilla's engine) API. Results of this work you can see here: http://members.lycos.co.uk/merplayers/wine/ Yes, it is Internet Explorer on Mozilla's engine under Wine! At last... it doesn't work as nice as one can think looking at the picture... but it starts to work. I'd like to do it using Linux Mozilla, but to do it I'd need to pass GtkWidget to Gecko. So AFAIK there is no way to do it in an acceptable way for Wine. If there is, please let me know. Gecko API is based on XPCOM that is quite similar to MSCOM. We cannot use Gecko's headers as they are designed for C++, but I wrote idl files that can be used by widl to generate binary-compatibile headers. Fortunetly, excluding interfaces, we can do everything using only C functions. Currently Wine's implementayion uses Mozilla ActiveX Comtrol. It's enough for some applications using it as replacement of WebBrowser Control, yet I don't know anyone using it as replacement of HTMLDocument (and it won't work as this is control, not document). This code needs a lot of cleanup and I need to remove temporary hacks, but I think it's time to start sending patches. Unfortunetly I'll be out next week and this week I won't have much time. This week I'll send only some simple code, and later will come more. Just wanted let you know:) Jacek

March 29, 2005

Re: KERNEL: Implement undocumented SetCPGlobal API call

by Troy Rollo

On Tue, 29 Mar 2005 15:03, Dmitry Timoshkov wrote: > What app does depend on it? I can't name a specific app that depends on it already (other than Windows login management processes), but: - the call has some fairly obvious uses such that it is not out of the question for an app to use it; - similar API calls to change the OEM code page are documented; - documented facilities in the API necessarily imply the existence of this API call; and - I am considering using it myself. While the MultiByteToWideChar API can have its behaviour varied by changing the first parameter from CP_ACP to some global, the *A calls cannot. Thus this API call may be important for a server app not compiled for Unicode (or which uses C libraries without a Unicode interface) which receives, for example, file names from a client application. In fact I had an enquiry a week or so ago from our London office which involved a problem for which the use of this API call is the only reasonable solution. Ideally the altered code page setting would be inherited by any child process created by the parent.

March 29, 2005

Re: Regression in winealsa (message only?)

by James Courtier-Dutton

Jeremy White wrote: > Hi Paul, > > I see the same behavior after Robert's change to use plug:hw:0 > (and removing my settings in ~/.wine/config). > > The attached patch 'fixes' the problem for me; can you try it? > > However, to be honest, the real issue is that I don't really > understand what's going on. It appears as though the > plug: devices are legitimate PCM device names, but that you > can't use them for the control interface. If that's true, > then this patch is correct. I just can't find any sensible > Alsa document to give me comfort that this is right. > > I'd appreciate affirmation of this or a pointer to better > Alsa doco <grin>. > > Cheers, > > Jeremy > I am an alsa developer, what exactly is the problem? For normal stereo playback use: "plug:front" For 5.1 playback use: "plug:surround51" For stereo capture (record) use: "plug:front" For mixer control interface use: "hw" The alsa api is an abstraction layer. One defines in an alsa config file what "plug:front" actually talks to. Then any alsa applications can then talk to same device name, even though the underlying hardware might have different features. As a generaly rule, don't use "hw" anywhere in the sound channel's device name. If you have more than one sound card, things are a bit different: First card: Stereo playback: "plug:front:0" surround51 playback: "plug:surround51:0" Stereo capture: "plug:front:0" Mixer: "hw:0" For second card: Stereo playback: "plug:front:1" surround51 playback: "plug:surround51:1" Stereo capture: "plug:front:1" Mixer: "hw:1" For third card: Stereo playback: "plug:front:2" surround51 playback: "plug:surround51:2" Stereo capture: "plug:front:2" Mixer: "hw:2" etc. Now the user might want to edit their alsa config files, so ideally wine should allow for multiple device names to be entered for each card.

March 29, 2005