Re: Wine menu creation questions

[Reece Dunn]

Frank Richter wrote:
> Also, Windows and Linux desktops have a bit of different "views" on what
> the "desktop menu" should contain: most of the time, the Windows start
> menu contains one folder per application, with that folder containing
> not only the application but also a link to the README or web page,
> uninstaller etc. In contrast, Linux desktop first sort the items per
> category (eg Education, Development) and there is one icon per
> application (no READMEs etc).

Sure.

At the moment these are located in the "Applications > Wine > Programs
> My Game > Game" which is too long. I was just suggesting cutting out
the "Programs" level, so the link would be "Applications > Wine > My
Game > Game", reducing the menu by one level. While this still means
that Windows applications will put their shortcuts in a sub-folder, it
reduces the amount of nested menus involved (especially if there is
just going to be a single menu option from Applications > Wine).

- Reece

Re: Wine menu creation questions

[Frank Richter]

On 25.01.2009 22:58, Owen Rudge wrote:
> "Windows software" may be a better term than "Wine". "Program Files" 
> wouldn't really make sense, since all the items in the Applications menu 
> are meant to be program files. On the issue of whether we should keep 
> the "Programs" subfolder, I guess you could transparently redirect 
> things that try to create items there, and it would probably not cause 
> too many problems. The current system though doesn't seem too bad.

Also, Windows and Linux desktops have a bit of different "views" on what
the "desktop menu" should contain: most of the time, the Windows start
menu contains one folder per application, with that folder containing
not only the application but also a link to the README or web page,
uninstaller etc. In contrast, Linux desktop first sort the items per
category (eg Education, Development) and there is one icon per
application (no READMEs etc).
Now, if the Windows start menu would simply be merged with the desktop
menu at the top level, you'd suddenly throw (potentially a lot)
application/vendor "categories" into it - arguably with a messy result.
Ideally, Windows applications would just show up in the according
desktop menu categories - but of course, since this information isn't
provided by Windows in any way* you would have to have a database of
application-to-category mappings**.
So realistically, while not the nicest solution, there probably has to
be some "Wine applications" or "Windows applications" (or, if you want
to do without Win* entirely, "Other applications" or so).

* - Vista added the Game Explorer, so games could be identified and
added to the Games category.
** - This actually sounds like something the "3rd party Wine users" (eg
Crossover, Bordeaux, Wine Doors) could implement.

-f.r.

Re: re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode

[Uwe Bonnes]

> "Dan" == Dan Kegel  writes:

Dan> That's how we used to do it, but tests showed that _filbuf really
Dan> has to do the cr removal.

Dan> On Jan 25, 2009 10:57 AM, "Uwe Bonnes" <
Dan> b...@elektron.ikp.physik.tu-darmstadt.de> wrote:

> "Dan" == Dan Kegel  writes:

Dan> I'll have a look...

Dan> For me it looks like our whole black magic handling for the CR
Dan> removal in read_i() is wrong. Probably _filbuf() should fill the
Dan> buffer as is, only fget(w)c() should skip CR in text mode and
Dan> fread() in binary mode should use unaltered chunks of _filbuf() in
Dan> binary mode and iterate through _filbuf() in text mode, skipping
Dan> CR.

Could it be that _filbuf also skips CR as return value in text mode?

B.t.w., for a file like "\\r\\r\\r\\nEOF", native _filbuf returns 0x0d...

-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Re: Wine runs IE7!

[Reece Dunn]

Hans Leidekker wrote:
>
> Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet
> that I had to implement, stub and override my way past before it would
> render a page, but finally, here's the obligatory screenshot.

Hi Hans,

Nice work! However, it does not work properly on my setup (Ubuntu
Intrepid). Running:

$ ./wine ~/Desktop/IE7-WindowsXP-x86-enu.exe
$ ./wine "c:\\program files\\internet explorer\\iexplore.exe"

