July 2006 - Wine-Devel - list.winehq.org

WineHQ.org will be moving to a new server today.
by Jeremy Newman July 20, 2006

July 20, 2006

Starting today at 2pm CDT winehq.org will be moving to a new ISP. At the same time I am moving everything over to new server hardware. This means we will be having some DNS issues for the next week or so. It really depends on how quickly your ISP's DNS servers catch the changes. As a workaround if you DNS is stale and you still need access to CVS/git/etc you can add the following to your /etc/hosts file 209.46.25.134 www.winehq.org cvs.winehq.org source.winehq.org bugs.winehq.org appdb.winehq.org wine.codeweavers.com Note: The above is all one line. Just remember to remove that after a week or so. I will also have a redirect setup from the old IP to a temporary hostname of www2.winehq.org at the new IP. This will allow the website to be available to everyone else. Lastly, Bugzilla and the Appdb will be down slightly longer as that is the last thing I will be copying over to the new server.

1 0

getwinegit.sh v0.4 released!
by Christian Lachner July 20, 2006

July 20, 2006

Hello all, There's a new Version of getwinegit.sh. It is now at 0.4. There is no need to comfigure the pathes to the programs getwinegit needs. Everything happens automatically now ;). I hope you enjoy this release... Here's the readme and the changelog: getwinegit.sh-README :: Intro getwinegit is a script which was designed to download/update, compile and install the current wine-source-tree from a git-repository. :: Usage Usage: getwinegit.sh mode [config-file] modes: -0 update the local source-tree -1 + compile the source -2 + install -3 no update; just compile the local source-tree and install -4 no update, no compile; just install -h help ;) The Config-File is optional :: Install Just copy getwinegit.sh wherever you want, make it executable and (optionally) create a softlink at /usr/bin. Then (or before) configure the script by editing the variables in the head with your favourite editor. APP The name of the app which's sources we want to fetch and compile GITROOT The GIT-Repository from where we want to fetch the sources SRC Your Source-Directory (default is /usr/src) TARGET The Sub-Directory where the sources will get stored LOG Location of the Logfile that getwinegit.sh creates PIDFILE Location of the PID-File COMPILED_HELPER A dirty File which is needed to detect, if the source is already compiled or not WAIT_FOR_CLEAN Seconds to wait until the script begins to clean the source. 0 = disabled (default is 5) DEFAULT_MODE The Mode in which getwinegit.sh should operate if NO Parameter is given. (default is 2) By default this Feature is commented out. To enable, remove the rhomb at the beginning of the line. getwinegit.sh needs some packages to function properly. Go install the following ones: gcc, make, curl, bison, flex, git. I hope i did not forget any. :: Future? This is one of the last versions. No great changes are planned, only bugfixes. :: Bugs? Report them to wine-devel or wine-users ;) getwinegit.sh ChangeLog 0.4 Long time no see, but now it's time, isn't it? - More Checks - The Script now tells you if you are already up-to-date with the git-repository - Cleanups :) - Some small Bugfixes

1 0

Asynchronous Direct3D rendering design sugeestion
by Stefan Dösinger July 20, 2006

July 20, 2006

