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

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches. P.S. I won't be available from the 15th for about a week or so. So, if you have any questions, I'm afraid you might have to be patient. Hope this is of interest to someone -Rob. ******Applications: Current status*********** ***In Painter 5 *Cursor pressure works. (Therefore is usable by most) *Cursor orientation is a little odd: The orientation maths needs to be re-done. *No eraser. Haven't yet cracked what enables the eraser. *Doesn't work in desktop mode: Need to map to desktop coordinates. *Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) *Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions. ***In Photoshop 6. *Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode. * Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs. *******To Do************* 1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this) 2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done. 3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen) 4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows. 5. Tests ~ --My current philosophy on tests is... ~ Use Photoshop & Painter, any formal tests ~ can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict. **********Long term to do (Anyone interested?):********* There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;) 1. Improve configuration of wintab. Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file. 2. Handle Z-Order of context properly. This entails *sharing Z-Order between apps. *Working out exactly what role windows have in determining tablet context z-orders. *Allow tablet contexts that don't cover the whole screen/tablet. *Handle inter-application clipping of tablet contexts *Allow all application's windows to receive tablet events when tablet context is on top 3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse) 4. Unicodify 5. Implement various wintab extensions. 6. Implement wintab manager functions. 7. Tests. *********Unknowns********* 1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop? 2. How Painter detects the eraser. Have 3 possibilities i. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!) ii. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only). iii. I've missed something 3. Requirements of other applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s /ZKMUGwQOuw/SIIbOkIUbd0= =R4M7 -----END PGP SIGNATURE-----

2 1

Work legalities
by Nathan Williams Dec. 11, 2007

Dec. 11, 2007

Hey everyone, I have been planning to do some work on wine for a while now, but after I started working I got myself a new programming job. I'm worried about the copyright of any external work I do, so I need a little advice. What do I need from my employer to clear me to work on wine? Is something verbal ok, or should I get it in writing? -- Nathan

10 12

[msi OLE automation] Re: msi patches info pls
by Misha Koshelev May 8, 2007

May 8, 2007

On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote: > Sorry for the lack of response, I'm currently waiting for our lawyers > to determine if it's ok to use code based on an oleview dump of a > native typelib, as that situation is not clear from a copyright > POV. I'm afraid I can't do more until they come to a conclusion on > that point. > So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result). From http://www.winehq.org/pipermail/wine-devel/2007-March/054589.html (posted by Rob Shearman) this is what I understand the correct process to be (I would like to understand the process in detail so I don't do something wrong to "taint" the wine copyright): As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??). Also, what does one do for enums? It does not seem like there is anything that can be changed in this case, so it is alright just to re-create them verbatim (without copying and pasting, and of course the indentation will be prettier)? Thank you very much for your help. Misha

5 10

Is Wine a platform for Codeweaver to make money?! Please help me understand.
by Sasan Iman April 10, 2007

April 10, 2007

First of all, let me say that I am not a developer. But I have been interested in Wine since early 2003. The thing that has always made me scratch my head is that the Windows software that motivates me to install Wine on my linux system (i.e. MS OFfice, etc.) has never worked with wine in a reliable manner. Meanwhile, Codeweaver has always had MS Office working on Wine. Now shouldn't getting the most common windows software working on Wine in an idiot-proof (meaning I can get it to work) manner be the highest priority for Wine developers? Instead, this is left to CodeWeavers and others. I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ? I just can't understand why the more common application are left to a commercial company. My conspiratorial side makes me want to think this is a conspiracy but I am sure there is valid technical and logistical reasons for it so I am asking you guys. Thanks. Sasan

12 20

re: Road to 1.0
by Dan Kegel April 3, 2007

April 3, 2007

Alexandre wrote: > That's still the plan, yes. I'm mostly waiting for the games > support to stabilize; the other main areas, office apps and > installers, both seem in good enough shape at this point. I suppose it depends on your definition of "office apps". Adobe Acrobat Pro and Quicken don't work yet, and they get used in a lot of offices. > I'm also hoping we can make some progress on the x11drv > factorisation before the freeze, so that we don't need to > change the interface too much to add the quartz driver later > on, we'll see how that goes. And if we delay it a bit more > maybe we can slip in Safedisc support too... Oh, yes, please. Here's a try at a 1.0 wish list: - Safedisc support - OpenGL child window problem solved for most common cards at least - Adobe CS2/8 era apps installing and working - Dragon Naturally Speaking 9 working (I'm selfish, I need that one :-) - Quicken 2006 installing/working (including online banking that requires 128 bits) - Mono integration working for non-toy apps - At least some of Munich's VB6 and/or databasey apps working (Hans just submitted a bunch of patches to fix most of the install issues in one) - Better application regression test suite (cxtest, yawt) October is looking about right for the start of the freeze, given that huge list. And my 1.1 wish list (i.e. hard things we can let slip past 1.0): - Activation context support - Quicken 2007 (which requires activation context support?) ... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

10 11

More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)
by Vit Hrachovy April 3, 2007

April 3, 2007

Hi, according to Stefan, Direct X options regarding * Available Video Memory * Enable GLSL will be useful in winecfg / Graphics section. However there is still missing consensus to how and whether to implement user accessible way to enable/disable GLSL in winecfg. Ray Jones, Stefan and me would like this in winecfg. Please share Your opinion. According to the discussion results, I'm going to add either only Available Video Memory text input box, or both Memory and GLSL toggle checkbox to winecfg. Summary of previous discussion follows: Available Video Memory (text input box) ---------------------- User will input here the RAM size of his graphic card. According to Stefan: "There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far." Enable GLSL (checkbox) ----------- GLSL should be made default in 1.0. However, according to Stefan: "some drivers(*cough* macos *cough*) have serious problems with glsl". Until there is a specification in 1.0 requirements that these issues have to be resolved prior 1.0, this checkbox would be useful even past 1.0. Stefan Dosinger with H. Verbeet pointed out that this option should be in Vertex Shader dropdown box, but after inspecting code, I've found wouldn't blend well with the rest of Vertex Shader idea. This is due to GLSL registry key differs from Vertex Shader registry key. Should they be merged into one? Ivan Gyurdiev pointed out that GLSL can be both enabled for hardware vertex shader and software vertex shader, so the idea of merging GLSL with Vertex Shader dropdown box would result in two menu options - 'GLSL with HW support' and 'GLSL with SW support'. Another stance is to make GLSL enabled by default in next Wine versions. Offscreen Rendering (dropdown box) ------------------- Default option will be 'fbo', optional is backbuffer. Stefan doesn't consider it worthy adding to winecfg. Regards Vit

3 3

Anyone working on XKB support for Wine (or any other Keyboard language detection enhancements)?
by Shachar Shemesh April 3, 2007

April 3, 2007

Hi all, The current keyboard detection and setting code is based on the traditional method of setting a keyboard in X11. It misdetects most any language that carries a US keyboard as the first group. While major work on other areas of Wine means that most programs today don't really care about that, it still confuses the $*(!@#&$ out of Word. It also has some pretty serious BiDi editing implications. I'm looking into replacing that with code based on the XKB X11 extension, today supported with any quasi reasonable X server. This should totally eliminate the guesswork done through keyboard change detection in wine today. The main question is this - is anyone today already working on this? Thanks, Shachar

3 2

Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
by Chris Robinson April 2, 2007

April 2, 2007

On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: > Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to > start. > --- > dlls/wined3d/directx.c | 9 +++++++-- > 1 files changed, 7 insertions(+), 2 deletions(-) This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had.

3 4