on a clean wineprefix with today's git, it installs (but seems to be
too quick!) and runs, but it complains about "Cannot find '%ws'."
(http://bugs.winehq.org/show_bug.cgi?id=17136) and doesn't show
anything in the browser window.

I also get the same issue as
http://bugs.winehq.org/show_bug.cgi?id=12433. Note that this is with
no overrides, winetricks or anything else.

Did you do anything special to get IE7 working (apart from wading
through the bugs you found)?

Thanks,
- Reece

Re: Wine menu creation questions

[Owen Rudge]

> I have noticed that when wine creates a menu item (that for example,
> on Ubuntu gets put in the Applications > Wine > Programs menu), the
> command that gets written uses 'wine' as the program to run. This
> means that you need to have Wine in your PATH and cannot use more than
> one version of Wine. For example, if I wanted to use /opt/wine-1.0,
> /opt/crossover and /opt/wine for different applications I cannot
> access these correctly from the menu items created. Additionally, the
> user experience (yes, I have been watching Owen's Google talk :)) is
> that the application does not start (especially if the only version of
> Wine is not on the PATH).

> The solution to this is to add the full path to wine, e.g.
> '/opt/wine-1.0/bin/wine' when generating the menus. Are there any
> objections to this?

This would probably seem sensible. It may cause some confusion for users 
if they do intentionally have multiple versions installed (knowing which 
items point to which version, etc), but unless one were to come up with 
some kind of "version switching" app that lets the user choose which 
version to run with, it would seem like it's the kind of thing we 
shouldn't be too bothered with.

> Along similar lines, building on what Owen said in the talk that if
> all goes well Jane user will not notice that she is using Wine to run
> her Windows software: why is there an entry in the Applications
> section that says 'Wine' (and why does it have the folder icon and not
> the Wine icon)! It would be better if this said something like
> "Program Files", replacing Wine > Programs -- this removes a level of
> indirection and gives the user something that they are familiar with
> and is more discoverable than 'Wine'.

"Windows software" may be a better term than "Wine". "Program Files" 
wouldn't really make sense, since all the items in the Applications menu 
are meant to be program files. On the issue of whether we should keep 
the "Programs" subfolder, I guess you could transparently redirect 
things that try to create items there, and it would probably not cause 
too many problems. The current system though doesn't seem too bad.

-- 
Owen Rudge
http://www.owenrudge.net/

Re: returned status 2

[Austin English]

On Sun, Jan 25, 2009 at 2:24 PM,   wrote:
> I was able to install some packages, but this and mdac27 can't find itself.  
> The file is there.???
> ubuntu 8.10   wine 1.1.13
> I was able to install all packages needed on ubuntu 6.06  wine 1.0.1; 
> different machine.
>
> thanks,
> Robert
>
> Location: 
> http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer.exe
>  [following]
> --2009-01-25 15:12:46--  
> http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer.exe
> Resolving ufpr.dl.sourceforge.net... 200.236.31.1, 200.17.202.1
> Connecting to ufpr.dl.sourceforge.net|200.236.31.1|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 882263 (862K) [application/x-msdos-program]
> Saving to: `BZEditW32_1.6.5_Installer.exe'
>
> 100%[==>]
>  882,263  110K/s   in 15s
>
> 2009-01-25 15:13:02 (57.7 KB/s) - `BZEditW32_1.6.5_Installer.exe' saved 
> [882263/882263]
>
> Executing wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe
> wine: cannot find '/home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe'
> Note: command 'wine 
> /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' returned status 
> 2.  Aborting.
>
>
>

wine-devel is not appropriate for winetricks problems. Report bugs at
http://code.google.com/p/winezeug/issues/list

-- 
-Austin

returned status 2

[gnuoytr]

I was able to install some packages, but this and mdac27 can't find itself.  
The file is there.???
ubuntu 8.10   wine 1.1.13
I was able to install all packages needed on ubuntu 6.06  wine 1.0.1; different 
machine.

thanks,
Robert

Location: 
http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer.exe 
[following]
--2009-01-25 15:12:46--  
http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer.exe
Resolving ufpr.dl.sourceforge.net... 200.236.31.1, 200.17.202.1
Connecting to ufpr.dl.sourceforge.net|200.236.31.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 882263 (862K) [application/x-msdos-program]
Saving to: `BZEditW32_1.6.5_Installer.exe'

100%[==>]
 882,263  110K/s   in 15s 

2009-01-25 15:13:02 (57.7 KB/s) - `BZEditW32_1.6.5_Installer.exe' saved 
[882263/882263]

Executing wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe
wine: cannot find '/home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe'
Note: command 'wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' 
returned status 2.  Aborting.

Re: Wine menu creation questions

[Austin English]

On Sun, Jan 25, 2009 at 3:32 PM, Reece Dunn  wrote:
> Hi,
>
> I have noticed that when wine creates a menu item (that for example,
> on Ubuntu gets put in the Applications > Wine > Programs menu), the
> command that gets written uses 'wine' as the program to run. This
> means that you need to have Wine in your PATH and cannot use more than
> one version of Wine. For example, if I wanted to use /opt/wine-1.0,
> /opt/crossover and /opt/wine for different applications I cannot
> access these correctly from the menu items created. Additionally, the
> user experience (yes, I have been watching Owen's Google talk :)) is
> that the application does not start (especially if the only version of
> Wine is not on the PATH).
>
> The solution to this is to add the full path to wine, e.g.
> '/opt/wine-1.0/bin/wine' when generating the menus. Are there any
> objections to this?
>
> Along similar lines, building on what Owen said in the talk that if
> all goes well Jane user will not notice that she is using Wine to run
> her Windows software: why is there an entry in the Applications
> section that says 'Wine' (and why does it have the folder icon and not
> the Wine icon)! It would be better if this said something like
> "Program Files", replacing Wine > Programs -- this removes a level of
> indirection and gives the user something that they are familiar with
> and is more discoverable than 'Wine'.
>
> Thoughts?
>
> - Reece
>
>
>

There's actually a bug on this:
http://bugs.winehq.org/show_bug.cgi?id=17055

but didn't generate much discussion.

Personally, I like it.
--
-Austin

Wine menu creation questions

[Reece Dunn]

Hi,

I have noticed that when wine creates a menu item (that for example,
on Ubuntu gets put in the Applications > Wine > Programs menu), the
command that gets written uses 'wine' as the program to run. This
means that you need to have Wine in your PATH and cannot use more than
one version of Wine. For example, if I wanted to use /opt/wine-1.0,
/opt/crossover and /opt/wine for different applications I cannot
access these correctly from the menu items created. Additionally, the
user experience (yes, I have been watching Owen's Google talk :)) is
that the application does not start (especially if the only version of
Wine is not on the PATH).

The solution to this is to add the full path to wine, e.g.
'/opt/wine-1.0/bin/wine' when generating the menus. Are there any
objections to this?

Along similar lines, building on what Owen said in the talk that if
all goes well Jane user will not notice that she is using Wine to run
her Windows software: why is there an entry in the Applications
section that says 'Wine' (and why does it have the folder icon and not
the Wine icon)! It would be better if this said something like
"Program Files", replacing Wine > Programs -- this removes a level of
indirection and gives the user something that they are familiar with
and is more discoverable than 'Wine'.

Thoughts?

- Reece

Talk at Google, "the Wine user experience"

[Owen Rudge]

Hey all,

I've been a bit quiet as of late with uni work and so on, but figured 
I'd let you guys know that I was visiting Google in Mountain View on 
Thursday, and while there gave a tech talk on "Windows Meets Linux: the 
Wine user experience" - basically going over some of the issues with 
getting Wine out to users, ensuring a smooth experience for these users, 
and the challenges involves in this. It seemed to be well-received, and 
the talk is now up on YouTube:

http://uk.youtube.com/watch?v=5E2HDQw4xmM

Cheers!

-- 
Owen Rudge
http://www.owenrudge.net/

Re: Updated DIB Engine

[Massimo Del Fedele]

Erich Hoover ha scritto:
> 
> What I was trying to say is if you could have something like this for 
> all the stubs:
> 
> BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT 
> widthDst, INT heightDst,
> DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT 
> widthSrc, INT heightSrc,
> BLENDFUNCTION blendfn)
> {
> FIXME("reverting to slow behavior!\n");
> return TheOldBehavior->AlphaBlend(...);
> }
> 
> 
> While I'm obviously not greatly familiar with this code, it seems like 
> the engine would have a better chance of being successful if 
> unimplemented features fell back to the old behavior.  It seems like 
> that would allow you to gradually transition over to the integrated DIB 
> engine a little bit at a time, rather than having a lot of unavailable 
> features that would all need to be implemented before the integrated DIB 
> engine could be turned on for everyone.  Even if you had to create a 
> special surface and copy the bitmap back and forth every time you had to 
> revert to the old behavior it seems like it would at least provide a 
> good testbed.
> 
> Erich Hoover
> ehoo...@mines.edu 
> 
> 
>

Well... almost impossible by keeping GDI and driver structure separated.
You call winex11 whith its physDev, and WineDib with it's own 
(different) physDev. Either don't have knowledge of other's structure 
(they're opaque pointers), nor they have e pointer of each other.
So, from Dib driver is impossible to call an x11 driver function.
That could be done directly from inside GDI32, but would require some 
deep changes on it, which I wanted to avoid.
BTW, I'm still thinking that the "better" way of adding the dib engine 
would be from inside gdi32, but whis would mean to change deeply a code 
that is working good.
Another possibility would be to add a pointer to x11 physDev inside the 
Dib physDev that one would be easier, but hacky.

Ciao

Max

Re: Updated DIB Engine

[Erich Hoover]

On Sun, Jan 25, 2009 at 11:25 AM, Massimo Del Fedele  wrote:

> Erich Hoover ha scritto:
> >
> > I haven't looked into your implementation in much detail (I need more
> > hours in a day, I swear), but would it be possible to pass all the stubs
> > on so that unimplemented functionality still works even if it's dog
> > slow?  It'd be nice if we could take advantage of the implemented
> > features, still be able to handle everything, and then spew a "FIXME:
> > Help Wine run faster by implementing this function in the DIB engine!"
> > for features that are not handled yet.  (yeah, yeah, I want my cake and
> > be able to eat it too)
> >
> > Erich Hoover
> > ehoo...@mines.edu 
> >
>
> Well, by now many functions are stubbed (with disabled FIXMEs for
> speed), and 3 apps I've tested on it works ok.
> Some bad graphics, but mostly usable.
> You can test it easily and, if you like, you can enable all the stubs
> FIXMEs uncommenting a #define on header file.
>
> Ciao
>
> Max
>
>
What I was trying to say is if you could have something like this for all
the stubs:

BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT
widthDst, INT heightDst,
DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT
widthSrc, INT heightSrc,
BLENDFUNCTION blendfn)
{
FIXME("reverting to slow behavior!\n");
return TheOldBehavior->AlphaBlend(...);
}


While I'm obviously not greatly familiar with this code, it seems like the
engine would have a better chance of being successful if unimplemented
features fell back to the old behavior.  It seems like that would allow you
to gradually transition over to the integrated DIB engine a little bit at a
time, rather than having a lot of unavailable features that would all need
to be implemented before the integrated DIB engine could be turned on for
everyone.  Even if you had to create a special surface and copy the bitmap
back and forth every time you had to revert to the old behavior it seems
like it would at least provide a good testbed.

Erich Hoover
ehoo...@mines.edu

Re: Updated DIB Engine

[Massimo Del Fedele]

Erich Hoover ha scritto:
> 
> I haven't looked into your implementation in much detail (I need more 
> hours in a day, I swear), but would it be possible to pass all the stubs 
> on so that unimplemented functionality still works even if it's dog 
> slow?  It'd be nice if we could take advantage of the implemented 
> features, still be able to handle everything, and then spew a "FIXME: 
> Help Wine run faster by implementing this function in the DIB engine!" 
> for features that are not handled yet.  (yeah, yeah, I want my cake and 
> be able to eat it too)
> 
> Erich Hoover
> ehoo...@mines.edu 
> 

Well, by now many functions are stubbed (with disabled FIXMEs for 
speed), and 3 apps I've tested on it works ok.
Some bad graphics, but mostly usable.
You can test it easily and, if you like, you can enable all the stubs 
FIXMEs uncommenting a #define on header file.

Ciao

Max

re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode

[Dan Kegel]

I'll have a look...

Re: Updated DIB Engine

[Erich Hoover]

On Sun, Jan 25, 2009 at 10:23 AM, Massimo Del Fedele  wrote:

> ...IMHO the engine will (if it ever enters on main trunk) stay
> disabled
> by default for long, long time. Having it to work ok to the same extent
> as is gdi32/winex11 now will take a lot of time and patches.
> ...
>

I haven't looked into your implementation in much detail (I need more hours
in a day, I swear), but would it be possible to pass all the stubs on so
that unimplemented functionality still works even if it's dog slow?  It'd be
nice if we could take advantage of the implemented features, still be able
to handle everything, and then spew a "FIXME: Help Wine run faster by
implementing this function in the DIB engine!" for features that are not
handled yet.  (yeah, yeah, I want my cake and be able to eat it too)

