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

AW: tools/wineprefixcreate.in: create default w32x86 path underspool/drivers

by Markus Gömmel

Hi Detlef, ah, I understand... I'm a Windows software developer trying to make our products running as smooth as possible under Wine. One of our products includes a fax printer driver and port monitor for faxing over ISDN boards. The setup routine of our product will not use an .inf file to install the printer driver, but will use a ::GetPrinterDriverDirectory() call to get the printer driver dir, is then copying all the necessary files into this directory, fills a DRIVER_INFO_3 structure and then calls ::AddPrinterDriver() This is probably a bit unusual, but not uncommon. I know some more professional products using this way to install printer drivers. So to support this way of installing, the path returned by ::GetPrinterDriverDirectory() should definitely exist, which is also does under real Windows. Am I wrong here? Markus > -----Ursprüngliche Nachricht----- > Von: wine.dev(a)web.de [mailto:wine.dev(a)web.de] > Gesendet: Freitag, 12. Oktober 2007 14:14 > An: wine-devel(a)winehq.org > Cc: m.goemmel(a)compulab.de > Betreff: Re: tools/wineprefixcreate.in: create default w32x86 > path underspool/drivers > > On Mi, 2007-10-10 at 13:10 +0200, Markus Gömmel wrote: > > + "$CROOT/windows/system32/spool/drivers/w32x86" \ > > The above Path is created, when we add a Printer Driver in wine. > Please update your wine. > > When you do not start with a clean ~/wine, you need to remove > the wine printers below > "HKLM\System\CurrentControlSet\Control\Print\Printers" > and the wine drivers below > "HKLM\System\CurrentControlSet\Control\Print\Environments\*". > > A "wine notepad" does the rest. > > > When an application try to access this path, I expect, that > they fail later, because we have no fake files for > "w32x86/3/wineps.drv" and "win40/0/wineps16.drv" yet. > > > -- > > By by ... Detlef > > >

Oct. 12, 2007

Re: tools/wineprefixcreate.in: create default w32x86 path under spool/drivers

by Detlef Riekenberg

On Mi, 2007-10-10 at 13:10 +0200, Markus Gömmel wrote: > + "$CROOT/windows/system32/spool/drivers/w32x86" \ The above Path is created, when we add a Printer Driver in wine. Please update your wine. When you do not start with a clean ~/wine, you need to remove the wine printers below "HKLM\System\CurrentControlSet\Control\Print\Printers" and the wine drivers below "HKLM\System\CurrentControlSet\Control\Print\Environments\*". A "wine notepad" does the rest. When an application try to access this path, I expect, that they fail later, because we have no fake files for "w32x86/3/wineps.drv" and "win40/0/wineps16.drv" yet. -- By by ... Detlef

Oct. 12, 2007

Re: Translations

by Marcus Meissner

On Fri, Oct 12, 2007 at 01:44:45PM +0200, Daniel Nylander wrote: > > I would like to contribute to the Wine project by submitting Swedish > translations. > > I would really like to translate the graphical tools (such as winecfg) > but as I can see it, it's not possible at the moment. > > Have you thought about implementing some sort of i18n/l10n framework? This is done via the Windows method of using the resource files. Check programs/winecfg/*.rc Ciao, Marcus

Oct. 12, 2007

Translations

by Daniel Nylander

I would like to contribute to the Wine project by submitting Swedish translations. I would really like to translate the graphical tools (such as winecfg) but as I can see it, it's not possible at the moment. Have you thought about implementing some sort of i18n/l10n framework? Regards, Daniel Nylander Stockholm, Sweden

Oct. 12, 2007

Re: make test drill

by Marcus Meissner