Hi, (warning: long mail) Currently the wined3d code is doing more or less syncronous rendering, that means that a Direct3D function call from the app results directly results in the equivalent opengl call(s). There are a few issues with that: * Multithreaded Direct3D: Opengl calls can only be done from the thread that owns the glX context. Direct3D calls can be done from any thread. Passing around the context is only possible with hacks(SetThreadContext or pthread_kill) and prone to deadlocks. * Performance: Applications expect the 3D calls to return immediately so they can do other things while the gpu is rendering. GL works in the same way, so our Direct3D rendering functions should return almost immediately too, but due to the state changes and drawStridedSlow seem to cause gl to wait until the pipeline is empty. My suggestion is to create a per-device thread which does the rendering and owns the thread, and the rendering calls only place some tokens into a queue and return immediately. This way the app gets the control back immediately and multithreaded direct3d is only about locking the queue correctly. The rendering thread and all rendering code would be in drawprim.c(and maybe a new file e.g. opengl_utils.c). The other files would contain no gl code. Here are some more concrete suggestions for implementing this: The pipeline is a block of memory with a fixed size(e.g. 64k, whatever), and the work orders that are placed in it consist of an opcode and any number of arguments. A NULL opcode means that the place is empty. When a new operation doesn't fit at the bottom of the pipeline we start again. A instruction pointer points at the opcode of the next instruction. If the next opcode is NULL that means that the pipeline is empty. When an instruction was executed the memory of the instruction is zeroed and the instruction pointer set to the next byte after the old instruction. A new instruction doesn't fit into the pipeline if it would overwrite nonzero memory, then we issue a warning and wait until some more space is free. A little modification would be to fix the number of arguments to an opcode. Checking for emtpy instructions would be easier then because we only have to check if the address holding the operation code is NULL and not the whole memory when placing a new instruction, but on the other hand waste memory. Of course we can HeapAlloc the instructions and place pointers to the allocated memory. That doesn't waste memory(maybe, depends on how HeapAlloc works), but imposes the overhead of regular HeapAlloc / HeapFree calls. So what instructions would we need? Everything that issues GL calls. Here are some I could think of and some implementation thoughts: SetRenderState: IWineD3DDevice::SetRenderState sets the update stateblock, and if not recording to a stateblock places a SETRENDERSTATE operation. Arguments are the render state to set and the value to set it to. When the instruction from the pipeline is exectured the value is set in the actual render stateblock and the gl state is updated with the code that is in setrenderstate already. IWineD3DDevice::GetRenderState returns the value from the update stateblock, so it is independent from the execution state of the pipe. SetTextureStageState: Arguments are the stage, state and value, otherwise it is simmilar to SetRenderState SetStreamSource, SetTexture, Set*Shader: Update the update state block, update the refcounts and if not recording queue a setting operation for the stream/texture/shader. This operation updates the render state block, but does not necessarilly change the gl setting(e.g. SetTexture requires texture coords in the vertex too) The Getters return the values stored in the update state block. SetDisplayMode, GetDisplayMode: Not GL calls SetClipPlane, SetMateral, SetLight, SetLightenable, SetTransform, MultiplyTransform, SetViewport: Pretty simple, update the updatestateblock, ... SetFVF, SetVertexDeclaration: Updates the update stateblock and queues a SetDeclaration operation. The declaration is stored in the render stateblock and referenced for rendering. I'd suggest that the render thread should not deal with FVFs Set*ShaderConstant: No idea UpdateTexture, UpdateSurface: No idea either. Maybe relay to DirectDraw Blits ApplyStateBlock: Compare the stateblock contents against the updatestateblock, update the updatestateblock and queue Set* commands for different ones Surface Locking: Set up the local memory for the surface, and if necessary issue a command to read back the surface from gl. Wait for this command to be executed and wait until the last command referencing the surface is finished. If a surface is locked often keep the local memory copy to avoid flushing the whole pipeline for the readback command. When the surface memory is ready pass return Surface unlocking: If necessary start converting the surface e.g. for color keying in a seperate thread and return. If the surface is used for drawing before the conversion is complete the rendering thread has to wait until the conversion is finished. Uploading the surface to gl is done during drawprim when the surface is used. Vertex Buffer locking: Simmilar to surface locking. If neither NOOVERWRITE or DISCARD locking flags are provided wait until all rendering with the buffer is done. Then return the buffer data. We may have to give up the idea of mapping gl memory via glMapBuffer or we might have to wait for the whole pipeline to be executed to place a command for that. Unlocking vertex buffers: If the semantics of the data is known start fixing up vertices in a seperate thread. When done fixing up the buffer place a preload command into the pipeline to load the buffer as early as possible, some gl implementations seem to need that. Again if the buffer is used for drawing until the conversion is done the drawing thread has to wait. Also convert buffers if no vbos are available to get rid of drawStridedSlow completely. Drawprim: This is the most complex thing: First, check if all bound textures and vertex buffers are unlocked(Unit test!). Then increase the rendering reference counter of all textures and buffers(to count how often the object is used in the queue). Then queue a drawprim command and return. If drawing from a user pointer we either have to wait until drawing is done or create a copy before placing the call(this is my favorite, we can fixup colors too while we're at it) Blits: Find out if the blit can be handled in opengl and queue a blit call(which will draw a textured quad). If gl can't handle that fall back to the gdi code, it will perform everything in software, from a gl perspective surface locks are done. This is slow, we will want to handle everything in gl. GetDC: At the moment this is a LockRect from the gl pov, we may want to write a gl gdi driver which queues commands on the pipeline Present: Queue a FLIP command and wait for the pipeline to be emptied, then return. Ideally the rendering is done when Present is called and present returns immediately. Destroying objects: Wait until they aren't needed in the pipeline anymore in Release. Open issues: SetRenderTarget: Afaik those have their own gl context. Should we have a different pipeline or request the worker to switch to a different gl context? Synchonisation is a issue Multiple swapchains: Simmilar issue Anything I forgot? How do we reference objects in the pipeline? For the start I'd suggest to use the implementation pointer, later we may want to replace it by handles(to avoid issues with the pointer size on 64 bit). See the roadmap. My suggestion for the roadmap: 1) Start by protecting the ddraw, d3d8 and d3d9 objects with critical sections against race conditions(easy). 2) Move the code around in wined3d a bit, split up COM from GL stuff without actually changing the way rendering is done. 3) Add a stub pipeline and add code queing the command 4) Move the context into the worker thread and call the actual gl commands from there Additional stuff that can be done if we feel like it: * Get rid of COM in wined3d * Move non-rendering things like Private Data, Stateblocks and Getters into ddraw, d3d8 and d3d9, leave only rendering code in wined3d. The software ddraw code has to stay in wined3d though * Adopt ddi, ddentry or whatever is used in windows xp / vista(Potential legal issues as these interfaces aren't well documented). Stefan

2 1

Re: dinput8 Dll(Un)RegisterServer
by Roderick Colenbrander July 20, 2006

July 20, 2006

Hi, A couple of weeks ago I have been working on dinput8. I implemented the CoCreateInstance code and other pieces. The first time I did the registering code the same way but this isn't correct. On windows the dinput8 objects are registered when directx is installed. Alexandre preferred it to put the stuff in wine.inf. My patch which also included a big testcase for dinput8 did this but wasn't merged. I didn't have time the past few weeks to clean it up, I was actually planning to do it this week. Tombraider legend worked 'fine' using the dinput8 at the time, I believe something broke in the latest version. At the time the main issue was that there was no keyboard or mouse input (forgot which of the two). For some reason I think based on 'device caps' tombraider wasn't calling Acquire for one of the devices. I traced it very deeply (I even wrote a dinput8->native dinput8 wrapper and verified it there). I was planning to contact Core Design about this. Regards, Roderick Colenbrander > Sorry I doesn't atteched the patch. > Hi, > > I implemented (taken from wine's dinput directory, modified) dinput8's > DllRegisterServer, and DllUnRegisterServer functions, which will register > dinput8, and dinputdevice8 co-classes. > With this patch Tomb Raider Legends go further, then crashes again with > builtin dinput. > Applies to current cvs. > > Changelog: > * Implement Dll(Un)RegisterServer > -- > Lamarr > Kovács András > andras(a)csevego.net > http://csevego.net -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