Erich Hoover
ehoo...@mines.edu

Re: Updated DIB Engine

[Massimo Del Fedele]

Roderick Colenbrander ha scritto:
>>
> 
> Having an environment variable is a minor detail. Sure it should 
be used transparently but it will take a lot of time (when the 
architecture is correct)
to enable it by default.

IMHO the engine will (if it ever enters on main trunk) stay disabled 
by default for long, long time. Having it to work ok to the same extent 
as is gdi32/winex11 now will take a lot of time and patches.

A lot of performance tuning would be needed as it could seriously
decrease performance in a lot of cases.

I agree completely on this

The gain / loss depends on what type of calls the program is making.
If it draws lets say on a line by line basis then software rendering 
could help.
But if it uses a smarter method a single X call might be more efficient.

More precisely, it will depend on the degree of optimization of dib 
engine code which, by now, is close to zero. When blitting will be 
optimized, for example, the performance increase will be huge.

Further there are also other tradeoffs e.g. when the latest version of 
the drawable is in X then
it might not be smart at all to copy it back to the DIB engine and let 
it do the rendering
just because we have a DIB engine.
The cost for the download and reupload to the videocard might be much 
higher.

The engine, as it is now, just renders on DIBs, when they're in memory, 
not on DDB. So it shouldn't penalize at all the rendering of drawables 
already owned by X. It'll just avoid the double copy between dib and x 
ant the way back just to, for example, render some text. That happens 
now in autocad, for example, which slows it down by a factor off 100.
The only "mixed" behaviour is when you're blitting a dib onto a ddb (or 
the way around), but even then the code converts the source bitmap to 
the destination format and then uses the best way to blit it.
It could even be optimized by blitting without converting before, but it 
would need some hard intervention on GDI code, which is what I wanted to 
avoid.

Ciao


Max

Re: Updated DIB Engine

[Massimo Del Fedele]

Ben Klein ha scritto:
> 
> I'm still opposed to adding an environment variable for something so
> simple (an enable/disable flag). It just seems like extra work for no
> benefit to me. I'm sure we can all agree that the registry is a
> suitable place for the setting.

The environment variable allows testing on the fly of enabled/disabled 
engine, AND allows to run some apps with engine enabled as others with 
engine disabled. Having to run regedit just to test an app run is 
overkilling, IMHO.
BTW, the environment variable is fully optional, you can but you haven't 
to use it, if you choose so. just set the registry variable and all is ok.

> 
> Isn't the idea that the DIB engine will only be used as needed, and
> will be good in all cases where it's used? If that's the case, it's
> not too important having on-the-fly per-application enabling/disabling
> (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
> 

The engine, as it is, is by far less than complete, so very few apps do 
benefit of it, one of them is autocad, at the moment. I guess most apps 
are penalized by the engine in present state.
So I really don't see the point of avoiding an environment var which, 
BTW, is checked just ONCE and on first loading of the DIB driver, and 
costs just about 5 lines of code.

Max

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64

[Mikołaj Zalewski]

Alexandre Julliard wrote:

>If there is evidence that Windows really uses the reserved fields to
>store bHot and bDropDownPressed then the code should be using
>bReserved[0] and bReserved[1], wrapped with appropriate accessor
>functions if necessary. Otherwise they should be moved somewhere else
>and the bReserved fields left alone. Either way, if we need the correct
>TBBUTTON layout we should be using a TBBUTTON structure.
>  
>
  The bHot and bDropDownPressed fields are in the TBUTTON_INFO structure 
that is internal to our implementation. It is not visible to the outside 
world. Probably for convinience, one debug function (TOOLBAR_DumpButton) 
assumes that the first fields of it are the same as of TBBUTTON and the 
same function is used dump  TBBUTTON and TBUTTON_INFO (with a flag to 
dump the additional fields). When I noticed this won't work on Win64, I 
thought adding the padding is the easiest solution. Another solution 
would be to split the dump function into one for TBUTTON_INFO and one 
TBBUTTON.

Mikołaj

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64

[Alexandre Julliard]

Mikołaj Zalewski  writes:

> Dmitry Timoshkov wrote:
>
>> "Mikołaj Zalewski"  wrote:
>>>  The bHot and bDropDownPressed would then be called bReserved[0] and 
>>> bReserved[1] so this could make more harm than good.
>>
>> You can make a union for that case, with an appropriate comment.
>>
>  TBBUTTON is an official Windows API structure. Adding a union inside 
> and doing it just because of some internals of our toolbar 
> implementation is IMHO not the best idea.

If there is evidence that Windows really uses the reserved fields to
store bHot and bDropDownPressed then the code should be using
bReserved[0] and bReserved[1], wrapped with appropriate accessor
functions if necessary. Otherwise they should be moved somewhere else
and the bReserved fields left alone. Either way, if we need the correct
TBBUTTON layout we should be using a TBBUTTON structure.

-- 
Alexandre Julliard
julli...@winehq.org

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Dmitry Timoshkov]

"Ambroz Bizjak"  wrote:

> What about an assertion right before the following line:
> *lpTransferred = lpOverlapped->InternalHigh;

That will make the behaviour incompatible with Windows by generating
wrong exception code.

> This way it will still "crash" in the same circumstances, but will make it 
> easier to debug programs.

In which way will it make easier in debugging?

-- 
Dmitry.

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64

[Mikołaj Zalewski]

Dmitry Timoshkov wrote:

> "Mikołaj Zalewski"  wrote:
>
 +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of 
 the structure
 + * is the same as of TBBUTTON */
 typedef struct
 {
 INT iBitmap;
 @@ -96,6 +98,9 @@ typedef struct
 BYTE  fsStyle;
 BYTE  bHot;
 BYTE  bDropDownPressed;
 +#ifdef _WIN64
 +BYTE bReserved64[4];
 +#endif
 DWORD_PTR dwData;
 INT_PTR iString;
 INT nRow;
>>>
>>>
>>>
>>> Then probably it would make sense to make TBBUTTON the first member 
>>> of the above
>>> structure. That would help in avoiding possible layout problems in 
>>> future.
>>>
>>  The bHot and bDropDownPressed would then be called bReserved[0] and 
>> bReserved[1] so this could make more harm than good.
>
>
> You can make a union for that case, with an appropriate comment.
>
 TBBUTTON is an official Windows API structure. Adding a union inside 
and doing it just because of some internals of our toolbar 
implementation is IMHO not the best idea.

Mikolaj

Re: Updated DIB Engine

[Roderick Colenbrander]

> 2009/1/25 Massimo Del Fedele :
> > The engine is disabled by default; can be changed by environment
> variable :
> >
> > export WINEDIB=ON (or ENABLE or ENABLED or TRUE)  enables it
> > export WINEDIB=OFF (or DISABLE or DISABLED or FALSE)  disables it
> >
> > or by registry key :
> >
> > HKCU/Software/Wine/DIB Engine/Enable='Y'  enables it
> > HKCU/Software/Wine/DIB Engine/Enable='N'  disables it
> >
> > the environment variable has precedence on registry, so for example if
> > WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is
> > enabled.
> >
> > I suggest to use the environment for the moment, at less you have an app
> > that runs much better with the engine (autocad, for example...) which
> > benefits from a default enabled engine in registry.
> 
> I'm still opposed to adding an environment variable for something so
> simple (an enable/disable flag). It just seems like extra work for no
> benefit to me. I'm sure we can all agree that the registry is a
> suitable place for the setting.
> 
> Isn't the idea that the DIB engine will only be used as needed, and
> will be good in all cases where it's used? If that's the case, it's
> not too important having on-the-fly per-application enabling/disabling
> (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).
> 

Having an environment variable is a minor detail. Sure it should be used 
transparently but it will take a lot of time (when the architecture is correct) 
to enable it by default. A lot of performance tuning would be needed as it 
could seriously decrease performance in a lot of cases. The gain / loss depends 
on what type of calls the program is making. If it draws lets say on a line by 
line basis then software rendering could help. But if it uses a smarter method 
a single X call might be more efficient. Further there are also other tradeoffs 
e.g. when the latest version of the drawable is in X then it might not be smart 
at all to copy it back to the DIB engine and let it do the rendering just 
because we have a DIB engine. The cost for the download and reupload to the 
videocard might be much higher.

Roderick
-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

2009/1/26 David Gerard :
> Is it possible to meaningfully enhance Wine by crashing the app, but
> in such a way as to note on the terminal that the crash is for
> compatibility with Win32, what crashed where, etc?

That might set an unwelcome precedence. Realistically, anyone
investigating such crashes could be pointed to (or find on their own)
the git commit that describes the reason.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[David Gerard]

2009/1/25 Remco :

> Well, the implementation can differ from Windows, as long as it has
> the same effect on the API/ABI level. Some applications actually do
> run faster because of this. And some run much slower because of this.


What apps run faster in Wine than in Windows? (What Win32 functions
run faster and better in Wine than in Windows?) Is this documented
e.g. on the wiki?


- d.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[David Gerard]

2009/1/25 Ben Klein :

> Wine's goal is perfectly clear: to provide, as best as possible, a
> complete and accurate implementation of win32 (and win64 long-term)
> and related APIs. If putting invalid data into a specific function
> causes a known crash on the only other implementation of win32
> (Microsoft Windows), especially considering that win32 is standardised
> by the same company that produces Windows, it can be assumed that the
> crash is the correct behaviour and Wine should emulate it.


Is it possible to meaningfully enhance Wine by crashing the app, but
in such a way as to note on the terminal that the crash is for
compatibility with Win32, what crashed where, etc?


> No, it's dooming Wine to have more success than it should have. Big
> difference. In implementing win32 API, Wine inherently opens up *nix
> to a whole new world of malware. Sure, it still needs to be explicitly
> run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine",
> but that won't stop spyware, trojans, worms etc. completely. And it
> shouldn't, because if Wine attempts to stop malware, then legitimate
> applications will surely suffer too. Not to mention legitimate
> software that *acts* like malware, e.g. punkbuster :)


Wine running malware correctly is a valuable feature, e.g. ZeroWine:

  http://www.offensivecomputing.net/?q=node/1028

It runs malware in Wine on Debian on QEMU for the purpose of producing
a full trace of all Win32 calls.


- d.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Kornél Pál]

Remco wrote:
> A while back there was some case where a buggy Windows program would
> run in Wine, while it didn't run in any version of Windows. After Wine
> became better, the buggy program stopped working. Of course it also
> meant that a lot of other programs started working. At some point you
> have to stop making bad programs work, and implement the API as close
> to Windows itself as possible. The buggy program can still be made to
> work with a custom patch.

Windows has an application compatibility layer that loads with specific 
(pre-configured and user configured) applications to provide backward 
compatible behavior for buggy applications by intercepting exported 
system DLL functions. Wine should have this as well that would enable 
more applications on Wine, possibly even more than on Windows.

Kornél

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

It's all been said, by myself and others. I just want something clarified.

2009/1/25 Guillaume SH :
> Regarding the part of your mail where you wrote : "that's actually
> good that applications crash when
> they pass invalid data", I must admit I don't understand your point at
> all. It seems to me a dogma, not the result of some thought or stand
> back.

If an application ends up with invalid data (possibly due to a bug in
the app, possibly due to corrupt data files, possibly due to user
input without proper checking in the app), a call to the function in
question (or any other function, for that matter) could easily end up
with invalid data.

In the case of invalid data crashing the application, the application
stops functioning, and no (further) damage can be caused.

In the case where Wine does something that win32/Windows doesn't,
which is to allow the program to continue with its invalid data, there
is potential for your system to become compromised by the application
continuing. What you describe as a potential exploit by crashing an
app with invalid data in this case could easily be used as an exploit
the other way, and something that specifically targets Wine, since the
behaviour is different in Windows, where the app crashes on invalid
data.

It's possible. It's potential. It's theoretical. It's something that
could be implemented as a proof-of-concept. It should be fixed, and
doing what the other guy does, when there are only two in the field,
makes sense when you're already trying to do what the other guy does
(which is run Windows applications). It doesn't even need to be
exactly the same code, as long as it has the same effect. There's
already been a suggestion for an alternative way to do the same thing.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Remco]

