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

Re: wine's setupapi.dll / newdev.dll ?

by Damjan Jovanovic

--- Robert Shearman <rob(a)codeweavers.com> wrote: > Damjan Jovanovic wrote: > > >I've been working on a still image implementation > for > >wine / ReactOS for a while now, and I've only > recently > >realised how impossible it is in wine at the > moment... > > > >wine's SETUPAPI.DLL is not even in its infancy, it > >doesn't even let you enumerate non-serial-port > >devices, and doesn't load class-installers, so you > >can't even install a scanner's INF file. I see that > >ReactOS's implementation is better and it is under > the > >right (LGPL) licence; are we planning on including > it > >into wine, and if so, when? > > > > > > I don't think it is planned. It is a question of > showing a demand for > the code and then someone taking the effort to merge > the necessary parts. > > >wine's NEWDEV.DLL is pure stubs - so you can't even > >start installing the device INF file. ReactOS's > latest > >SVN version of it is a little closer to what I > need, > >but can we include GPL code in wine? (I've asked > the > >developers to relicense it under the LGPL for us, > but > >they haven't gotten back to me yet). > > > > > > What does NEWDEV do? Called through rundll32.exe from umpnpmgr, it does all the user-interface aspects of device installation. All those screens you see in Windows, where you select a device category (eg. Mouse), then click "Next", then you see a list of manufacturers and their devices and that "Have disk" button, and then you select one and click "Next" and it carries on - all that is done by NEWDEV.DLL. > >So what should I do - submit my STI.DLL and > STI_CI.DLL > >into wine now, even though they won't be usable for > a > >good while - or wait for wine to mature? > > > > > > Will STI and STI_CI work with the GPL NEWDEV code? > If so, I would submit > them and then hope someone will come along and > implement the necessary > parts of NEWDEV or convince the ReactOS developers > to re-license it. > > >And does anyone know any good documentation for > >writing COM out-of-process servers (that use > ncalrpc > >transport and have some [local] methods)? > > > > > > What documentation do you need? ncalrpc is just like > any other transport > - you just need to specify the right format for the > endpoint and the RPC > runtime does the work of opening it for you. Local > methods are also > straightforward. It just means that no remoting > information is generated > for it. This is typically used when the convenient > form of the function > has types incompatible with the RPC runtime. You can > use a remote form > with the call_as attribute to allow you to write a > translating > proxy/stub function to call the remote function. See > > dlls/oleaut32/usrmarshal.c. It seems you can't do the following - Microsoft's MIDL specifically forbids specifying binding handles for COM interfaces (so wine's widl must be broken, because it does allow it): [ object, implicit_handle(handle_t bindingHandle) ] interface IStillImage { .... } So how else do you control which RPC binding handle is used in marshalling a particular COM interface? > -- > Rob Shearman > > __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

Dec. 29, 2005

Re: wine's setupapi.dll / newdev.dll ?

by Thomas Weidenmueller

Robert Shearman wrote: > What does NEWDEV do? It's the driver installation wizard that pops up when the system detects a new device. > Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit > them and then hope someone will come along and implement the necessary > parts of NEWDEV or convince the ReactOS developers to re-license it. Both, newdev and setupapi are LGPL in ReactOS. - Thomas

Dec. 29, 2005

Re: wine's setupapi.dll / newdev.dll ?

by Robert Shearman

Damjan Jovanovic wrote: >I've been working on a still image implementation for >wine / ReactOS for a while now, and I've only recently >realised how impossible it is in wine at the moment... > >wine's SETUPAPI.DLL is not even in its infancy, it >doesn't even let you enumerate non-serial-port >devices, and doesn't load class-installers, so you >can't even install a scanner's INF file. I see that >ReactOS's implementation is better and it is under the >right (LGPL) licence; are we planning on including it >into wine, and if so, when? > > I don't think it is planned. It is a question of showing a demand for the code and then someone taking the effort to merge the necessary parts. >wine's NEWDEV.DLL is pure stubs - so you can't even >start installing the device INF file. ReactOS's latest >SVN version of it is a little closer to what I need, >but can we include GPL code in wine? (I've asked the >developers to relicense it under the LGPL for us, but >they haven't gotten back to me yet). > > What does NEWDEV do? >So what should I do - submit my STI.DLL and STI_CI.DLL >into wine now, even though they won't be usable for a >good while - or wait for wine to mature? > > Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit them and then hope someone will come along and implement the necessary parts of NEWDEV or convince the ReactOS developers to re-license it. >And does anyone know any good documentation for >writing COM out-of-process servers (that use ncalrpc >transport and have some [local] methods)? > > What documentation do you need? ncalrpc is just like any other transport - you just need to specify the right format for the endpoint and the RPC runtime does the work of opening it for you. Local methods are also straightforward. It just means that no remoting information is generated for it. This is typically used when the convenient form of the function has types incompatible with the RPC runtime. You can use a remote form with the call_as attribute to allow you to write a translating proxy/stub function to call the remote function. See dlls/oleaut32/usrmarshal.c. -- Rob Shearman

Dec. 29, 2005

Re: [Bug 3095] ID Collisions in menus