1 0

Lotus native on Linux
by Fabian Cenedese July 20, 2006

July 20, 2006

Hi I just got this newsletter, thought I'd share it here: >At my previous job, everyone in the company was forced to use Lotus Notes. I recall being often annoyed with the Notes e-mail client for its clumsy user interface and appalling lack of features (to say nothing of its crummy calendar). The moment the platform supported POP3 mail clients, I switched to Netscape Messenger. > >But regardless of my personal feelings about Notes, the platform eventually earned my respect. The Notes developers on our IT staff built and maintained several excellent applications exclusively for my department. We used those applications regularly, along with our trading partners, and we quickly came to depend on them. The power of Notes as a collaborative platform is clear to anyone who uses it in this way. > >On Monday, a Notes client will be available for Linux. That s right. Companies will be able to <http://www-128.ibm.com/developerworks/lotus>download Lotus Notes on Linux 7.0.1, an Eclipse plug-in that delivers Notes client functionality to Linux workstations. This includes the crummy e-mail and calendar (which themselves are custom Notes apps), and other collaboration software, as well as your company s own custom applications that once ran only on Mac OS and Windows desktops. Initial support will be for Red Hat Enterprise Linux 4, update 3, but IBM promises a version for Novell SUSE Linux Desktop 10 within 90 days. > >Pricing starts at US$101 per client plus another $70 per client for messaging. Current Mac OS and Windows licenses can be transferred. > >But don t be looking to code your Notes apps on a Linux box. For that, you ll have to wait for the full Eclipse implementation code-named Hannover which IBM says should be at milestone 3 (public beta) by this fall. Hannover will implement RCP under Eclipse 3.2, and will introduce Notes to support for the OpenDocument format (ODF) spec from OASIS. IBM expects general availability the first half of 2007. > >Why did IBM wait so long to develop a Linux-based client? We were waiting for Eclipse to be ready, said Arthur Fontaine, IBM s senior offering manager. The company did not want to add a third code base to the MacOS and Windows bases it was already maintaining. > >IBM sees an opportunity to enter the Linux desktop market with a lower-cost alternative to Mac OS and Windows operating systems, Fontaine added. Among the subtler messages IBM is sending, he said, is that we re changing to a new client software development model. This has been evidenced by the Eclipse-ification of its Rational tools and later this year its Sametime 7.5 instant messaging client. This sends a message that IBM is attacking the deficit of desktop apps that Linux suffers. > >Love or hate it, Lotus Notes usage in the enterprise remains strong. And stronger still are the prospects of enterprise desktop Linux. For more coverage of this important story, see the upcoming Aug. 1 issue of SD Times. > >Contact me at <mailto:ecorreia(a)bzmedia.com>ecorreia(a)bzmedia.com. > >Edward J. Correia bye Fabi