On Sun, Jan 25, 2009 at 1:53 PM, Guillaume SH  wrote:
> The most interesting part in your answer is indeed this word of
> "Behaviour" you used. Indeed, in my understanding (but maybe "I am
> hoping" is more correct here) wine's goal is to provide the same
> functionalities as Windows API, not to implement those functionalities
> C statement for C statement with respect to Window's ones.
>
> Two reason comes to my mind :
> 1 - Just copycatting Windows implementation would brought wine very
> close to plagiarism, thus legally threaten is mere existence

Legal problems aside, copycatting Windows is exactly what has to
happen for Wine to function like it should. It can't be a 'better'
version of Windows, because many programs depend on the quirks and
faults of the Windows API/ABI.

And I don't think there are any legal problems. Wine developers don't
look at reverse-engineered Windows code, so Wine's code will
inevitably differ a great deal. Implementing quirks the same way will
make the code more similar than before, but there are still things
like coding style and implementation details that differ a great deal.
Probably not even 1% of the C statements in Wine is an exact match to
a statement in Windows.

> 2 - Obviously, Windows implementation is not always the most efficient
> nor the most secure, due to commercial stakes (release schedule,
> financial arbitrations...)

Well, the implementation can differ from Windows, as long as it has
the same effect on the API/ABI level. Some applications actually do
run faster because of this. And some run much slower because of this.

> Regarding the part of your mail where you wrote : "that's actually
> good that applications crash when
> they pass invalid data", I must admit I don't understand your point at
> all. It seems to me a dogma, not the result of some thought or stand
> back.

A while back there was some case where a buggy Windows program would
run in Wine, while it didn't run in any version of Windows. After Wine
became better, the buggy program stopped working. Of course it also
meant that a lot of other programs started working. At some point you
have to stop making bad programs work, and implement the API as close
to Windows itself as possible. The buggy program can still be made to
work with a custom patch.

Remco

Re: Updated DIB Engine

[Ben Klein]

2009/1/25 Massimo Del Fedele :
> The engine is disabled by default; can be changed by environment variable :
>
> export WINEDIB=ON (or ENABLE or ENABLED or TRUE)  enables it
> export WINEDIB=OFF (or DISABLE or DISABLED or FALSE)  disables it
>
> or by registry key :
>
> HKCU/Software/Wine/DIB Engine/Enable='Y'  enables it
> HKCU/Software/Wine/DIB Engine/Enable='N'  disables it
>
> the environment variable has precedence on registry, so for example if
> WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is
> enabled.
>
> I suggest to use the environment for the moment, at less you have an app
> that runs much better with the engine (autocad, for example...) which
> benefits from a default enabled engine in registry.

I'm still opposed to adding an environment variable for something so
simple (an enable/disable flag). It just seems like extra work for no
benefit to me. I'm sure we can all agree that the registry is a
suitable place for the setting.

Isn't the idea that the DIB engine will only be used as needed, and
will be good in all cases where it's used? If that's the case, it's
not too important having on-the-fly per-application enabling/disabling
(whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful).

Re: performance issue when OffscreenRenderingMode = "pbuffer"

[Jérôme Gardou]

Roderick Colenbrander a écrit :
>> Roderick Colenbrander a écrit :
>> 
 I tried to play Supreme Commander using pbuffer option instead of fbo.
 
>> I 
>> 
 was quite happy with it, since I gained quite a bunch of performance (I
 mean, something I really COULD see), but after a while, the performance
 dropped dramatically, to ~4-5 fps.

 I tested quite a few thing, and I finally found that pixel bufers were 
 not taken in account when calculating available texture memory. The
 
>> game 
>> 
 then allocated more textures, and good opengl didn't dare complain when
 putting them in system memory.

 Attached is a patch which should solve the problem.

 For those who are curious, try setting VideoMemorySize to 200 instead
 
>> of 
>> 
 256. It works just like a charm.

 
 
>>> I think the basic idea of the patch is good but the calculation itself
>>>   
>> should take into account double buffering. In wine we don't use double
>> buffering on pbuffers but we might be receiving a WGL pixel format which uses
>> double buffering, so in that case the amount of video memory would be a
>> factor 2 too low.
>> 
>>> Something like this would give you the double buffering capability from
>>>   
>> a d3d device:
>> 
>>> This->adapter->cfgs[iPixelFormat]->doubleBuffer
>>>
>>> Roderick
>>>   
>>>   
>> OK. Here is a new one, more readable I think. I'll send it to 
>> wine-patches once I manage to configure git-send-email :)
>> 
>
> Hi,
>
> I think it would be best to add an attribute 'pbuffer_size' or something like 
> that to the WineD3DContext storing the size of the pbuffer. This is needed 
> because GetPixelFormat won't work on a pbuffer. The problem with this call is 
> that GetPixelFormat doesn't see 'offscreen pixel formats' (like e.g. floating 
> point ones and there are others) which can be used for pbuffers. Further I 
> think it is nicer to not have to recalculate its size. I don't think there is 
> a way to get the pixel format from a pbuffer.
>
> Roderick
>
>   
Patch sent...

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

2009/1/26 Guillaume SH :
> I will be my last mail though because I understood that there is a
> consensus that wine shouldn't be a safe and good tool enabling
> transition from Windows to free-OS, but rather a tool with a
> not-so-clear goal (again I'm not willing to start flaming, so please
> don't).

Wine's goal is perfectly clear: to provide, as best as possible, a
complete and accurate implementation of win32 (and win64 long-term)
and related APIs. If putting invalid data into a specific function
causes a known crash on the only other implementation of win32
(Microsoft Windows), especially considering that win32 is standardised
by the same company that produces Windows, it can be assumed that the
crash is the correct behaviour and Wine should emulate it.

>>> 1 - Freedom (possibility to browse sources, self-compile from sources
>>> and even modifying them)
>>
>> This one commit does not making the source any less open.
> I totally agree : this the first reason i evoked and it is 100% reached by 
> wine
>
>>> 2 - Free from charge
>>
>> This one commit does not put a price tag on Wine.
> I totally agree : this is the second reason I evoked and it is 100%
> reached by wine
>
>>> 3 - Communicating openly about known defects in software, fixing
>>> defects without respects for commercial stakes (ex: hide bug until the
>>> xxth release, or not fixing a known bug until it is publicly
>>> discovered)
> I agree that wine doesn't try to hide defect, but Microsoft is, and
> copycatting Microsoft behavior is like being accomplice of its silence
> and lack of actions

Microsoft's defect, if not already documented, has been revealed by
this patch. It's not something they're likely to fix. If they fix it,
then a matching fix has to go in Wine at some point (which could be
interesting due to different behaviour on different Windows versions).
Until they fix the bug and update win32 specifications to match,
crashes directly caused by the commit in question are expected and can
be assumed to be correct.

> Regarding the security part, I am full aware of the facts you stated,
> and this is a point that's dooming wine to have less success than It
> could have.

No, it's dooming Wine to have more success than it should have. Big
difference. In implementing win32 API, Wine inherently opens up *nix
to a whole new world of malware. Sure, it still needs to be explicitly
run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine",
but that won't stop spyware, trojans, worms etc. completely. And it
shouldn't, because if Wine attempts to stop malware, then legitimate
applications will surely suffer too. Not to mention legitimate
software that *acts* like malware, e.g. punkbuster :)

> You are an intelligent man Ben, I happy to exchange with such a man.

Lies, all lies! But thank you nonetheless.

Re: performance issue when OffscreenRenderingMode = "pbuffer"

[Roderick Colenbrander]

> Roderick Colenbrander a écrit :
> >> I tried to play Supreme Commander using pbuffer option instead of fbo.
> I 
> >> was quite happy with it, since I gained quite a bunch of performance (I
> >> mean, something I really COULD see), but after a while, the performance
> >> dropped dramatically, to ~4-5 fps.
> >>
> >> I tested quite a few thing, and I finally found that pixel bufers were 
> >> not taken in account when calculating available texture memory. The
> game 
> >> then allocated more textures, and good opengl didn't dare complain when
> >> putting them in system memory.
> >>
> >> Attached is a patch which should solve the problem.
> >>
> >> For those who are curious, try setting VideoMemorySize to 200 instead
> of 
> >> 256. It works just like a charm.
> >>
> >> 
> >
> > I think the basic idea of the patch is good but the calculation itself
> should take into account double buffering. In wine we don't use double
> buffering on pbuffers but we might be receiving a WGL pixel format which uses
> double buffering, so in that case the amount of video memory would be a
> factor 2 too low.
> >
> > Something like this would give you the double buffering capability from
> a d3d device:
> > This->adapter->cfgs[iPixelFormat]->doubleBuffer
> >
> > Roderick
> >   
> OK. Here is a new one, more readable I think. I'll send it to 
> wine-patches once I manage to configure git-send-email :)