On Fri, Oct 12, 2007 at 12:22:43PM +0200, Francois Gouget wrote: > On Tue, 9 Oct 2007, Jeremy White wrote: > [...] > > I think a test that fails, or crashes a system because of a driver bug is a broken test. > > It's admittedly hard to write a test that will detect a vmware situation or driver > > bug and work around it, but I think that is what we should do. > > > > It's just like compiling without warnings. Once there are no warnings, it's > > easy to make sure none creep in. But once just a few are excused as being > > 'understandable', then a lot more quickly creep in, and no one pays attention > > to warnings. > > I would add that if 'make test' crashes a user's X server or the whole > system, then that user will just stop running 'make test' at all (or > will run it in VNC if he is very very persistent), and will certainly > not set them up to run automatically and report the results to > tests.winehq.org. With people running 'make test' and reporting their > results being already so few and far between this is pretty bad. > > So it's important that these issues be investigated and either worked > around in Wine, or a clear way of fixing them by upgrading the drivers > found and documented. Or do a bugreport for X / your distro! :) But I just tried bothering our X developers, but mentioning the Xorg "ati" driver (for my Radeon Mobility) just causes laughs. :/ Ciao, Marcus

Oct. 12, 2007

Re: WineD3D: p8 improvements 2/2

by H. Verbeet

On 11/10/2007, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > + "MUL index.x, index.x, constants.x;\n" /* Scale the index by 255/256 */ > + "ADD index.x, index.x, constants.y;\n" /* Add a bias of '0.5' in order to sample in the middle */ Why not use a MAD there?

Oct. 12, 2007

Re: defining and revamping our bugzilla categories

by Detlef Riekenberg

On Do, 2007-10-11 at 16:32 -0600, Jesse Allen wrote: > How about "gdi-printing" and "gdi-video"? No. GDI is more than printing and for printing, you need GDI, but also much more out of GDI Whe the bug-creator set the component to "printing", we can change it later to the more specific component, when needed (gdi, wineps, spooler, comdlg32 as examples) -- By by ... Detlef

Oct. 12, 2007

Re: defining and revamping our bugzilla categories

by Detlef Riekenberg

On Do, 2007-10-11 at 14:24 -0500, James Hawkins wrote: > > > wine-gdi-(printing) -> gdi > > > > > > I vote for "printing" next to "gdi" > > > > What's wrong with having a new printing component? That was my vote above. I asked for a "printing" component over 1 year ago, but only "wine-gdi" was changes to "wine-gdi-(printing)" > Lumping *all* > gdi/printing bugs into gdi-(printing) is a bad idea. Yes. -- By by ... Detlef

Oct. 12, 2007

Re: make test drill

by Francois Gouget

On Wed, 10 Oct 2007, Steven Edwards wrote: [...] > Just to be clear, what I mean is a whitelist rather than a blacklist. The problem with whitelists is that they will stop us from finding where there are issues. They may be ok when running the tests on Windows as we don't really care if our tests cannot run on a Windows system due to a Windows driver bug. However we want to know about the Linux systems (Mac OS X, FreeBSD, etc) where Wine runs into driver bugs because we want to workaround these bugs where possible. So on Linux we should use blacklists. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Oct. 12, 2007

Re: make test drill

by Francois Gouget

On Tue, 9 Oct 2007, Jeremy White wrote: [...] > I think a test that fails, or crashes a system because of a driver bug is a broken test. > It's admittedly hard to write a test that will detect a vmware situation or driver > bug and work around it, but I think that is what we should do. > > It's just like compiling without warnings. Once there are no warnings, it's > easy to make sure none creep in. But once just a few are excused as being > 'understandable', then a lot more quickly creep in, and no one pays attention > to warnings. I would add that if 'make test' crashes a user's X server or the whole system, then that user will just stop running 'make test' at all (or will run it in VNC if he is very very persistent), and will certainly not set them up to run automatically and report the results to tests.winehq.org. With people running 'make test' and reporting their results being already so few and far between this is pretty bad. So it's important that these issues be investigated and either worked around in Wine, or a clear way of fixing them by upgrading the drivers found and documented. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

Oct. 12, 2007