2 1

Re: advapi32: partial LookupAccountSid implementation
by Robert Reif July 20, 2006

July 20, 2006

Robert Reif wrote: > Implement some more of LookupAccountSidW for local computer. > Make LookupAccountSidA use LookupAccountSidW. > Add debugstr_sid for local debugging. Please hold off on this patch. It seems to have a problem. It passed the windows compiled tests but I am seeing a problem with the tests when ported to the wine tests framework.

1 0

Free Trial of Auto Assault available for download.
by Hans Kristian Rosbach July 20, 2006

July 20, 2006

https://secure.plaync.com/cgi-bin/free_trial.pl?partner=10 Remember to enter your email address at the bottom of the page to actually receive a free trial key. Then start the trial ~1GB (or full version ~3GB) download. While downloading you create an account at plaync. Press the add game link in account management, enter the serial key you should have in your email by now. When the game is added, you might still have to "activate" the game from the account management screen. Once these steps are done you should be able to attempt an install and play this very new and fun game. I have not tested to run this under wine, but thought some others might want to. The game was released this easter and resembles the good old Carmageddon games, only MMORPG. No credit-card necessary for this trial luckily. I hope this will drive wine development forward, good luck! PS: You might not want to create the plaync account before you have seen that you can make the game install, or else you might be wasting a good 14 day trial. In any case, you can install, start the game and get into the first menu without having an account. And even that might be a challenge for wine . -HK