Hi,

I think it would be best to add an attribute 'pbuffer_size' or something like 
that to the WineD3DContext storing the size of the pbuffer. This is needed 
because GetPixelFormat won't work on a pbuffer. The problem with this call is 
that GetPixelFormat doesn't see 'offscreen pixel formats' (like e.g. floating 
point ones and there are others) which can be used for pbuffers. Further I 
think it is nicer to not have to recalculate its size. I don't think there is a 
way to get the pixel format from a pbuffer.

Roderick


-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: bugzilla/appdb hung

[John Haywards]

Hmm, now bugzilla's slow again... :(
But no error message...


On Thu, 08 Jan 2009 10:43:15 -0600, Jeremy Newman wrote:

> I made some tweaks to the mysql config. Hopefully it this will happen
> less often to hopefully not at all now.
> 
> -Newman
> 
> John Haywards wrote:
>> On Mon, 05 Jan 2009 06:10:05 -0800, Dan Kegel wrote:
>> 
>>   Warning: mysql_connect() [function.mysql-connect]: User winehq
>> already has more than 'max_user_connections' active connections in
>> /home/ winehq/opt/appdb/include/query.php on line 82
>>   Database error, please try again soon: User winehq already has
>>   more
>> than 'max_user_connections' active connections
>> 
>> At this moment...

A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Guillaume SH]

Hi Dimitry,

Thank you very much for bringing this explanation to my knowledge.

As you name came over and over through wine-devel list, I am aware
that you are an experimented and influential member within wine
community (which make a huge difference with me, as this is the first
time I try to bring a contribution to wine(1) ), so I will consider
this explanation as the way most involved wine people are considering
things up.

The most interesting part in your answer is indeed this word of
"Behaviour" you used. Indeed, in my understanding (but maybe "I am
hoping" is more correct here) wine's goal is to provide the same
functionalities as Windows API, not to implement those functionalities
C statement for C statement with respect to Window's ones.

Two reason comes to my mind :
1 - Just copycatting Windows implementation would brought wine very
close to plagiarism, thus legally threaten is mere existence
2 - Obviously, Windows implementation is not always the most efficient
nor the most secure, due to commercial stakes (release schedule,
financial arbitrations...)

Regarding the part of your mail where you wrote : "that's actually
good that applications crash when
they pass invalid data", I must admit I don't understand your point at
all. It seems to me a dogma, not the result of some thought or stand
back.
Don't misunderstand me here, I'm not insulting you neither I'm not
saying that I am better than you nor I'm not trying to start a flaming
thread. I respect the assertion you stated, but honestly and deeply
fail to understand why is it correct.


Guillaume

(1) Talking openly and honestly about a subject that may be considered
a problem is a way of contributing, less concrete than patches, but
real too.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

2009/1/25 Guillaume SH :
> This week however I was quite puzzled by one commit : "kernel32: Make
> GetOverlappedResult crash on NULL args as native does."(1)
>
> Thinking about it I see only one argument justifying it's the good
> direction : for the sake or portability from wine to windows
> platforms. For example, a firm using wine on a free-OS platform, for
> software development with a Windows target platform.

I see it as a matter of correctness. Unexpected success can be worse
than unexpected failure. Imagine a case where, due to invalid data, an
application would randomly destroy or corrupt data all over the user's
computer. The only thing saving it is this kernel32 crash. If Wine
doesn't have it, bye-bye data integrity.

Of course, this is just a hypothetical. But it's important to note
that Wine is not *meant* to be *better* than Windows, it's mean to
*accurately* implement the win32 API. Thus, it's important to be able
to reproduce positive and negative cases as the API is defined.

> Relying on this assertion (which someone may demonstrate me to be
> false, secondary or incomplete), I'm afraid that wine take a step in
> the wrong direction from what seems to me the third major reason to
> switch from non-free OS platform (typically Windows) from free-OS
> platform. Those 3 main reasons are for me :
>
> 1 - Freedom (possibility to browse sources, self-compile from sources
> and even modifying them)

This one commit does not making the source any less open.

> 2 - Free from charge

This one commit does not put a price tag on Wine.

> 3 - Communicating openly about known defects in software, fixing
> defects without respects for commercial stakes (ex: hide bug until the
> xxth release, or not fixing a known bug until it is publicly
> discovered)

If anything, it's communicating a defect more openly. We're
specifically saying that, under the right circumstances, the API call
will crash (the expected behaviour if running on a native system).

Also note that commercial stakes do not factor in to Wine (with the
possible exception of Crossover Office), and that Wine is certainly
not hiding bugs from anyone. That said, bugs are unknown and
unacknowledged until someone discovers them, and in the case of
open-source software, that someone is invariably "the public" (i.e. an
average user).

> I feel sad enough about it, and I think it can prevent advertised
> people to use it but above all to recommends Windows user to go for
> free-OS platform with usage of wine for their needs not covered by
> free-software (like proprietary format).

You know what would be better? Convince people to not use win32 at
all, and to use open APIs on open operating systems. We don't live in
such a rationally open world. Wine has to deal with the proprietary
and (in places) poorly documented win32 API, and in some cases simply
reproduce behaviour not necessarily defined in the win32 spec but that
is reliably reproducible on Windows (native) systems.

> PS : I am fully aware that free software have defects too, some of
> them being security issue. I am also aware, that in a software as huge
> as wine, reaching even a medium security level is a real strong
> challenge, increased by the defects in Windows API design. I am also
> fully aware that security is a process, not a product.

Wine doesn't have security. OK, that's a bit simplified, but Wine does
not protect you from malicious software. Most malware on Windows
systems are perfectly valid win32 apps, and if Wine was perfect then
the malware would work in Wine too. With every improvement to Wine (in
terms of API completeness, accuracy etc.), more malware can
potentially run. That's just the way the cookie crumbles.

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ambroz Bizjak]

On Sunday 25 January 2009 12:39:22 Dmitry Timoshkov wrote:
> "Guillaume SH"  wrote:
> > As I'm following wine only for a short time (count in months, not in
> > years) I guess reproducing windows unfixed defects is a choice
> > (although I am not sure this decision comes from consensus or from a
> > boss statement) made by wine team.
>
> That comes from a simple understanding that win32 API behaviour
> is defined by Microsoft, not by anybody else. Having a NULL check,
> or even an exception handler in an API is not fix for a defect as
> you might imply, that's actually good that applications crash when
> they pass invalid data. Wine needs to handle invalid case only when
> Windows does have them, and only if there are applications depending
> on that behaviour.
>
> If you whish to "fix" win32 API, make Microsoft hire you.
What about an assertion right before the following line:
*lpTransferred = lpOverlapped->InternalHigh;

This way it will still "crash" in the same circumstances, but will make it 
easier to debug programs.

Re: performance issue when OffscreenRenderingMode = "pbuffer"

[Jérôme Gardou]

Roderick Colenbrander a écrit :
I tried to play Supreme Commander using pbuffer option instead of fbo. I 
was quite happy with it, since I gained quite a bunch of performance (I 
mean, something I really COULD see), but after a while, the performance 
dropped dramatically, to ~4-5 fps.


I tested quite a few thing, and I finally found that pixel bufers were 
not taken in account when calculating available texture memory. The game 
then allocated more textures, and good opengl didn't dare complain when 
putting them in system memory.


Attached is a patch which should solve the problem.

For those who are curious, try setting VideoMemorySize to 200 instead of 
256. It works just like a charm.





I think the basic idea of the patch is good but the calculation itself should 
take into account double buffering. In wine we don't use double buffering on 
pbuffers but we might be receiving a WGL pixel format which uses double 
buffering, so in that case the amount of video memory would be a factor 2 too 
low.