by Dmitry Timoshkov

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> wrote: > Currently my added tests are: > 1. Menu with menuitem id A, get info via id A obviously gives the menuitem > 2. Menu containing empty submenu with hmenu (and hence id) of B, getinfo via > id B gives the menuitem (ie popups can be returned) > 3. Menu containing submenu with hmenu (and hence id) of B which in turn > contains 2 menu items, both with id of B. Getinfo on id B gives the first of > the two items. Again, the very first thing I'd suggest to do is to write a comprehensive test case and send it to wine-patches with appropriate todo_wine statements to make it pass. Then we could see exact steps which lead to a failure and could start thinking of a possible fix. -- Dmitry.

Dec. 29, 2005

Re: MSACM: initialize some ACMSTREAMHEADER fields for the sake of native codecs

by Eric Pouech

Alex Villacís Lasso wrote: > The ACMAPP sample application from MSDN reveals this annoying bug in > playback: with a native ACM codec (such as the Ogg Vorbis one bundled > with some Japanese RPGs), builtin msacm will successfully tell the codec > to decode the first two frames of compressed audio, and then the sound > will loop on these two frames. What is really happening is that winmm is > using double-buffering, and reusing the ACMSTREAMHEADER structures for > playback, and acmStreamConvert simply passes the structures into the > codec, without clearing cb[Src|Dst]LengthUsed (here is the bug) which > was set in the previous call to acmStreamConvert on that > ACMSTREAMHEADER. The native codec *expects* these fields to be set to 0, > and refuses to decode otherwise. well, you should check who is supposed to clear those flags between msacm or winmm (I suppose wavemap). A+ -- Eric Pouech

Dec. 29, 2005

Re: wine's setupapi.dll / newdev.dll ?

by Marcus Meissner

On Thu, Dec 29, 2005 at 12:46:48AM -0800, Damjan Jovanovic wrote: > I've been working on a still image implementation for > wine / ReactOS for a while now, and I've only recently > realised how impossible it is in wine at the moment... > > wine's SETUPAPI.DLL is not even in its infancy, it > doesn't even let you enumerate non-serial-port > devices, and doesn't load class-installers, so you > can't even install a scanner's INF file. I see that > ReactOS's implementation is better and it is under the > right (LGPL) licence; are we planning on including it > into wine, and if so, when? If it can be ported to the WINE framework ... Feel free to submit patches ... > wine's NEWDEV.DLL is pure stubs - so you can't even > start installing the device INF file. ReactOS's latest > SVN version of it is a little closer to what I need, > but can we include GPL code in wine? (I've asked the > developers to relicense it under the LGPL for us, but > they haven't gotten back to me yet). > > So what should I do - submit my STI.DLL and STI_CI.DLL > into wine now, even though they won't be usable for a > good while - or wait for wine to mature? I would say only if we can make sure it works continously. What does STI provide? Access to digital cameras and scanners? Ciao, Marcus

Dec. 29, 2005

wine's setupapi.dll / newdev.dll ?

by Damjan Jovanovic

I've been working on a still image implementation for wine / ReactOS for a while now, and I've only recently realised how impossible it is in wine at the moment... wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into wine, and if so, when? wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet). So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature? And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)? Thank you Damjan __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

Dec. 29, 2005

Re: potential bug in winecfg

by Jesse Allen

On 12/28/05, Segin <segin2005(a)gmail.com> wrote: > I was attempting to add another override for a program > (C:\StarCraft\starcraft.exe), however, when I selected the "Emulate > Virtual Desktop" checkbox, winecfg freezes. There is no CPU usage, and > there is nothing trown to the console. I am using Linux > 2.6.14-gentoo-r3, and the slackware 10.2 binary build of wine 0.9.4 > without debug symbols. The latest version of wine available for my > distribution is the very last alpha release (20050925, IIRC). > > > I have also seen a problem with winecfg freezing the whole box the last two days, 20051226 snapshot. Outsite ping won't even work. My distro is slackware-current here. I think it may be related to audio because I removed my user from the audio group and I have not since been able to recreate the lockup. The reason I guessed audio is because 9 times out of 10 it locks up when clicking the audio tab. But it also locks up in or clicking the graphics tab.

Dec. 29, 2005

potential bug in winecfg

by Segin

I was attempting to add another override for a program (C:\StarCraft\starcraft.exe), however, when I selected the "Emulate Virtual Desktop" checkbox, winecfg freezes. There is no CPU usage, and there is nothing trown to the console. I am using Linux 2.6.14-gentoo-r3, and the slackware 10.2 binary build of wine 0.9.4 without debug symbols. The latest version of wine available for my distribution is the very last alpha release (20050925, IIRC).

Dec. 29, 2005

re: a more native host environment

by Dan Kegel

Justin wrote: > I'd like to see wine produce real PE dll files that > use unix system calls as a back end. For example, a > real kernel32.dll in PE format that maps at the same > addresses as the windows XP version, and so on. I think that would make it hard to link in Linux shared libraries. > PE executables could be seamlessly loaded with an ibcs > extension Er, you may be speaking nonsense here. ibcs has to do with loading system V binaries. > and properly linked against wine's real PE system dlls. They're already properly linked. Are you running into some problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 29, 2005