Re: quartz once again: was DEVENUM.DLL Implementation
>>wouldn't it be possible to just shift maintainer / copyright holder / whatever >>to a new person that does believe it is legal and is willing to take that >>risk too. Just to clarify - we've been talking on and off with Hidenori about something like this for some time. He seems rather busy though, and I have no further news to report at this time. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: Adding shmserver
Alexandre Julliard wrote: Boris Reisig <[EMAIL PROTECTED]> writes: I saw previous posts about the shmserver solution. Its an excellent idea but will it be included in wine? No it won't. It's a neat hack, but it doesn't preserve the core idea behind the server design, which is that processes are properly isolated. With the shm server you basically go back to the Win9x days where any buggy process can trash the system structures; and I don't think that this is where we want to go. I believe that our design has pretty stringent safeguards against a buggy process trashing the system structures. By write-locking the shm area, the possibility of a buggy app (or wine client side code) overwriting system structures is virtually nil. Any server call that is handled 'in place' in a given process could verify its parameters, unlock the shm area while doing its work, and relock it before passing control back to the app. It would take a very buggy (or deliberately malicious) process to cause a serious issue there. Furthermore, the architecture still retains the seperate server. Thus, it would be possible to restrict shm access to trusted processes. Users would then have the ability to decide for themselves whether speeding up a given app is worth the risk to them. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: PATCH: glibc 2.3.x and errno
Alexandre Julliard wrote: I'm afraid that won't be enough. When using thread-local storage, glibc doesn't even call __errno_location any more, it directly stores errno into the thread storage using %gs. It seems the only solution is to make Wine threads work on top of libc threads, but that will be messy. We have a winethreads-on-pthread implementation that we did for some of our non-x86 work a while back. It's pretty simple, and we haven't really tested it on an x86 machine recently - when we did so last, it definitely had some problems. It is pretty similar to work that Andrew Lewycky did at Corel to support cprof and multithreaded profiling, and probably has some of the same caveats that were discussed on wine-devel in March of 2000. The code (excluding some configure checks) is here - some updates will probably be required to get it working with a more recent tree. WineHQ is welcome to use it. It would be nice if any improvements made to it were donated to ReWind as well: http://www.geocrawler.com/archives/3/9376/2001/12/50/7309863/ Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: Wine kernel acceleration module?
Francois Gouget wrote: But of course that's true only if the kernel module has a bug. With the shared memory server any Windows application can crash all the others (but not the machine). To sum up, here's a table of what crashes based on the source of the bug: | Current | Kernel | Shm --+---++ Bug in the server | Wine | Machine| Wine --+---++ Bug in a Windows | Process | Process| Wine application | || So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely. It's also a good argument for having the option to keep using the current server so that you can make the trade-off between speed and stability yourself. The ShmServer is designed with that in mind. The server code has been moved into a shared library, and the wineserver process still exists in the ShmServer model. While it's not actually available in the current code, it would be trivial to restrict access to the shm area to specific trusted processes and force other processes to go through the normal wineserver route. Additionally, the ShmServer is designed so that the actual shared memory area can be write-locked until a server call is made. Thus it becomes very difficult, though not completely impossible, for an individual process to scribble over the server memory by accident. So the bottom right entry in your table should perhaps be changed to read '99% Process / 1% Wine' What it does *not* prevent is a deliberately malicious app scribbling over server memory - certainly a problem, but for many uses of Wine, not a significant one. Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: Wine kernel acceleration module?
Dan Kegel wrote: Brian Vincent (C) wrote: This issue has been discussed several times. If you dig in the WWN archives you'll find mentions of it going back a few years. Much more interesting was this post: http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html The approach is a shared memory wineserver. I beg to differ. IMHO the kernel module approach is the best. The PEACE team, for instance, is going this route in their implementation of win32 on BSD. Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system. We spent some time on that as well before working on the ShmServer approach. With a kernel module approach, hosting multiple wineserver environments becomes more difficult. A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes. Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis. About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective. Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: DIB engine
Alexandre Julliard wrote: David Hammerton <[EMAIL PROTECTED]> writes: If we just always used the dibengine no matter what, we would sometimes 'lose' on the whole coerce thing - what if the dibsection (or whatever) is in gdimod, we'd then have to do a whole copy of it back to sync things up, which is just silly when we could use x11's renderer (the image is already over there)... But if we always use the DIB engine there won't be any coerce stuff at all, everything will be done directly in the DIB and we won't use the X11 renderer. Then the only time you have to copy is when doing a BitBlt to the screen. The DIB engine is a long way from being finished, however. There are some major missing features - text rendering, for example. If the DIB engine is integrated in such a way that it completely replaces X rendering for DIBSections, it will work poorly for many applications, and would be less likely to get used and improved. With the current architecture, it can be improved on a completely incremental basis. -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: Games
Mark Hannessen wrote: When the patch was published, there was a discussion, and the conclusion was that the code is very probably legal, and is not against DMCA Are you sure about the above statements? Have you checked that, or it is just your opinion? Carlos words regarding copy protection: You aren't giving hints to decrypt some code, simply implementing the win32 API, and sometimes implementing a PC architecture, it is far away of decrypt code ;). Laurent's copy protection patch, while impressive, does have a pretty serious copyright-related issue, which has nothing to do with the DMCA. The problem is that his SafeDisc driver is - at least in parts - a direct translation of a dissassembly. Such translation means that technically it's a derivative work, and thus would require the agreement of the original copyright owner to redistribute. -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: DIB engine
Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). > It's not all that complete by any means, but we wanted to get it out > there, so feel free to comment on it (or even apply it to Wine if it's > good enough). Primary attribution should go to Jonathan Meunier, a co-op student who worked with us earlier this year. David Hammerton, Peter Hunniset, and I all assisted with it to one degree or another. If there is any general interest in pursuing DIB Engine work, we would of course appreciate it if developers are willing to license their contributions to ReWind. Ove seems to have forgotten to include the documentation, which includes some nice background on DIB issues in general, and should go into the documentation directory. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED] TRANSGAMING TECHNOLOGIES DIB ENGINE DOCUMENTATION (GDI RENDERER) Copyright (c) 2002 TransGaming Technologies Inc. SCENARIO The Win32 API allows for a graphics format called DIBSections. DIBSections allow the application to write to the image in two ways: Direct Access and through GDI. Direct Access means that the application can simply write whatever data it likes to the image - the application has a pointer to the physical image bits, and can write to this with no problem. In ReWind's X11 Driver we can emulate this kind of access by using XImages. The GDI access allows the application to do a whole heap of extra stuff to its graphics, including special rendering such as lines, polygons, ellipses and so on. ReWind emulates such calls through the use of X11's renderer by using XPixmaps. With a DIBSection, the Win32 API allows both of these features to be used on a single image. This is currently supported by ReWind, but it can be slow at times and rather 'hacky'. This is achieved using the following method: o When a DIBSection is created, space is allocated for the application (where the application can directly write to). This is also an XImage. o Another XImage is created for 'conversions' (see depth conversion). o An XPixmap (which is a X Drawable) is created on the X Server. o The application-side data is memory protected to no access. Now, ReWind's X11 driver keeps track of which "image" is most up-to-date, it has 3 mods: gdimod, appmod and insync. (There is actually a 4th mod called 'auxmod' which is used for auxiliary tasks such as OpenGL). These mods represent different states, as follows: o gdimod means that the XPixmap has the most up-to-date version of the image, it was written to last. o appmod means that the application has the most up-to-date version, it has written the image data manually. o insync means that the both the images are up-to-date, they contain the same data. The application can then write into the memory which it is given direct access to, but when it tries to do so a segmentation fault is raised because the memory has been protected. This segmentation fault is caught by ReWind which it recognizes as an attempt to access the application data of a DIBSection. A "coercion" is now called on this DIBSection. If the DIBSection is in gdimod at the time of the segmentation fault, a copy is necessary before we allow the application to write to the DIBSection. The Pixmap is then fetched from X and placed into the XImage in the correct format. The Application is now free to write to the image data, the DIBSection is placed in appmod. A similar thing happens when a GDI painting function gets called, we ensure that the DIBSection is in gdimod (The Pixmap is up-to-date). X is then free to to its rendering. A Problem: Depth conversions and X Limitations: There are many other "nicer" ways that could, in theory, work. With some extensions X is able to render into a XImage, we could use Shared Memory Pixmaps or we could work on getting the upcoming on-the-fly X depth changing into XFree86 4.3. Unfortunately none of these are complete enough to work for our needs. One of the big things that many of them lack is palette support (8bit graphics). So, presently XPixmaps must be in the depth format that the users current X is running at. But the application only knows one way to draw to the DIBSection: The format it requested. This means we have to do depth conversions when we do our coercions from one format to another. This can be slow, particularly if we are constantly doing the conversions. One of the worst cases is when the application requested 8 bit paletted mode and X is running in 24b
Re: quartz.dll
Hidenori, I have sent you a private reply to the above address. Since it has the appearance of a temporary address that you might not check, I am replying here as well to let you know. If there is a better address for me to reach you at, please feel free to send it to me. The quick summary: I have an idea that may be able to provide you with protection against the liability that you believe exists. Thanks, -Gav Hidenori Takeshima wrote: > I'm original developer of quartz. > I don't want my quartz code to be restored. > > There seems to be many patented algorythms. > Many codecs like MPEG-1/2/4 are patented. > The ffmpeg library seems to use > many patented codes. > And the legal state of quartz interfaces is > unclear for me. > I can't accept any liability. > > Please add all codes in CVS explicitly: > The code has been removed since the > original author requests 'please > remove my quartz codes' explicitly. > The original author don't accept any liability. > > > __ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: quartz.dll
Hidenori, I have sent you a private reply to the above address. Since it has the appearance of a temporary address that you might not check, I am replying here as well to let you know. If there is a better address for me to reach you at, please feel free to sent it to me. The quick summary: I have an idea that may be able to provide you with protection against the liability that you believe exists. Thanks, -Gav Hidenori Takeshima wrote: > I'm original developer of quartz. > I don't want my quartz code to be restored. > > There seems to be many patented algorythms. > Many codecs like MPEG-1/2/4 are patented. > The ffmpeg library seems to use > many patented codes. > And the legal state of quartz interfaces is > unclear for me. > I can't accept any liability. > > Please add all codes in CVS explicitly: > The code has been removed since the > original author requests 'please > remove my quartz codes' explicitly. > The original author don't accept any liability. > > > __ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: Quartz DLL
Lionel Ulmer wrote: > On Fri, Aug 30, 2002 at 05:37:08PM -0500, Igor Izyumin wrote: > >>Is it in rewind (the LGPL tree?) The link goes to the AFPL tree. Is this >>code also in ReWind? > > Well, I looked at one of the file in the WineX tree pointed by the link and > the license for this particular file is LGPL. And once a file is LGPLed, it > cannot be moved back to APFL (AFAIK). > > So, well, even if it's not in ReWind I do not see what (except for respect > for Hidenori's wishes) would prevent us to merge it in WineHQ. Of course, to > do that, one would have to ask WineX people what files are under which > license (ie is the file license header 'correct' for the whole file to be > sure they did not mix APFL and LGPL code in one file). The WineX head branch hasn't quite had all the license and quartz updating as yet, but you can find the detailed list in the WineX LICENSE file for the winex-2-0-branch CVS branch: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/winex/wine/LICENSE?rev=1.3.2.2 I tried contacting Hidenori for several weeks before we included the quartz code in WineX 2.1, but without success. His email address no longer seems valid, and mail to the postmaster at his domain has gone unanswered. Google searches also turn up very little. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: ALSA driver
Ove Kaaven wrote: > On 19 Apr 2002, Marco Pietrobono wrote: > > >> I'm starting to work on a native ALSA driver for wine. Since I >>remember that Marcus was working (or was planning to work) an that one >>too, I would like to know if there is already something to work on or to >>contribute to, or if I need to start from scratch. > > You must be mistaken, Eric Pouech was working on the ALSA driver. This > driver is also pretty much complete, just bugfixes remain. Unfortunately, > it's currently in the cold slimy clutches (from the LGPL-Wine perspective) > of TransGaming staff, who might not want to part with it without getting > some of that glorious LGPL code in Wine relicensed in exchange... Actually, we have no official claim over the ALSA driver - we offered to sponsor Eric Poech's development, but he asked that we put it into another sponsorship instead. I am going to try to get the details of our proposals to trade / sponsor some code up next week. We have this DIB engine we've been working on for a bit, for example It is true though that TransGaming's David Hammerton 'has his clutches' on the code - he's been working on it with Eric in his spare time. That said, I just checked and while his hands are kind of cold, they didn't appear to be at all slimy. David said that he might try to check it into the ReWind tree this weekend. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: License change vote results
Jeremy White wrote: > > It's not clear to me that Dimi's reaction was unwarranted; Brett > is a complete outsider to Wine and he persists in > clogging our development mailing list with flames and insults; > I think Dimi and others have been remarkably patient, all > things considered. For my part, I have to agree with the above. Brett, I think that you've done far more harm than good with your constant need to have the last word. Please let us (the Wine community) figure this out on our own. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
TransGaming LGPL clarifications
"Dimitrie O. Paun" wrote: > > > AFAIK, Transgaming will have big problems with LGPL. It is Codeweavers that > > will still be viable. > > And why is that? In fact, Gav failed to even hint at why a LGPLed Wine > would invalidate TG's current business model. I had thought that I articulated our issues with the LGPL in my previous postings, but I'm happy to reiterate my concerns. Keep in mind that there is a distinction between our current business model, and the business we may do in the future. There are several things we're doing that we haven't talked about publicly yet. My LGPL concerns are: 1) We support copy protected CDs in our WineX binary releases. This support required changes at a fairly low level: the cdrom code, exception handling code, and the wineserver. We cannot release this code (at least as it stands now) due to concerns over the DCMA, etc. If the WineHQ core went LGPL, we would not be able to apply our copy-protection patches and release a binary-only package. More generally, this problem applies to anyone who wants to combine Wine code with any custom systems or interfaces that might be protected by NDA or other such legal restriction. 2) While much of our DirectX work is confined to the core DirectX DLLs, some of it also occurs in places like the X11drv - much of the code to deal with specific hardware extensions (like NVidia's Vertex Array Range capabilities) is there. Additionally, we still don't have complete DLL seperation, so it is not at all clear that all our work could be neatly isolated into non-LGPLed DLLs. 3) If the codebase had been LGPLed earlier we would not have been able to start TransGaming in the first place, since we would not be able to attract any end users to the street-performer-protocol model. The incentive of helping us afford to make the code free is a very powerful one, and is central to our busines. Why should end users contribute to us if we would just have to give the code away anyway? Furthermore, if we had had to LGPL our initial code, there would be nothing stopping large gaming companies from making use of our work without contributing to it's creation. As I've said before, having another company's code is *not* good enough reward for us: we need cash in order to pay people. Our developers can't eat electrons. 3) The LGPL would have prevented us from doing any of the work on DCOM. If we had known that we would have no way to recoup our costs, we could not have afforded to do the work. With the LGPL, the only way that we could have recouped costs would have been to pre-sell the code before it worked. IE: Only the consulting-shop model would be allowed. 4) Most importantly, the LGPL is a one way road. Once we start down that path, it will be next to impossible to go back. If the LGPL would have prevented any of the work that TransGaming has contributed up until now, who knows what other companies or models it will prevent from forming in the future? Additionally, I would like to remind people of the contributions that TransGaming has made to the project so far: o Since TransGaming was started, we have contributed close to 2Mb worth of patches to the public tree; that's around 5% of all patches to Wine in that period. Not bad, considering our size, I think. o We contributed a full restructuring of the DirectDraw code, nicely seperating it into the user and driver side, and making possible new innovations like the SDL driver that we posted earlier. We added implementations for newer 2D APIs that were previously unsupported. o We contributed a significant rewrite of the DirectSound code, adding in HEL support, amongst other things. o We contributed a great deal of code to speed up DIBSections and related 2D functions. We had been considering doing a product very similar to CodeWeavers' QuickTime crossover work, and tuned a fair bit of code to work better with QuickTime. CodeWeavers seems happy enough selling that code now. o As part our DCOM work, we did extensive bugfixing in the code for Typelibs, safearray, RPC, etc. That code was contributed back, and is used in other's commercial products. If the main tree goes LGPL, or if there is a significant LGPLed fork, we are going to need to seriously rethink how (or if) we make any further contributions. That said, I believe that my WineCorp suggestions address both my concerns as well as the issues raised by the LGPL camp. The WineCorp model would effectively be like the LGPL, but with additional options for different commercial opportunities. Most importantly, it would have the flexibility to address any future business models that have not yet been considered. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Wineconf attendance
Since various people have been saying "I'll go if you go", I just want to let people know that Ove and I will both be going to the Wineconf. Maybe I'll bring my fencing equipment and we can settle the licensing debate properly with a duel. 8-) http://www.fencing.net/pages/clubs/ccg/images/sn_ath.jpg -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Licensing response and an idea
Andriy Palamarchuk wrote: > [... skipped ...] > > o A new non-profit company is created: WineCorp > > o Developers contribute their work to WineCorp - > > possibly assigning > > copyright, or at least giving WineCorp the rights > > to do with the code whatever it pleases. > > o WineCorp distributes the code under an AFPL-like > > license - no commercial redistribution allowed. > [... skipped ...] > > You did not mention whether you want to have this > license only or to have Wine licensed also with some > open-source license? > > I think in this case even GPL can be a choice for the > second license. Under the WineCorp approach, the AFPL + an allowance for commercial redistribution if Wine code is returned is essentially equivalent to the LGPL. It's more flexible though, since it allows for the possibility of other unforseen ways in which commercial redistribution without immediate release of source would be possible. It would also be possible for the WineCorp to allow certain portions or all of the code to be dual-licensed under the LGPL and mixed with other GPL or LGPLed projects. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Licensing response and an idea
orms which might not be viable under the LGPL. o The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work. o New business models like TransGaming's, with conditional-future- release of code. While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back. I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code. I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about. Here's the quick and dirty version: o A new non-profit company is created: WineCorp o Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases. o WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed. o WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things: - Releases source modifications to WineCorp immediately. - Releases source modifications within a preset timeframe (maybe one year). - Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit). - Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development o For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL. o WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's. One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion. Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests. Food for though, anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Direct 3D 8.0 Wrapper for OpenGL Open Sourced
Damjan Lango wrote: > > Just found this on http://www.osnews.com/: > > Direct 3D 8.0 Wrapper for OpenGL Open Sourced > http://www.osnews.com/story.php?news_id=613 > > Not sure what is the license, but maybe it could > be incorporated to wine as an alternative to the > transgaming's version. Well, you're welcome to try, but their 'library' seems to consist mostly of stubs and Microsoft's own code. There is very very little there. The prospect is certainly not keeping me up at nights. 8-) It might be better to help find us more subscribers so that we can release our real, working code to the WineHQ tree. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Wine license change: it's about time!
While I do want to contribute further to this debate, I need some time to gather my thoughts. In the meantime though, I want to address Dimitrie's quote - and fundamental misunderstanding - of me below. "Dimitrie O. Paun" wrote: > A BSD license is a STRONG DETERANT for a business to contribute code > back. The reason for this is that they have no guarantee that another > business will not improve a little the code, and thus get a competitive > advantage. Or that other companies will not use that code on top of the > code they wrote but not released, and thus again, get that edge. This is a > fantastic _deterant_ for releasing code back. In fact, Gav validated > exactly this point when he tried to argue for the BSD license last time: > > > But there are companies out there who will benefit significantly > from commercial use of this code, and who can afford to sponsor a > portion of the development cost. Until such a sponsorship happens, > we cannot apply the WineHQ license to that code. > > In other words, they needed that code. They invested some money do get > it. They are happy with the results. Why not release the code? They have > what they needed in the first place? The reason is clear -- it cost them > to get there, they can not aford to bring everybody there for free. I can > 100% understand that. But if the code was under the LGPL, it would not > matter, because even if they brought everybody there, other companies > could not step ahead of them, since if they did, they themselves could > have used that code. > > In other words, TG could have kept Direct3D proprietary, released > everything else back under LGPL, and they could have _known_ they still > have the competitive edge in the D3D work! This is why the LGPL is in fact > an _incentive_ for such colaboration. Quite the opposite: It is not 'competitive advantage' that concerns us, or others using our code without contributing their own code. It is simply that we could not and cannot afford to do our development without monetary compensation. If the OLE DLLs had been LGPLed, we could not have been able to afford to do any DCOM work, since we would have had no prospect of getting paid for it. Under the LGPL, the only possible business model is this: a) Find someone who might need some piece of code b) Sell them on: "We can do this for you, and release it under the LGPL for $x dollars. We're really good at what we do, honest" c) Do the work, and hope to actually get paid. The current license, by contrast, allows many other alternate models that are worth trying. In the case of the DCOM code, there was something that we had a need for with our current subscriber base, but we could not afford to do the work just for that base, since it is not yet large enough. Instead, we have this business model: a) Do the work up front, proving that it works, covering a small portion of the cost from our current subscribers. b) Talk to potential sponsors who need the work c) If they agree on a price, release the code under the Wine license. The TransGaming subscription model is simply this writ large, trying to get the individual users to act collectively as sponsors of the work. The LGPL simply slams the door shut on that whole model, saying in effect "It's my way or the highway". At the same time, I believe that I understand the main concern of the LGPL proponents: the current license allows the possibility of benefiting from the project without any contribution. Where I differ from them is that someone else's code is not enough to keep my employees eating. What I need as a contribution is not code, but cash. Anyhow, I'm going to go and put my thinking cap on, and try to see if I can think of some arrangement that might work better for everyone. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: A new SDL back-end we've been toying with
David Elliott wrote: > > On 2002.01.28 02:12 Gavriel State wrote: > > There would be no appreciable differences. As I said, this was mostly > > something > > we were just toying with. > > Very interesting. I was considering making an RFB (the VNC protocol) > backend for Wine for about the same reason. That is that the only really > decent driver is X11 right now since ttydrv is fairly useless. > > Hmm, maybe I should actually do that. As an added bonus since VNC is just > basically a generic framebuffer it would allow a fairly easy port to > another generic framebuffer interface such as LinuxFB (or whatever the new > hot-shit FB project for Linux is these days). Well, the sdldrv is a long way from being capable of that kind of thing. 8-) The big thing that's missing is a real GDI renderer. It's great to have something that can kind-of do a bitblt, but if you want to have windows and menus and such on the screen, a real renderer is needed. Aside from BitBlit-ing, it would need to handle polygons, brushes, pens, clipping, and most painfully, text. It's possible that some of Huw's recent work might help there, but I'm not sure - I think that XRender actually requires X... Now, the interesting thing is this: Once we have a GDI renderer, we can eliminate a *huge* amount of DIBSection cruft from the X11 driver. Currently Wine goes through astounding manipulations to get X to draw things for us when we should be doing it ourselves. This is very slow, and affects more apps than you might think (ie: WordPerfect). We actually have a co-op student (Hi Jonathan!) who we've asked to look into this a bit. He's quite new to Wine, and has some other duties as well, but I'm sure that he would be interested in sharing the work. 8-) -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: A new SDL back-end we've been toying with
There would be no appreciable differences. As I said, this was mostly something we were just toying with. -Gav Hetz Ben Hamo wrote: > > Hï Gavriel, > > Could you provide 2 screenshots please - one with this SDL driver and the > same - without SDL please? > > Thanks, > Hetz > > On Sunday 27 January 2002 06:49, Gavriel State wrote: > > Hi everyone, > > > > We just put this together for some testing, and thought that someone might > > find it handy. I'm not submitting it to wine-patches, since we haven't > > tested it on the most recent winehq tree, but it should be pretty easy to > > integrate in. It's not 100% complete by any means, but it has both GDI > > bitmap and DDraw support. We can vouch that it runs some of the DDraw > > samples, but beyond that, who knows. > > > > That said, the SDL driver should be a useful alternative to the ttydrv > > for testing purposes. > > > > -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
A new SDL back-end we've been toying with
Hi everyone, We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows. That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED] sdldrv.tar.gz Description: GNU Zip compressed data
Re: Wine Tasklist
eric pouech wrote: > > > * Native Alsa support > >- Could it offer capabilities that OSS does not offer? > [snip] > >- Anti-rational: Alsa includes an OSS compatibilty mode that seems to > > work pretty well > ALSA is needed when you need proper full duplex capabilities > however, only ALSA 1.0 should be supported (0.5 and 0.9 shouldn't, > except > if 0.9 interface turns out to stay the one for 1.0) One of the most annoying problems we've seen with Alsa OSS emulation is that it doesn't properly support directly mmap-ing the sound buffer. It kind of claims to do it, but on most of the machines we've tried alsa on, actually doing the mmap fails. This means that to build a single Wine binary that supports doing dsound on most different hardware, we have to disable direct sound buffer access, and use the dsound HEL mode instead. This, in turn, results in either latency problems, or cracking, depending on how we tune dsound, even on OSS systems. And problems are magnified on ALSA cards, since the driver is doing yet another layer of conversion before sending the data out to the sound chip. The TransGaming subscribers have voted for us to do something to fix this. I'd like to put one of our people on it, but we can't spare them right now from their DX8 tasks. So: we are willing to sponsor the development of an ALSA back-end sound driver for Wine, if anyone is willing to work on it. If you're interested in doing the work, let me know and we can discuss details. > > * Winedbg g++ 3.0 support > >- The debugging format and the ABI changed in g++ 3.0 and winedbg > > does not support the new ABI. > >- This prevents debugging of C++ Winelib applications > >- This is especially troublesome for MFC Winelib applications Why would you want to use Winedbg for a Winelib application, instead of gdb? > some other items to look at: > * make the server a linux kernel module (has been discontinued) but > could > provide some performance enhancements We did some more examination of this question, and came up with some notes and code for doing a server-accellerator kernel module that would move some functionality into the kernel, but keep the current architecture mostly intact. If I recall, the architecture centered around the creation of a /proc like virtual file-system for managing NT kernel objects. Our own resources for continuing this effort directly are limited, but again, we would consider sponsoring further development along these lines: WineServer overhead is one of the nastier performance blocks for several games we've looked at. I'll try to see if we can put the notes and code we've done so far into better shape to be picked up by someone else. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Installshield 6 (inter-proc) patches
Alexandre Julliard wrote: > > Gavriel State <[EMAIL PROTECTED]> writes: > > > There are several factors to that equation, and I'm afraid we don't have > > a firm ETA yet. > > Well, this worries me. It sounds like you are planning to do the same > thing you did with your DirectX stuff: by making the code available on > your site, and promising to release it at some hypothetical future > date, you remove all incentive for other people to spend time > improving the main Wine, thus ensuring that it always lacks some > features. I don't like this at all. > > If you can't/don't want to release your code, I'd strongly suggest > that you reconsider your strategy of making it publicly available. If > it was only available to paying customers, there would at least be a > reason for other people to work on a free implementation. But if > everybody who needs some feature in Wine can simply download WineX > instead, no one will spend time re-implementing that feature. This is > beginning to seriously hurt the project, and we need to find a way to > address this issue. The DCOM issues had been ignored by other Wine developers for YEARS before we came along. It's not at all clear that our work there has discouraged anyone else from working in that area. To say that our work is preventing anyone from doing a free version of DCOM is completely incorrect. To the contrary: we have already contributed substantial amounts of this code to the public tree - thousands of lines, in fact. That can only help anyone with a sudden and unexpected interest in recreating our work. Now, it is our firm desire to see *all* of that code end up in the main version of Wine. The fact is, unfortunately, that we simply cannot afford to give everything away as soon as we write it. We only got a minimal implementation of the DCOM code working six weeks ago. We are not a rich company, with millions in VC funding to burn; this means that our DCOM work has to remain under the AFPL until we can find a sponsor willing to defray some of the tens of thousands of dollars it cost us to develop it. Furthermore, we are committed to writing quality, robust code. We don't think it's in anyone's best interest for the current version of the code, which is effectively limited to the requirements of InstallShield, to be used as the basis of future DCOM related work. We in the midsts of working on a much more flexible architecture which will permit more than just typelib based proxying. I don't really think this affects individual users at all. They can simply download and use the code from our website, or apply the necessary patch to WineHQ wine. They can even redistribute it all non-commercially should they wish. Without a doubt, we are committed to the Wine project and have already contributed a great deal of code to support it. However, to maintain the quality and integrity of the project, we stand by our decision of only contributing code when it makes sense to do so (in order to allow us to continue developing quality code) and when it reaches a certain minimal degree of quality. Publicly questioning our ethics is certainly not the right solution nor is it in the spirit of the project, especially given how much we have supported it to-date. We believe that we ARE doing the Wine user and developer community a service and propelling it further. The only people that our lack of haste in contributing code back really affects are organizations that want to make immediate commercial use of the code. These organizations include the one you work for, and its clients. If you want to see the DCOM code Wine-licensed soon, you need to talk to your boss and your clients, not me. At this point, I think it would be best if we were to take this discussion off-line so that we can determine a solution that works for everyone. Take care, -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Installshield 6 (inter-proc) patches
There are several factors to that equation, and I'm afraid we don't have a firm ETA yet. Sorry, -Gav "J.Brown (Ender/Amigo)" wrote: > > Any idea when Oves interprocess patches will be put into the main Wine CVS > tree? > > The code currently in WineX isn't really that ugly at all, and it is a > very important part of Wine to have working IS6 support. > > Regards,| Any significantly advanced technology is indistinguishable from > | a perl script. > Ender | > (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: UNC patch & parsing fstab/mtab
Alexandre Julliard wrote: > > Dan Kegel <[EMAIL PROTECTED]> writes: > > > Just how terrible is parsing /etc/mtab? It doesn't look like > > much code. I'd be happy to provide a nice OO wrapper object > > for it if that would make you happier. It would then no > > longer be an ugly hack. Would that satisfy you? Or are > > you fundamentally opposed to it for some other reason than > > code clarity? > > Code clarity is one thing (it should be probably using getmntent and > friends), performance is another (parsing /etc/mtab on each CreateFile > is *not* a good idea), but mainly I'm opposed to the concept of > configuring everything by hand except magically getting smb shares > through /etc/mtab, when they may not at all reflect what you want the > Windows application to see. It doesn't fit in the current > configuration philosophy. Now of course the config philosophy can be > changed, but it must remain coherent. I don't doubt that we don't want to be parsing /etc/mtab on each CreateFile, but I will put in a word for some modifications to the configuration philosophy when it comes to drive letters. One of the problems we've come across recently is this: for games that use copy protection, we need to have direct access to the device that a CD-ROM drive uses. For the moment, this relys on the user to manually configure their drive letters. From what we've seen, doing so is beyond the ken of many of our users. As such, we've put together a scheme for parsing /etc/fstab on startup (not mtab: the drive may not be mounted), and automatically adding drive letters for each iso9660 filesystem listed. The patch (to the WineX tree) is here: http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ We're happy to contribute this in our next outward merge if people think it's useful. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: UNC patch
Alexandre Julliard wrote: > > Dan Kegel <[EMAIL PROTECTED]> writes: > > > Just how terrible is parsing /etc/mtab? It doesn't look like > > much code. I'd be happy to provide a nice OO wrapper object > > for it if that would make you happier. It would then no > > longer be an ugly hack. Would that satisfy you? Or are > > you fundamentally opposed to it for some other reason than > > code clarity? > > Code clarity is one thing (it should be probably using getmntent and > friends), performance is another (parsing /etc/mtab on each CreateFile > is *not* a good idea), but mainly I'm opposed to the concept of > configuring everything by hand except magically getting smb shares > through /etc/mtab, when they may not at all reflect what you want the > Windows application to see. It doesn't fit in the current > configuration philosophy. Now of course the config philosophy can be > changed, but it must remain coherent. I don't doubt that we don't want to be parsing /etc/mtab on each CreateFile, but I will put in a word for some modifications to the configuration philosophy when it comes to drive letters. One of the problems we've come across recently is this: for games that use copy protection, we need to have direct access to the device that a CD-ROM drive uses. For the moment, this relys on the user to manually configure their drive letters. From what we've seen, doing so is beyond the ken of many of our users. As such, we've http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Improving DIB support for SHM
Doh! I guess we've been too lax about integrating some of our non D3D
work back into WineHQ. We did this in WineX some time ago, but with
a couple of differences:
1) We don't restrict using XShmGetImage to the whole-screen case
and
2) We save and restore the XImage mask fields around the call to
XShmGetImage, which seems to like to write over those fields
to no useful purpose.
IE:
/* We must save and restore the bmpImage's masks in order
* to preserve them across the call to XShmGetImage, which
* decides to eliminate them since it doesn't happen to know
* what the format of the image is supposed to be, even though
* we do. */
saveRed = bmpImage->red_mask;
saveBlue= bmpImage->blue_mask;
saveGreen = bmpImage->green_mask;
XShmGetImage( gdi_display, descr->drawable, bmpImage,
descr->xSrc, descr->ySrc, AllPlanes);
bmpImage->red_mask = saveRed;
bmpImage->blue_mask = saveBlue;
bmpImage->green_mask = saveGreen;
We'll probably get around to doing some merging back into WineHQ after
our next release.
-Gav
Jukka Heinonen wrote:
>
> The following patch halves the time it takes to move units
> from one square to another in Civilization 2. If SHM is supported,
> the patch uses XShmGetImage instead of XGetSubImage when filling
> the whole XImage (which is probably way too careful since SHM is
> much faster than the alternative...). Hopefully this
> version is paranoid enough to work with older XFree86 servers
> where XShmGetImage might change the underlying XImage format
> into XYPixmap.
>
> Changelog:
> Try to use XShmGetImage instead of XGetSubImage if SHM is supported.
> Do a sanity check before using XShmPutImage.
>
> Index: wine/graphics/x11drv/dib.c
> ===
> RCS file: /home/wine/wine/graphics/x11drv/dib.c,v
> retrieving revision 1.82
> diff -u -r1.82 dib.c
> --- wine/graphics/x11drv/dib.c 2001/11/05 23:52:18 1.82
> +++ wine/graphics/x11drv/dib.c 2001/11/21 12:39:42
> @@ -4473,7 +4473,7 @@
> descr->xSrc, descr->ySrc, descr->xDest, descr->yDest,
> descr->width, descr->height);
> #ifdef HAVE_LIBXXSHM
> -if (descr->useShm)
> +if (descr->useShm && descr->image)
> {
> XShmPutImage( gdi_display, descr->drawable, descr->gc, bmpImage,
>descr->xSrc, descr->ySrc, descr->xDest, descr->yDest,
> @@ -4519,9 +4519,26 @@
> TRACE("XGetSubImage(%ld,%d,%d,%d,%d,%ld,%d,%p,%d,%d)\n",
> descr->drawable, descr->xSrc, descr->ySrc, descr->width,
> lines, AllPlanes, ZPixmap, bmpImage, descr->xDest, descr->yDest);
> -XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc,
> - descr->width, lines, AllPlanes, ZPixmap,
> - bmpImage, descr->xDest, descr->yDest );
> +
> +#ifdef HAVE_LIBXXSHM
> +if (descr->useShm && descr->image &&
> +descr->xDest == 0 && descr->yDest == 0 &&
> +descr->width == bmpImage->width &&
> +lines == bmpImage->height &&
> +XShmPixmapFormat( gdi_display ) == ZPixmap)
> +{
> +XShmGetImage( gdi_display, descr->drawable, bmpImage,
> + descr->xSrc, descr->ySrc, AllPlanes );
> +if (bmpImage->format != ZPixmap)
> +ERR( "XShmGetImage changed image format!\n" );
> +}
> +else
> +#endif
> +{
> + XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc,
> + descr->width, lines, AllPlanes, ZPixmap,
> + bmpImage, descr->xDest, descr->yDest );
> +}
>
> TRACE("Dib: depth=%2d r=%lx g=%lx b=%lx\n",
>descr->infoBpp,descr->rMask,descr->gMask,descr->bMask);
>
> --
> Jukka Heinonen <http://www.iki.fi/jhei/>
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: InstallShield 6 - success
Dan Kegel wrote: > > Ove Kaaven wrote: > > > > Apart from the two patches I just submitted to wine-patches, a > > stdole32.tlb from real Windows, and the registry entries in > > winedefault.reg, you need my interprocess com hacks, which I've now put on > > WineHQ: http://www.winehq.com/~ovek/install.diff > > > > The installation progress bar doesn't seem to display for some reason > > (might be a repaint issue or something else related to Alexandre's latest > > work, or something completely different, don't know), but anyway, even if > > it doesn't tell you its progress, it actually successfully installs now! > > Huzzah! So where do we send the beer and pizza to thank you? :-) Well, in addition to sending pizza to Ove (I don't think he likes beer), you might consider telling all your friends to sign up for our subscription services. 8-) Ove's work has been part of the final push we're doing before going live on October 22nd. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Nasty Evil Memory Fragmentation fix
Alexandre Julliard wrote: > That's why we have multiple free lists. The code is using the Win95 > values now, but there is no reason we couldn't add a few larger values > in the HEAP_freeListSizes array, instead of creating a new mechanism. This still doesn't help us: as Ove points out, we still end up allocating from newly created free blocks even if old blocks would suit us better. Ove Kaaven wrote: > > A new allocator would definitely be a good thing. This one was done > > the way it is in order to use a compatible memory layout, but it turns > > out this is not necessary so we could scrap it. > > Well, after looking at some allocator algorithms, it seems to me there's > no reason to change neither the bin sizes nor the data structures. We just > have to change the free block selection algorithm - from my reading of the > code, right now it seems to always choose the *newest* (most recently > added) free block that's big enough. By changing it to always choose the > *oldest* free block instead, we'd already have a huge improvement. > (That's essentially the effect of Gav's patch, but only for big blocks, > but I suspect that could safely be done for *all* block sizes) Actually, we originally had it pushing all new free blocks (regardless of size) to the end. Our fear though was that doing that would cause slowdowns as it would lengthen the free-block search time. By doing it only for larger blocks, small block allocations should be faster. There are a variety of other issues that are important to consider with an allocator though: locality of reference (memory blocks allocated together are likely to be used together, and we should therefore try to allocate them near one another to reduce paging time); speedy allocation of small blocks; best-fit efficiency (ie: prefer to take a free block that's close to the size we're looking for rather than split a bigger block, etc. I've had a brief look at the code referenced by Adam Moss (found at http://g.oswego.edu/dl/html/malloc.html), and it looks like it would be a vast improvement over Wine's current Heap manager. It even has Windows code that uses VirtualAlloc to reserve actual memory. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Nasty Evil Memory Fragmentation fix
We just spent about 3 days tracking down a very subtle memory
fragmentation problem in an app we're working on. The problem:
App allocates lots of little blocks, then a few large blocks,
then lots of little blocks. Throughout this process, many
blocks would be freed from all over the heap. Repeat ad infinitum.
We ended up creating a new subheap every time one of these larger
blocks came along. The new space from the subheap then went to
the top of the freelist, so all the small allocations then filled
it up until the next large block allocation. IE: We never got a
chance to reuse freed blocks in older subheaps - at least not
very well.
This fix addresses the problem by pushing 'large' freed blocks to
the end of the free list, leaving 'small' blocks at the front, to
be found sooner. The size of 'large' vs 'small' is tunable.
Despite the workaround, we're still not too pleased with the current
heap allocator. It's quite slow, and still not as efficient as
it could be. It would probably be worth the effort to integrate
a new allocator - anyone know if there's a high-quality Wine-license-
compatible allocator out there?
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
--- heap.c Wed Sep 26 19:11:21 2001
+++ /home/gavriels/transgaming/wine/memory/heap.c Tue Oct 9 23:53:15 2001
@@ -59,6 +59,8 @@
#define QUIET 1 /* Suppress messages */
#define NOISY 0 /* Report all errors */
+#define FREE_BLOCK_INSERTION_THRESHOLD 4096
+
#define HEAP_NB_FREE_LISTS 4 /* Number of free lists */
/* Max size of the blocks on the free lists */
@@ -229,11 +231,11 @@
/***
- * HEAP_InsertFreeBlock
+ * HEAP_InsertFreeBlockAtFront
*
- * Insert a free block into the free list.
+ * Insert a free block into the front of the free list.
*/
-static void HEAP_InsertFreeBlock( HEAP *heap, ARENA_FREE *pArena )
+static void HEAP_InsertFreeBlockAtFront( HEAP *heap, ARENA_FREE *pArena )
{
FREE_LIST_ENTRY *pEntry = heap->freeList;
while (pEntry->size < pArena->size) pEntry++;
@@ -244,6 +246,31 @@
pEntry->arena.next = pArena;
}
+/***
+ * HEAP_InsertFreeBlockAtEnd
+ *
+ * Insert a free block into the end of the free list.
+ */
+static void HEAP_InsertFreeBlockAtEnd( HEAP *heap, ARENA_FREE *pArena )
+{
+FREE_LIST_ENTRY *pEntry = heap->freeList;
+
+/* Determine which free list contains blocks of the appropriate size. */
+while (pEntry->size < pArena->size) pEntry++;
+
+/* But we want to put this block on the end of said appropriate free list.
+ * So instead, find the list for the next size up, knowing that they are
+ * all connected. */
+if (++pEntry == heap->freeList+HEAP_NB_FREE_LISTS)
+pEntry = heap->freeList;
+
+pArena->size |= ARENA_FLAG_FREE;
+pArena->next = &pEntry->arena;
+pArena->prev = pEntry->arena.prev;
+
+pArena->next->prev = pArena;
+pArena->prev->next = pArena;
+}
/***
* HEAP_FindSubHeap
@@ -372,7 +399,11 @@
/* Last, insert the new block into the free list */
pFree->size = size - sizeof(*pFree);
-HEAP_InsertFreeBlock( subheap->heap, pFree );
+
+if ((pFree->size & ARENA_SIZE_MASK) > FREE_BLOCK_INSERTION_THRESHOLD)
+HEAP_InsertFreeBlockAtEnd( subheap->heap, pFree );
+else
+HEAP_InsertFreeBlockAtFront( subheap->heap, pFree );
}
Re: dlls/advapi32/crypt.c
Patrik Stridvall wrote: > > > On another note, however, I was re-reading the CryptoAPI > > thread and I don't > > think that Vladimir Vukicevic's questions were really > > answered from September > > 3rd. > > Can you be a little more specific? > > As far using GPL:ed libraries, that is a question that > really can't be properly answered without a real court > case. I think that Vladimir's suggestion that OpenSSL could be used as an alternative back end did not recieve sufficient attention. He wasn't sure that that was a good approach given the fact that it would arguably cause difficulty for people who wanted to run GPLed apps on top of Wine+OpenSSL. Since the number of GPLed Windows apps that do not have Linux counterparts is vanishingly small, the OpenSSL option seems to me more appropriate than using a libgcrypt back end. The OpenSSL license does not have the viral properties that the GPL has (it's an old-style BSD-type license, complete with the advertising clause), and therefore we should be able to weak-link Wine with libOpenSSL without any license contamination. Packagers who distribute libOpenSSL with Wine would then be responsible for meeting the OpenSSL license requirements for advertising and attribution. That said on the licensing side, I have no idea whether the OpenSSL code actually provides the functionality we need to implement the CryptoAPIs. Has anyone looked into this yet? The other alternative is to ask the libgcrypt team if they are willing to consider LGPL-ing their library so that we can use it. Has anyone asked? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: InstallShield and ole question...
Dan Kegel wrote: > > Jeremy White wrote: > > With COM, the other issue is that someone needs to look at the MS patents > > in this area. Mainsoft is telling people that they can't use Wine to > > port COM code, because Microsoft holds patents on some of the Vtable > > logic used in COM (and no, I don't have any more detail than that, > > this came to me third hand). > > I've also asked the FSF for help tracking this FUD down and refuting it. > > For the curious: > Snooping on his conversation using google.com, I see it's patent number > 5297284 he's worried about. > > >http://164.195.100.11/netacgi/nph-Parser?Sect2=PTO1&p=1&u=%2Fnetahtml%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F5297284 Hmmm - a few points to consider: 1) The patent seems very much oriented towards compilers for object oriented languages. I'm not sure how broadly that patent can be applied to code like ours that uses C to mimic the behaviour of a OO language. If there's an issue anywhere, I'd suspect that it's with g++, not Wine. 2) Even with g++, the work described in the patent that's actually new (ie: wasn't implemented in other C++ compilers as of April 1991) mostly seems to cover multiple inheritance related issues - adjusting the this pointer to the right part of an MI object's vtable, etc. Since a COM interface is nothing but a flat array of function pointers, I fail to see any relevance at all to the Wine side of things. 3) At least some of the g++ people seem to know something about this patent. There's a small thread here: http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html And there's some further discussion wrt the ia64 C++ abi here: http://reality.sgi.com/dehnert_engr/cxx/cxx-closed.html 4) G++ was around for quite some time prior to the patent application. You can download an archival copy of g++ 1.39.0, which predates the patent here: http://planetmirror.com/pub/gcc/old-releases/gcc-1/?N=D Anyhow, this is just from a very cursory analysis, but I'd say that the Mainsoft FUD is just that: FUD. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: TrueType font metrics for PostScript driver
Ian Pilcher wrote: > > In order to Unicode-enable the PostScript driver, it needs information > about about font encodings that isn't present in Adobe's AFM file > format (glyph names for character encodings greater than 256). For > Type 1 fonts with a standard encoding, the driver can use the encoding > in the Adobe Glyph List. (There's no other choice.) > > TrueType font designers, however, seem to regard glyph naming as an > opportunity to express their creativity. Besides, the information is > present in the TrueType font files, so the driver might as well use it. > > The driver could read this information directly from the font files, but > this would make Wine dependant on the FreeType libraries, and that > doesn't strike me as a wonderful idea. Instead, I have cobbled together What do you find objectionable about making wine work more closely with FreeType? >From the end user perspective, printing in Wine sucks right now due to the fact that you've got to manually make all these AFM files (or now your proposed TT equivalent), and then just kind of hope that the printer has the font available. If you're printing to a local inkjet or something and you have Ghostscript set up just so, it'll work, but it acts horribly if you're printing to a remote PS device. The only way that that problem can be solved is if we can automatically upload a T1 version of any given font to the PS file. We can only do that if we have access to the glyph outline data, which would require linking to something like FreeType in some way. When we were doing WPO2K for Linux at Corel, we used Bitstream's commercial font server for this purpose. It had an extended API that you could use to get at additional font characteristics and glyph outlines. It was a major pain to use, and it appears to be the top reason that end users have problems with the product (font server configuration is a nightmare for newbies). It's a shame that we didn't use FreeType instead. What I'd love to see happen with fonts in Wine is this: - shift the x11drv and wineps over to using the DDK Font Engine APIs that are currently just stubs. - Implement a FreeType font driver that links to Freetype and uses the FreeType APIs for all font metrics data as well as rasterization. - Implement an X11-dependant font driver in the Font Engine to rely on as a backup if FreeType isn't available. Using FreeType more directly would also allow Wine to do serious typography - the metrics data available from X is awful compared to what you can get directly from FreeType, and doing anything less gives you subtle variations in glyph placement that can completely mess up the decision of where to break a line. If we ever want to see people using Wine for serious graphics and page layout applications, we have no choice but to go for the FreeType approach. Now, all of that said, I don't actually have the time to help with any of this directly (unless someone wants to throw a contract my way, of course). All I can really do is cheer you on from the sidelines should you decide to go for it, and perhaps offer the occasional nugget of advice. Speaking of which, I do hope that you've seen the font & printing code in the Corel wine tree. It may not do you much immediate good, but I suspect that it could be a usefull reference point. Good luck! -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: InstallShield and ole question...
Mike Bond wrote: > > This getes me back to the other part of the question, is anyone currently > working on this? I know people at CodeWeavers supposedly were working on > getting the various mutations of InstallShield working, this error seems > to be pretty common across all InstallSheild v6 based installers I've seen. > I had also heard there was progress getting Alice install working at > TransGaming, is that InstallSheild v6 based? The fix we put into the TransGaming tree was from Andreas Mohr, and it fixed some problems related to previous versions of InstallSheild. We haven't made any progress on v6. We'd certainly like to see it get done, but our resources are somewhat limited at the moment, and we're concentrating on the DirectX work. Something that's interesting about the InstallShield objects is this: They seem to expose a fair amount of their interfaces through OLE Automation. I don't know for certain, but I have a recollection that some work was done to support Automation for WordPerfect. I can't remember whether that work was actually completed, or bypassed through the use of dde for scripting instead. If automation does work, then perhaps it's enough to simply run the InstallShield ikernel.exe and see if the user-side of the installer works through automation rather than requiring marshalling. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: OpenGL Visual Management ... continued.
[EMAIL PROTECTED] wrote: > > On Mon, 16 Apr 2001, Gavriel State wrote: > > > Can you double-check that you applied the patch correctly? I was experiencing > > exactly the behaviour you describe on my system in 8-bit mode, and the patch > > (included again, just in case) does a good job of fixing it on my machine. > > > > If this fix isn't the right one, I'm at a loss to explain what's going on. > > > > -Gav > > I did do a make clean in all the x11drv's and make again, I didn't want > to believe it either, and I looked at the source to make sure the > patch applied, but I will check it all again tomorow. I think there may > be some other fairly recent patch involved. I have been using 16 bpp > lately because 8bpp looks like 5bpp even with the setup_opengl_visual > comented out (I assumed that some other patch had changed that, but not > so) - so something else is wrong. Also, with setup_opengl_visual > active, I have critsect timeouts, and have a hard time to get the app to > start at all. I'm not sure about this last problem - unless it's somehow that the X driver for your card flakes out when asked for a double-buffered visual in 8-bit mode. I have however figured out the other problem. It's not that the code I added isn't working, it's that in desktop mode and non-managed mode, our colormap isn't being switched in. I thought that this could be because we're not setting the WM_COLORMAP_WINDOW property of our created windows, but a quick test of forcing it on in X11DRV_WND_CreateWindow was unable to fix the problem. Does anyone else have any idea what the problem might be there? Is it the window manager's responsability to switch in the Colormap? If so, I guess that we need to do it ourselves for non-managed mode, but that doesn't explain why it isn't working in desktop mode. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: OpenGL Visual Management ... continued.
[EMAIL PROTECTED] wrote: > > > AFAICT, it makes no difference. At 8 bpp, with the pointer on the wine > desktop, the entire X display is black & white. With the pointer off > the desktop, it still looks like it is run with a VGA16 server, well, > maybe VGA32, if there were such a thing. I might have missed a patch in > that flurry of msvcrt patches, but I don't think so. Maybe we barked up > the wrong tree? At 16 bpp, all is well. I tried > "CopyDefaultColors" = "256", but it didn't seem to make any difference. Can you double-check that you applied the patch correctly? I was experiencing exactly the behaviour you describe on my system in 8-bit mode, and the patch (included again, just in case) does a good job of fixing it on my machine. If this fix isn't the right one, I'm at a loss to explain what's going on. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED] Document
Re: OpenGL Visual Management ... continued.
[EMAIL PROTECTED] wrote: > > On Fri, 30 Mar 2001, Gavriel State wrote: > > > > Ok - this is what I'll explore further then. It may be a few more days > > before I can get to it though, since it looks like I'm going to be a daddy > > in a few hours. 8-) > > > > -Gav > > > Don't let me stop you. :-) I lived with local patches for about 3 > months while file handles were getting sorted out, I guess I can give > you a few days - hell, take a week if you need it. I just hope the > wine-users don't catch us. Ok - I just submitted a patch that takes care of this. Basically, since we're now using a private colormap even when doing 'shared' color, we have to copy the most important colors out of the default colormap to avoid colormap flashing. I chose 128, since it was the first power of 2 that let kdm's graduated-color title bars display properly. It's user-adjustable in the config file though ([x11drv]/CopyDefaultColors). As far as the other thing goes, everything turned out very well. 8-) [EMAIL PROTECTED] -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: OpenGL Visual Management ... continued.
[EMAIL PROTECTED] wrote: > > At a guess - the privately created ColorMaps need to take their initial colors > > from the Default Color Map? > > That sounds about right. Oh, at one point I reverted only wnd.c - no > difference - then palette.c. Colors seemed better with the pointer off > the window IIRC, but it still went to black and white withe the pointer > on the desktop. Ok - this is what I'll explore further then. It may be a few more days before I can get to it though, since it looks like I'm going to be a daddy in a few hours. 8-) -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: OpenGL Visual Management
[EMAIL PROTECTED] wrote: > > On Mon, 26 Mar 2001, Gavriel State wrote: > > > This patch fixes several issues with the way OpenGL manages visuals: > > Something is not right, I think. Ordinary apps (Dmitry's About.exe, > say) look as if they were using a vga16 server - unless the pointer is > over the desktop: then the entire X display is black and white. > Without a desktop with managed moving the pointer over the app's window > radically changes the palette for the whole screen, but not to black and > white. With neither managed nor desktop, the pointer has no effect on > the palette. Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I don't remember getting it when testing the 3dfx card I just loaned out to someone. Maybe I flubbed the 8-bit testing there... Can you tell me: - What video card you're using - What bit depth and resolution you've got - Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c - Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing). > No doubt I am not well set up for DGA: DGA shouldn't matter for this stuff at all. > I haven't really looked into it much yet...maybe you will see right off > what you or I have done wrong? At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map? I'll try to have a further look into it tomorrow. Sorry for any wasted time. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: WineX-Transgaming
"Gottfried F. Zojer" wrote: > > Hi, > > I m new to this list.So I hope that a little bit of feedback is coming > to my > first posting.Is somebody on this list who is working on DirectX APi s > into WINE.I heart from the WineX Api from Transgaming Tech. > It s hosted on SourgeForge.Unfortuntely this server must be a very slow > because it was impossible for me to get access to the CVS-Tree. > Thanks in advance If you have technical questions specific to the new DirectX code, you're best off directing them to the new WineX-devel list we've created on SourceForge. If you can't reach SourceForge at all, give it another go later in the day, it occasionally has load issues. If you are having persistant problems with SourceForge CVS, you can apply one of the earlier patches from the TransGaming website to the WineHQ tree. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
TransGaming & SourceForge
Hi everyone, Just wanted to let everyone know that the TransGaming DirectX development is now being hosted at SourceForge. You can get updates from our live CVS tree, discuss DirectX specific issues on the 'WineX-devel' mailing list, etc. The SourceForge project page is at: http://sourceforge.net/project/winex The CVSROOT for CVS is: :pserver:[EMAIL PROTECTED]:/cvsroot/winex We're doing WineHQ merge-ins every week or two, so things should stay relatively up to date. Currently, we're undertaking a rearchitecture of the Direct3D work, along the lines of the DDraw HAL work we've been contributing to the WineHQ tree. Basically, we're seperating the glX code into the x11drv for device independance. We're also redoing the front end interfaces to start supporting D3D APIs both older and newer than D3D 7. On the OpenGL front, we've done some work on the visual management code that solves some problems we were seeing where you couldn't get a double-buffered visual on some cards without using -desktop mode. I should be posting a patch for this back to wine-patches very soon. There are still some kinks to be worked out... -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: [PATCH] deferred trace
Alexandre Julliard wrote: > > gerard patel <[EMAIL PROTECTED]> writes: > > > 2) I don't see how I will get the window list I generate with > > WIN_WalkWindows if there is no change at all in Wine - I should > > have said that to cut in the trace size in not a goal per se, but a > > mean to make debugging easier. > > If I have to make a first run with full trace that I have to browse to see > > what is the meaning of the window handles appearing in the trace, I lose > > a lot of time. Having immediately a view of all existing windows is *very* > > handy. > > I don't doubt it's very useful for the specific problem you are > tracking; but it's hardly generic enough to be included in the main > tree. I disagree - many of the bugs I encounter can happen well into the run of a program. For example, debugging a dialog box in an app that comes up only after a specific set of occurances. Having the ability to turn on -debugmsg +all at will would make this kind of debugging much easier. Trying to do this with an external program controlling the debug trace is an excersize in futility due to the speed hit you get from -debugmsg +all. I remember wishing fondly for something like this when we were working on WordPerfect, but never having the time to do it myself. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Speeding up wineserver syncronization objects with shared memory
Alexandre Julliard wrote:
>
> > As far as I've observed (I've got Win2000 available), most Windows DLL's have
> > 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for
> > the sections. This means that the separate sections can't be mmap'd (or else
> > they'd lose their required relative relationships):
>
> Actually the file alignment doesn't need to be 4096, it needs to match
> the filesystem block size. On a FAT filesystem the block size is 512
> so Linux will happily mmap every section. On a 1k-block ext2 fs it
> will be able to mmap about 50% of them.
Looking at the kernel sources, it appears to be page-alignment, not
filesystem block size that mmap needs to match. Rereading old wine-devel
archives, it appears that the notion that the filesystem block size is
involved is either from a very old kernel, or a misreading of some kernel
comments. From linux/mm/mmap.c:
unsigned long do_mmap(struct file * file, unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags, unsigned long off)
.
.
.
/* Obtain the address to map to. we verify (or select) it and ensure
* that it represents a valid section of the address space.
*/
if (flags & MAP_FIXED) {
if (addr & ~PAGE_MASK)
return -EINVAL;
} else {
> > Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not
> > having such an option as far as I can recall), the fixup tables usually seem
> > to apply to just about every page in the code section.
>
> Only if the dll cannot be loaded at the preferred address, which
> shouldn't happen too often. I'm not saying your patch is useless, but
> I doubt the gain is as large as you seem to think.
It's worthwhile to point out that while many Win2K system DLLs may be
512-byte aligned, almost any app written in the past several years is
probably using 4k alignment, since that was made the default with MSVC 5.0.
It makes one wonders why MS would be using old compilers for the OS...
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: RESUBMIT: afm
Back in Febuary, Marcus Meissner wrote:
>
> Changelog:
> fixed one NULL ptr problem
> added loading of .afm files from several common locations
> (ghostscript, a2ps, enscript, (teTeX), X11)
>
> Index: afm.c
> ===
> RCS file: /home/wine/wine/dlls/wineps/afm.c,v
> retrieving revision 1.4
> diff -u -r1.4 afm.c
> --- afm.c 2001/01/02 20:30:16 1.4
> +++ afm.c 2001/02/03 18:50:42
> BOOL PSDRV_GetFontMetrics(void)
> {
> int idx = 0;
> char key[256];
> char value[256];
> +char *path;
> +DIR *dir;
> +
> +/* some packages with afm files in that directory */
> +PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/");
> +PSDRV_ReadAFMDir("/usr/share/a2ps/afm/");
> +PSDRV_ReadAFMDir("/usr/share/enscript/");
> +PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/");
We just did an integration with WineHQ, and this code has started to grate on me
(mostly because of the fact that the AFM parser spits out a bunch of error messages
while trying to parse my AFM files.
Rather than hardcoding the paths into the code, could we do this instead:
while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value,
sizeof(value)))
PSDRV_ReadAFMDir(value);
This has the added benefit of allowing the user to specify only those AFM directories
that their rasterizer knows about too. With the above, I get a whole bunch of printer
fonts listed as available in wine that I can't actually print if Ghostscript isn't
configured to find the font files.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: Speeding up wineserver synchronization objects with shared memory
Ove Kaaven wrote: > > On Sat, 24 Feb 2001, Robert O'Callahan wrote: > > > Ove Kaaven wrote: > > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > > Then on some other thread in the same address space > > > > that serves wineserver requests: > > > > > > There's no such thread, and will never be such a thread (having the > > > wineserver calling into client threads is an inherently unstable > > > design). > > > > The wineserver need not depend on the client thread responding to its > > (asynchronous) messages. In this case, if the client ignores the > > messages, you get the same effect as if it never releases its mutex, > > which is not a new failure mode. > > Sure it is, if the process isn't holding the mutex. Your design lets a > process own the mutex without holding it. So if a process acquires it, > then releases it, does something else for 10 minutes and then hangs, and > some other process decides it should grab the mutex, then it should be > allowed to do so, since the original process isn't holding it. But it > can't... Rather than have a dedicated thread to maintain any such communication back and forth with the server, why not simply use a signal to the first thread in the process. The signal should execute regardless of whether or not the thread is hung, and if the mutex is 'owned' by the process, but not currently 'held', the signal handler releases the mutex, and marks it as no longer owned. Even without that approach though, I don't think that the new failure mode is really likely to be that big a deal. If process A owns a mutex that process B wants, they quite likely have some functional interdependance which would be disrupted as much by any generic hang in process A as by a hang followed by a failure to release the mutex. And besides, once the user kills the hung process, the server should be able to reclaim the shared mutex object anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Speeding up wineserver syncronization objects with shared memory
Alexandre Julliard wrote: > > Gavriel State <[EMAIL PROTECTED]> writes: > > > After some more thinking, Ove and I have come up with a mechanism that should >eliminate > > most of the wineserver overhead for mutexes and semaphores, without the need to >resort > > to a kernel module. We're probably going to give this a try over the next few >days, so > > any feedback will be very much appreciated. > > I don't see how you are going to make this work reliably. A basic > design principle of the server is that no matter what a client process > does, it cannot break either the server or other clients; given the > number of bugs Windows apps contain, I feel this is very important. Definitely a drawback, I agree. But the shared memory area could be relatively high in the address space, so that a stray pointer is much more likely to run into unmapped memory and segfault before overwriting crucial data. The only way we're going to be able to get both speed and safety though is to have some kernel support. While that's beyond the scope of what I'd like to accomplish in the short term, I think that it's something worth thinking about more. While the solution proposed by David Howells may be overkill, I'm not sure that simply changing the communication mechanism as you suggested (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - we'll still have the context switch overhead. > As soon as you introduce a shared memory area, you need the > collaboration of all clients to ensure the stability of the whole > system, since any client can corrupt system data structures. This is > very bad. Also since the server is single-threaded its data structures > don't need to be protected; but as soon as you manipulate them from > multiple threads you need locking mechanisms, which will probably cost > a lot in performance too. At least in the case of mutexes, I believe that all we need to do is make sure that the count field is always modified through interlocked increment/decrement/etc including the wineserver. Here's some slightly modified pseudocode: Client: ReleaseMutex: Do everything that the server do_release used to do, except wake_up InterlockedDecrement(&count) Check if there were other threads waiting, and call the server to wake them. WaitForSingleObject: last = InterlockedCompareExchange(&count,bignum,0) if count == bignum we have the lock count = last+1 do everything the server mutex_satisfied does return WAIT_OBJECT_0 else if we're the mutex owner count++ return WAIT_OBJECT_0 else call wineserver's WaitForSingleObject Server: mutex_signalled: last = InterlockedCompareExchange(&count,bignum,0) if count == bignum || we're the mutex owner we have the lock count = last+1 mutex_satisfied: Same as before, but don't change the count check_wait: Same as before, but if we're checking multiple objects and one fails, we need to reset the count for any mutex objects that we signalled successfully. Definitely more complicated than before, but if we're careful, the count value can itself serve as the locking mechanism. The only case I can see where there's a potential issue is where a process releases the mutex lock, calls the server to wake up any waiting threads, and before the server signals the waiting threads, a third thread grabs the mutex. While this isn't ideal, it gets resolved when the third thread releases and tells the server to wake up other processes. This solution is probably only worthwhile as a short-term hack that we'll try in our tree. While I think it ought to work for the specific things that we're trying to accomplish immediately, it's probably too dangerous to put into the WineHQ tree. If there's interest in moving forward on better solutions to the server overhead problem, we're certainly willing to help with those. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Speeding up wineserver syncronization objects with shared memory
Hi everyone, We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. After some more thinking, Ove and I have come up with a mechanism that should eliminate most of the wineserver overhead for mutexes and semaphores, without the need to resort to a kernel module. We're probably going to give this a try over the next few days, so any feedback will be very much appreciated. Here's what we've been discussing in private email: Ove writes: > Gav writes: > > > Alternatively, I wonder if there's some way to speed up synchronization stuff > > through the use of some kind of shared memory area that all wine processes know > > about. The shared memory area could be used to do mutexes with atomic test-and- > > set operations. > > Maybe. But we probably don't want extensive busy waits, so we'd need to > call the wineserver when we need to wait. And the wineserver isn't really > designed to do bus-locked atomic access to such shared areas itself. But > perhaps with some client cooperation... in win32, a mutex is just a > different (and slower) kind of a critical section, anyway (but since it's > handle-based it can work across address spaces). > > If each mutex had a wcount field shared among all clients, we could do... > > ReleaseMutex: > wc = InterlockedDecrement(&wcount) > if wc > 0 > call wineserver's ReleaseMutex > > WaitForSingleObject: > wc = InterlockedIncrement(&wcount) > if wc < 0 > return WAIT_OBJECT_0 > call wineserver's WaitForSingleObject > > which would at least do something about the > ReleaseMutex/WaitForSingleObject pairs in the same thread... That's exactly the kind of thing I was thinking about. We can probably do the same for the CriticalSection semaphores as well. I don't think that we can do anything to speed up Events though. So the next question is: what's the best way to manage the shared area for each mutex/semaphore? We could just expose the wineserver handle table directly in the shared memory area, expanding the handle_entry struct in the server with a DWORD to server as the count field. Theoretically it brings up security concerns, but I don't think that we care that much at this point. Thoughts, anyone? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Header file legal issues (was Re: process.h patch)
Patrik Stridvall wrote: > > > One fly in the legal ointment is that while the headers may not be > > copyrighable, the shrinkwrap license may still be legal as a contract. > > There's a case where a court suggested that someone who buys a copy > > of a product that contains a shrinkwrap license agreement and unwraps > > it is legally bound to follow it, while the person who later finds the > > unwrapped CD 'on the street' with no such license is allowed to copy > > the portions that are unprotected by copyright. > > If that is so, wouldn't it mean that if you have a pirated copy of the > headers you can legally copy and distribute parts that are unprotected by copyright. > :-) According to the analysis I've read on the case, that's exactly right: http://cyber.law.harvard.edu/property/alternative/minassian.html -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Header file legal issues (was Re: process.h patch)
David Elliott wrote: > Part of the reason for rewriting the include files was also for licensing. If we > rewrite the header files ourselves then it's pretty much guaranteed that they can > be licensed exactly the same as Wine. If we "borrow" them then who knows. Most > Windows compilers I have seen have some sort of license on what you can do with > their header files that might not make them fit for inclusion into Wine. > > An idea that just popped into my head is maybe seeing if we can get a windows > compiler maker (e.g. Borland) to donate a full set of headers under the Wine > license. However they may have licensed them with certain terms and be unable to > do that. While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable. I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written. Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html The court in that case said: Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement. Since Wine absolutely requires the specific header file layout, strucutre and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright. In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable. One fly in the legal ointment is that while the headers may not be copyrighable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. It's unclear where the anti-trust issue fits in there. Food for thought, anyhow... -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Fix to OpenGL for BadMatch issue with Alice
Hi Lionel,
I recently remembered that I hadn't mentioned the below patch to you. This is
something that we put in the last TG patch to fix an issue with Alice, but I'm not
sure if the problem in question is the fault of the Wine OpenGL code or an issue
with NVidia's OpenGL driver (I haven't really tried it on other drivers yet).
Alice creates a rendering window, then walks through the pixel formats for that
window's DC using DescribePixelFormat. The current implementation of
DescribePixelFormat
simply creates a new visual for each pixel format by calling glXChooseVisual.
Under the NVidia libGL, at least, this creates a new visual even if there's already
a visual that matches the requested parameters.
Once we try to create a wgl context, the previous implementation was picking one
of the newly created visuals, and initializing the glX context with that. An
instant later, we get an X BadMatch error, since the rendering window that Alice
is using was created with the default X11DRV visual, not the visual that was
created by DescribePixelFormat.
The patch below is a simple fix to just always use the X11DRV visual when creating
contexts. Ideally we would somehow recreate the X11DRV window with the new visual,
but I suspect that will have to wait for significant restructuring of the X11DRV.
I didn't notice until later that you'd done a similar hack in X11DRV_ChoosePixelFormat,
forcing the visual there to be the default. We could do the same thing for
X11DRV_DescribePixelFormat as well, or we could simply drop most of the visual
management code in graphics/x11drv/opengl.c and use my patch below. What's
your preference?
-Gav
Index: wine/dlls/opengl32/wgl.c
diff -u wine/dlls/opengl32/wgl.c:1.1.1.3 wine/dlls/opengl32/wgl.c:1.3
--- wine/dlls/opengl32/wgl.c:1.1.1.3Tue Jan 23 12:12:23 2001
+++ wine/dlls/opengl32/wgl.cTue Jan 23 12:23:42 2001
@@ -78,6 +78,8 @@
X11DRV_PDEVICE *physDev;
XVisualInfo *vis;
Wine_GLContext *ret;
+ int num;
+ XVisualInfo template;
TRACE("(%08x)\n", hdc);
@@ -88,8 +90,9 @@
physDev = (X11DRV_PDEVICE *)dc->physDev;
- /* First, get the visual for the choosen pixel format */
- vis = physDev->visuals[physDev->current_pf - 1];
+ /* First, get the visual in use by the X11DRV */
+ template.visualid = XVisualIDFromVisual(X11DRV_GetVisual());
+ vis = XGetVisualInfo(display, VisualIDMask, &template, &num);
if (vis == NULL) {
ERR("NULL visual !!!\n");
@@ -299,7 +302,7 @@
return ret->func;
} else {
- ERR("Extension defined in the OpenGL library but NOT in opengl_ext.c... Please
report ([EMAIL PROTECTED]) !\n");
+ ERR("Extension %s defined in the OpenGL library but NOT in opengl_ext.c...
+Please report ([EMAIL PROTECTED]) !\n", lpszProc);
return NULL;
}
}
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: Small DDraw problem
Lionel Ulmer wrote:
> It stopped just after doing a SetCooperativeLevel. After some checkings, the
> error came from there (file dlls/ddraw/ddraw/main.c) :
>
> HRESULT WINAPI
> Main_DirectDraw_SetCooperativeLevel(LPDIRECTDRAW7 iface, HWND hwnd, DWORD cooplevel)
> {
> ()
> if ((This->cooperative_level & DDSCL_EXCLUSIVE) &&
> (cooplevel & DDSCL_EXCLUSIVE))
> return DDERR_EXCLUSIVEMODEALREADYSET;
> ()
> }
> I wonder if this test is really needed ? My interpretation of the
> 'DDERR_EXCLUSIVEMODEALREADYSET' error was that ANOTHER application already
> used this flag, not that it was already set for the current application.
>
> Anyway, removing this test fixed Grim Fandango. It now starts fine, except
> for some palette problems.
>
> If you agree, I will submit a patch that removes this test :-)
I think you're right - I have a recollection of having removed this myself in a
local tree that I accidently deleted at some point. I'd say it's good for a
check-in.
> PS: I found out that Grim Fandango eats up my X auto repeat (I need to do a
> 'xset r on' after)... I thought that this was removed in recent Wine
> versions ?
No idea on this - Ove?
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: Current Directory Strangely Affects Behaviour of Applications
Alan Chandler wrote: > If I cd to the directory in which the game is installed (ie > ~/win/sierra/gpl) and then run > > wine gpl.exe > > The program starts and fills the whole of my screen with a single > black window. It sits there until I move the mouse, at which time it > exits. > > I have just discovered that if I cd to the root of my c: drive (ie > ~/win) and then run > > wine c:\\sierra\\gpl\\gpl.exe > > The program starts and I get a 640x480 window with the correct startup > screen (I have "Desktop" = "640x480" in my config file). It is NOT > managed (even though I have "Managed" = "Y" in my config file). > However the program appears to partially work - in that > > a) The program responds to the mouse when I click on the correct > parts of the screen, > > b) It runs a race with computer AI cars when I tell it too. > > Can anyone suggest why this subtle change might exist? I can't think of *why* this is happening, but I can confirm that we've seen this with a few other programs, including 3DMark2000. I don't believe that it's an issue particular to the TG patch, but I don't know of any examples of this happening with, say, a pure OpenGL game that doesn't require the TG patch. As far as the managed issue goes, when DirectDraw creates the full-screen window, it doesn't use tha managed flag, since there are some DirectInput related issues that cause problems unless the visible top-left of the full-screen window is at the top-left of the real screen. When you've got support for XVidMode, it shouldn't matter, since it should you into the appropriate mode automatically. You can try turning off the OWN_WINDOW #define in dlls/ddraw/dsurface/user.c - doing that will cause the DDraw cooperative window to be used directly for full-screen access, as opposed to the window DDraw creates itself. This is known to cause issues with some apps, and looks bad with XVidMode since you see the window manager border around the top left of the screen and the bottom-right is chopped off somewhat. > [As an aside, the colours seem to be the negative of what they should > be - but it could just be a completely wrong pallette, the program > should respond to the keyboard, but all keys affect the underlying > console window in which the game was started, and there is a > multiplayer option where it should (at least) detect that I have a > TCP/IP connection, but doesn't - can anyone say, are these known > limitations of the transgaming patch?] DDraw doesn't deal well with 8-bit mode and palettes right now, so that could be one explanation for the negative colors. As for the keyboard input, there are some subtle issues with the OWN_WINDOW stuff now that may be causing you problems. Again, try turning it off in the dsurface/user.c code. > Lastly, is the transgaming patch likely to be folded into the up to > date CVS versions of wine anytime soon. The D3D code won't be submitted until we have the subscriber levels we need to keep the project viable - but we're not comfortable enough with the current code to start taking anyone's money yet. Most of the rest of our work is already in WineHQ CVS. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: psdrv: map Courier New to Courier
Ian Pilcher wrote: > > This may be a stupid question, but where is the Corel Wine tree? It's at http://opensource.corel.com It hasn't been updated in quite a while, and the last import from WineHQ was back in December '99, I believe. In addition to the font/printing work, there may still be a few other outstanding fixes that haven't made it into the Wine tree - but the only way to tell is probably going to be manual inspection of the diffs. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
An icky inter-thread messaging deadlock
We've run into a bit of a nasty issue with the DDraw OWN_WINDOW code. This code exists to create a fake 'full screen' window for DDraw apps that ask for exclusive full-screen control. The window is created in dlls/ddraw/dsurface/user.c. It gets created in the DDraw update thread that is used to periodically refresh that window. As the thread starts, it creates the window and uses SetWindowPos to position it and show it. We have to create the window in the update thread, since there's no guarantee that the thread that puts DDraw into full-screen mode has a message loop. The problem arises here: in the call to SetWindowPos, we end up calling EVENT_Synchronize, which tries to send a focus-change message to a window in the main thread. The inter-thread SendMessage in the update thread then blocks, waiting for a reply. In the meantime, the main thread goes about it's merry way, and in the case below, tries to initialize Direct3D. For various reasons, this also requires us to do a SetWindowPos call on the full-screen window. Problem is, that the update thread is holding the SysLevel lock, but it can't release it until the main thread processes the focus-out message. A trace is included below We're at a bit of a loss for coming up with a reasonable solution here. We could peek for messages in the main thread immediately after creating the update thread, but this seems not quite right. Oddly enough, putting a sleep(1) immediately after creating the update thread allows the main thread to get past the deadlock and into 3d rendering (which doesn't actually require the update thread), but the update thread still sits there waiting for the focus message to be processed for some reason. Suggestions anyone? Update Thread #0 0x402df634 in () #1 0x400f3b74 in () #2 0x400bf187 in wine_server_call (req=REQ_SELECT) at client.c:243 #3 0x400c3ac4 in WaitForMultipleObjectsEx (count=1, handles=0x49f96b60, wait_all=0, timeout=4294967295, alertable=0) at ../include/server.h:1622 #4 0x400c3906 in WaitForSingleObject (handle=1414155695, timeout=4294967295) at synchro.c:110 #5 0x40708c47 in QUEUE_WaitBits (bits=32768, timeout=4294967295) at queue.c:729 #6 0x406fc0d5 in MSG_SendMessageInterThread (hDestQueue=583, hwnd=432, msg=31, wParam=0, lParam=0, timeout=4294967295, flags=4096, pRes=0x49f96c2c) at message.c:888 #7 0x406fd761 in MSG_SendMessage (hwnd=432, msg=31, wParam=0, lParam=0, timeout=4294967295, flags=4096, pRes=0x49f96c2c) at message.c:1795 #8 0x406fd8a3 in SendMessageA (hwnd=432, msg=31, wParam=0, lParam=0) at message.c:1845 #9 0x407ba02a in EVENT_FocusOut (hWnd=432, event=0x49f96d58) at event.c:851 #10 0x407b95c9 in EVENT_ProcessEvent (event=0x49f96d58) at event.c:413 #11 0x407b8f4a in EVENT_ProcessAllEvents (arg=0) at event.c:200 #12 0x407b8fa2 in X11DRV_Synchronize () at event.c:214 #13 0x406f2c5e in EVENT_Synchronize () at event.c:23 #14 0x40719bc0 in SetWindowPos (hwnd=792, hwndInsertAfter=0, x=0, y=0, cx=0, cy=0, flags=9563) at winpos.c:2943 #15 0x407772da in User_create_own_window (This=0x40362004) at dsurface/user.c:320 #16 0x40777370 in User_update_thread (arg=0x40362004) at dsurface/user.c:352 #17 0x400c4a90 in THREAD_Start () at thread.c:276 #18 0x400c3cbe in SYSDEPS_StartThread (teb=0x49fa7000) at sysdeps.c:134 === Main Thread (gdb) bt #0 0x402df634 in () #1 0x400f3b74 in () #2 0x400bf187 in wine_server_call (req=REQ_SELECT) at client.c:243 #3 0x400c3ac4 in WaitForMultipleObjectsEx (count=1, handles=0x40564a14, wait_all=0, timeout=4294967295, alertable=0) at ../include/server.h:1622 #4 0x400c3906 in WaitForSingleObject (handle=84, timeout=4294967295) at synchro.c:110 #5 0x40058b72 in RtlpWaitForCriticalSection (crit=0x40745928) at critsection.c:190 #6 0x40058d07 in RtlEnterCriticalSection (crit=0x40745928) at critsection.c:240 #7 0x400c4138 in _EnterSysLevel (lock=0x40745928) at syslevel.c:77 #8 0x40710d0c in WIN_LockWnds () at win.c:55 #9 0x40710df8 in WIN_FindWndPtr (hwnd=640) at win.c:108 #10 0x407193be in SetWindowPos (hwnd=640, hwndInsertAfter=0, x=0, y=0, cx=0, cy=0, flags=9499) at winpos.c:2625 #11 0x407771aa in get_display_window (This=0x403606d8, pt=0x40564bf4) at dsurface/user.c:260 #12 0x40777263 in User_DirectDrawSurface_get_display_window (This=0x403606d8) at dsurface/user.c:301 #13 0x4075d54b in common_inst_OpenGL (rguid=0x1014c4c, surface=0x4036095c, device=0x40360ab8, d3d=0x40363da0) at d3ddevice/mesa.c:667 #14 0x4075df35 in d3d7inst_OpenGL (rguid=0x1014c4c, surface=0x4036095c, device=0x49800c7c, d3d=0x40363da0, vtable=0x40786500) at d3ddevice/mesa.c:966 #15 0x4076c518 in MESA_IDirect3D7Impl_CreateDevice (iface=0x40363da0, rguid=0x1014c4c, surface=0x4036095c, device=0x49800c7c)
Re: QUEUE_WaitBits race condition
Ulrich Weigand wrote: > > Ove, could you try whether this solves your deadlock? > > Bye, > Ulrich > > ChangeLog: > > * include/queue.h windows/queue.c windows/message.c > Protect queue->wakeBits/changeBits/wakeBits by critical section. Any reason this hasn't been checked into CVS yet? It seems to solve that deadlock issue, according to Ove. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Reenable DXGrab
Ove Kaaven wrote:
>
> I've looked at the DDK, and it seems that whoever designed DirectDraw/3D
> weren't the same guys that designed DirectSound. There isn't exactly a COM
> interface, rather the HAL interface is a range of C structures and
> callbacks (although GUIDs and vtables seem to be referenced here and
> there), e.g.
>
> typedef struct _DDHAL_DDCALLBACKS
> {
> DWORDdwSize;
> DWORDdwFlags;
> LPDDHAL_DESTROYDRIVERDestroyDriver;
> LPDDHAL_CREATESURFACECreateSurface;
> LPDDHAL_SETCOLORKEY SetColorKey;
> LPDDHAL_SETMODE SetMode;
> LPDDHAL_WAITFORVERTICALBLANK WaitForVerticalBlank;
> LPDDHAL_CANCREATESURFACE CanCreateSurface;
> LPDDHAL_CREATEPALETTECreatePalette;
> LPDDHAL_GETSCANLINE GetScanLine;
> // *** New fields for DX2 *** //
> LPDDHAL_SETEXCLUSIVEMODE SetExclusiveMode;
> LPDDHAL_FLIPTOGDISURFACE FlipToGDISurface;
> } DDHAL_DDCALLBACKS;
Well, the SetMode callback could be used for XVidMode/DGA support,
if we can retrieve the cooperative window from the DDraw object
it gets passed. We might also be able to do DXGrab this way as
well, but that raises the issue that in Windows, the DD driver
HAL interface above is intended for video use only, not input
use. I'm not quite sure where it's appropriate for us to make
a connection between video and input related stuff. We certainly
*could* have the x11driver ddraw HAL make the call to grab the
mouse, but I don't know if this is the cleanest way to do things.
None of the DDK interfaces that I've seen seem to lend themselves
to the task of managing our glX context needs. They have
'context' APIs, but they're on a per D3D Object level, which I don't
think meshes well with glX. Also, they don't seem expose an API to
set the context.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
Re: Reenable DXGrab
Ove Kaaven wrote: > > > > I've been thinking about going about all this in a different > > > way. Instead > > > of loading up dlls/ddraw with driver-dependent code, perhaps we should > > > consider driver separation not only in dsound (like it's done > > > now, with > > > IDsDriver in the wineoss driver), and like I want to do with dinput > > > (IDiDriver in winmm's joystick driver etc), but also in ddraw? > > > > > > So the x11drv (and any future graphics drivers) would export a > > > IDdDriver-or-whatever-it's-called COM interface, that dlls/ddraw could > > > then build upon, just like in windoze. All the DGA, DXGrab, > > > and GLX code > > > would then have to be moved into the x11drv, obviously, so > > > it'd be a lot > > > of work, but it'd certainly give us some advantages as well... When I read Alexandre's comments on the USER issue, I was thinking about suggesting this as a potential solution. Then I thought of all the work that would be involved and decided not to bring it up. On further reflection, it does sound like this is the Right Thing(tm) to do. After all, Windows' display and input drivers have DirectX hooks in them, so why shouldn't Wine's? With this kind of restructuring, we'll want to make the driver API as independant of X as possible. This seems easy for the DXGrab and OpenGL stuff, but I don't quite see how we'll handle XVidMode and DGA2 in a clean way. We can simply expose driver API that allows DDraw to make driver calls that are equivalent to the X calls is uses now, but I don't think that would buy us much over what we have now. I'm happy to sign us up to do this kind of restructuring, but there are some other things that are higher on our priority list at the moment. It may take us a few weeks to get around to this. In the meantime, on the DXGrab front, given that the previous DDraw implementation used WIN_FindWndPtr for this, can we leave it in for now until the restructuring happens? Some 2D games suck a fair bit without this... -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Reenable DXGrab
Alexandre Julliard wrote: > > Gavriel State <[EMAIL PROTECTED]> writes: > > > This option was accidently removed with the previous ddraw patch. > > > > This patch reenables it when using the XVidMode driver. > > Please avoid using WIN_FindWndPtr() in ddraw, it is an internal USER > function. Hmm - I'm not sure that I see any simple way around using WIN_FindWndPtr() for this. In addition to the DXGrab code, we also need to get at the drawable to set up a glX context for 3D. How else can we get at the underlying X drawable? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Programms that error with transmeta patches..
This should be fixed in the DDraw-only patch Ove posted to wine-patches today. It'll be a couple of days before we put out a new AFPLed D3D patch though. -Gav MK wrote: > > MK wrote: > > > > Hi > > using the recommeded build of 12/22 and transmeta patches i get the > > following errors: > > fixme:ddraw:User_DirectDraw_GetCaps unsupported structure versions: > > 316/316 vs 380 > > when running motoracer 1 > > > > and i get a ScreenStack :: build(): BitBlt message > > hen i try to run StarCraft > > > > Thanks > > Mike > I mean transgaming patches...i just drank too much when typing that > message > > MK -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Transgaming patch compilation (update) and Baldurs Gate 2 Success
"Adam D. Moss" wrote: > trace:ddraw:User_DirectDraw_GetCaps (0x40392810)->(0x405868a4,0x40586a10) > fixme:ddraw:User_DirectDraw_GetCaps unsupported structure versions: 364/364 vs 380 Ok - I suspect what's going on here is that the User_DirectDraw_GetCaps function only supports DDCAPS_DX7 at the moment. We should be checking for the size of the structure and comparing it against the various different DDCAPS strucutres to figure out which one to return. Instead, we seem to just be assuming it's the DX7 structure, and smashing anything that used to be there before. The old code defaulted to the DX5 structure, which is probably what Grim Fandango needs. This is probably messing up many older apps that used to work. Ove, we'll definitly need to address this before we submit a patch to winehq - can you look into it? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Transgaming patch compilation (update) and Baldurs Gate 2 Success
"Adam D. Moss" wrote: > > "Adam D. Moss" wrote: > > Another clean rebuild later and I'm still getting a crash > > whenever anything tries to use DDraw though! (Trunk works.) > > Right, I finally tried the Transgaming patches against a 'real' > raw Wine-20001222 and I still get the same problem: a generic > WINE crash whenever something tries to use DirectDraw (haven't > tried D3D, or at least I believe that my D3D apps are using > DDraw to set up the screen mode beforehand, crashing, and > never getting to do any 3D anyway). Another possibility that occurs to me after seeing a similar report on the newsgroup is that you're running into a race condition with the new update thread. You can turn off the update thread by editing wine/dlls/ddraw/dsurface/user.c and removing the comments around the 'SYNC_UPDATE' #define near the top of the file. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Transgaming patch compilation (update) and Baldurs Gate 2 Success
"Adam D. Moss" wrote: > Right, I finally tried the Transgaming patches against a 'real' > raw Wine-20001222 and I still get the same problem: a generic > WINE crash whenever something tries to use DirectDraw (haven't > tried D3D, or at least I believe that my D3D apps are using > DDraw to set up the screen mode beforehand, crashing, and > never getting to do any 3D anyway). What apps are you trying? That can make all the difference in the world8-) Our standard regression test are the examples from the DirectX SDK. When in doubt, try those first. > XFree86 3.3.6 on S3ViRGE, Linux 2.2.18, glibc 2.1.2, > Mesa 3.4. Would a specific trace-log or such be useful? Definitely. Do a -debugmsg +ddraw trace, but don't send anything too long to wine-devel for courtesy's sake. If you have a big trace, send it to us directly. > Has anyone had luck on a similar setup? Again, DirectDraw works > on the trunk. My laptop is S3 Savage based, and I'm running it with the latest CVS of utah-glx and XFree 3.3.6. It's slow for 3D though, since the utah-glx drivers don't support sending triangle strips or fans directly to the hardware. And I haven't been able to get direct rendering working with it. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: New wine icon
Ove Kaaven wrote: > > (But from what I found in my mailbox, it seems you were right about the > martini glass issue, at least, it's just that the WineHQ logo isn't really > a wine glass either) Clearly, the WineHQ logo is meant to be a glass of Port. 8-) http://port-wines.com/ http://www.amazon.com/exec/obidos/ASIN/B4SUIA/portwinescom/104-6111571-0117562 -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Re: Transgaming patch compilation (update) and Baldurs Gate 2 Success
FT Rathore wrote: > Hi > I did get the wine (plus transgaming patch) to compile and link all the > files that were not being linked correctly (refer to my prevoius mesage) > In the end of this message I have the list of files I needed to compile > and the gcc link command to manually link libddraw.so. A few people have reported this - the problem happens when you forget to rerun ./autoconf and ./configure after applying the patch. All the files you need should be in the Makefile.in in dlls/ddraw. > I did get it to run Baldurs Gate 2 Shadow of Amn with the use 3D option on > (and Everquest a little bit). In BG2 it actually goes through the > splashes, and everything else works , but the sound gets underrun, but the > game runs fine, slightly slow probably because the terminal is flooded > with underrun messages like below: A fair bit of work is still going on with sound. I'll let Ove answer this question in more detail. > But still, it runs I played it for about 10 minutes, casted spells checked > things out. Excellent. 8-) Glad to know it works on something we hadn't tested yet. - Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
TransGaming DirectX Release
Hi Everyone, Several months ago, I promised that wine-devel folks would be among the first to know what TransGaming Technologies has been up to. While we're not ready to make a big PR push at this point, we wanted to make sure that everyone involved in Wine is up to speed with what we're doing. Our goal is nothing less than 100% compatibility for running Windows games on Linux through Wine. So - we've been working hard on revamping the DirectX code within Wine to fully support the Direct3D 7 APIs, as well as substantially restructuring the DirectDraw code. So far, we've been able to get most of the core Direct3D 7 sample apps up and running, as well as some major game titles (Sacrifice), and the 3DMark2000 benchmark. We've implemented most of the code D3D features, including multitexturing, stencil buffers, alpha blending, fog, etc. We're still working on optimizations such as holding D3D Vertex Buffers in video memory for quick access to hardware T&L. On the DirectDraw side, we've unified the code in the the x11 and DGA drivers into a new more OO design, separating direct use of xlib from the core code. We've added an 'update thread' which should make non-DGA use almost as good as DGA, especially when combined with some of contextual smarts in the GDI x11 driver Ove submitted a few weeks ago to speed up DIBsections. We still have some work to do on this front, since DGA support hasn't yet been integrated into our new design. Initially, the Direct3D code will be released with limited redistribution rights under the Aladdin Free Public License - it will not be available under the Wine license. The DirectDraw code will be made available under the Wine license, and we should be submitting a patch with that code within a couple of days. In 2001, we will be setting up a subscription service that allows users to vote on the games they would most like to see working. Users who pay will be allowed to vote on what we work on next - essentially a variant of the Street Performer Protocol (http://www.firstmonday.dk/issues/issue4_6/kelsey/). Once a set number of users have subscribed to the service we will release the code under the Wine license. After the initial code is released under the Wine license, so will all subsequent patches, assuming we retain a set minimum number of subscriptions. You can get the AFPLed code from our web site (http://www.transgaming.com/) now. Once we have some feedback on the 2D side of things, we'll send a patch to wine-patches for release under the Wine license. Happy Holidays! -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
Recent breakage in window-moving
Hi Alexandre,
A patch you made a couple of days ago seems to have broken window-moving
in managed mode. When you try to move a window, the mouse jumps back to the
move origin position. It seems to be related to the change below, though
I honestly can't see why this code is needed at all. My guess is that previously,
we were simply queueing a hardware event which wasn't handled until after
the drag-loop was done...
RCS file: /home/wine/wine/windows/winpos.c,v
retrieving revision 1.81
retrieving revision 1.83
diff -u -r1.81 -r1.83
--- winpos.c2000/12/13 20:03:53 1.81
+++ winpos.c2000/12/18 03:10:42 1.83
[deleted]
@@ -2938,13 +2943,10 @@
EVENT_Synchronize(); /* Synchronize with the host window system */
if (!GetCapture() && ((wndPtr->dwStyle & WS_VISIBLE) || (flags & SWP_HIDEWINDOW)))
-{
+{
/* Simulate a mouse event to set the cursor */
int iWndsLocks = WIN_SuspendWndsLock();
-
- hardware_event( WM_MOUSEMOVE, GET_KEYSTATE(), 0,
- PosX, PosY, GetTickCount(), 0 );
-
+mouse_event( MOUSEEVENTF_MOVE, 0, 0, 0, 0 );
WIN_RestoreWndsLock(iWndsLocks);
}
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
Re: Where to put TEB's on PPC?[was:Re: is WINE portable?]
s not interfere with what Wine does. Not a bad strategy in general, but in the specific case of LinuxPPC, I think that the appropriate level might well be pthreads. On MacOS X, I have no idea what other low level interfaces might be available. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Where to put TEB's on PPC?[was:Re: is WINE portable?]
Josh DuBois wrote: > >My first question to the group is: does anyone know of a good place > to put the TEB thread-info structures on the PPC architecture? On Intel > they get stored in the fs register, and on non-intel sparc there's some > thread-local storage pointer the OS gives you. It _looks_ like > linuxthreads for PPC puts all its thread info in a big list, so that's > what I've done (in a hacky way) for linuxppc. I feel like it should > change eventually, though (I'm just shooting for something that works > for the time being) because finding the current thread means getting a > pointer you think is on the stack and then searching the whole list for > a TEB with a stack that could contain that pointer. Seems slow. > >Does anyone know of a really _good_ place to put these on the PPC? > >Looking at a ppc manual I see some general purpose registers - > spg0-spg3 that are reserved for OS use, but I assume there's no way for > a user-level program to set them under linux? Is there really any reason not to just use pthread directly? We're not constrained by binary compatability issues on LinuxPPC (or MacOS X), so there's no need to preserve any special registers. Of course, as I'm writing this I'm trying to remember why I didn't try this out at MacHack this year when I tried to update the PPC port. I remember going through the same process of trying to find a register that I could be sure was preserved across library calls, and even consulted Stan Shebs (one of the gcc PPC developers). I couldn't find anything that seemed appropriate in time, so I just gave up. I have no recollection whether using pthreads' local storage even occured to me then. Also, if you're interested I can send you my original WINE PPC port, circa March 99. I think that I just hacked out any threading at all for that try. The only thing that might be of more than curiosity value in it is a fix somewhere in the event handling code to byteswap the x,y location from a mouse click -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Issues regarding porting WineLib to MacOS X
James Hatheway wrote: > > I have just started to look into making a list of all of > the issues that would have to be resolved to port an > application to MacOS X using WineLib. I briefly started on a MacOS X port at MacHack, but stopped after being annoyed at how many header files for important stuff MacOS X seemed to be missing. I have a tarball of an old hacky winelib port to LinuxPPC around. At MacHack I switched to updating it for then-current WineLib, but got stuck on the issue of thread local storage. The solution there is to apply a patch that makes wine use pthreads for Windows threads (I know that Andrew Lewycky did this for Corel for the cprof profiler, and I think that CodeWeavers may also have something). > Current list of possible issues: > > -> Endianness. Since we are using WineLib, could > have resources written in native (big) endian format > with wrc. Any external data files such as cursors, bitmaps, sound > would have to be converted. The PUT_WORD/GET_WORD macros > need byte swapping turned off. (Did I miss anything?) There was some argument between Bertho and I on this point, as I recall: Should resources always be in little endian format, and converted to big endian at load time, or should they be written in big endian format from wrc? The solution I used in my hacky port a year ago was that wrc writes out big-endian data. This means that there has to be some conversion for the external formats you mentioned. I think it's best to do the conversion once in wrc, not every time a resource is loaded. When we did MacPort at Corel, we went further than that: things like bitmaps and cursors were converted into something closer to the format that was used in the underlying OS. IE: Windows cursor resources were converted into Mac cursor resources, etc. Actually, speaking of MacPort, if your project is MFC based, you might want to talk to Corel about using MacPort instead of WINE. Last I heard they were working on Carbonizing it for MacOS X. > -> Memory alignment issues These are more of a performance issue than anything else. You have two choices: either pack structures the same way they're packed in Windows, or pack things the way the native compiler wants to pack them. In either case you're going to need data conversion for data that gets loaded from disk, whether that conversion is just byte-swapping or also moves the data into structures with slightly different alignment is the question. > -> Presence of Assembly language in code will have to be written >in C or translated to PowerPC assembly. (assembly is generated >in spec.c files, as well as other places like in the server) My hacky port from last year has the necessary PPC asm generation. > -> Debugger seems tied completely to Intel architecture. >(Since we will be using WineLib, we probably don't need > winedbg, can use gdb?) gdb worked just fine in my hacky PPC port last year. > -> Need a X11 server or need to make a x11drv replacement that >is Quartz specific. (There is a XFree86 port to MacOS X, but >it only runs seperately from Quartz at this time. Making the >X server a rootless client of Quartz is on the TODO list of >Darwin but there is no mention of its current status. >There is a commercial server, at: >http://www.tenon.com/products/xtools/ which already implements >this) Mmmm - new backend driver. This would be a good thing, IMHO. It'll be a major pain to do, but would be a huge boost to taking WINE truly cross-platform. The GDI side should be fairly straightforwards, but the window/event management will be nasty. > -> Need to be able to build Windows app using gcc (might be issues >such as using MS specific keywords/language constructs, etc.) >Does ATL build properly with gcc? Don't know about ATL building with gcc, but it should certainly built with CodeWarrior, since Metrowerks has to support it on Windows and the compiler uses a common front end. Metrowerks is likely to be better in general at compiling code from Windows. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: CRTDLL Qtns
Alexandre Julliard wrote: > > "Griffiths, Jonathon" <[EMAIL PROTECTED]> writes: > > > -MS docs state that crtdll is not very threadsafe, however I cant see any > > reason why wines shouldnt be. I don't think any apps depend on non > > threadsafe behaviour since by definition it is unpredictable. So I think it > > may be worthwhile to make it MT safe. This would mean a large part of the > > code could be shared with msvcrt.dll (way in the future). Also, under unix I > > would expect more processes to be running so potentially it is more > > important to be safe. Does this make sense? > > I think there's no point in making functions thread-safe if they are > not thread-safe in Microsoft implementation. Any app that uses these > functions will have to provide its own locking anyway, so we'd only be > duplicating it and slowing things down. Again, what about WineLib apps? Remember, that these apps on Windows would have been linked to thread safe functions in msvcrt, but under WineLib will be linked to libcrt.dll. Or are we going to have a seperate libmsvcrt.dll? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Porting winelib to non x86 platforms
> [EMAIL PROTECTED] wrote: > > What is your opinion about the above subject, especially in the sense that > > it may provide a good incentive for application developers to build their projects > > using winelib and gaina sort of platform independent code ? Jeremy White wrote: > MacOS X, however, is another story. If you get an X server on > MacOS X, it should be pretty easy. If you want to do it > the right way, you'd need to develop a Carbon driver to parallel > the Wine x11 driver. That, while conceptually straightforward, > will be a lot of work. I got some simple winelib apps up and running on LinuxPPC in early 1999, but it was fairly hackish, and most of my changes didn't make it into the mainline WINE tree. I did some work updating the port for newer releases of LinuxPPC at MacHack this summer, but got stuck trying to figure out how to properly deal with the thread local storage. My old code still works ok though, if you happen to have a LinuxPPC machine around. MacOS X, as Jeremy says, is another story. A fair bit more work is required, but it's be no means impossible. I believe that Ulrich Weigand has gotten WineLib apps up and running on SPARC. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: CRTDLL
Jeremy White wrote: > AFAIK, the only reason we have to use the CRTDLL fopen is > so that the file handle is known to Wine. That way, if the program > uses any non CRTDLL Windows API on the file handle, it will work. The other major thing that we need WINE's fopen for is handling Windows style pathnames: glibc is unlikely to be able to open D:\foo\bar.baz > However, in my experience, code that uses fopen() tends to only > use fwrite() and fread(). Thus, I believe that code like that would > mostly work. Further, if we're working with Winelib with code > that doesn't behave as I expect, IMHO it would be better to normalize > all of that code than to wrapper and/or reinvent glibc. We mostly just have to wrap it, not reinvent it, I think. The exception is for some of the things like reading and writing Windows style CR/LF text files. Hmm - it appears as though the MSVC 6.0 EULA may allow redistribution of the MSVCRT DLL under liberal enough conditions that closed source (but not open source) Winelib apps could use it. I don't know if this is something that we'd *want* winelib apps to do, but it's an intriguing possibility if the linkage issues could be worked out. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: CRTDLL
Uwe Bonnes wrote: > my personal believe is that it doesn't make much sense to work more on > CRTDLL. What about it's use in WineLib apps? Remember, a WineLib apps's fopen call needs to get redirected to CRTDLL fopen, *not* glibc's fopen. There's also a need for implementations of things like fscanf that know how to deal with DOS CR/LFs. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: RFC - Winelib constructor init problem
Jeremy White wrote: > However, the more I think about this, I think that the whole approach > I've proposed is, at this time, inferior to Alexandre's proposal. I've been running into another problem as of late that would be solved nicely by Alexandre's solution that isn't easily solved otherwise. I've been playing with GL and DDraw winelib apps on a machine with an NVidia video card and the NVidia XFree 4.0 accellerated libGL. The NVidia libGL makes pthreads calls during it's initialization. Due to issues with dll loading order, libGL is being initialized prior to the initialization of threading within libwine (via the .init/constructor init mechanism), and we thus segfault immediately in the pthread wrappers. You can see this easily enough on any machine with the NVidia drivers (or other libGL implementations that rely on pthreads) by adding opengl32 or ddraw to the IMPORTS line in the Makefile for programs/notepad. Short of Alexandre's solution, the workaround I'm using now is to forcably call THREAD_Init() before any call to NtCurrentTeb in the pthreads wrappers. *That* is decidedly uglier than the foo/foo.so solution. > Does anyone know which list is best for discussing such > a proposition? I follow glibc-linux, but it's a pretty > low traffic list. So long as it gets to Ulrich Drepper you're probably fine. Just cc him on your suggestion... -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: RFC - Winelib constructor init problem
Jeremy White wrote: > > [...] > > > > It doesn't appear to be able to pass argc and argv until it actually > > loads the executable start code: > > Hmm. We're using different versions; I can't find elf/boot1.c. > The code I've focused on (from glibc 2.1.3-15): I was looking at the ld.so / ld-linux. On a debian machine, do an 'apt-get source ldso'. > From elf/dl-open.c: (the _dl_init_next function returns > the DT_INIT ptr, if any) > > /* Run the initializer functions of new objects. */ > while ((init = _dl_init_next (&new->l_searchlist))) > (*(void (*) (int, char **, char **)) init) (__libc_argc, > __libc_argv, > __environ); So the odd things here are that a) both glibc and ld.so implement dlopen - which one is actually being used? and b) where is glibc getting __libc_argc and __libc_argv from in the first place. If it's being passed through ld.so, how is that happening given the code snippet I posted earlier from ld.so? The only possibility I can think of is that the ELF AT_ENTRY tag is only filled by something in glibc, which then takes over some of the task of dynamic loading after ld.so runs START() - this would explain why glibc has the dynamic loader code in it. I suppose that the best way to figure out what's actually going on is to start playing with debug builds of both ld.so and glibc. > > [...] > > To further confound things though, when I actually tried making > > a simple shared lib with an _init function, it *did* get argc > > and argv, but as you suggested, libc then went wonky because > > it didn't get initialized properly - note the line above that reads: > > Now, that's odd, because I've just rerun through my samples, > and everything seems to work as I expected (I can do a getenv(), > which seems to be a good litmus test). I did notice when testing > with Wine that I had to go to some extreme lengths to > prevent libc from being loaded ahead of Wine (as reported by ldd), > which does cause disastrous results (but it always does). My test essentially consisted of a shared lib, not linked to glibc, which implemented an _init routine that saved argc/argv and then tried to call through to glibc's _init routine, and a small program linked to the lib with a main() that just walked through the argv list printing each argument. It would segfault in printf for some reason, regardless of whether I had called glibc's _init routine. > I can't agree more! I keep wishing I could think of a better > reason than that though. Alexandre has this annoying habit of > making decisions based on practical things, rather than either > your or my high moral standards . 8-) Another thing that this reminds me of is the discussion over the wineserver - for winelib apps that don't expect to be doing lots of communication across several processes, wouldn't it be nice to not have a seperate executable and process for the wineserver? For single threaded apps this might allow us to see similar performance gains as with the proposed kernel-module wineserver -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: RFC - Winelib constructor init problem
Jeremy White wrote:
>
> Gav sparked me to go look and see how I could pull argc/argv
> out during the constructor phase of library load,
> and I believe I have found a method that should work,
> at least for elf/glibc implementations.
I'm glad I sparked some investigation, but on further reflection and
looking at code, I'm not sure that this is actually possible.
> The good news is that _init is passed argc, argv, and environp.
The glibc source code certainly seems to assume that this is the
case, but I've been looking at the ld-linux sources, and I don't
see the mechanism it uses to do this:
The code in question (in d-link/boot1.c) looks like this:
for(tpnt = _dl_loaded_modules; tpnt; tpnt = tpnt->next)
{
/* Apparently crt1 for the application is responsible for handling this.
* We only need to run the init/fini for shared libraries
*/
if (tpnt->libtype == program_interpreter ||
tpnt->libtype == elf_executable) continue;
if (tpnt->init_flag & INIT_FUNCS_CALLED) continue;
tpnt->init_flag |= INIT_FUNCS_CALLED;
if(tpnt->dynamic_info[DT_INIT]) {
_dl_elf_init = (int (*)(void)) (tpnt->loadaddr +
tpnt->dynamic_info[DT_INIT]);
(*_dl_elf_init)();
}
.
.
.
It doesn't appear to be able to pass argc and argv until it actually
loads the executable start code:
/* OK we are done here. Turn out the lights, and lock up. */
_dl_elf_main = (int (*)(int, char**, char**)) dl_data[AT_ENTRY];
/*
* Transfer control to the application.
*/
START();
Where START() is a macro that cleans up the the local stack for
the boot function, leaving the stack with the arguments passed
from the kernel.
To further confound things though, when I actually tried making
a simple shared lib with an _init function, it *did* get argc
and argv, but as you suggested, libc then went wonky because
it didn't get initialized properly - note the line above that reads:
tpnt->init_flag |= INIT_FUNCS_CALLED;
This is what's causing it to stop once it's run one _init function.
I also just tried getting the address for the libc _init function
from dlsym and calling through to that from the test library,
but that didn't seem to work, though I did see it travel down
into the bowels of glibc initialization.
> The one thing I can't clearly assess is whether this method
> is portable to all of the platforms we care about.
The _init thing is I believe fairly gcc/ELF centric. It works
because the linker twigs that it needs to put a DT_INIT tag into
the ELF headers, pointed to that function.
> One advantage to Alexandre's method (let Wine run, do
> a LoadLibrary(), GetProcAddress("WinMain"), start the app),
> is that it is more portable.
I suppose - but it feels wrong to build a winelib app foo, and
end up with a 'foo' and a 'foo.so', where there's no real code in
'foo'.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
Re: RFC - Winelib constructor init problem
Jeremy White wrote: > > Alexandre Julliard wrote: > > This is certainly doable with .so dlls, but it probably won't work > > right with static linking (though I'm not sure if we care about that). > > And of course you won't have access to the command-line when > > initializing the dlls, so options like -display, -dll, -desktop > > won't be supported. > > Good point. I favor this option over the others, because I believe > it to be the more correct one. (Empirically MFC works with > only GDI, Kernel, and User, but your point remains valid - my solution > is not complete). > > If we were to change to have each DLL initialize itself > from its constructor, is argc/argv processing the only flaw > with this approach? (I ask because a brief review of the glibc > code indicates that argc/argv are processed prior to > traversing the ctors list, so they should be available to us). We're looking into a similar issue now - some libGL implementations call pthreads functions in their constructors, leading to headaches because the pthreads wrapper functions rely on threading having been initialized by that point. Dredgeing my memory for what we had been working on at Corel reminded me that we had overcome the argc/argv issue by relying on glibc __environ global. Basically, you can extract argc/argv from that and pass it on to PROCESS_InitWinelib from any constructor you like, since glibc should already have it initialized. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Corel tree merge
Huw D M Davies wrote: > > On Tue, Aug 08, 2000 at 06:09:42PM -0700, Alexandre Julliard wrote: > > Another problem with the patch is that it adds dependencies between > > gdi, wineps and winspool, and this is Not Good(tm). Inter-dll calls > > are only allowed to call functions exported in the spec file; the APS > > functionality should be exposed through the standard Windows APIs. > > Yes, this is the reason why I haven't merged this code from the Corel > tree myself. It's not quite as hard to unravel as the FontTastic > stuff though... I'm not sure that it's really worth trying to integrate the FontTastic changes into the mainline winehq tree - the only way to solve the inter-dll calling issue here is to implement the font apis from the ddk, and make both the ps driver and the x11 driver use those apis. Trying to shoehorn the FontTastic changes into that approach will be painful at best - since it's using X Font APIs to enumerate the available fonts, it's going to be hard to avoid crossing dll boundaries from the PS side to the X side. Furthermore, one of the interesting things that came out at the recent VA Printing Summit was the fact that the new X Rendering Model under development totally throws out all the existing X font APIs. Basically, the X guys concluded that they'd much rather have the client end deal with most font issues. All the new server is going to know how to do is to composite pre-rasterized glyphs on screen. The client end will have to supply the server with the rasterized glyphs, and there will be some kind of communications channel that allows the server to make intelligent caching decisions. Since FreeType already provides a nice client API, it's probably going to become the de-facto way to render text. It's a good choice for WINE use because it lets us avoid the X-Driver/PS-Driver Inter-DLL calling problem (ie we wouldn't *have* to implement the ddk font apis). Of course there's always the FreeType patent issue to consider as well, but they are looking into using autohinting to get around that (this theoretically should result in similar quality glyph rasterization, without any question of running up against the Apple hinting patent). Of course, with antialiased rendering, small text looks pretty good even unhinted in my experience. -Gav -- Gavriel State CEO TransGaming Technologies [EMAIL PROTECTED]
Re: crtdll (fopen and friends)
Ove Kaaven wrote:
> Had you figured out how we're going to call Winelib routines instead of
> libc routines when it comes to functions like fopen() and friends? The
> Winelib app I'm experimenting with does fopen() to open some data files,
> but there are a few problems...
We need to add something like:
#ifdef WINELIB
#define fopen CRTDLL_fopen
.
{Rest of CRTDLL functions handled similarly}
.
#endif
To crtdll.h and include it from windows.h.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
Calling PE DLLs from ELF
Gavriel State wrote: > This could be worked around with some kind of import library system - IE: > have a tool that can build an ELF stub import library from a PE DLL, with > a initialization routine that would do the LoadLibrary and proc address > resolution for you. But that doesn't exist right now, as far as I know. It occurs to me that this might be a nice way to avoid having to make manual calls to GetProcAddress to support using native MS DLLs. The current way of doing things is really ugly. Also, doing this would help us keep track of the dll-dependance tree more precisely. Alternatively, we could perhaps come up with a replacement for ld.so that can resolve ELF imports from PE exports. I don't know enough about how the loader/relay code works to know how hard this would be. Anyone? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: [Q] compiling mfc application with winelib
Vivek Dasgupta wrote: > I also tested one more combination. i.e. i have my mfc application > which uses my single function mfc based dll . Now > i compile myapp.exe linking to libmfc.so & winelib. But i want to use > native mydll.dll. > BUt it didn't work. > SO do I have to also load mydll.dll and GetProcAddress for each function > in mydll.dll? For now, that's probably the best solution, though it may not actually work properly if mydll.dll needs to import from libmfc. The problem is that myapp.exe is being built with ELF linkage - all the function calls are being resolved by the ELF linkage mechanisms in ld and ld.so. Let's say you have myapp.cpp, which makes a call to function Foo() in mydll.dll. Since you're compiling with ELF tools, ld doesn't know where to find Foo(), since you can't put mydll.dll on the linker command line (ld wouldn't know what to do with a PE dll). This could be worked around with some kind of import library system - IE: have a tool that can build an ELF stub import library from a PE DLL, with a initialization routine that would do the LoadLibrary and proc address resolution for you. But that doesn't exist right now, as far as I know. Furthermore, even if it did exist, you're going to run into problems with C++ name mangling if mydll.dll wants to link to mfc: the gcc name mangling will be different from what mydll expects, so you'll need to make a full spec file for MFC. You'd probably need the ordinals too. > All this because some apps use third party dlls for which source code is > not available and it has to be loaded natively. > > If you need ordinals in your spec file, the necessary information is in a file > > MFC42.DEF in the MFC source tree. This file has the mangled names and the > > ordinals. To create the spec file, you need the unmangled names. The function > > UnDecorateSymbolName() in the win32 API (see documentation in Visual C++) can > > unmangle the names. It looks like the spec file can be automatically generated > > if necessary. > > But I suppose we need the mangled names for g++. i.e. unmangle names > from mfc42.def and use g++ to mangle them and then put them in spec file > ? I haven't tried this yet. Yes, this should be what you need if you want your libmfc.so to work with mydll.dll. The spec file should map the MFC .def name to the g++ mangled name: For example, for CWnd::Attach(HWND hWndNew): The line in the MFC .def file is: ?Attach@CWnd@@QAEHPAUHWND__@@@Z @ 1651 NONAME And the g++ mangled name is: Attach__4CWndP6HWND__ So the line in the .spec file should be something like: 1651 stdcall ?Attach@CWnd@@QAEHPAUHWND__@@@Z(ptr ptr) Attach__4CWndP6HWND__ > Also while compiling MFC (or any app) the attribute errors are very > important. There were a few crashes due to ignoring of attribute > (stdcall/cdecl) by the compiler. This causes both > the called function and the calling function to free the used stack > space resulting in misplacement of stack pointer. > For most such cases the compiler issues warnings but for a friend > function the compiler doesn't give warning and still ignores __stdcall > attribute. Thus function definition uses __stdcall attribute but when it > is called it uses __cdecl attribute. > For such cases we declared the function outside the class without friend > keyword and it works now. > You could put this in winelib/mfc howto. This is a g++ bug that Corel had Cygnus work on for g++ compiler enhancements. Basically, the compiler was ignoring __stdcall attributes in member functions, if I recall correctly. I'd try using the latest version of g++ to see if it fixes the problem, and if not, ask people on the gcc mailing list about it. You'll also want to edit wine/include/wine/obj_base.h to turn on the com_interface attribute macros. You need these in order to be able to use native COM objects from C++ built with g++, or for native code to use COM objects built using g++. Again, you'll need the latest version of g++ for this to work properly. > Now I am compiling MFC with -D_AFXDLL . However it is giving problems > with a type > IBindStatusCallback in oleimpl.h. This is supposed to come from urlmon.h > and wine doesn't have urlmon.h. Has anybody complied MFC with -D_AFXDLL? Corel has not yet sent in patches from the header work that was done for their MFC development. There was definitely a full implementation of urlmon.h, and other headers. Jeff - would Corel be willing to make the old win_include headers like urlmon.h available for WineHQ developers to integrate? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Resource Leak Tracking
Douglas Ridgway wrote: > > Where is the "memory/object/resource leak in Wine" option? > > See http://www.winehq.com/patches970914/ for one way of trying to find > such a leak. The required patch probably won't apply without modification. > There might also be a more recent or better way to find such a leak. Actually, the Corel tree has an extensive resource/memory leak tracker, including a motif-based graphical profile viewer client. Last I heard, Alexandre didn't want to put that into WineHQ, since he wanted Wine to properly implement the equivalent Win32 APIs so that resource-monitoring Win32 apps would work. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
The MSVC++ 6.0 license
Jeremy White wrote: > p.s. Stick with Visi C++ 5. IMHO its MFC license is cleaner than that > of VC 6. Actually, I just picked up a copy of MSVC 6.0 and it appears that they changed the license between the original release and the Service Pack 3 release - they removed the bit in section 1.1 about requiring that you be developing your software product only for use with a Microsoft OS. In any case, even the original license explicitly says that the MFC redistribution rights are *in addition* to the usage rights in section 1.1. The relevant portion of the original EULA: 1.1General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the SOFTWARE PRODUCT for the sole purposes of designing, developing, and testing your software product(s) that are designed to operate in conjunction with any Microsoft operating system product. [Other unrelated stuff deleted] >From the SP3 EULA: 3. Section 1.1 of the EULA is deleted in its entirety and replaced with the following: 1.1General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the SOFTWARE PRODUCT for the purpose of designing, developing, and testing your software product(s). [Other unrelated stuff deleted] Disclaimer - I am not a lawyer, but I've spent lots of time with them investigating software licenses. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: MFC questions
"Wilbur N. Dale" wrote: > 1. Compile MFC. Several years ago we (Lumin Software) tried to compile MFC. > The attempt failed and we found another way to do what we wanted. MS > documentation states that compiling MFC was deliberately made difficult. > Considering my experience with stuff they call "easy" I am not looking forward > to compiling MFC. We are currently using Visual Studio 5 for windows > development. At Corel, we had MFC compiled and running sample apps in WineLib in late 1998. It's mostly a question of the Wine headers, which weren't originally up to snuff. We did quite a bit of work on them, and most of those changes have been contributed back to WineHQ, so it should be pretty easy now. The other thing that was a big deal was getting the startup code working properly - since MFC needs to initialize static data *after* WineLib gets initialized. I believe that that issue has been addressed now on the WineHQ side with some of the work done on the .spec file tools recently. -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: Font rasterizing support Re: RFC: Wine 1.0
Douglas Ridgway wrote: > > Also, we need more font support. Is there any kind of font rasterizer in > > wine? We implemented some code to read font data and curve data out of > > truetype fonts that we're willing to contribute, but since there's no > > rasterizer, it would be mostly useless. > > My opinion is that the X server is the place for the font rasterizer. Wine > needs additional interfaces beyond what X provides, which means either > extending the X Font Protocol or using a custom font server. > > I don't know how this interacts with printing, however. The code for interfacing with BitStream's FontTastic font server is in the Corel tree. The BitStream server supports an extended XFS api that allows us to do things like get a glyph outlines, etc. The API itself is readily visible in the header files, though the actual client interface library (a derivative of the XFS interface library used by X Servers) is only available as a binary. Bitstream might be convinced to allow Corel to release the source portion of the library, but it shouldn't be strictly necessary if someone wants to extend the XFree 4.0 FreeType enabled xfs with the same extensions. The integration in the Corel tree is rather hackish, since it actually ends up mixing the psdrv and the x11drv code a fair bit. There's also a ton of #ifdefs. It was done on a very tight schedule for the amount of work that was required. Ideally, we would implement fonts in the graphice drivers on top of the font engine interfaces that are already defined for NT device drivers. That way, one would be able to take a binary printer driver and have it work properly. The font engine interfaces could then be implemented in an abstract way so as to support multiple possible back ends (FreeType direct linking, extended XFS protocol, etc). It would be a fair bit of work, and I'm pretty sure that there would be X client/server related issues that I haven't really explored very much. I posted about this a while ago, but neither Huw nor I came up with a definitive plan. -Gav -- Gavriel State CEO TransGaming Technologies [EMAIL PROTECTED]
Re: New contact info for Gav
Ove Kaaven wrote: > > On Fri, 28 Apr 2000, Gavriel State wrote: > > > As a couple of you may have already heard, I've decided to leave Corel > > to start a new software company. I can't talk about what I'm going to > > be up to yet, but people here will certainly be among the first to > > know when the time comes. > > Just came to think of it, there's one thing I wonder when it comes to that > - what will happen at Corel then, who will be your successor there, will > they still work with Wine the same way? Not being there anymore, I don't think that it would be appropriate for me to speak for Corel on this topic. Jeff, Toufic: would either of you care to comment on Corel's current Wine plans? -Gav PS: I've incorporated now, so it's safe for me to publicly reveal the name of the new company. I still can't say what I'm actually doing yet (especially given that I'm at E3 right now, and my ideas are somewhat in flux). -- Gavriel State CEO TransGaming Technologies [EMAIL PROTECTED]
Re: Resource endianness
This was supposed to have been sent last week, but it looks like it never made it out of the Corel email gateway Bertho Stultiens wrote: > - Should wine only use little-endian in the resources? In my oppinion, > yes. Let the resources be the same all the time and let the > resource-loader take care of conversion. There is a comment in a header > about byte-swapping and wrc. I really would prefer to have byte-swapping > in wine rather than wrc. Mainly because wine already requires to do the > analysis of resource-contents, whereas wrc only packs data (without > contextual/semantical knowledge). > > - Who has tried to run wine(lib) on big-endian processors and what are > the experiences? I had clock and at least one other app up and running on LinuxPPC about a year ago. I just let wrc spit out native (big) endian data, and with the byte swapping turned off for the wine PUT_WORD/GET_WORD macros, the things I tried worked fine. I didn't have any bitmaps, or any complicated rc files though. I'm not sure I see the benefit of forcing little-endianness in the resources. If you're on a different CPU, you're not going to be able to load an x86 PE file anyway, so why not just output in native-endianness? IE: (convert cursors, icons, etc). If wrc outputs everything in little endian format, that means that WINE has to do byte-reversals at runtime. The performance lag is probably minor, but why not shift the burden to build time? I don't think that there are all that many resources types this should affect in wrc - just cursors, icons, and bitmaps, I think. As for the CreateXXXIndirect routines, the ideal thing to do would be to support both little-endian and big-endian data where possible. For example, CreateBitmapIndirect could check the depth field: if the data is in the wrong endian-order, it could activate byteswapping code. This would mean that apps can both dynamically generate their own data to pass to CreateBitmapIndirect, *or* they could just do a simple load from a BMP file. Actually, this is really unlikely to affect anything other than bitmap data - very little else is generally loaded from data files. This is roughly the approach we took with MacPort for bringing our graphics apps to the Mac, except that the resource compiler actually spit out data that was not only in native endian format, but also in a format nearer to what the OS used for that data. IE: BMP input was converted to a format that was a direct representation of a Macintosh PixMap. -Gav -- Gavriel State Gainfully Unemployed Guy [EMAIL PROTECTED]
Re: Wine PPC?
michael_cardenas wrote: > > We have had a large number of requests to port our software to LinuxPPC. > Apparently lots of graphics software users have macs running canvas and are > interested in this type of port. > > Is this really feasible? What are your opinions on the possibility of > this? I imagine it would mostly require the porting of the asm code, which > there doesn't seem to be much of... I had some simple WineLib apps up and running on LinuxPPC about a year ago. Check the wine-patches archives for my work: not all of it made it in, due to the fact that I fudged around some important things like the exception handling structures, and register-based calling conventions for some APIs. I may have a tarball around somewhere -Gav -- Gavriel State Gainfully Unemployed Guy [EMAIL PROTECTED]
Re: Loader patch
gerard patel wrote: > > > > You can replace 'fallout' by 'word viewer 97'; it's the same problem I think, I >replaced > pe_image and module.c and the problem goes away. Try reverting the CVS commit and trying the original patch I sent - the original patch checks to ensure that the pe section offsets are on pagesize bounds, and if not avoids the FILE_dommap call and just copies the section instead. Alexandre modified the patch to always rely on FILE_dommap, counting on the pagesize failure handling code there to do the copying. I'm not sure why this would be failing, though it's possible it might be because FILE_dommap() is trying to use mmap to reserve the destination address range a second time - it was already reserved by the loader in PE_LoadImage(). I just tried my April 18th CVS tree (with my version of the patch) agains WordViewer, and it seems to come up fine (but won't open any files). Oddly, when I tried WordViewer against the current CVS, it comes up to the splash screen, but dies there with a critical section deadlock. Is this what you're seeing? -Gav -- Gavriel State Gainfully Unemployed Guy [EMAIL PROTECTED]
New contact info for Gav
Hi everyone, As a couple of you may have already heard, I've decided to leave Corel to start a new software company. I can't talk about what I'm going to be up to yet, but people here will certainly be among the first to know when the time comes. I'll certainly still be involved in WINE - and I'll be contributing directly to the main tree from now on, rather than indirectly through the Corel tree. I'll probably also spend some time on patch-merging my work from the Corel tree (the stuff that's not FontTastic dependant anyway). 8-) In the meantime, if anyone wants to get in touch with me, my non-Corel email address is: [EMAIL PROTECTED] Tuesday was my last day at Corel, so I expect that '[EMAIL PROTECTED]' will bounce as of now. (I tried to send this out on Tuesday, actually, but Corel's mail server didn't seem to like talking to winehq.com for some reason...) Take care, -Gav -- Gavriel State Gainfully Unemployed Guy [EMAIL PROTECTED]
Re: WINE loader and demand paging
Alan Shutko wrote: > > Can windows executables and dlls be shared and demand paged, or will > each loaded instance consume extra memory? Sometimes. If the executable/dll has been built with it's sections aligned to 4k (page-sized) boundaries, it can be mmap-ed in, which means that the kernel can share and demand page it. The DLL/Exe also has to have it's sections loaded in the place it's requested - if it has to be 'rebased' (moved to a different base address), WINE has to do a fair bit of work, and scribble all over the code adjusting branches, etc. This makes the affected pages not-shared. Coincidentily enough, I've just submitted the patch that allows us to mmap in the code to the WineHQ treeit's already in the shipping WPO2k tree. 8-) -Gav -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Canvas 7 for Linux released!
michael cardenas wrote: > > We want to express tremendous gratitude to all the wine developers. > With only minor modifications to wine, we were able to port our entire > application to linux in 6 months. > > We have already submitted most of our modifications to wine, and > the rest we will release soon, but they are minor also. Are you guys using our corelwine branch, or the main winehq branch with some of our additions? -Gav -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: WINE<->Samba integration
The licensing isn't a problem, since WINE is under a BSDish license, and soon to switch to the X11 license. What's much more questionable is how we can mix WINE code with QT code: can windows handled by WINE co-exist in the same process as QT's windows? If not, we have two possible approaches: 1) Make a seperate process that handles UI for browsing, etc, and have WINE talk to it through a socket. 2) Rewrite netserv/libmwn to be completely independant of the underlying GUI system (ie: have them weak link to another library that provides UI). That way, we could do a direct WINE UI for browsing and password entry in addition to a KDE UI. Doing something like this will help the transition to KDE 2.0, and will make GNOME-based usage possible as well. I'd definitely favour option (2), as it gives us the most flexibility. It will require more work, though. -Gav Oleg Noskov wrote: > > Well, at present time libmwn depends on some KDE core libraries and on ccqt library >(Corel's > version on Qt 1.4x). Looks like if WINE team is interested in using netserv/libmwn, >we should > consider extracting UNC mapping/wrapping code from libmwn and making it a completely >separate > library (currently libmwn contains LOTS of other stuff needed by Corel File >Manager). But > before we do that, we need a decision to be made by all interested parties that this >is > exactly the way that we want to go. Also, licensing issues need to be clarified >because > currently netserv/libmwn is CPL and we cannot mix GPL code with CPL code. > > Thanks, > Oleg > > Andrew Lewycky wrote: > > > > Netserv/libmwn are working great in Corel Linux and can be used by WINE. > > > > > > If WINE is running not in Corel Linux, it is still possible to use all of this, >provided > > > netserv is launched by some script or application before all the UNC-related >activity > > > begins. > > > > > > (For instance, I have Corel File Manager running in my RedHat-based NetWinder >computer > > > and it is using all the abovementioned functionality). > > > > > > > > > Netserv/libmwn are distributed under CPL. > > > > > > Please contact me if you have any questions/concerns. > > > > > > Thanks > > > > > > Oleg Noskov > > > [EMAIL PROTECTED] > > > > Would you consider putting together debian package sfor netserv and > > libmwn? Ideally, kde-corel would depend on these packages. In the mean > > while, we can just have the netserv and libmwn "replace" (in the sense > > of the dpkg replace control field) kde-corel. > > > > Andrew Lewycky > > [EMAIL PROTECTED] > > x1846 > > -- > The free Corel LINUX OS Download is NOW available! Check it out at >http://linux.corel.com -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: WINE<->Samba integration
This never made it to the public list...
-Gav
--
Gavriel State
Engineering Architect - Linux Development
Corel Corp
[EMAIL PROTECTED]
Hello,
here at Corel we already have pretty much the same functionality you're discussing here
already developed and shipping since Corel Linux 1.0.
Here's what we do in brief:
- we have a constantly running server process (called netserv) which does
a) UNC name resolution and handing
b) Credentials (username/domain/password) caching
c) Autmounting of shares
- we have a shared library (libmwn) which is acting as a wrapper for Linux file I/O. We
have our wrappers for open/fopen/access/stat/unlink etc. library functions and system
calls. Internally, libmwn looks if a file name is a UNC filename and in such case it
issues a "netmap" call to the netserv process. Netserv mounts the corresponding share
in
the temporary location if necessary (or reuses earlier mounted share if UID of the
caller
is the same) and returns temporary local path to the libmwn. Libmwn passes that name to
the native function/system call and returns to the calling program. When mounting,
netserv uses its credentials cache to find out which set of credentials to use. If
necessary, user will be prompted for new set of credentials (works OK for us). Netserv
monitors successful network access attempts and updates its cache.
Additionally, netserv takes care of garbage collection, usage counters, removal of
temporary directories,
There are plans for adding similar functionality to netserv/libmwn for transparent NFS
access.
Netserv/libmwn are working great in Corel Linux and can be used by WINE.
If WINE is running not in Corel Linux, it is still possible to use all of this,
provided
netserv is launched by some script or application before all the UNC-related activity
begins.
(For instance, I have Corel File Manager running in my RedHat-based NetWinder computer
and it is using all the abovementioned functionality).
Netserv/libmwn are distributed under CPL.
Please contact me if you have any questions/concerns.
Thanks
Oleg Noskov
[EMAIL PROTECTED]
Gavriel State wrote:
> I've cc'd this to the public wine-devel mailing list - this kind of
> architectural issue needs to be discussed with everyone.
>
> Jean-Claude Batista wrote:
> > I want to implement the Windows NetBeui functionality within Wine.
> > I would appreciate any constructive comments regarding this
> > implementation. This is my first idea on how this could be done,
> > so if you have the felling that things should be done differently,
> > let me know!
> >
> > The way I see this implementation consists in three levels. The File
> > I/O functions, the Windows Networking API ( the WNet functions)
> > and the shell functions that deal with virtual folders to implement
> > the network neighborhood.
> >
> > Since a filename can consist of a UNC (Universal Naming Convention) and a
> > file path, the file I/O functions must be able to find them on the network.
> > I believe the less troublesome way to obtain file network transparency
> > would be to use "smbmount" (Samba mount tool) to mount the network drive
> > to a temporary path and then use this path to access the file. Once the
> > file is no longer needed, we would unmount the path. I'm not sure I could
> > call smbd functions directly and using the C code, it might result in a
> > licensing conflict between Wine and Samba. Using smbmount might require
> > to install it as root with the SUID bit enabled, so that users can mount
> > the drives.
>
> There is a library called 'smbwrapper', that if preloaded before libc,
> will replace the libc file management routines with ones that understand
> UNC pathnames. IE: You'd be able to fopen "\\server\share\file" directly.
> Also, you can list the network neighborhood by just doing an ls on /smb.
> There may be a license issue though, in which case we might have to
> use smbmount directly as described above. It's probably worth contacting
> the Samba team via email if it looks like there's a license issue.
>
> Note that the Corel File Manager does exactly the same kind of thing (using
> smbmount, etc) and they may have already implemented code that might be
> useful on the WINE side in some of their libraries. I've cc'd Oleg and Ming
> on this message, in case they can give any more insight into this.
>
> > Since we need to keep track ok all the mounted drives, I think we should
> > do that in the Wine server side. Here is how :
>
> Sounds reasonable.
>
> > We can have an hash or a list of all the mounted network drives.
> >
> > struct network_mount
> > {
> > int count;
Re: WINE<->Samba integration
rence count lowered ) when : > > 1. a file is closed on file_destroy, if its full file name contains the > MOUNT_PREFIX. > 2. before we change the current directory using SetCurrentDirectory, if > the current directory contains the MOUNT_PREFIX. > 3. after doing a directory listing (using FindFirstFile, FindNextFile & > FindClose) from a network path, if the path countains the MOUNT_PREFIX. > 4. after doing a single directory or file operation like MoveFile, > CreateDirectory, etc. The network path would be mounted then unmounted. > > So everything else will still work as it is. From a performance perspective, > does this sound reasonable? > > The WNet functions would be implemented by spawning smbclients processes > and capturing the output. The Shell functions that have to be modified/implemented > still require additional investigation. One of the related things we'd have to implement is UI for browsing the Samba network in the file and printing dialogs... > This is still a draft for now but I'm waiting for comments and suggestions! > > Thanks, > > -- Jean-Claude Batista > [EMAIL PROTECTED] -Gav -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Installing different wine versions
And you can set the environment variable WINEPREFIX to use a different .wine directory and .winerc file using corelwine - our launcher scripts use 'WINEPREFIX=.wpo2000', for example. -Gav [EMAIL PROTECTED] wrote: > > On Wed, 15 Mar 2000, Uwe Bonnes wrote: > > > Hallo, > > > > as long as there was no wine server ( and I built with disable-lib), I > > could easyly run different wine versions (clean cvs, my own hacked > > tree, some old version, corelwine). Now even if I rename the > > executable in e.g. corelwine to "corelwine" and try to execute this, > > it will call the wineserver from the default wine tree. > > > > Do people have a concept to handle that? > > Could you not set BINDIR to a different path for each version? Or if > you manipulate it so BINDIR is not valid, I think it will try to run the > wineserver from the cwd where wine was started. > > > > Bye > > > > Uwe Bonnes[EMAIL PROTECTED] > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > - Tel. 06151 162516 Fax. 06151 164321 -- > > > Lawson > >< Microsoft free environment > > This mail client runs on Wine. Your mileage may vary. > > ---cut here--- > > > YOU'RE PAYING TOO MUCH FOR THE INTERNET! > Juno now offers FREE Internet Access! > Try it today - there's no risk! For your FREE software, visit: > http://dl.www.juno.com/get/tagj. -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: X Window with 24-bit color depth
This is fixed in our tree - you can get the code via anonymous CVS at opensource.corel.com. It'll get integrated into the main tree once we've shipped our office suite and we have time for patch integration. -Gav Shigefumi Takeda wrote: > > Hi there, > > While testing some applications under the latest Wine, I have found > a problem: > > Wine always fails to display an image data (DIB) of 32-bit color depth > on X Window with 24-bit color depth. > > X11DRV_DIB_SetImageBits_32() should create 24-bit RGB/BGR bitmap > from 32-bit color DIB in the case of 24-bit color depth, in distinction from > the case of 32-bit color depth. However, the function just copies 32-bit > color DIB at both cases. In the case of creating 24-bit color bitmap from > 32-bit color DIB at X11DRV_DIB_SetImageBits_32(), it may have to do > like the case of 24/32-bit color depth at X11DRV_DIB_GetImageBits_24(). > Also, X11DRV_DIB_GetImageBits_32() may have to create 32-bit color > DIB from 24-bit color bitmap in the case of 24-bit color depth, like the > case of 24/32-bit color depth at X11DRV_DIB_SetImageBits_24(). > > Thank you, > Shigefumi Takeda > [EMAIL PROTECTED] -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: dos drives
I think that he means that Linux users will not expect to see 'C:\' in the file dialogs for apps ported using WINE. Our tree has several mods that make C:\ look like /, and D:\ look like ~/. And in the file dialogs they have captions beside them like 'The System', and 'My Home'. Lots of this code is build into the file dialogs in a clean way, but we also have a hack that watches calls like DrawText and such like, looking for DOS paths and displaying them as UNIX paths (dropping the drive letter and flipping the direction of slashes). It's not perfect, but it's better than 'C:\'. -Gav Juergen Schmied wrote: > > > Is there a flag somewhere to turn off the emulated dos drive names in the > > file dialogs? > How do you mean this? There is nothing emulated. > > juergen > > --- > [EMAIL PROTECTED] > > ... from sunny Berlin -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: fontastic?
Yes, our stuff will require fonttastic - it won't work with just any old font server. The code doesn't just look for a font server in the font path, it also checks to see if the server has a couple of extensions for getting at glyph outline data, etc. -Gav michael cardenas wrote: > > So, the font functionality you added to wine will only work with fontastic? > Or with any font server? The code looks like it just checks for any font > server that uses tcp/ in it's fontpath. > > >Yup: > > > >http://www.bitstream.com/news/press/1999/1215_1999_corel.html > > > >-Gav > > > >michael cardenas wrote: > >> > >> So are you guys going to ship it with your products? I think applix does. > >> > >> >It's a font server from Bitstream that provides additional functionality > >> >not normally available in X (like being able to access Glyph outline data). > >> > > >> >-Gav > >> > > >> >michael cardenas wrote: > >> >> > >> >> Hi. I'm trying to use your changes to wine and I'm stepping through > >> >> GetGlyphOutline and since there's no fontastic server, it just returns > >> >> GDI_ERROR. What's a fontastic server? > >> >> > >> >> thanks. > >> >> > >> >> michael cardenas > >> > > >> >-- > >> >Gavriel State > >> >Engineering Architect - Linux Development > >> >Corel Corp > >> >[EMAIL PROTECTED] > > > >-- > >Gavriel State > >Engineering Architect - Linux Development > >Corel Corp > >[EMAIL PROTECTED] -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED] -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