Something like this would give you the double buffering capability from a d3d 
device:
This->adapter->cfgs[iPixelFormat]->doubleBuffer

Roderick
  
OK. Here is a new one, more readable I think. I'll send it to 
wine-patches once I manage to configure git-send-email :)
>From 3f20a3570a99a57c3e065f1ef93277c28fb61a4e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= 
Date: Sun, 25 Jan 2009 12:52:45 +0100
Subject: [PATCH] wined3d: take into account video ram that pixel buffers use.

---
 dlls/wined3d/context.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index da3053a..86d9db4 100644
--- a/dlls/wined3d/context.c
+++ b/dlls/wined3d/context.c
@@ -635,6 +635,7 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This, 
IWineD3DSurfaceImpl *tar
 HGLRC ctx = NULL, oldCtx;
 WineD3DContext *ret = NULL;
 int s;
+long size = 0 ;
 
 TRACE("(%p): Creating a %s context for render target %p\n", This, 
create_pbuffer ? "offscreen" : "onscreen", target);
 
@@ -679,6 +680,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This, 
IWineD3DSurfaceImpl *tar
 goto out;
 }
 ReleaseDC(win_handle, hdc_parent);
+size = target->currentDesc.Width * target->currentDesc.Height * 
target->bytesPerPixel ;
+if(This->adapter->cfgs[iPixelFormat].doubleBuffer)
+size *= 2 ;
 } else {
 PIXELFORMATDESCRIPTOR pfd;
 int iPixelFormat;
@@ -898,6 +902,8 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This, 
IWineD3DSurfaceImpl *tar
 }
 This->frag_pipe->enable_extension((IWineD3DDevice *) This, TRUE);
 
+WineD3DAdapterChangeGLRam(This, size) ;
+
 return ret;
 
 out:
@@ -958,6 +964,7 @@ static void RemoveContextFromArray(IWineD3DDeviceImpl 
*This, WineD3DContext *con
  */
 void DestroyContext(IWineD3DDeviceImpl *This, WineD3DContext *context) {
 struct fbo_entry *entry, *entry2;
+long size = 0 ;
 
 TRACE("Destroying ctx %p\n", context);
 
@@ -986,11 +993,18 @@ void DestroyContext(IWineD3DDeviceImpl *This, 
WineD3DContext *context) {
 /* Cleanup the GL context */
 pwglMakeCurrent(NULL, NULL);
 if(context->isPBuffer) {
+int iPixelFormat = GetPixelFormat(context->hdc) ;
+IWineD3DSurfaceImpl* surf = (IWineD3DSurfaceImpl*) context->surface ;
 GL_EXTCALL(wglReleasePbufferDCARB(context->pbuffer, context->hdc));
 GL_EXTCALL(wglDestroyPbufferARB(context->pbuffer));
+size = surf->currentDesc.Width * surf->currentDesc.Height * 
surf->bytesPerPixel ;
+if(This->adapter->cfgs[iPixelFormat].doubleBuffer)
+size *= 2 ;
 } else ReleaseDC(context->win_handle, context->hdc);
 pwglDeleteContext(context->glCtx);
 
+WineD3DAdapterChangeGLRam(This, (-1)*size) ;
+
 HeapFree(GetProcessHeap(), 0, context->vshader_const_dirty);
 HeapFree(GetProcessHeap(), 0, context->pshader_const_dirty);
 RemoveContextFromArray(This, context);
-- 
1.6.0.6

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64

[Dmitry Timoshkov]

"Mikołaj Zalewski"  wrote:

>>> +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of the 
>>> structure
>>> + * is the same as of TBBUTTON */
>>> typedef struct
>>> {
>>> INT iBitmap;
>>> @@ -96,6 +98,9 @@ typedef struct
>>> BYTE  fsStyle;
>>> BYTE  bHot;
>>> BYTE  bDropDownPressed;
>>> +#ifdef _WIN64
>>> +BYTE bReserved64[4];
>>> +#endif
>>> DWORD_PTR dwData;
>>> INT_PTR iString;
>>> INT nRow;
>>
>>
>> Then probably it would make sense to make TBBUTTON the first member of the 
>> above
>> structure. That would help in avoiding possible layout problems in future.
>>
>  The bHot and bDropDownPressed would then be called bReserved[0] and 
> bReserved[1] so this could make more harm than 
> good.

You can make a union for that case, with an appropriate comment.

-- 
Dmitry. 

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Dmitry Timoshkov]

"Guillaume SH"  wrote:

> As I'm following wine only for a short time (count in months, not in
> years) I guess reproducing windows unfixed defects is a choice
> (although I am not sure this decision comes from consensus or from a
> boss statement) made by wine team.

That comes from a simple understanding that win32 API behaviour
is defined by Microsoft, not by anybody else. Having a NULL check,
or even an exception handler in an API is not fix for a defect as
you might imply, that's actually good that applications crash when
they pass invalid data. Wine needs to handle invalid case only when
Windows does have them, and only if there are applications depending
on that behaviour.

If you whish to "fix" win32 API, make Microsoft hire you.

-- 
Dmitry.

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64

[Mikołaj Zalewski]

Dmitry Timoshkov wrote:

> "Mikolaj Zalewski"  wrote:
>
>> +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of 
>> the structure
>> + * is the same as of TBBUTTON */
>> typedef struct
>> {
>> INT iBitmap;
>> @@ -96,6 +98,9 @@ typedef struct
>> BYTE  fsStyle;
>> BYTE  bHot;
>> BYTE  bDropDownPressed;
>> +#ifdef _WIN64
>> +BYTE bReserved64[4];
>> +#endif
>> DWORD_PTR dwData;
>> INT_PTR iString;
>> INT nRow;
>
>
> Then probably it would make sense to make TBBUTTON the first member of 
> the above
> structure. That would help in avoiding possible layout problems in 
> future.
>
  The bHot and bDropDownPressed would then be called bReserved[0] and 
bReserved[1] so this could make more harm than good.

Mikolaj

Re: performance issue when OffscreenRenderingMode = "pbuffer"

[Roderick Colenbrander]

> I tried to play Supreme Commander using pbuffer option instead of fbo. I 
> was quite happy with it, since I gained quite a bunch of performance (I 
> mean, something I really COULD see), but after a while, the performance 
> dropped dramatically, to ~4-5 fps.
> 
> I tested quite a few thing, and I finally found that pixel bufers were 
> not taken in account when calculating available texture memory. The game 
> then allocated more textures, and good opengl didn't dare complain when 
> putting them in system memory.
> 
> Attached is a patch which should solve the problem.
> 
> For those who are curious, try setting VideoMemorySize to 200 instead of 
> 256. It works just like a charm.
> 

I think the basic idea of the patch is good but the calculation itself should 
take into account double buffering. In wine we don't use double buffering on 
pbuffers but we might be receiving a WGL pixel format which uses double 
buffering, so in that case the amount of video memory would be a factor 2 too 
low.

Something like this would give you the double buffering capability from a d3d 
device:
This->adapter->cfgs[iPixelFormat]->doubleBuffer

Roderick
-- 
NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: user32: Resend: Move character conversion logic to dde_server.d &remove todo's

[Jeff Latimer]

Dmitry Timoshkov wrote:
>> It highlights the problem and that the translation should take place 
>> in the server.  In earlier discussions last year this was an issue.
> Again, do you have a test case for that as a proof?
When solving the winebrowser problem, I was fixing the existing 
translation code in dde_client.c.  This broke the raw dde tests.  At 
that point I had a close look the results deduced that the code needed 
to be moved but a substantial test case had to be developed to 
demonstrate the situation.  I submitted the following dde.c tests:
/* Test the combinations of A and W interfaces with A and W data
   end to end to ensure that data conversions are accurate */
sprintf(buffer, "%s dde enda", argv[0]);
CreateProcessA(NULL, buffer, NULL, NULL, FALSE,
   CREATE_SUSPENDED, NULL, NULL, &startup, &proc);

test_end_to_end_server(proc.hProcess, proc.hThread, TRUE);

sprintf(buffer, "%s dde endw", argv[0]);
CreateProcessA(NULL, buffer, NULL, NULL, FALSE,
   CREATE_SUSPENDED, NULL, NULL, &startup, &proc);

test_end_to_end_server(proc.hProcess, proc.hThread, FALSE);

sprintf(buffer, "%s dde enda", argv[0]);
CreateProcessA(NULL, buffer, NULL, NULL, FALSE,
   CREATE_SUSPENDED, NULL, NULL, &startup, &proc);

test_end_to_end_server(proc.hProcess, proc.hThread, FALSE);

sprintf(buffer, "%s dde endw", argv[0]);
CreateProcessA(NULL, buffer, NULL, NULL, FALSE,
   CREATE_SUSPENDED, NULL, NULL, &startup, &proc);

test_end_to_end_server(proc.hProcess, proc.hThread, TRUE);

These tests have todo's that are fixed by this patch we are discussing.  
The existing code dde_client is actually broken as it does not handle 
the todo's that are retired by this patch.  I am not sure that I can 
demonstrate the problem without "fixing" the existing code to 
demonstrate that it breaks the raw dde tests.  Do I have to go to this 
trouble to prove the case?
> Have you tested winebrowser under Windows to see if that's the case?
I did not know that we could do that.  I will have a look at it.
> And again, a test replicating the problem is required in order to avoid
> a regression in future.
The tests I have previously had accepted actually demonstrate the 
problem and guard against regression.

A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Guillaume SH]

Hi wine team,

First let me thank you for providing wine software witch I see as a
strong asset in the expansion of free software and as a useful tool
for people (like me) already using free software wherever possible. At
this point, Wine is at a very good level both in API coverage, quality
(less and less hack, more and more nice and clean solutions) and
efficiency. Reaching that level required a tremendous work in all
kinds of domains (implementation, coordination, patch value judgment,
test suite...). In this regard I want to thank you again and
congratulate you all guys, what you have done so far is quite an
achievement.

This week however I was quite puzzled by one commit : "kernel32: Make
GetOverlappedResult crash on NULL args as native does."(1)

As I'm following wine only for a short time (count in months, not in
years) I guess reproducing windows unfixed defects is a choice
(although I am not sure this decision comes from consensus or from a
boss statement) made by wine team.

Thinking about it I see only one argument justifying it's the good
direction : for the sake or portability from wine to windows
platforms. For example, a firm using wine on a free-OS platform, for
software development with a Windows target platform.

Relying on this assertion (which someone may demonstrate me to be
false, secondary or incomplete), I'm afraid that wine take a step in
the wrong direction from what seems to me the third major reason to
switch from non-free OS platform (typically Windows) from free-OS
platform. Those 3 main reasons are for me :

1 - Freedom (possibility to browse sources, self-compile from sources
and even modifying them)

2 - Free from charge

3 - Communicating openly about known defects in software, fixing
defects without respects for commercial stakes (ex: hide bug until the
xxth release, or not fixing a known bug until it is publicly
discovered)

To summarize, I'm stating that removing the clean and safe way to
handle NULL parameters in this function to fall back to bad and dirty
crash, exposing security issue for user (a software can be created
specifically by a ill-intentioned one to exploit this defect), all for
the sake of being as bad as Windows is, is a step in the wrong
direction.

I feel sad enough about it, and I think it can prevent advertised
people to use it but above all to recommends Windows user to go for
free-OS platform with usage of wine for their needs not covered by
free-software (like proprietary format).

Nevertheless, just as I said, I'm still very enthusiast about wine and
still think it's great and very useful. I will continue to use it,
promote its usage when suitable, and also warn about its known defects
people around me.

Guillaume

(1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009


PS : I am fully aware that free software have defects too, some of
them being security issue. I am also aware, that in a software as huge
as wine, reaching even a medium security level is a real strong
challenge, increased by the defects in Windows API design. I am also
fully aware that security is a process, not a product.

Re: [2/3]: winemenubuilder: generate fd.o MIME and file type associations

[Damjan Jovanovic]

On Sat, Jan 24, 2009 at 7:11 PM, Frank Richter  wrote:
> On 24.01.2009 12:03, Damjan Jovanovic wrote:
>> +static char* wchars_to_unix_chars(LPCWSTR string)
>> +{
>> +char *ret;
>> +INT size = WideCharToMultiByte(CP_UNIXCP, 0, string, -1, NULL, 0, NULL, 
>> NULL);
>
> Since that is used to write fd.o desktop and mime files: double-check
> the respective specs, I believe they mandate UTF-8 as the character
> encoding. UNIXCP isn't necessarily UTF-8.
>
> -f.r.

Thank you, I've resent that patch.

Damjan

Re : performance issue when OffscreenRenderingMode = "pbuffer"

[paulo lesgaz]

Jerome,

your patch must be sent to wine-patch, not to wine-devel.

A+

David

--- En date de : Dim 25.1.09, Jérôme Gardou  a écrit :
De: Jérôme Gardou 
Objet: performance issue when OffscreenRenderingMode = "pbuffer"
À: wine-devel@winehq.org
Date: Dimanche 25 Janvier 2009, 2h42

I tried to play Supreme Commander using pbuffer option instead of fbo. I was
quite happy with it, since I gained quite a bunch of performance (I mean,
something I really COULD see), but after a while, the performance dropped
dramatically, to ~4-5 fps.

I tested quite a few thing, and I finally found that pixel bufers were not
taken in account when calculating available texture memory. The game then
allocated more textures, and good opengl didn't dare complain when putting
them in system memory.

Attached is a patch which should solve the problem.

For those who are curious, try setting VideoMemorySize to 200 instead of 256.
It works just like a charm.

>From 8e7b7e517b15e2ddb2cdd1526dfab3dfbf856bd5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= 
Date: Sun, 25 Jan 2009 02:34:03 +0100
Subject: [PATCH] wined3d: take pixel buffers in account when calculating
texture ram.

---
 dlls/wined3d/context.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index da3053a..9fad82d 100644
--- a/dlls/wined3d/context.c
+++ b/dlls/wined3d/context.c
@@ -898,6 +898,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This,
IWineD3DSurfaceImpl *tar
 }
 This->frag_pipe->enable_extension((IWineD3DDevice *) This, TRUE);
 
+if(create_pbuffer)
+WineD3DAdapterChangeGLRam(This,
((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Width *
((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Height *
((IWineD3DSurfaceImpl*)(ret->surface))->bytesPerPixel) ;
+
 return ret;
 
 out:
@@ -988,6 +991,7 @@ void DestroyContext(IWineD3DDeviceImpl *This,
WineD3DContext *context) {
 if(context->isPBuffer) {
 GL_EXTCALL(wglReleasePbufferDCARB(context->pbuffer,
context->hdc));
 GL_EXTCALL(wglDestroyPbufferARB(context->pbuffer));
+WineD3DAdapterChangeGLRam(This,(-1) *
((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Width *
((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Height *
((IWineD3DSurfaceImpl*)(context->surface))->bytesPerPixel) ;
 } else ReleaseDC(context->win_handle, context->hdc);
 pwglDeleteContext(context->glCtx);
 
-- 
1.6.0.6