1 0

Re: Test Framework for WIDL [1/2]
by Dan Hipschman July 19, 2006

July 19, 2006

On Wed, Jul 19, 2006 at 02:09:45PM -0700, Dan Hipschman wrote: > > This sets up a regression testing framework for WIDL (it could be used > in other places, too). You'll need the next patch to actually do "make > test" in tools/widl/tests, but this patch contains the test script and > list of test cases. The test cases contain all the header files used by > Wine that are generated from IDL files. Note that the TLB files are > commented out for now since they contain a timestamp and hence can't be > directly compared with known good copies. It's still better to at least > have a test for the headers and work on getting a test for the TLB files > soon. I wanted to clarify something. Please note that this test framework is only comparing the current output of widl with the future output of widl. It's not comparing any Windows files, and it's possible that the output of widl could change in the future and still be correct. My main motivation here is that the current IDL files used by Wine only use a small set of features, so having a tests like this allows us to more confidently add new features to widl and be sure we aren't breaking anything on which Wine depends.

1 0

race condition in dinput's multiple joystick code and IL2
by Christoph Frick July 19, 2006

July 19, 2006

hi there, the code i submitted some weeks ago about having more than one /dev/input/event-joystick shows from time to time a race condition in IL2 Sturmovik. this game is written in java and somehow exe-fied. so the whole thing is running a boatload of threads. my box is a smp-opteron-system with gentoo and a 2.6.17 kernel. my problem is the following (in dlls/dinput/joystick_linuxinput.c): the new code calls a method (find_joydevs) on serveral places which checks by a global variable, whether it ran before (have_joydevs) and then builds up a list of the valid devices (joydevs). so what happes there is a struct is filled on the stack and later memcpy-ied to the end of a (re)alloced (HeapAlloc/HeapRealloc) list. things like the device are strdup'ed from the stack into the struct before copy. so in IL2 often - but not always - the have_joydevs has a count > -1, the joydevs has a pointer. but when it access the "struct" behind it, this is uninitialized memory (at least for the device-member) and random errors occur. so what i have tried so far: - put find_joydevs into a critical section - dont use strdup, but HeapAlloc+lstrcpyA nothing helped. the only other thing that came this morning into my mind but i have not yet tried to change, is the fact, that i malloc the string and store the pointer to it in the struct. next thing is a memcpy of the whole struct, which seems ok to my c-knowledge. so if one of the wine gurus has some tips i would be glad to try them out. -- cu

3 3

RE: Winlib - Active Scripting
by Luc-Eric Rousseau July 19, 2006

July 19, 2006

Right, there might be legal issues for distribution, but I was thinking in term of getting a port up-and-running quick internally to validate what parts to replace moving forward. I'm particulary interested in Wine for OS X, a plateform MainWin hasn't announced support for. We have a test version of our application up-and-running on linux in 64-bit, however, which if I'm not mistaken isn't possible with Wine at this stage. We do like the idea of customizing the app for each plateform, this is why I am interested in WineLib and having access to the source. > -----Original Message----- > From: Jason Green [mailto:jave27(a)gmail.com] > > On 7/19/06, Dan Kegel <dank(a)kegel.com> wrote: > > Hi Luc, > > I know of no issues (other than that this would restrict > you to running on x86, > > but perhaps that's not an issue for you). > > I don't think anyone's done it before, but I could be wrong. > > > > On 7/19/06, Luc-Eric Rousseau <lucer(a)softimage.com> wrote: > > > thanks. > > > Are there any known issue with the native microsoft WSH (Windows > > > Scripting Host)DLL under wine? Has this this been done > with a WineLib > > > app in the past? > > If you're planning on distributing this app to customers, there may be > legal licensing issues involved with using those libraries. IANAL, > but just thought I'd give a heads up. > > Jason >

2 1