Re: wine/ misc/registry.c documentation/samples/config
Mike Hearn wrote: I think we'd do just as well to provide a little tool you can run on Windows to watch a software installation and import the registry entries/files into Wine. I wrote such a tool once. Do you want me to ask my former employer if he would mind releasing it? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: XML escaping problem in WWN 264
Francois Gouget wrote: In WWN 264 there's the following: <rant> ... </rant> But it does not get through in the HTML page because it's getting transformed into ... which the browser is correctly ignoring. We've had this problem before but I don't remember what the fix is... Do you? You probably need to turn the "&" into "&", so you would get: <rant> Then again, it is probably right to do it in the XML ->HTML converter, and not in the XML itself. I.e. - the XML->HTML converter needs to transform an inline "<" into < again. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz
Mike McCormack wrote: It can be compiled into the same binaries as used in CrossOver, but only if you use the same compiler, headers and libraries as we use. Or close enough to it. It's been done before. http://lingnu.com/support.html Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz
Short answer - RTFM Grant Williamson wrote: Hi, I am just wondering how much does the wine source located on http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz differ from 20040716. RTFM diff -r I guess its codeweavers internal patched version, I see changes in there dating to January. Are there any restrictions on using this source? Read the license. This source is under the license attached to it. Most (if not all) of it should be LGPL. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Microsoft genuine downloads looking for wine
Mike Hearn wrote: On Thu, 17 Feb 2005 07:45:11 +0200, Shachar Shemesh wrote: In any case, at least from a technical point of view, going around such test ought to be fairly simple If the mere existence of this key makes the validation fail, what's to stop a virus from simply adding this key as a way to stop legitimate users from downloading the security fix for that same virus? If MS is really doing what we think they may be doing here, I don't think they are going to be enjoying it for long. They are (what else is new?) shooting themselves in the foot (again?). I don't think we want to go there. I demonstrated a way of checking for Wine to Rob last night that we really cannot fix or workaround, and if I can think of it they certainly can too. I think I know what way you are thinking of. Not sure someone less versed in the way Wine works (it's an emulator, right?) would figure that one out, but I guess you are right. I'll try to catch you on IRC and see if we are, indeed, talking about the same thing. Basically if we start integrating workarounds into Wine, it'll lead to an arms race we cannot possibly win. Technically, it will probably cost them more than it will cost us. Then again, they also have more resources. I'll just point out that I don't think there is anything inherently wrong with MS wishing to keep the parts that truly are core Windows for Windows legal license users only. The main problem with MS is that what they call "core OS" can get quite absurd. Better to ensure our users don't need anything from that website. Amen to that. So, opengl, dcom, what else do we need? :-) thanks -mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Microsoft genuine downloads looking for wine
Jonathan Wilson wrote: I expect that the check program will be reverse engineered and cracked to return "genuine" even for pirate copies in fairly short order. Doesn't relate to us in any way. We are not pirates. Either that or the pirates will just grab the patches and circulate them on the pirate sites anyway. That one, unfortunately, I doubt. The patches are the least interesting thing for pirates. If pirates cared about keeping their machines secure, we would have all been at a much better position today. -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Microsoft genuine downloads looking for wine
Ivan Leo Puoti wrote: A valid and working code is returned if the version is set to xp. Still, even if this is only an initial attempt, they appear to want to discriminate wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads. It's also the first time Microsoft acknowledges the existence of Wine. Ivan Leo. Let's wait until they actually do something bad before we go around accusing them, shall we? In any case, at least from a technical point of view, going around such test ought to be fairly simple. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: IDC_RIGHT, IDC_CENTER not defined ?
George Ginden wrote: George Ginden ha scritto: OK I'm trying to implement text alignment in the edit control. Now, one question how do I know (in the EDIT_WM_NCCreate for example) if the text alignment has been requested by the programmer ? Nevermind, I've figured it out. Now I need to set the "caret" position within the edit control... Something which converts x,y coords to the column would be cool... Eg: text is at x offset, and the cursor position should be updated as well... EDIT_SetCaretPosition at x, y ... Regards. If you use "GetCharacterPlacement" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4l84.asp), you will get the following: 1. A list of pixel offsets for each character. 2. Caret position. 3. For future BiDi support - logical to visual mapping. I.e. - the next character logically is three characters down visually. Please consider using it, so as my task (when I finally get to it, sigh) will be easier. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Software Freedom Law Center
Brian Vincent wrote: On Tue, 01 Feb 2005 07:38:42 -0600, Jeremy White <[EMAIL PROTECTED]> wrote: I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients. I think this is an excellent idea. A little of my experience with lawyers. I fully trust Jeremy to know this, and know how to handle this. Still, it's something to keep in mind. Lawyers are hired to cover their asses. When you go out to consult with one, they are usually trained to do just one thing - alert you to the dangers of the actions you are about to take. Actually, at least in Israel, malpractice laws more or less require them to do so. It is therefor usually not beneficial to ask them questions that revolve around "is there a risk in doing". Almost always the answer will be "yes, there is". You usually want to know not whether there are risks, but what these risks are. A lawyer can sometimes help you with that, but more often then not can't. Your three ideas were great. I can also think of a few other things: 1) EULA enforcement. Are there areas where EULA's don't apply, is that information useful to us in any way, or is it information we want to publish? I can answer that one for you. Sometimes they are, sometimes they are not. I'm pretty sure I've read about precedences pointing both ways. For example - an EULA where the user has a chance to read it before making the actual transaction is more likely to bind. In my eyes, an EULA that comes way after you have already started using the product, such as with the Microsoft Updates site, cannot be binding (but that's just me). The question is therefor not whether EULAs apply, or whether any specific EULA applies. It's whether you are likely to get sued. 2) Along the same lines, I'm sure most MS EULA's have boilerplate that says, "If any part of this EULA is unenforceable, it does not affect the other parts." Are there any parts of MS EULA's that aren't enforceable because they are a monopoly? What about redistribution rights? Can the "core fonts" be packaged? I can give you my answer to the last one. No, they cannot. You need to remember that Microsoft is likely not even the copyright owner. Also, fonts are typically protected by something called a "design patent". We can gather some money (I think it's somewhere in the $50K area) and buy copyright and patent license for distributing them. It's been done with some Hebrew fonts and OpenOffice - you are allowed to give those proprietary fonts with OpenOffice, but only if it's a release sanctioned by Sun. I think the more important aspect here is a moral one - these is copyrighted work. We need to respect this copyright. -Brian Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Richedit using program
In case anyone is interested, there is an open source (GPL) notepad replacement which does syntax highlighting. You can grab it at http://notepad-plus.sourceforge.net/uk/site.htm. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
Jeremy White wrote: Fourth, the Wine server had an issue with the way it managed it request queues. To be honest, I don't understand this bug or the fix; all I know is that Mike McCormack figured this one out and posted a magic fix. This was, I believe, the primary reason that the wineserver would chew 100% cpu with iTunes. From what I understood from him, this had a lot to do with the "epoll" change I investigated some time back. I'll let Mike say whether that is so. If it was, it was merely the time it takes to copy the list of file descriptors to check into kernel space, and the list of modified descriptors back. I've had a client with this problem a while back. http://winehq.org/?issue=238#epoll%20(con't) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: dcom95.exe removed from sf.net
Ivan Leo Puoti wrote:
Jeremy Newman wrote:
No, we need reliable US and international mirrors. Don't remove the file
again please.
Content located on any SourceForge.net-hosted subdomain which is
subject to the sole editorial control of the owner or licensee of such
subdomain, shall be subject to the OSI-approved license
We are violating the sourceforge.net rules, I don't believe this is
acceptable, and sf could even
close down the project pages for this
It is unlikely they will, but we are violating their TOS and this
isn't a nice thing to do.
Ivan.
So why not ask them for explicit permission, and take it down only if
they say no?
Also, they are hosting the "corefonts" project, which is 100% files of
the same type license as dcom95, so I find it hard to believe they will
say no.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: gmail invitation
Izak Burger wrote: http://ars.userfriendly.org/cartoons/?id=20041013 I have another six if anyone else desperately wants one... :-) You think that's good? I got this one http://ars.userfriendly.org/cartoons/?id=20040622 Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: MFC app and WineLib
Serge S. Spiridonoff wrote: I expected that answer :( Anyway, I've managed to compile MFC source but got stuck at linking... 1) The output file is mfc.dll.EXE.so which doesn't seem right. Oviously I have to pass some extra switches to either wineg++ or winebuild but I can't figure out the correct ones. 2) I suspect I need a .spec file too, right? Is it possible to generate it from mfc42.def that goes with MFC source? What about C++ name mangling? Serge Something is wrong with your makefile. You are calling winegcc with the wrong flags. Care to send the list your makefile? Was it generated with a fairly recent winemaker? If so, did you use "--dll"? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: <> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive
Kuba Ober wrote:
I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type
edit \\server\myhome\file.txt
And it opens it just fine.
Similarly, I can type
dir "\\server\shared files"
I'm sure the DOS utilities just use long file name APIs and those "simply
work". It should be the same for win32 apps.
This is networking stuff, though. Now as far as virtual namespaces go, I have
no idea.
Try to go to the temporary internet files folder. Under explorer you see
the shortcuts and their location. From dos (do "dir /a") you see just
"Content.IE5" and "Desktop.ini" (which is what makes this folder a shell
extension).
This involved some {guid} stuff in the name, but I sure doubt that CreateFile
would dig that.
It won't. This is a *shell* extension.
Maybe the unix stuff can go under \\__unix\something ?
That's an interesting idea, actually. I actually don't think that we
need to change anything in wine.
mkdir -p ~/.wine/dosdevices/unc/__unix
ln -s / ~/.wine/dosdevices/unc/__unix/root
That should give you a link to the files the way you want them. I'm too
out of touch of the thread to figure out whether that solves our
problems. If it does, we can just have wineprefix create create this
link
Cheers, Kuba
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: A new systray patch
Mike Hearn wrote: On Mon, 2004-12-13 at 20:16 +0200, Shachar Shemesh wrote: I'd love to get my digital camera syncing on Linux (Mustek). It uses a shell extension. Good enough reason for you? :-) Is a shell extension really the only way you can access the camera? That's pretty poor UI design if so (imho :). I no choice but to agree. It came in cheap, and I don't heavily rely on it. Otherwise I wouldn't have gone for anything short of a camera that acts as a USB storage device. What desktop do you use, if any? KDE. Maybe we can add bridging shell extensions to the list of fun tasks. Hmm. Like I said in an earlier email, a shell extension (including a complete hand-coded OLE server) was my first Windows program ever. Since then (1996), however, I have done a lot of other stuff, and have blissfully wiped out most of the knowledge in that area. If I win the lottery (or enough people decide that I'm worthy of an award), I /may/ pick something like that up. Until then, however, don't count on me. Just today I noticed that an edit control partial update optimization totally breaks BiDi display, so it's unlikely that my mainstream work will abate any time soon. As for the camera, USB support has to work before we can do anything with that. It will probably be simpler to get kamera to support the MDC 3000. If you reached this page through a search on the camera's support in Linux - just veer away from it. No optical zoom, all pictures taken relying mostly on the built-in flash overexpose. No reason to buy it unless you got it as a gift. thanks -mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: A new systray patch
Mike Hearn wrote: Shachar Shemesh wrote: Though, if we would want to support shell extensions, I don't see how we could effectively do it without having it do everything the native explorer does That would be the other reason. But, I think it makes more sense to try and bridge shell extensions to Nautilus/Konqueror rather than reimplement Explorer-the-file-manager. At least, that's what I'd try first. Flip side is I'm not aware of any shell extensions people want to run on Wine, at least, not yet ... I'd love to get my digital camera syncing on Linux (Mustek). It uses a shell extension. Good enough reason for you? :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: A new systray patch
Alexandre Julliard wrote: Calling it Explorer would imply that it's supposed to do everything Windows explorer does, which seems a bit dubious to me. It'd be like calling the wineserver the winekernel. No, I don't see why it implies that it has to do everything the Windows one does, but it has to do everything that some apps depend on. Though, if we would want to support shell extensions, I don't see how we could effectively do it without having it do everything the native explorer does.... Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: some description for ExtTextOut
Vitaly Lipatov wrote: + *ETO_GRAYED - undocumented on MSDN + *ETO_OPAQUE - use background color for fill the rectangle + *ETO_CLIPPED - clipping text to the rectangle + *ETO_GLYPH_INDEX + *ETO_GLYPH_INDEX - Buffer is of glyph locations in fonts rather than encoded characters. Implies ETO_IGNORELANGUAGE + *ETO_RTLREADING + *ETO_RTLREADING - Paragraph is basically a right-to-left paragraph. Affects BiDi ordering + *ETO_IGNORELANGUAGE + *ETO_IGNORELANGUAGE - Undocumented in MSDN - instructs ExtTextOut not to do BiDi reordering + *ETO_PDY - unimplemented + *ETO_NUMERICSLATIN - unimplemented + *ETO_NUMERICSLOCAL - unimplemented + *ETO_NUMERICSLATIN - unimplemented always assumed - do not translate numbers into locale representations + *ETO_NUMERICSLOCAL - unimplemented - Numerals in Arabic/Farsi context should assume local form Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wine Bug Busters @ 7pm GMT
Mike Hearn wrote: Likewise, if you're wanting to get into Wine hacking but aren't sure where to start, or started but got stuck, or just have questions to ask those who already climbed the learning curve then this is a great chance. You don't have to be a developer, feel free to come and watch even if you're just interested in seeing how it's done. Damn, had to miss it. Any impressions from the event? IRC logs? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: <> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive
Steven Edwards wrote: --- Mike Hearn <[EMAIL PROTECTED]> wrote: What's wrong with additional APIs? The browse folder API isn't COM based anyway. It would be much better to use the API provided to create a namespace for the Unix filesystem. The Control Panel and Network Neighborhood are good examples of this. Quite a few third party apps create a virtual namespace for things like CVS so I don't see why we can't work in the existing API to do this with the Unix fs. Thanks Steven It's been a LONG while since I messed with shell extensions. However, if my memory serves me right, you cannot pass virtual namespaces to "CreateFile" and friends. The only one who knows how to work with virtual namespaces is explorer. That may not be much of a problem for the winecfg utility, but it's something to consider. Esp. being that we don't have a proper explorer (and none is planned for Wine that I know of, and ReactOs doesn't seem to need Posix filenames...) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: <> Added shell32.dll functions to browse for unix directory;
Robert van Herk wrote: So yes, I could put it all in a structure on the stack and then pass it to the dlgproc, but it will only arrive there on WM_INITDIALOG. However, I will also need the structure when the other messages come in. So where do I save it then, if I cannot put it in a global var? Am I missing something? Robert One option is to store it inside the dialog itself. Use "SetWindowsLong" to store the pointer. Just make sure that you pass the right parameter on to WM_INITDIALOG, and that you deallocate the struct (if it's allocated dynamically from the heap) before the window is destroyed (WM_DESTROY is a good bet). Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wine book
I'm not sure what I'm writing here is appropriate for actual "headings". It's just some points to keep in mind when writing the actual chapters. Brian Vincent wrote: [1] Chapter outlines: Title: "Wine: Running Windows Applications on Linux" [4] 1. Wine Introduction[15 pages] What is Wine? How Can Wine Help You? An Introduction to Windows Components Overview of Wine's Components Recent Changes to Wine A History of the Wine Project How Can You Get Wine? Back to earth - what will wine not do at this stage. 2. Installing Wine [20 pages] System Requirements Bundled Versions Downloading Packaged Versions Accessing CVS Compiling and Installing Wine The soft vs. hard dependencies. How to tell whether you have everything you need. Uninstalling Wine 5. Installing Common Programs [35 pages] Microsoft Office Internet explorer? Adobe Photoshop File Utilities Peer-to-Peer Applications Further Help: The Wine Application Database 10. Introduction to Winelib [20 pages] Introduction to Winelib Make sure you mention here that you'll still need wine at the end of the day! Licensing Considerations Portability Considerations Getting Started Understanding the Winelib toolkit A Roadmap for Porting Installation of the MinGW Compiler 13. Advanced Porting Techniques [25 pages] C++ Problems Working with Microsoft Foundation Classes Actually, Boaz can probably help you with: Working with Advanced Template Library Working with Templates Moving From Visual Studio to MinGW PPS. I'd like to think this won't affect WWN because I really have no life. However, that's not too realistic. Hopefully WWN won't suffer too much. Let's hope so. Good news is that you'd have to keep on the wine mailing list. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Implement GetLayout
Rémi Assailly wrote: Shachar Shemesh wrote : Thanks for spotting another one for my growing heap of BiDi TODOs http://bugs.winehq.org/show_bug.cgi?id=2584 Shachar I know that there is no effect... I'm sorry if I came off cynical. There was no cynicism in that comment. I opened 2584 as a result of seeing your patch. I was not aware of this particular missing functionality. I'm aiming for http://bugs.winehq.org/show_bug.cgi?id=609 to be the ultimate documentation of all BiDi APIs in Windows. Opening 2584 is a good thing, as it documents things that are still to be done. What is wrong ? It seems that this flag reverses the meaning of several common conventions (left/right etc.). The idea is probably so that applications that are natively right to left not have to change their design too much. I can't tell you exactly what it means, however, as I don't know myself. It will probably be a matter of comparing behaviors to the real Windows. I have some doubts about whether anyone is even using this flag at all. Maybe on localized Hebrew Windows, where the whole window decorations are reversed (Ughh. My GF has localized XP Home installed. This thing is horrible, but I didn't spot any non-Windows native applications that were affected by it). Tell me and I will help you, if you want... I'll gladly accept all the help I can get. Basically, this particular unimplemented bit requires writing small test programs on Windows, and then running them on Wine until they produce the same results. The idea is that you read the MSDN page for the function (linked from the bug). That page also links to http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowfeatures.asp?frame=true#layout_mirroring, which gives more details on what this flag is supposed to mean. If you check out 2584 again, you will see I added this new information there. The steps one takes is to read all the relevant manuals, and try to understand what this means. Next, you write a small test program that does stuff with and without this flag, showing where this flag takes effect on Windows. Next, you move this test program to Wine and start tweaking Wine until it behaves the same there. There is also a last step, which is to make this program into a test suite, returning success or failure. I'm not sure, however, how that is supposed to be done for programs where success and failure are measured with graphical output. Hope this helps you help me help everyone. :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Implement GetLayout
Rémi Assailly wrote: I added some things to my previous patch. Please tell me if something seems incorrect or is missing Thanks ;) Changelog: * implement GetLayout Thanks for spotting another one for my growing heap of BiDi TODOs http://bugs.winehq.org/show_bug.cgi?id=2584 Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: No RichEdit20A window class
Krzysztof Foltman wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Packaging Questions, New Debian Package, Packagers Guide
Francois Gouget wrote: On Wed, 24 Nov 2004, Shachar Shemesh wrote: Marcus Meissner wrote: Here is a list of the soft dependencies. We suggest packagers install each and every last of those before building the package. These libraries are not dependencies in the RPM sense. In DEB packages, they should appear as "Suggests" or "Recommends", as the case may be. ICU Adds support for BiDi to Wine. http://oss.software.ibm.com/icu/. Instructions for building (and testing) with BiDi are available at http://winehq.org/?issue=218#How%20To%20Set%20Up%20BiDi%20Support The problem with ICU is that, iirc, it introduces a dependency on libstdc++, and, afaik, libstdc++ binary compatiblity is broken quite often. This is probably not an issue for the Debian packages which we can expect to be rebuilt whenever a libstdc++ becomes the Debian standard. But it's a problem if one wants to build a somewhat generic RPM package that can be installed on anything from RedHat 8 to Fedora Core 3, or on RedHat, Mandrake and SUSE. So if the Package Maintainer's guide recommends building with ICU, it should also mention this issue. Sounds fair. I'll also mention that I'm working on moving the dependency out of the core wine functionality. I.e., if the dependency is not there, it's just BiDi that won't work. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Packaging Questions, New Debian Package, Packagers Guide
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers
install each and every last of those before building the package.
These libraries are not dependencies in the RPM sense. In DEB packages,
they should appear as "Suggests" or "Recommends", as the case may be.
ICU
Adds support for BiDi to Wine. http://oss.software.ibm.com/icu/.
Instructions for building (and testing) with BiDi are available at
http://winehq.org/?issue=218#How%20To%20Set%20Up%20BiDi%20Support
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Packaging Questions, New Debian Package, Packagers Guide
Scott Ritchie wrote: However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine? ICU is compiled statically. There is no runtime dependency on libicu. It is an exception, however. The general rule should be that the optional packages are build-dep, but only "suggested" or "Recommended" (I've never really managed to understand the difference between them) for the compiled result. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Problem roundup
Vincent Béron wrote: So all this boils down to is that RH shipped a glibc update which broke backwards compatibility, with the same version number (glibc-2.3.2). A Wine compiled on the newer version takes advantage of epoll support being present, but will refuse to run on the older version. Had only that been the case. The newer glibc has the "epoll" symbols, but if you try to invoke them, they'll always return "not implemented". It's one of the weirdest moves by RedHat I've seen. Now, the obvious question is how can we prevent that in the future? Specify a glibc version-release (we'll get users rpm --force'ing it, a future glibc update can (or not) break it, etc.)? Probably not. Let a Wine compiled with epoll support run on a epoll-less system? I tried that in my original patch. That approach was rejected. Another question to finish: how do other users of epoll handle all this? Use libevent? Sorry, couldn't resist :-) Vincent Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll, LSB
Robert Shearman wrote: Shachar Shemesh wrote: I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK". As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too? Windows uses ntdll. We don't want to get rid of wine_unicode because it is also used in wineserver and that obviously cannot use ntdll. Rob A very good reason. One that doesn't apply to BiDi, though. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: KERNEL32: add a test case for CompareStringW undocumented flag 0x10000000
Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
The flag (0x1000) passed to CompareString reverse the sort order
of a number of unicode characters. I've got no idea why it would
want to do that... maybe somebody can shed some light on what the
reason behind this would be?
Attached is a small test case that demonstrates a problem in Wine's
compare string. Explanation:
The word "Mohammad" is spelled in Arabic Meem, Hah, Meem, Shadda, Dal.
The Shadda's purpose is to double the pronunciation of the preceding
letter, which is the reason it's written with a double M in English. The
attached program uses "CompareStringW" to compare the proper spelling of
"Mohammad" to three variations. One is the version without the Shadda at
all (as Mohammad is usually spelled by modern Arabic writers), one is
Mohammad with the Meem explicitly doubled, and one is the same as the
last one, where the second Meem is replaced with the preceding letter
(Lam). They are noted as "mohamad", "mohammad" and "mohamlad"
respectively. The one with proper spelling is noted as "moham_ad".
moham_ad is compared against all three with no flags, with the
"NORM_IGNORENONSPACE" flag, and with our unidentified flag. The program
was run on Windows 2000 and on Wine.
On W2K, moham_ad is sorted between mohamlad and mohammad. If
IGNORENONSPACE is used, it is exactly equal to mohammad. One wine,
moham_ad is less than all three. This means we have a bug in Wine.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
// compare.cpp : Defines the entry point for the console application.
//
#include
#include
WCHAR mohamad[]={0x645, 0x62d, 0x645, 0x62f, 0};
WCHAR mohammad[]={0x645, 0x62d, 0x645, 0x645, 0x62f, 0};
WCHAR moham_ad[]={0x645, 0x62d, 0x645, 0x651, 0x62f, 0};
WCHAR mohamlad[]={0x645, 0x62d, 0x645, 0x644, 0x62f, 0};
const char * compare( WCHAR *mountain, DWORD flags )
{
switch( CompareStringW(LOCALE_SYSTEM_DEFAULT, flags, moham_ad, -1, mountain, -1 ) )
{
case CSTR_LESS_THAN:
return "less than";
case CSTR_EQUAL:
return "equal";
case CSTR_GREATER_THAN:
return "greater than";
}
return "Error";
}
void test( DWORD flags )
{
printf("\nTesting with flags %08x\n", flags);
printf("One m - %s\n", compare(mohamad, flags));
printf("ml - %s\n", compare(mohamlad, flags));
printf("Two m - %s\n", compare(mohammad, flags));
}
int main()
{
test(0);
test(NORM_IGNORENONSPACE);
test(0x1000);
return 0;
}
Re: epoll, LSB (was: Re: Problem roundup)
Dmitry Timoshkov wrote: That's my point here: we don't need an external unicode solution, we already have one, we just need to add missing parts, and we really don't want to depened on ICU or anything else. I think the source of the problem is a small misunderstanding about what LPK.DLL does on windows. It's not where the reordering algorithm is. That's in uniscribe. What's there is how this reordering algorithm is used for ExtTextOut, DrawText, EditControl and so on. As such, I think it's best if we did the same in Wine. Since the interface to LPK.DLL is undocumented, I think it's best to use something with similar functionality but different name, say "WINELPK". As for the algorithm itself, I have no objection to it being implemented in wine_unicode. I'm just questioning the wisdom of that DLL. What does Windows use for the same functionality? If it's not there, where is it and why not put it there for wine too? As for the reordering algorithm, that should be implemented in USP10.dll under (ScriptLayout, ScriptStringGetOrder etc.). I don't see anything wrong with Uniscribe depending on ICU for the time being, in any case. Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do. I don't understand you: you were arguing some time ago that ICU is too bad as an external library and freebidi is not ready to be used in Wine. Now you want to use that approach anyway. It's really time to rethink your stance and either import an existing bidi code to Wine and use it as a base for further improvements, or find a replacement for ICU and start to use it. The reasons I stated against ICU are exactly what's haunting us now. It's too big, it depends on the C++ runtime, and you can't dynamically link it. Other than that, it's a great library. I'm just hoping that if another DLL had these problems rather than GDI, end users would suffer less. Particularly if that new DLL was a soft dependency, (as LPK is in Windows, BTW). Fribidi would have been great, if only it supported UTF-16. It doesn't, and adding UTF-16 support is non-trivial. There were structural changes that were meant to take place to make UTF-16 support easier, in which case I was planning on implementing it upstream. It is also easy to dynamically link fribidi. However, these changes are taking their time in happening, so we use ICU for the time being. None of this translates to "we'll write our own". As for taking one of those code's and making them our own, I simply don't see what's there for us to gain. ICU is C++, nothing we can reasonably do will change that. Fribidi is difficult to add UTF-16 support to at the moment, so we gain nothing there too. Writing our own is a headache of magnitudes I don't want to even think of. String folding, case mapping, character types, collation, decomposition, code page conversions are already implemented in wine_unicode, I don't see why bi-di can't added there as well. If we would think in terms of laziness Wine would be nowhere these days. Because BiDi already has a well determined place in Windows. That place is uniscribe. Uniscribe does a little of the other things as well, but quite frankly, not much. At least not that I could make out. As such, I vote for implementing stuff where it should be. This also has the extra benefit of making uniscribe the one depending on ICU, not GDI. Assuming GDI's dependence on Uniscribe is through LPK, and that LPK is a soft dependency, this means that users that don't have the right C++ runtime, don't want the extra size, or can't get ICU depending DLLs loaded for whatever other reason will still be able to use Wine (though not Uniscribe, which I think is only fair). Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: KERNEL32: add a test case for CompareStringW undocumented flag 0x10000000
Dmitry Timoshkov wrote: "Mike McCormack" <[EMAIL PROTECTED]> wrote: The flag (0x1000) passed to CompareString reverse the sort order of a number of unicode characters. I've got no idea why it would want to do that... maybe somebody can shed some light on what the reason behind this would be? Just a shot in the dark: perhaps the flag is supposed to force CompareString to make character reordering first (taking into account bidirectional layout) and only then do an actual string comparison? A. BiDi strings are compared in logical order. Reordering is just about the last thing you do before display. B. This changes the greater than/less than semantics, not the order. Then again, this does not make sense any way you turn it. The regression test shows that table 1 is lower than table 2 with the flag, higher without. Let's look at it: table 1 has three characters in various forms. These are Arabic "Shadda", and two CJK marks (prolonged sound mark and iteration and sound iteration marks). table 2 has quite a bit of characters. Taking the range I know well (Hebrew - U0590-U05FF), it has all the diacritics and "Ta'amim" marks. This makes no sense. I even asked on the Arabeyes project's IRC channel. Comparing Arabic and Hebrew is totally meaningless. The other characters in table 2 belong to the following languages: Spacing modifier (U02b0-U02ff), Combining diacritical marks (U0300-U036f), Greek (three characters, all marked as "reserved"), Cyrillic, Devanagari, Bengali, Gurmukhi, and that's where I gave up on looking up the names of languages I didn't even know existed. I will mention "Combining marks for symbols", though, which I think is crucial to understanding this. I will also mention "CJK Symbols and Punctuation", range U3000-U303F, and the Hiragana range U3040-U309F. Now, here's the thing. ALL the symbols in table 2 are diacritic or punctuation symbols written either below or above the letter. They are combining marks which do not change the letter's width. On the other hand, Shadda in Arabic means to double the pronunciation of the character it combines with. In other words, this undocumented flag means that letters that are doubled in Arabic should come after other languages' diacritics. It's still apples and oranges, but maybe we have a clue as to "why". Does anyone here know what the CJK marks mean? Out of interest, could it be that U0A01 needs to be added to table 2? If so, we may have a solution to what this flag means. Mike, can you test it out? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll, LSB (was: Re: Problem roundup)
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: Eventually we have to implement bi-di support there without relying on any external libraries. BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on earth should we insist on writing it ourselves? We don't really have to write it from scratch, porting an existing code would suffice, but a difference between unicode char width (16 vs. 32 bit) makes it impossible to use any system unicode APIs. Lost you there. We are currently using ICU precisely because it does have UTF-16 support. Another reason to have an internal implementation is to not depend on possible differences between implementations, differences in collation tables is an obvious example here. Lost you there again. There is no dependence of BiDi on collation, or we would use ICU for a lot more than only BiDi. ICU is an entire Unicode solution, and does have all of those things. Seriously, I don't see anyone here volunteering to maintain the BiDi code, and I don't have the resources to chase Unicode around. I really think using an external library is the right thing to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll, LSB (was: Re: Problem roundup)
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Hmm. Would separating the BiDi code (which is the reason ICU is linked
with GDI) into a separate DLL (they way it is on Windows 2000) help?
We have wine_unicode.dll for that and many things are already separated
there, like unicode, case map, collation tables and appropriate algorithms.
After some looking into it, I think this is the wrong place to place
BiDi. At the moment, Windows does BiDi (depending on version) at either
function level, LPK.DLL or uniscribe. In other words, Windows already
have specific locations where BiDi is performed.
wine_unicode, on the other hand, is just a helper used internally by
wine. The thing we REALLY should do in the long run is implement
uniscribe. That's where BiDi really must be.
Eventually we have to implement bi-di support there without relying on any
external libraries.
BiDi is a $&!(@*#)$ complicated algorithm (excuse my language). Why on
earth should we insist on writing it ourselves?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: epoll, LSB (was: Re: Problem roundup)
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help? We have wine_unicode.dll ... Eventually we have to implement bi-di support there without relying on any external libraries. why? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll, LSB (was: Re: Problem roundup)
Mike Hearn wrote: There have been discussions about this on fedora-devel, I think the conclusion was that you don't need to do this. Basically compiling for i586 using athlon scheduling should give great results on all processors even P4 due to the internal chip designs, or somesuch. I think an i686 build of Wine will bear close resemblance to an i386 build as we have no hand written assembly that would benefit and the new instruction i686 provides over i586 is quite specialist and not used by gcc nor Wine. At least this is my understanding. No, that's not what optimizing does. The instruction set of all CPUs since 386 is virtually identical, and since 486 is almost completely identical. HOWEVER, different internal CPU structure means that the CPUs progressively approach the RISC architecture. One of the characteristics of the RISC architecture is that the compiler is very aware of internal CPU structures, pipeline lengths and bubbles. When you switch on i686 optimization, actual produced instructions would probably not differ much. What would differ is the order in which they are produced. Code optimized for 686 would run on 586 (and probably 486 as well), but not run as fast. I don't know how significant this impact is. Wine is not very CPU intensive. It's just something to keep in mind. Compound that with the fact that I provide for quite a few older versions of RH (RH7.3, RH8, RH9) and FC (FC1, FC2, soon FC3) and WBEL (WBEL 3), and that there are wine-devel packages too (only the i386 flavor), and you get the big quantity of packages there are. Yes while we're on the subject the FC2 RPMs are compiled with libICU giving GDI32 a dependency on libstdc++ 5, whereas FC3 apparently only installs libstdc++ 6 by default requiring the user to install compat-libstdc++ (assuming they can diagnose the linker/rpm error of course). This came to light because a user tried to install the FC2 RPM on FC3 due to lack of FC3 RPMs. Hmm. Would separating the BiDi code (which is the reason ICU is linked with GDI) into a separate DLL (they way it is on Windows 2000) help? It's something I want to do anyways because: 1. It's how it is on Windows. 2. It would probably allow CrossOver to come with BiDi support. 3. GDI is not the only BiDi consumer. Specifically, DrawText needs to be BiDi aware, as well as the Edit control. This would mean that the same problem would still happen for Israeli and Arabic speaking wine users needing FC3 RPMs, but it would not block everyone. Do you think I should add an explicit dependancy on the redhat-release (or fedora-release) package, so people don't install them on the wrong distribution? That might help yes. I hate that solution. I've been bitten by overly strict dependencies before. If you require libstdc++5, mark as depending on it. Same goes for libc versions. Also, don't forget the people which will try to install a Mandrake rpm on SuSE, or a SuSE one on RH (without any thought about the versions involved). It's a mess, but Wine does some things so close to glibc that it's difficult to provide a "one binary fits all" without compiling an a very old setup (such as what Mozilla and probably CX do). Personally, I think the right way to solve that one is to fix the dependencies in the spec file. I don't see any reason for a RH RPM to install on SUSE and not run. If it installs, it should run. If there are library differences, it shouldn't install, citing the library it needs. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Problem roundup
Vincent Béron wrote: Le ven 19/11/2004 à 09:02, Mike Hearn a écrit : 1) The RH9 RPMs are apparently being compiled with epoll support linked in. This is causing user pain. We should really be using dlsym here, why are we not again? If you're talking about this thread (http://www.linuxquestions.org/questions/showthread.php?s=&threadid=252670), then I didn't reproduce it on my RH9 setup when I released 20041019 (I have a video card fan problem right now, so the video card in that computer is now in my main computer, so I can't test it just right now). I guess the user have a different kernel/glibc than I do (I'm using RH9+updates from RH for RH9+updates from FedoraLegacy for RH9 as of the releases of Wine). The epoll detection/support is not very robust yet it seems. It's not that. The problem seems to be that RH updated their glibc major version number. Maybe you need to create a dependency in the RPM for a specific glibc version (>=2.3?). That's the reason my original epoll patch was using syscall, btw. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: prevent peekmessage from crashing when msg == NULL
Juan Lang wrote:
I try to do a make test before
sending in a patch to make sure I didn't regress anything (fortunately
Alexandre seems to as well).
Problem is that, for me, make tests fails on vanilla wine. For that
reason, I don't usually bother. I have never managed to figure out what
is causing these failures.
For example, just got a fresh CVS, compiled and ran the tests:
make[3]: Entering directory
`/home/sun/sources/wine/wine/dlls/dsound/tests'
../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p
dsound_test.exe.so capture.c && touch capture.ok
../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p
dsound_test.exe.so ds3d.c && touch ds3d.ok
../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p
dsound_test.exe.so ds3d8.c && touch ds3d8.ok
../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p
dsound_test.exe.so dsound.c && touch dsound.ok
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x88780078
dsound.c:177: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
DSERR_NODRIVER
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x88780078
dsound.c:186: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
DSERR_NODRIVER
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x88780078
dsound.c:195: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
DSERR_NODRIVER
fixme:ole:CoCreateInstance no instance created for interface
{11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x80004002
fixme:ole:CoCreateInstance no classfactory created for CLSID
{11ab3ec0-25ec-11d1-a4d8-00c04fc28aca}, hres is 0x80040154
make[3]: *** [dsound.ok] Error 3
make[3]: Leaving directory `/home/sun/sources/wine/wine/dlls/dsound/tests'
make[2]: *** [tests/__test__] Error 2
make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/dsound'
make[1]: *** [dsound/__test__] Error 2
Is this something wrong on my config?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Kernel 2.6.9
Paul Rupe wrote:
Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with
this version that don't happen when I reboot back to 2.6.8.1. I haven't
had much luck debugging it so far, but each time, ps shows a
wine-preloader process and wineserver still running.
What happens when you kill the wineserver?
I have seen errors where killed wine processes remained defunct even
after their parent has died. They were rebooted to init, but still
remained defunct. In certain (RedHat 2.4) kernels, such processes could
even keep sockets bound to ports, requiring a reboot.
While this is obviously a kernel bug, I wasn't able to form a
reconstruction in a way suiteable for having a kernel guru have a look
at it. The system with which this problem was happening was too complex
(and proprietary) to ship to someone else, and the problem was inconsistant.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Do we need one of those on our docs?
From the samba developer's guide, http://us1.samba.org/samba/devel/ *Important:* In order to avoid any potential licensing issues we also ask that anyone who has signed the Microsoft CIFS Royalty Free Agreement <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cifs/protocol/royalty-free_cifs_technical_reference_license_agreement.asp> not submit patches to Samba, nor base patches on the referenced specification. We ask, too, that patches submitted to Samba not infringe on any known patents. Finally, as with all GPL work, the submitter should ensure that submitted patches do not conflict with any third-party copyright. Do we need to put in something like that too? I'm not a lawyer (but I can probably get one). My understanding is that the "protocols" Microsoft policy don't really affect us. What may affect us is the wider and wider distribution of the Windows source code (Shared Source). We should not be highly affected by trade secrets: anyone publishing a trade secret is nullifying the secretness of it, and is the one bearing the responsibility for this action. However, copyright problems may be a problem for us. If someone takes a significant amount of code from MS and submits it, we may have some backtracking to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: rsaenh
Alexandre Julliard wrote: Juan Lang <[EMAIL PROTECTED]> writes: Looks good to me, Michael, though I'd suggest using /dev/random rather than /dev/urandom: the blocking behavior of the former shouldn't be a problem for Wine (since this DLL makes no timing guarantees anyway). That doesn't mean we want to block, especially for things like CPGenRandom that don't require the highest quality randomness. I think in general /dev/urandom is a much better choice. I'm with Juan here. I think urandom is not good enough. In general, /dev/random should be used when cryptographic keys are required. MSDN is fairly clear on this matter (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cpgenrandom.asp): *CPGenRandom* is one of the more difficult functions to implement correctly, and it must be done correctly to maintain the security of a CSP. *CPGenRandom* is used internally by the *CPGenKey* <http://msdn.microsoft.com/library/en-us/seccrypto/security/cpgenkey.asp> function, as well by applications when generating data items used in cryptographic protocols such as challenge strings. A CSP is not producing message security if values of the cryptographic keys or challenge strings produced by a CSP are predictable. The way I read it, the rest of the discussion further enhances this point. They are basically saying that the seed should be taken from a hardware device, if one is available. If one is not available, they mumble that there are some alternatives, but make it clear that they are not wholly satisfied with the quality of randomness achieved. The way I read this, if we get our data from /dev/random we are at full liberty to disregard the input seed, as this is a hardware device seeding. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Gradient Color for Caption Bar
Mike McCormack wrote: William Poetra Yoga H wrote: Use GdiGradientFill (not GradientFill) to implement gradient caption bar (for now). GradientFill is pretty slow, as it files the rectangle line by line. I'm not sure how much this is going to slow down a normal application. It used to draw pixel by pixel, and that was a very noticable slowdown... line by line is much faster than that, but it still may cause a slowdown in some circumstances. Anybody have any ideas about how to speed up GradientFill? How many colors are typically drawn across a single bar? If this number is significantly less than the number of vertical lines, you can precalculate the width of each color bar, and draw a series of boxes. Mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: add epoll implementation to libwine_port (take 3)
Mike McCormack wrote: Boaz Harrosh wrote: [Q] Does that mean that we directly check if it is supported in kernel, bypassing glibc all together? how do we avoid conflicts with glibc? The definitions are wrapped by #ifndef HAVE_EPOLL_CREATE, which is set by a configure check. The end result is that we use this code if libc does not provide an epoll implementation, and use libc's if it is available. Mike You do realize that many (somewhat old) glibcs have epoll_create defined that is hardwired to return E_NOSYS without calling the kernel, right? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: UCS2 vs. UTF16 question
Hi Juan, I took the liberty of answering to the list. I hope you don't mind. Juan Lang wrote: Hi Schachar, something you said earlier this year at wineconf caught my ear, and I think I'm finally understanding enough to ask about it. You said Windows uses UCS2-LE (I think you did, anyway) rather than UTF16. Is that true? I most certainly didn't say that. I may have mentioned UCS4, but to the best of my knowledge at the time, Windows uses UTF-16. As a result of your email, I tried to check it again, however. The results are somewhat inconclusive. I generated a file (attached) containing two musical symbols in Unicode. These are from the codepoints above U1, and are therefor unrepresentable in UCS2. Opening this file up in notepad reveals a mixed result. On the one hand, they appear as two unknown characters (which seems to suggest that at least Notepad understands this is UTF-16LE). On the other hand, I did not manage to find any font that has any characters with codepoints above U1. I'm hoping one of our far-eastern speakers jumps in with more insight (Mike?). Are surrogates used on Windows? How common are they? Does that then imply that Windows really can't handle characters outside the Basic Multilingual Plane? Does that also imply that WCHARs are in fact fixed-width in Windows? As far as I know, they are not. Sorry. I'm planning to write a tool to detect the following problematic bit of code: char str[] = "hi", *p = str + sizeof(str) - 1; p--; At least, it's problematic when str contains double-byte characters. I'm not sure what you are aiming at achieving. Are you trying to hit the beginning of the last character of the string? If so, then you do, indeed, have a problem here. If the type of char and p were WCHAR * instead, and WCHARs are fixed width, there isn't a problem. If you have thoughts on similar programming bugs relating to internationalization (use of strchr and strrchr, for example) I'd be interested to hear them. In the past I have written programs that had to do MBCS (the non-unicode Japanese encoding). This is an encoding in which some characters are one byte, and some two. The best I could come up with was to build a wrapper around std::string that had two bytes per character internally. When you loaded a string, it would check character by character for whether it's a double byte, and then have each string location contain exactly one character. This allowed random access, as well as both forward AND backwards scanning. Fortunately, UTF is much better than MBCS. Given a byte in either UTF-8 or UTF-16, it's fairly easy to figure out whether it's part of a surrogate, and what part. If you have assurance that the string you are handling is a well formed one, you can do backward scans of a UTF string fairly easily. Thanks, --Juan ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com Do you want a gmail account? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Temporary fix to trying to put a pointer in a DWORD
Vincent Béron wrote: Besides the fact that HIDWORD and LODWORD (typo in LODDWORD) do not exist, Yes, I was extrapolating on existing macros for readability. it looks fine as long as you don't actually compile it. Writing those two and compiling yields the error "initializer element is not constant". Yes. You are right. If you try to cast them to "unsigned long long", you get the compiler to reveal the true problem: keyboard.c:86: warning: initializer element is not computable at load time Which is, I'm afraid, without solution. The compiler is not smart enough to understand that the cast (or a shift of 32 bits) is not really a mathematical operation, and will refuse to do it if it doesn't know the exact value at compile time. I tried doing the same thing with pointer arithmetics, but to no avail (the cast fails). I'm afraid this one bested me. I don't see a clean solution to this one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Temporary fix to trying to put a pointer in a DWORD
Vincent Béron wrote:
Le sam 16/10/2004 à 23:54, Dmitry Timoshkov a écrit :
"Vincent Béron" <[EMAIL PROTECTED]> wrote:
We try to put a pointer in a DWORD in a static initialization of
CRITICAL_SECTION_DEBUGs. Of course it doesn't work on Win64. We'll have
to find a better solution though.
Another way to fix it is to use full 'DWORD Spare[2]' to store a pointer
on Win64 and leave it as it is now for Win32.
I tried, but since it's a static initialization you don't have access to
& (addessof), so you can't put the high part in one and the low part in
the other. Maybe with a union, but then we'd extend a MS type.
Vincent
How about this, then?
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Index: dlls/dinput/keyboard.c
===
RCS file: /home/sun/sources/cvs/wine/dlls/dinput/keyboard.c,v
retrieving revision 1.9
diff -u -r1.9 keyboard.c
--- dlls/dinput/keyboard.c 21 Sep 2004 20:04:37 - 1.9
+++ dlls/dinput/keyboard.c 17 Oct 2004 05:23:04 -
@@ -75,11 +75,12 @@
static BYTE DInputKeyState[256]; /* array for 'GetDeviceState' */
static CRITICAL_SECTION keyboard_crit;
+static const char * const critsect_debug_strid = __FILE__ ": keyboard_crit";
static CRITICAL_SECTION_DEBUG critsect_debug =
{
0, 0, &keyboard_crit,
{ &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList },
- 0, 0, { 0, (DWORD)(__FILE__ ": keyboard_crit") }
+ 0, 0, { HIDWORD(critsect_debug_strid), LODDWORD(critsect_debug_strid) }
};
static CRITICAL_SECTION keyboard_crit = { &critsect_debug, -1, 0, 0, 0, 0 };
Re: Rename Wine User Guide to Wine User's Guide?
Scott Ritchie wrote: The Winelib documentation is called the Winelib User's Guide, but the Wine documentation is called the Wine User Guide. I think for consistency's sake we should rename the Wine User Guide to Wine User's Guide - afterall, it's a guide for the user, not about the user. Thoughts? Thanks, Scott Ritchie [EMAIL PROTECTED] After reading major parts of this thread, I can only come to the conclusion that it's time for me to rewrite my wine presentation. In particular, there is a part there about wine "not being ready". I guess, if we can spend over four days arguing about an apostrophe, then there is nothing to it but assume that all the coding is done :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wineconf 2005
Jeremy White wrote:
Thoughts? Comments?
First of all, unlike last year, I think we should definitely do it in
Europe this time.
Just wanted to reiterate the Cyprus idea (Jeremy, please don't tell me
you didn't see it coming). If it's there, I'll take care of
administrative stuff (hotel, conference rooms, etc.).
Cheers,
Jeremy
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Audit the buttons code
Dmitry Timoshkov wrote: I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true. I'd suggest to omit that single line of the comment, that's all. Again, that's the user32 code, and it really doesn't matter where MS has decided to put the docs for it. But how would someone reading the comment find the docs? Especially if the code is in User32 and docs are in comctl. Also, it would appear to me that you can't say "version 6" without saying version 6 of what. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Contributing to WINE
Hi Ronald, I cannot stress this point enough. Wine is a community project. Everyone involved in the Wine project would appreciate a chance to answer your questions, as well as hear what you have to say. Sometimes there is a need to establish private communication with certain people. As a rule, however, all technical guidance and discussions should be done on the mailing list. This way, everyone gets a chance to respond to your inquiries. Also, it appears that many participants of this list, as well as the web mail archive, are having problems with the format in which you send your emails. Please try to send mail to this list in plain text format. The format in which you sent me seems to be ok, but I cannot say for sure. Ronald Robin wrote: Hi Shachar, thank you for your response to my post. I am sorry for several things: First, that we have not tried posting to this mailing list before. We thought before that it would be better to establish communications first with the person who leads the project (i.e. Mr. Julliard). I guess that was my mistake. Second, that it took me a long time to respond back to you. You've been a great help. Thank you for the suggestions that you gave. I'm sure it would be most helpful in case we would need to hire some more help in the future. Anyway, I'd like to introduce myself again. I'm Ronald Robin of SpecOpS Labs. I am the Project Manager for the David Project. I'm in charge of managing the research and development efforts within our lab as well as those done by our partner universities an institutions including the the National Computer Center, De Lasalle University, and Ateneo de Manila Univesity here in the Philippines. As mandated by our President & CEO, Frederick Lewis and our CTO, Peter Valdez, we are glad to announce to you that one of my team's newer objectives is to regularly contribute to the WINE Community. To get things started with, I can assign some of our developers to focus working on something we can proudly contribute to the WINE community. We may not be able to dedicate a significant number of them, but it’s a start. Any development you can put towards the wine project would be appreciated and welcomed. I was wondering, is it ok for me to ask you some more questions? Better yet, ask everyone the questions. This way, you will get answers even if I happen to be busy, or not know the answer. I believe you're one of the best persons right now to help us get some ideas as to what particular problem areas we can focus our contribution efforts on. It would be really nice if my team can contribute something significant to the community. While I thank you for the complement, this is not how things usually work in a free software project. As you may know, Wine has several areas that could use a developer's attention. We don't know much about your company, so it would be hard to know what areas would be best for you to contribute in. First off, we would all appreciate if you sent any code you happen to change in Wine while working on David anyways. This basic form of contribution is usually the easiest for you to do. As for general areas of improvements in Wine, there are a few. Development there had better be coordinated with the people already working on these things. Probably the area most needing tender love and care is DCOM. While people are currently working on it, we still depend on Microsoft's DLLs in that area, which is not a good thing. Another place that could use enhancement is MSI. Personally, I also want to see better BiDi support, but that's something not many of the list's members care about as much as I. I'm sure other list members will be happy to fill in other areas where your help would be most appreciated. Thanks again. Any time. Cheers! Ronald Robin Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Audit the buttons code
Dmitry Timoshkov wrote: "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote: I've explained that already: the comment's purpose is to identify the *documentation* that the code has been audited against. Which is the commctl 6.0 documentation. This is where MS says the standard controls reside in XP, what's the problem? The problem is that the documentation is misleading (intentionally or not it doesn't matter), and following a wrong doc is not what we want to do in Wine. I'm sorry for butting in on this. I don't understand your problem either. Dimi didn't change the location of the code - it's still in user32. Our dependencies won't change as a result of his patch, and it therefor follows that no program will break as a result of this comment. What he did do, however, is carefully read the docs to find out how nuances work. He then proceeded to audit our code to make sure that it conforms. When you do such an audit, you do it against the docs, wherever they may be. In this case, Dimi used version 6.0 of the comctl32.dll documentation. It can hardly be his fault that that's where the docs for button controls are. I don't think any amount of patch sending or arguing on our part is going to persuade Microsoft to move the docs elsewhere. Personally, I also see value in documenting what version of the docs the audit was performed against, so that future mismatches can be tracked down. Can you suggest a better way to write the comment? Shachar P.S. Such comments do suffer from another problem. They tend to fall out of date. For that reason alone I'm not sure this comment is a good idea. Otherwise, we get a future commit that changes something, but neglects to update the comment accordingly, and the comment turns useless or even dangerous. Maybe if we change that to contain the date or the CVS version number of the file that was audited -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: [Wine] Edit Windows XP registry with wines regedit?
Saulius Krasuckas wrote: I hope there would be no license [2] collisions. You meant to say that you hope that the license collisions are resolvable. The current license is not LGPL compatible due to the "no making money" clause. The "docs" credit is also not LGPL compatible. However, the author also says: If you ask I will very likely allow other types of distribution. (have already had questions of it as a bonus on eBay auctions. ask, and you will likely get permission) I'm just a kind of control freak, so I want to know what's going on. which gives hope that if you ask him nicely, he will be willing to relicense the relevant parts as LGPL. [2] http://home.eunet.no/~pnordahl/ntpasswd/COPYING.txt Shachar p.s. The "no commercial distribution" runs counter to item 1 of the open source definition (http://opensource.org/docs/definition.php). This means that this license is not an open source license. One has, of course, every justification for saying "so what", but I just wanted to mention this. Sh. -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Listbox fixes
Alexandre Julliard wrote: Yes it happens regularly, maybe once or twice a month. And yes, it would be a good idea for other developers to run the tests too. Thing is, they don't run for me. On a clean CVS checkout after compile, I get: wine$ make test make[1]: Entering directory `/home/sun/sources/wine/wine/dlls' make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/advapi32' make[3]: Entering directory `/home/sun/sources/wine/wine/dlls/advapi32/tests' ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so crypt.c && touch crypt.ok Xlib: extension "XFree86-DRI" missing on display ":0.0". /home/sun/.wine updated successfully. fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image crypt.c:110: Test failed: 122 fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image crypt.c:117: Test failed: 122 fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image make[3]: *** [crypt.ok] Error 2 make[3]: Leaving directory `/home/sun/sources/wine/wine/dlls/advapi32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/advapi32' make[1]: *** [advapi32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/wine/dlls' make: *** [dlls/__test__] Error 2 Since I know these same tests pass on Alexandre's machine, I can only assume there is something missing in my setup. However, as I don't know what, I simply let it go and do my best without running the tests. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Listbox fixes
Alexandre Julliard wrote: Yes it happens regularly, maybe once or twice a month. And yes, it would be a good idea for other developers to run the tests too. Thing is, they don't run for me. On a clean CVS checkout after compile, I get: wine$ make test make[1]: Entering directory `/home/sun/sources/wine/wine/dlls' make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/advapi32' make[3]: Entering directory `/home/sun/sources/wine/wine/dlls/advapi32/tests' ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so crypt.c && touch crypt.ok Xlib: extension "XFree86-DRI" missing on display ":0.0". /home/sun/.wine updated successfully. fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380ef8): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image crypt.c:110: Test failed: 122 fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image crypt.c:117: Test failed: 122 fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image fixme:crypt:CRYPT_VerifyImage (rsabase.dll, 0x40380f18): not verifying image make[3]: *** [crypt.ok] Error 2 make[3]: Leaving directory `/home/sun/sources/wine/wine/dlls/advapi32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/advapi32' make[1]: *** [advapi32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/wine/dlls' make: *** [dlls/__test__] Error 2 Since I know these same tests pass on Alexandre's machine, I can only assume there is something missing in my setup. However, as I don't know what, I simply let it go and do my best without running the tests. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Contributing to WINE
Dimitrie O. Paun wrote: One more thing: it's best if you can post plain text messages to the mailing list. Not HTML, or any other strange formats. Your message for example was in a weird format that's not supported by my mail program, and it caused me no end of grief. I guess it's not THAT weird. The message was signed using something called "comodo" (http://www.comodogroup.com). I believe the weird format is a result of the signing of the message. I'm not sure how standard this format is, but Mozilla seemed to be able to cope with it, including verifying the certificate and the signature on the email. Ronald, I think Outlook has an option of signing messages out of bound. This means that the message itself is sent as plain text, while the signature is sent as an attachment. This format is preferred for all recipients, as it requires less knowledge on the receiving side. Also, bear in mind that in some countries digital signatures are legally binding. These include at least the US and Israel. This means that one can hold you to anything you say in any signed email you send. Add to the the fact that the email's date and subject is not signed, and that you sometimes want to answer an email with a simple "yes", and I'm not sure that signing each and every outgoing email is a very good idea. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Contributing to WINE
Ronald Robin wrote: Hi! My name is Ronald and I was wondering if any of you guys out there can help me get in touch with Mr. Alexander Julliard or any of the leaders here in the WINE community. We've been trying to get in touch with him for months now and we have consistently failed to receive a response. My company, SpecOps Labs, would like to discuss how we can contribute and work together with the WINE community. We believe we have a lot to contribute to the WINE community. However, without contact with any of the executives at WINEHQ, we are unable to do so. We want to engage in an initial dialog with Mr. Julliard. Our CTO has already tried emailing him twice. It's possible we don't have the right contact information. We'd greatly appreciate it if someone here could help us out. Hi Ronald, First, allow me to say that it is a pleasure to finally hear from SpecOps directly. So far, all the communication between your company and this project have been through press releases on your part, and public responses on ours. I am hoping we will all find that direct communication is a better way to conduct both business and development. I cannot answer for Alexandre regarding your inquiries with him. I am not even sure what "leaders in the WINE community" mean. As a free software project, wine has no executives, as it is not a body with a legally standing existence. If the cooperation discussion you wish to conduct is of a technical nature, the best way to conduct them is here, on this list. If it is of a legal nature, I'm not really sure what your legal standing would be. Legally, Wine belongs to its copyright holders, many of them can be reached through this list, but not all of them. Neither Alexandre, nor any other single person or entity, can approve activities that require all copyright holder's consent. This includes, among other things I'm probably forgetting, selling the code and changing the code's license to something not LGPL compatible. If what you are after is hired work to help you in development, you have several options. First of all, to the best of my knowledge, there are three companies that today have the know how to provide such services. These are CodeWeavers (http://www.codeweavers.com), TransGaming (http://www.transgaming.com/) who mostly work on their own proprietary variant of Wine, and my company, Lingnu (http://www.lingnu.com). There may also be other companies I am not aware of. Your best bet with any of those is to go through the "contact information" on their web site. In addition to that, some of the wine hackers on this list also work as free lancers. I am sure that directing a request to this list asking for hired help will provide you with people willing to sell you their time and knowledge. Hoping I've been helpful, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: MSCMS: new dll
The idea is very very good, but I have a couple of comments: Francois Gouget wrote: +echo +echo "Notes:" Why not use the autoconf macro specific for this purpose? I think it's called "AC_WARN" or something. + echo "*** Alsa not detected. The winealsa.drv.so driver will be a dummy." + echo "*** NAS not detected. The winenas.drv.so driver will be a dummy." I think a more user oriented description is in order here. This is too alarming, and the list will be flooded by newbies asking whether it's possible to run wine without them. Instead, use a terminology according to the line of "Wine will not be able to produce sound using the Alsa driver". +if test -z "$ICULIBS" I do believe this is the wrong test. If we must do it here, test for "HAVE_ICU". + echo "*** ICU not detected. Building without bidi support." Again, gotta avoid Jargon. Let's face it, 99% of Wine users don't care about this one. Instead, write: "Building wine without BiDirectional languages (Hebrew, Arabic) support" This will greatly reduce the number of users alarmed by this configure message. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Directx9
Mike Hearn wrote: I don't think it makes any sense to put it off indefinately on the grounds that Wine is still a developers-only release. That's circular logic. Hear hear. Also, I think the sooner we start treating wine as a mature product, the better. Declaring a making a product mature is a great step in making it one. Shachar
Re: Why is our OutputDebugString a server request?
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
But as far as I can see, this means that Windows debuggers won't get
it. Wouldn't it be better to implement it the Win32 way? At the very
least, implement it ALSO as the Win32 way?
It will generate an output string debug event, so Windows debuggers
should be able to deal with it. The real Win32 way would be to raise
an exception, which is certainly something we could do;
Not according to my information. According to my information, this is
merely a mutex and an event. (is that what you meant?).
I'll do some proper looking into here.
but since
Win32 provides a debug event for this purpose, it seemed reasonable to
use it. Now, if you know of a case where it causes trouble, it can be
changed.
I get the feeling that I misunderstood what you just said. What is the
debug event? where do we do anything with it?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Why is our OutputDebugString a server request?
Pouech Eric DMI AEI CAEN wrote: so that debuggers can intercept it (especially ones with GUI) and do what they want with it. A+ > Message du 13/09/04 17:50 > De : "Shachar Shemesh" > A : "Wine Development" > Copie à : > Objet : Why is our OutputDebugString a server request? > But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Why is our OutputDebugString a server request?
Hi all, It seems that OutputDebugString is defined in the Win32 API as a set of client side operations. In wine, however, it is a server request. I have not traced it into the server to see whether they carry out the same operations or not. However, even if they do, I am wondering why we need them? Wouldn't it be better to not do server side things that can be done client side? (http://www.unixwiz.net/techtips/outputdebugstring.html) Shachar P.S. I perfectly understand that obtaining mutexes and waiting on events is a server side operation. However, it was my impression that such things are best carried out by mimicking the Win32 structure as much as possible. Isn't that the case? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll patch - status?
Mike McCormack wrote: Do you still think my third patch has the problem? I stand corrected. Sorry about the noise. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll patch - status?
Mike McCormack wrote: Just got your last mail regarding races... From what I can see, it should now behave the same way as select_loop(). No, it does not. Sorry. When using poll, the important field we look at is revents. Let's recap the problem: 1. epoll is called, and marks users at offsets 1 2 and 3 as having interesting events to handle. 2. The handling of event 1 removed user 3 from the list. fd is deallocated, and entry is cleared. node 3 is added to the beginning of the free nodes list. 3. Event 2 is handled. During that handling it asks for a new node. Since 3 is at the beginning of the free list, that's what it gets. It sets a new fd for it, and ask it to wait on certain unrelated events. 4. The loop handling the epoll events arrive at event 3. Had that been the "poll" loop, we would be looking at the revents field. That field was cleared by the removal at step 2, and as no call to poll happened since it was re added in 3, we would correctly surmise that there is nothing interesting to be done for this user, and move on. We would be inefficient, as the counter of handled users would not reach zero, and we would have to scan the entire list. However, we would not perform incorrect processing. However, with your patch, things are different. The "revents" equivalent is stored in an array dedicated to the epoll results, and it is impossible for the del-user function to clear it. We do check that "Events" is not zero, but it's not. We therefor think that the events flagged for the old occupant of user #3 actually belong to the new occupant, and we handle it incorrectly. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll patch - status?
Mike McCormack wrote: Shachar Shemesh wrote: Read the comment in the appropriate section of my code. You have a race here that will crash you occasionally. Fixed. Ahmm. I'm not so sure. Did you also handle the case where 1, 2 and 3 were flagged, 1 releases 3, and 2 asks for a new fd and receives 3? Don't forget that if 2 asks for a new fd, it will certainly receive 3, because of the way the free list is managed. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: epoll patch - status?
Mike McCormack wrote:
I mean I've allocated an array of 10 struct epoll_events to receive
events from epoll, and I plan to dynamically allocate it later.
I have greater plans for wineserver :-)
As part of those plans, I'm going to ask some kernel gurus whether
that's strictly necessary. If it's not, I may actually advocate making
it even lower (1, in particular).
No, there's a return in there, so only one of the main loops is entered.
I stand corrected.
Well, the most serious problem with this code is the race you did not
handle. I don't like the use of a whole pollfd array, but that's not
for me to decide.
OK, I've fixed the race as I mentioned above. I'm trying to use
exactly the same data structures as the select() loop where possible
so that it's easier to verify the epoll_loop works assuming that the
select_loop() works.
Looking forward to comments on the attached patch.
Index: server/fd.c
===
RCS file: /home/wine/wine/server/fd.c,v
retrieving revision 1.25
diff -u -r1.25 fd.c
--- server/fd.c 9 Sep 2004 00:28:36 - 1.25
+++ server/fd.c 9 Sep 2004 04:51:16 -
@@ -2,6 +2,8 @@
* Server-side file descriptor management
*
* Copyright (C) 2000, 2003 Alexandre Julliard
+ * Copyright (C) 2004 Shachar Shemesh for Lingnu Open Source Consulting ltd.
+ * Copyright (C) 2004 Mike McCormack
I was actually talking about adding:
* Epoll header copied here is Copyright (C) 2002, 2003 by the Free
Software Foundation, Inc.
However, as I see you no longer copy the header into the program, this
is no longer necessary.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -236,6 +242,106 @@
static int allocated_users; /* count of allocated entries in the array
*/
static struct fd **freelist;/* list of free entries in the array */
+#ifdef HAVE_SYS_EPOLL_H
+
+#define EPOLL_SIZE 1024
+#define MAX_EVENTS 10
+
+static int epoll_fd;
+struct epoll_event *epoll_ev_first, *epoll_ev_last;
+
+/* this should optimize away if the poll constants are the same as the epoll ones */
Hmm. Need to verify that, though.
+static inline int epoll_events( int events )
+{
+int r = 0;
+
+if( (POLLIN == EPOLLIN) && (POLLOUT == EPOLLOUT) &&
+(POLLERR == EPOLLERR) && (POLLHUP == EPOLLHUP) )
+return events;
+if( POLLIN&events ) r |= EPOLLIN;
+if( POLLOUT&events ) r |= EPOLLOUT;
+if( POLLERR&events ) r |= EPOLLERR;
+if( POLLHUP&events ) r |= EPOLLHUP;
+return r;
+}
+
+static inline void do_epoll_add( int fd, int events, unsigned int user )
+{
+struct epoll_event eev;
+int r;
+
+if (epoll_fd < 0)
+return;
+if (fd < 0)
+return;
+if (!events)
+return;
+eev.events = events;
+eev.data.u32 = user;
+r = epoll_ctl( epoll_fd, EPOLL_CTL_ADD, fd, &eev );
+assert( 0 == r );
+}
+
+static inline void do_epoll_mod( int fd, int events, unsigned int user )
+{
+struct epoll_event eev;
+int r;
+
+if (epoll_fd < 0)
+return;
+if (fd < 0)
+return;
+eev.events = events;
+eev.data.u32 = user;
+r = epoll_ctl( epoll_fd, EPOLL_CTL_MOD, fd, &eev );
+assert( 0 == r );
+}
+
+static inline void do_epoll_remove( int fd, int old_events, unsigned int user )
+{
+struct epoll_event eev, *i;
+int r;
+
+if (epoll_fd < 0)
+return;
+if (fd < 0)
+return;
+if (!old_events)
+return;
+r = epoll_ctl( epoll_fd, EPOLL_CTL_DEL, fd, &eev );
+assert( 0 == r );
This assert still depends on the removal semantics. If it's ok for the
users to close the Unix fd before removing it from the poll array, you
may find that it's already gone and the assert will fail.
If you like, make that:
assert( 0 == r || errno == ENOENT );
+
+/* remove any unprocessed events for this fd */
+for( i=epoll_ev_first; i
+if (i->data.u32 == user)
+i->events = 0;
+}
+
+void init_fd()
+{
+epoll_fd = epoll_create(EPOLL_SIZE);
+}
+
+#else
+
+static inline void do_epoll_add( int fd, int events, unsigned int user )
+{
+}
+
+static inline void do_epoll_mod( int fd, int events, unsigned int user )
+{
+}
+
+static inline void do_epoll_remove( int fd, int old_events, unsigned int user )
+{
+}
+
+void init_fd()
+{
+}
+
+#endif
+
/* add a user in the poll array and return its index, or -1 on failure */
static int add_poll_user( struct fd *fd )
{
@@ -280,6 +386,7 @@
{
assert( user >= 0 );
assert( poll_users[user] == fd );
+do_epoll_remove( pollfd[user].fd, pollfd[user].events, user );
pollfd[user].fd = -1;
pollfd[user].events = 0;
pollfd[user].revents = 0;
@@ -288,56 +395,95 @@
active_users--;
}
-
-/* server main poll() loop */
Re: epoll patch - status?
Mike McCormack wrote:
Shachar Shemesh wrote:
After a discussion with Alexandre on IRC I came to the conclusion
that nothing I will do will make this patch go in. Mike, please add
it to your list of "uncommitted patches".
Hi Shachar,
I'm not sure which Mike the above is addressed at... :)
Mike Hearn addressed the need for a repository of uncommitted patches.
I agree epoll is something worth persuing, so I had a go at refining
your patch in accordance with what Alexandre recommended (quoted
below). Here's what I came up with... it's not complete as yet, but
hopefully it's more conformant with Alexandre's wishes ...
Notes:
* used direct syscalls as my libc doesn't have epoll_* functions
Which Alexandre already asked not to. In any case, if you do, you have
to add a copyright notice to the authors of the header file who's
content you are copying.
* fixed array of epoll_event structures for starters
I missed that. What did you mean by this?
* do_epoll_remove assert commented as it occasionally triggers
Was that assert in my code? By looking at it, I see no reason for it NOT
to be triggered occasionally. Don't forget that the file descriptor may
have been closed prior to being removed from the list, in which case the
system removed it from the epoll fd itself.
It works for a quick test, but I'm sure everybody can find problems
with it...
I'm afraid so. Read on.
Mike
+static inline void do_epoll_add( int fd, int events, int user )
+{
+struct epoll_event eev;
+int r;
+
+if( epoll_fd < 0 )
+return;
+if( fd < 0 )
+return;
+if( !events )
+return;
+eev.events = events;
+eev.data.u32 = user;
+r = epoll_ctl( epoll_fd, EPOLL_CTL_ADD, fd, &eev );
+assert( 0 == r );
+}
If the file descriptor is already in there, EPOLL_CTL_ADD will fail. You
will then have to call EPOLL_CTL_MOD.
In "add_poll_user", you are allocating a totally useless (if epoll is
used) "pollfd" array.
-
-/* server main poll() loop */
-void main_loop(void)
+static inline int next_delta()
{
-int ret;
+long diff = -1;
+struct list expired_list, *ptr;
+struct timeval now;
-while (active_users)
+if (list_empty(&timeout_list))
+return diff;
+
+gettimeofday( &now, NULL );
+
+/* first remove all expired timers from the list */
+
+list_init( &expired_list );
+while ((ptr = list_head( &timeout_list )) != NULL)
{
-long diff = -1;
-if (!list_empty( &timeout_list ))
+struct timeout_user *timeout = LIST_ENTRY( ptr, struct timeout_user, entry );
+
+if (!time_before( &now, &timeout->when ))
{
-struct list expired_list, *ptr;
-struct timeval now;
-gettimeofday( &now, NULL );
+list_remove( &timeout->entry );
+list_add_tail( &expired_list, &timeout->entry );
+}
+else break;
+}
-/* first remove all expired timers from the list */
+/* now call the callback for all the removed timers */
-list_init( &expired_list );
-while ((ptr = list_head( &timeout_list )) != NULL)
-{
-struct timeout_user *timeout = LIST_ENTRY( ptr, struct timeout_user,
entry );
+while ((ptr = list_head( &expired_list )) != NULL)
+{
+struct timeout_user *timeout = LIST_ENTRY( ptr, struct timeout_user, entry );
+list_remove( &timeout->entry );
+timeout->callback( timeout->private );
+free( timeout );
+}
-if (!time_before( &now, &timeout->when ))
-{
-list_remove( &timeout->entry );
-list_add_tail( &expired_list, &timeout->entry );
-}
-else break;
-}
+if (!active_users) return diff; /* last user removed by a timeout */
-/* now call the callback for all the removed timers */
+if ((ptr = list_head( &timeout_list )) != NULL)
+{
+struct timeout_user *timeout = LIST_ENTRY( ptr, struct timeout_user, entry );
+diff = (timeout->when.tv_sec - now.tv_sec) * 1000
+ + (timeout->when.tv_usec - now.tv_usec) / 1000;
+if (diff < 0) diff = 0;
+}
-while ((ptr = list_head( &expired_list )) != NULL)
-{
-struct timeout_user *timeout = LIST_ENTRY( ptr, struct timeout_user, entry );
-list_remove( &timeout->entry );
-timeout->callback( timeout->private );
-free( timeout );
-}
+return diff;
+}
I'm assuming you pulled the timeout code into a separate function here.
If there is anything fd related here, please let me know.
-if (!active_users
Re: epoll patch - status?
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
I'm sorry for being a pest about this. I was wondering whether there
is anything that needs to be done on that one in order to facilitate
committing this patch?
It needs some cleaning up, you need to find a way to make fewer
changes to the poll() side of things, also the epoll stuff should be
separated enough that you can put it inside #ifdef instead of having
dummy declarations of the epoll functions. Also try to better follow
the coding conventions of the rest of the file, for instance use
underscores in variable names, get rid of some useless asserts, etc.
After a discussion with Alexandre on IRC I came to the conclusion that
nothing I will do will make this patch go in. Mike, please add it to
your list of "uncommitted patches".
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
epoll patch - status?
Hi Alexandre, I'm sorry for being a pest about this. I was wondering whether there is anything that needs to be done on that one in order to facilitate committing this patch? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
EINTR vs. WSAEINTR
Hi list, When calling "select" (or any other socket function, for that purpose), there is a chance that a signal will arrive while we are blocking on the socket. This will cause the blocking function to return with EINTR. The usual recommendation is to retry the operation if that is the case. http://www.wlug.org.nz/EINTR Our current behavior, at least in "WS_select", is to convert it to WSAEINTR, and return the error. I think this behavior is wrong. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/windows_sockets_error_codes_2.asp MSDN says that WSAEINTR is only returned if WSACancelBlockingCall is received during the wait. I have a program for which I can affect the source that fails because of a select call being interrupted. I'm wondering whether it's better to fix the program to retry on WSAEINTR, or to fix wine. One possible fix to Wine is to mask all signals right before calling "select", and restore the signal mask when returning. This will ensure that EINTR will not be received. Can someone more versed in winsock voice an opinion about whether this is indeed a problem in Wine? Shachar
Re: E-mail adress
Mike Hearn wrote: A better technique is to the CSS unicode bi-di attributes to convert Mike Hearn <[EMAIL PROTECTED]> in the webpage to Mike Hearn <[EMAIL PROTECTED]> in the rendered image the browser shows you. I came across this trick the other day and it's pretty neat. Boring old techniques like "username at host" are apparently useless against modern harvester bots, so maybe it's worth doing this. Wow. You'd expect me to think of that one.. Still, that does not allow easy copy&paste, and it has unpleasant effect on web sites that actually USE bidi. Also, in order to be really effective, you would need to use RLO (else the strong directionality of the English letters would still make it left to right), and I'm not sure how widespread a support this has. Worst, this doesn't work for automatic clicks. A better approach, in my humble opinion, is to use javascript. A simple method is visible in my site (a simple script that reorders the words, so that they do not appear as a full name anywhere unless you understand javascript). A more complex method is to RSA encode the email using a 15 bit key that is hard-wired into the decoding javascript. This method is impossible to work around without actually running a javascript engine on the harvester, which would open them to all sorts of fun abuse by us. :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: wineserver epoll
Mike Hearn wrote: Building with a recent glibc and running on an older one is not supported by glibc, and it won't work for many reasons having nothing to do with epoll. Crossover runs everywhere because it is built against a very old glibc. To clarify, it is possible to build against a new glibc and have it run on older libcs, but the process is far from intuitive and requires special tools, header overrides etc. We do this in autopackage, and it works, but it's quite tricky to get right. So I guess Shachar could use dlopen, or possibly the epoll functions are weak symbols - quite a lot of glibc functions are these days. In that case you can just mark them with the weak attribute and that's no problem. Details, please. How do I do that? Shachar
Re: [wine] Linux registry
Hmm, How about a more general approach, then. I offered in the past to put wine's registry into a relational database, for performance reasons. That was turned down due to editability reasons. However, how about we use a plugin mechanism. We will have the wine built in text-file registry handler, and we will also have a plugin mechanism by which we could write external registry handlers. This way, wine could have registry in a relational database, in a binary windows compatible file, or using these guys' project, and the end user will be the one to decide which is best for them. David Lee Lambert wrote: On Mon, Aug 30, 2004 at 03:27:49PM +0200, Robert van Herk wrote: Lots of good reasons on why this project is not good enough to rely on. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Problem in mutex?
Shachar Shemesh wrote:
[EMAIL PROTECTED]:~/sources/wine/threadtest$ time ../wine/wine Debug/main.exe
> /dev/null
Program exit 299732
Just for comparison, when running on Windows, I get as far as 298015,
but in less time.
Just for the record, if all the threads run to completion, and the mutex
do their job, the number should have been 30. Any other number seems
to indicate that there was a problem with the mutex. If a mutex failed
to be granted we should have seen messages, which didn't happen either.
This problem is for both Windows AND wine. I can only deduct that I'm
doing something wrong. Maybe named mutexes are not shared like I thought
they are? When I try to create the mutex only once and share the handle
I get a lot of failed locking responses, also on Windows. Then again,
when I use the original code, even on windows, the number is not a
multiple of 1000, which suggests that not all increments happened.
The only explanation is that there is a bug in the win32 code. But what?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Problem in mutex?
Mike Hearn wrote:
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
Doubt it, it *looks* OK. But the acid test is to run it on Windows.
I've not used the mutex APIs much though, so could well be wrong.
err:ntdll:RtlpWaitForCriticalSection section 0x4017fec0 "?" wait
timed out in thread 0009, blocked by , retrying (60 sec)
Well, this must be a Wine internal critical section and 0 is an
invalid thread ID. So it looks like something is going badly wrong
inside Wine.
What does the backtrace of thread 9 look like?
thanks -mike
Wine-dbg>info thread
process tid prio (all id:s are in hex)
0008 (D) Z:\home\sun\sources\wine\threadtest\threadtest.exe
00090 <==
Wine-dbg>bt
Backtrace:
=>1 0x400484d1 (0x402fac54)
2 0x401e5462 NTDLL_wait_for_multiple_objects+0x122(count=0x0,
handles=0x0, flags=0x8, timeout=0x402fad10)
[/home/sun/sources/wine/wine/dlls/ntdll/sync.c:587] in ntdll (0x402facf8)
3 0x401e39cc usr1_handler+0x4c(__signal=0xa, __context=0x33)
[/home/sun/sources/wine/wine/dlls/ntdll/signal_i386.c:1160] in ntdll
(0x402fad1c)
4 0xe420 (0x406bcd98)
5 0x401e5462 NTDLL_wait_for_multiple_objects+0x122(count=0x1,
handles=0x406bce8c, flags=0xc, timeout=0x406bcebc)
[/home/sun/sources/wine/wine/dlls/ntdll/sync.c:587] in ntdll (0x406bce3c)
6 0x401e54d6 NtWaitForMultipleObjects+0x66(count=0x1,
handles=0x406bce8c, wait_all=0x0, alertable=0x0, timeout=0x406bcebc)
[/home/sun/sources/wine/wine/dlls/ntdll/sync.c:605] in ntdll (0x406bce64)
7 0x401e552c NtWaitForSingleObject+0x3c(handle=0x2c98,
alertable=0x0, timeout=0x406bcebc)
[/home/sun/sources/wine/wine/dlls/ntdll/sync.c:614] in ntdll (0x406bce84)
8 0x401bfd15 RtlpWaitForCriticalSection+0x115(crit=0x4017fec0)
[/home/sun/sources/wine/wine/dlls/ntdll/critsection.c:220] in ntdll
(0x406bcf24)
9 0x401bffa9 RtlEnterCriticalSection+0x49(crit=0x4017fec0)
[/home/sun/sources/wine/wine/dlls/ntdll/critsection.c:298] in ntdll
(0x406bcf3c)
10 0x406cf980 (0x406bfe90)
11 0x405b318afixme:dbghelp:elf_load_debug_info Unsupported Dwarf2
information
(0x406bff20)
12 0x404ffe52 start_process+0xf2(arg=0x0)
[/home/sun/sources/wine/wine/dlls/kernel/process.c:1014] in kernel32
(0x406bfff4)
13 0x4001d151 wine_switch_to_stack+0x11 in libwine.so.1 (0x)
I find that there are several disturbing things here:
1. There is only one process. How did that happen?
2. The debugger cannot load the debug info for my winelib application.
What the?
3. When compiling this in Visual Studio 6 and running on wine:
[EMAIL PROTECTED]:~/sources/wine/threadtest$ time ../wine/wine Debug/main.exe >
/dev/null
Program exit 299732
real0m17.826s
user0m3.244s
sys 0m5.671s
Just for comparison, when running on Windows, I get as far as 298015,
but in less time.
In order to achieve this, I lowered the stack (second CreateThread
parameter) to 8*1024, to avoid running out of memory. This does not
solve the problem when compiled as winelib, though. Could this be a
winelib problem??
In short - things are getting weirder.....
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Almost final epoll patch
Hi list,
Attached is the epoll patch. All problems described in my previous patch
sent should be solved here. The only reason I'm not sending this to
wine-patches instead of here is that I have not yet had a chance to
check it on my client's huge system, and so I cannot say for sure that
all problems are truly and utterly resolved.
In any case, I would welcome any and all comments about it. This patch
is against CVS head, and should compile even if epoll.h is not
available, as well as on old glibc's where epoll.h required stdint.h as
a prerequisite, and the library's implementation did not have glibc.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Index: configure
===
RCS file: /home/sun/sources/cvs/wine/configure,v
retrieving revision 1.592
diff -u -r1.592 configure
--- configure 24 Aug 2004 21:00:15 - 1.592
+++ configure 27 Aug 2004 11:43:39 -
@@ -16207,6 +16207,7 @@
+
for ac_header in \
arpa/inet.h \
arpa/nameser.h \
@@ -16269,6 +16270,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: configure.ac
===
RCS file: /home/sun/sources/cvs/wine/configure.ac,v
retrieving revision 1.303
diff -u -r1.303 configure.ac
--- configure.ac24 Aug 2004 21:00:15 - 1.303
+++ configure.ac27 Aug 2004 11:42:58 -
@@ -1156,6 +1156,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: include/config.h.in
===
RCS file: /home/sun/sources/cvs/wine/include/config.h.in,v
retrieving revision 1.193
diff -u -r1.193 config.h.in
--- include/config.h.in 4 Aug 2004 19:10:26 - 1.193
+++ include/config.h.in 27 Aug 2004 11:42:58 -
@@ -608,6 +608,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_ELF32_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_SYS_EPOLL_H
+
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_ERRNO_H
Index: server/fd.c
===
RCS file: /home/sun/sources/cvs/wine/server/fd.c,v
retrieving revision 1.22
diff -u -r1.22 fd.c
--- server/fd.c 18 Aug 2004 00:04:58 - 1.22
+++ server/fd.c 27 Aug 2004 11:47:12 -
@@ -33,6 +33,13 @@
#ifdef HAVE_SYS_POLL_H
#include
#endif
+#ifdef HAVE_SYS_EPOLL_H
+#include
+#include
+#endif
+#ifdef HAVE_SYS_SYSCALL_H
+#include
+#endif
#include
#include
#include
@@ -255,51 +262,173 @@
//
-/* poll support */
+/* poll and epoll support */
-static struct fd **poll_users; /* users array */
-static struct pollfd *pollfd; /* poll fd array */
-static int nb_users;/* count of array entries actually in use
*/
+struct fdtrack {
+enum { FDT_FREE, FDT_UNWATCHED, FDT_WATCHED, FDT_ERROR } state;
+union {
+int nextfree;
+struct fd *fd;
+} data;
+};
+
+/* Vars used by both */
static int active_users;/* current number of active users */
static int allocated_users; /* count of allocated entries in the
array */
-static struct fd **freelist;/* list of free entries in the array */
+static struct fdtrack *poll_users; /* users array */
+static int freelist;/* list of free entries in the array. End
of list marker is -1 */
+
+/* Vars used by poll */
+static struct pollfd *pollfd; /* poll fd array */
+static int nb_users;/* Maximal index of array entry actually
in use */
+
+/* Vars used by epoll */
+static int epoll_fd=-1; /* File descriptor for the epoll */
+static const int EPOLL_SIZE=1024; /* "Maximal size" passed to epoll_create.
This is an optimization, not a real maximum */
+static struct epoll_event *epoll_revents; /* Array for event results */
+static int epoll_revents_size; /* Number of elements in epoll_revents */
+static int in_epoll;/* Marks whether we are currently
processing the epoll results */
+static int closependinglist;/* List of users in close pending state.
End of list marker is -1 */
+
+#if defined(HAVE_SYS_EPOLL_H) && (HAVE_SYS_EPOLL_H)
+/* To prevent wine from not loading on non-epoll supporting platforms,
+ * we need to dynamically call the epoll functions */
+#ifndef __NR_epoll_create
+#define __NR_epoll_create 254
+#endif
+
+#ifndef __NR_epoll_ctl
+#define __NR_epoll_ctl 255
+#endif
+
+#ifndef __
Problem in mutex?
Hi all,
Attached is a sample program, originally written to find out about the
impact of using epoll on performance.
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
err:ntdll:RtlpWaitForCriticalSection section 0x4017fec0 "?" wait timed
out in thread 0009, blocked by , retrying (60 sec)
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
#include
#include
#define NUMTHREADS 3000
int flag;
int count;
DWORD WINAPI ThreadMain( LPVOID lpParam )
{
HANDLE hmutex=CreateMutex( NULL, FALSE, "ThreadCreationTest");
int i=0;
for( i=0; i<100; ++i )
{
DWORD dwWait=WaitForSingleObject(hmutex,INFINITE);
switch( dwWait ) {
case WAIT_OBJECT_0:
{
int oldcount=count;
if( flag )
fprintf(stderr, "No mutual exclusion!\n");
flag=1;
oldcount++;
count=oldcount;
flag=0;
}
ReleaseMutex(hmutex);
break;
default:
fprintf(stderr, "Didn't get mutex %lx\n", dwWait );
break;
}
}
CloseHandle(hmutex);
printf("Thread %d exiting with count at %d\n", lpParam, count );
return 0;
}
int main( int argc, char *argv )
{
int i;
HANDLE threads[NUMTHREADS];
flag=0;
count=0;
for( i=0; i
Re: Non-perfect epoll patch
Shachar Shemesh wrote:
Hi all,
Attached is a non-perfect patch for review. This is a migration of the
wineserver to use epoll instead of poll (if it's available).
current known issue with this patch:
1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile
if epoll not available at compile time)
2. Segfaults on wine exit.
3. Lots of debug asserts.
Comments welcome.
Shachar
The patch is not yet ready for commit, but I do have preliminary benchmarks:
The attached program (compiled as winelib) was used. ulimit -n was
raised to 10240.
With the current wine code:
real0m41.076s
user0m5.070s
sys 0m7.722s
the main wine process was taking 10% CPU time, and wineserver was taking
over 60% cpu time. load average was over 2
With my preliminary path:
real0m20.985s
user0m5.316s
sys 0m11.421s
main wine process was still taking 10%, but so was wineserver. load
average was about 1.5.
We can see that there is a significant drop in actual execution time,
even though there is an INCREASE in user+system processing time. I
believe this is not a fluke (results are pretty consistent), but rather
that the poll behavior was taking a huge toll on the system in areas
where it wasn't attributed towards wine, even though it was wine
related. I would take the real time measurement as the indicative one.
Ideas for better benchmarks would be greatly appreciated.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
#include
#include
DWORD WINAPI ThreadMain( LPVOID lpParam )
{
sleep(1);
return 0;
}
int main( int argc, char *argv )
{
int i;
for( i=0; i<1; ++i ){
DWORD threadid;
HANDLE hThread;
hThread=CreateThread(NULL, 0, ThreadMain, 0, 0, &threadid);
/*printf("Thread created %p\n", hThread);*/
CloseHandle(hThread);
}
}
### Generated by Winemaker
SRCDIR= .
SUBDIRS =
DLLS =
EXES = threadtest.exe
### Common settings
#CEXTRA= -mno-cygwin
#CXXEXTRA = -mno-cygwin
CEXTRA=
CXXEXTRA =
RCEXTRA =
INCLUDE_PATH = -I/home/sun/sources/wine/wine/include
DLL_PATH =
LIBRARY_PATH =
LIBRARIES =
### threadtest.exe sources and settings
threadtest_exe_MODULE = threadtest.exe
threadtest_exe_C_SRCS = main.c
threadtest_exe_CXX_SRCS=
threadtest_exe_RC_SRCS=
#threadtest_exe_LDFLAGS= -mconsole \
# -mno-cygwin
threadtest_exe_LDFLAGS= -mconsole
threadtest_exe_DLL_PATH=
threadtest_exe_DLLS =
threadtest_exe_LIBRARY_PATH= -L/home/sun/sources/wine/wine/libs
-L/home/sun/sources/wine/wine/dlls
threadtest_exe_LIBRARIES= uuid
threadtest_exe_OBJS = $(threadtest_exe_C_SRCS:.c=.o) \
$(threadtest_exe_CXX_SRCS:.cpp=.o) \
$(threadtest_exe_RC_SRCS:.rc=.res)
### Global source lists
C_SRCS= $(threadtest_exe_C_SRCS)
CXX_SRCS = $(threadtest_exe_CXX_SRCS)
RC_SRCS = $(threadtest_exe_RC_SRCS)
### Tools
CC = winegcc
CXX = winegcc
RC = wrc
WINEBUILD = winebuild
### Generic targets
all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so)
### Build rules
.PHONY: all clean dummy
$(SUBDIRS): dummy
@cd $@ && $(MAKE)
# Implicit rules
.SUFFIXES: .cpp .rc .res
DEFINCL = $(INCLUDE_PATH) $(DEFINES) $(OPTIONS)
.c.o:
$(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o $@ $<
.cpp.o:
$(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $<
.cxx.o:
$(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $<
.rc.res:
$(RC) $(RCFLAGS) $(RCEXTRA) $(DEFINCL) -fo$@ $<
# Rules for cleaning
CLEAN_FILES = *.dbg.c y.tab.c y.tab.h lex.yy.c \
core *.orig *.rej \
\\\#*\\\# *~ *% .\\\#*
clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__)
$(RM) $(CLEAN_FILES) $(RC_SRCS:.rc=.res) $(C_SRCS:.c=.o) $(CXX_SRCS:.cpp=.o)
$(RM) $(DLLS:%=%.dbg.o) $(DLLS:%=%.so)
$(RM) $(EXES:%=%.dbg.o) $(EXES:%=%.so) $(EXES:%.exe=%)
$(SUBDIRS:%=%/__clean__): dummy
cd `dirname [EMAIL PROTECTED] && $(MAKE) clean
$(EXTRASUBDIRS:%=%/__clean__): dummy
-cd `dirname [EMAIL PROTECTED] && $(RM) $(CLEAN_FILES)
### Target specific build rules
$(threadtest_exe_MODULE).dbg.c: $(threadtest_exe_C_SRCS) $(threadtest_exe_CXX_SRCS)
$(WINEBUILD) -o $@ --debug -C$(SRCDIR) $(threadtest_exe_C_SRCS)
$(threadtest_exe_CXX_SRCS)
$(threadtest_exe_MODULE).so: $(threadtest_exe_MODULE).dbg.o $(threadtest_exe_OBJS)
$(CXX) $(threadtest_exe_LDFLAGS) -o $@ $(threadtest_exe_OBJS)
$(threadtest_exe_MODULE).dbg.o $(threadtest_exe_LIBRARY_PATH) $(LIBRARY_PATH)
$(threadtest_exe_DLLS:%=-l%) $(threadtest_exe_LIBRARIES:%=-l%)
Re: poll vs. epoll
Dan Kegel wrote: Shachar Shemesh wrote: Now don't go and do level-triggered stuff just because it's easier :-) That's not it at all, and edge vs. level is not part of my considerations. Libevent does support a wider variety of selection interfaces, and with wider platform support, than your library. Don't get me wrong. Libevent is good stuff. Niels is a very good guy. I don't think platform support is an issue (which platform do you need?) We are trying to have as wide support as we can, obviously. The one interface rn is missing, I think, is a timer. Which wineserver needs. Buffered events would be a fine addition, too. But rn has the basic notification stuff; it was intended to focus on those. But then why NOT use libevent :-) If you are really itching, why not just add edge trigger to libevent? The more I think about it, the more I'm getting the impression that going edge trigger means we need to maintain our own cache of not-yet-useful data The same cache is maintained in the kernel for you if you use level triggering. True, but that does save me on writing and debugging. After all, that's why libraries are there for to begin with. Also, it would seem to me that keeping data in the fd cache until it's actually needed saves on copies. Isn't that the case? Also, can you show me how to do edge trigger via poll? There is no need for that, since Linux and *BSD all support some form of edge-triggered notification. For Linux platforms prior to epoll, what's there? I'll qualify the starvation claim. Suppose we have five fds we are watching. Suppose one (let's call it "3") of them is really really intensive in it's request rate. Using the current interface (as used in the preliminary patch I sent), each time we call epoll we will see that 3 is active, but any time any other fd has anything to do, it will be handled. Suppose we go edge triggered now. We call epoll, and it's likely that 3 will be the only one active. We will call the 3 handling function, which will try to exhaust the requests arriving on 3 before returning. No it's a problem - requests potentially are never exhausted on 3. When do we exit the handler to do other stuff? We would need to write some mechanism to introduce this fairness ourselves. Yes, but that's easy. It's about four lines of code. I'm sure it is. So is managing the buffers etc. Thing is - why go into it at all if the difference is small? As an aside I'll mention that I'd like to see those four lines :-) What's this about partial memory buffering? Sounds like you're inventing a difficulty here. It may be that I'm referring to a difficulty that also exists in the usual case. I'm talking about half received "packets" of information on stream entities (such as TCP sockets and pipes). - Dan Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: poll vs. epoll
Dan Kegel wrote: Shachar Shemesh wrote: It doesn't compile (rn.c is not including ). When I fix that, it checks whether epoll_create works. If it does, it sets all handlers to use sigio. I don't think this library is quite stable enough :-) You're a tough customer :-) It's quite close; guess I should polish it up a bit. In any case, it seems that it's interface is not ideal for wineserver. Libevent, on the other hand.. Now don't go and do level-triggered stuff just because it's easier :-) That's not it at all, and edge vs. level is not part of my considerations. Libevent does support a wider variety of selection interfaces, and with wider platform support, than your library. I don't think it's fair to say level-triggered is ideal for wineserver. In fact, wineserver is an example of the kind of program that is easier to convert to edge-triggering than most programs, since it's small and self-contained. Can you give benchmarks for performance differences between the two? The more I think about it, the more I'm getting the impression that going edge trigger means we need to maintain our own cache of not-yet-useful data, as well as risking starvation. I'm sure there are cases where this is preferable, but can you explain why this is such a case? Also, can you show me how to do edge trigger via poll? Sigh. I wish my wrists were in better shape; I'd convert it myself. As it is, he who does the work gets to choose interfaces. - Dan I'll qualify the starvation claim. Suppose we have five fds we are watching. Suppose one (let's call it "3") of them is really really intensive in it's request rate. Using the current interface (as used in the preliminary patch I sent), each time we call epoll we will see that 3 is active, but any time any other fd has anything to do, it will be handled. Suppose we go edge triggered now. We call epoll, and it's likely that 3 will be the only one active. We will call the 3 handling function, which will try to exhaust the requests arriving on 3 before returning. No it's a problem - requests potentially are never exhausted on 3. When do we exit the handler to do other stuff? We would need to write some mechanism to introduce this fairness ourselves. In short, if you are going edge trigger, your relative scheduling priority is your responsibility, as well as keeping all partial memory buffered. With level trigger, the kernel does that for you. Is there any reason to assume that we can do that better than the kernel? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Non-perfect epoll patch
Shachar Shemesh wrote: Hi all, Attached is a non-perfect patch for review. This is a migration of the wineserver to use epoll instead of poll (if it's available). current known issue with this patch: 1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile if epoll not available at compile time) 2. Segfaults on wine exit. 3. Lots of debug asserts. Comments welcome. Shachar One more thing. I don't think it matters much, but this patch is against 20040716. -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Non-perfect epoll patch
Hi all,
Attached is a non-perfect patch for review. This is a migration of the
wineserver to use epoll instead of poll (if it's available).
current known issue with this patch:
1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile
if epoll not available at compile time)
2. Segfaults on wine exit.
3. Lots of debug asserts.
Comments welcome.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Index: configure
===
RCS file: /home/sun/sources/cvs/wine/configure,v
retrieving revision 1.573
diff -u -r1.573 configure
--- configure 17 Jul 2004 00:52:37 - 1.573
+++ configure 24 Aug 2004 12:03:32 -
@@ -6727,6 +6727,79 @@
fi
+echo "$as_me:$LINENO: checking for epoll_create in -lepoll" >&5
+echo $ECHO_N "checking for epoll_create in -lepoll... $ECHO_C" >&6
+if test "${ac_cv_lib_epoll_epoll_create+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ ac_check_lib_save_LIBS=$LIBS
+LIBS="-lepoll $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+/* Override any gcc2 internal prototype to avoid an error. */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char epoll_create ();
+int
+main ()
+{
+epoll_create ();
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+ (eval $ac_link) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+{ ac_try='test -z "$ac_c_werror_flag" || test ! -s
conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+{ ac_try='test -s conftest$ac_exeext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ac_cv_lib_epoll_epoll_create=yes
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_epoll_epoll_create=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+ conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_epoll_epoll_create" >&5
+echo "${ECHO_T}$ac_cv_lib_epoll_epoll_create" >&6
+if test $ac_cv_lib_epoll_epoll_create = yes; then
+ cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBEPOLL 1
+_ACEOF
+
+ LIBS="-lepoll $LIBS"
+
+fi
+
+
echo "$as_me:$LINENO: checking for res_9_init in -lresolv" >&5
echo $ECHO_N "checking for res_9_init in -lresolv... $ECHO_C" >&6
if test "${ac_cv_lib_resolv_res_9_init+set}" = set; then
@@ -16190,6 +16263,7 @@
+
for ac_func in \
_lwp_create \
_lwp_self \
@@ -16202,6 +16276,7 @@
_vsnprintf \
chsize \
clone \
+epoll_create \
finite \
fpclass \
fstatfs \
@@ -16435,6 +16510,7 @@
+
for ac_header in \
arpa/inet.h \
arpa/nameser.h \
@@ -16495,6 +16571,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: configure.ac
===
RCS file: /home/sun/sources/cvs/wine/configure.ac,v
retrieving revision 1.285
diff -u -r1.285 configure.ac
--- configure.ac6 Jul 2004 21:01:19 - 1.285
+++ configure.ac24 Aug 2004 12:01:22 -
@@ -140,6 +140,8 @@
AC_CHECK_LIB(xpg4,_xpg4_setrunelocale)
dnl Check for -lpoll for Mac OS X/Darwin
AC_CHECK_LIB(poll,poll)
+dnl Check for -lepoll
+AC_CHECK_LIB(epoll,epoll_create)
dnl Check for -lresolv for Mac OS X/Darwin
AC_CHECK_LIB(resolv,res_9_init)
dnl Check for -lpthread
@@ -1036,6 +1038,7 @@
_vsnprintf \
chsize \
clone \
+epoll_create \
finite \
fpclass \
fstatfs \
@@ -1146,6 +1149,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: in
Re: poll vs. epoll
Shachar Shemesh wrote: Dan Kegel wrote: By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. That's fine, except that compiling your library on a machine that has epoll, and then trying to run it on a machine without will not work. It will not load if runtime glibc doesn't have epoll. I'm using "syscall" to work around that problem in wine. Compile time detection is insufficient. My code is at http://kegel.com/rn Sure will have a look. It doesn't compile (rn.c is not including ). When I fix that, it checks whether epoll_create works. If it does, it sets all handlers to use sigio. I don't think this library is quite stable enough :-) In any case, it seems that it's interface is not ideal for wineserver. Libevent, on the other hand.. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Steven Edwards wrote:
Hi Alexander,
--- Alexander Yaworsky <[EMAIL PROTECTED]> wrote:
I even tried to submit a patch but it was silently ignored. Let me
remind about this patch --
http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe
it will be useful. If you have suggestions, I promise to
rewrite it as required ;))
Dont take offence if your patch goes to the void. Just resubmit after a
a week to give it a chance to filter through Alexandre's tree. Its
possible either
1. He is going to merge it and its just taken him a while
2. He rejected it and just forgot to send a note due to the constrants
of time.
3. It went to the void in space where the lost patches go.
Just resubmit and you should hear something back from someone.
Thanks
Steven
Actually, during the last wineconf, "There's nothing obviously wrong
with it, but it makes Alexandre uneasy" for the usual reason patches go
to void
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Document an API difference
Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: poll vs. epoll
Dan Kegel wrote: Shachar wrote: I noticed that in server/fd.c, the wineserver is using "poll" to select between file descriptors. The application is going through this code over 2000 times a second, with over 380 file descriptors each time. I am wondering whether this can be the cause of the slowdown. One of the possible solutions to this would be to use epoll instead. This, of course, would have to be backed by a configure check, as not all systems for which wine is intended support epoll. Another, arguably better, solution would be to use libevent for this purpose. Libevent has the distinct advantage that it automatically chooses the best tool for the job (epoll, poll, /dev/poll, or if all else fails, select). By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. Compile time detection is insufficient. My code is at http://kegel.com/rn Sure will have a look. If you actually try to use it, let me know. I expect it might be useful mostly as a guide. It's edge-trigger oriented, but you can trivially add the flag (or remove the flag) needed to get level-triggered behavior again if you really need it. I highly recommend using edge-triggered behavior, though. I'm sure that edge trigger yields better performance. The problem, however, what with all the potential races edge trigger introduces, and the fact I'm not sufficiently familiar with the wineserver semantics, that going edge trigger in a bug free way right now is beyond me. - Dan Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
poll vs. epoll
Hi all,
I have a program (a server) that has a very large number of
synchronization constructs. Even when everything is idle there,
wineserver is taking 60% of the CPU, raising load average to 2.4. When
load is applied, response time occasionally jumps from tenths of a
second to two minutes.
I noticed that in server/fd.c, the wineserver is using "poll" to select
between file descriptors. The application is going through this code
over 2000 times a second, with over 380 file descriptors each time. I am
wondering whether this can be the cause of the slowdown.
One of the possible solutions to this would be to use epoll instead.
This, of course, would have to be backed by a configure check, as not
all systems for which wine is intended support epoll. Another, arguably
better, solution would be to use libevent for this purpose. Libevent has
the distinct advantage that it automatically chooses the best tool for
the job (epoll, poll, /dev/poll, or if all else fails, select). However,
if there is another, independent use of poll, porting the semantics to
libevent may prove non-trivial.
So what does the forum think?
One last question. What are the "users"? What constructs cause a new
file descriptor to be allocated in the wineserver?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: GetFontLanguageInfo patch.
Leib Moscovitz wrote:
Shachar Shemesh wrote:
Leib Moscovitz wrote:
Dear Shachar,
Yes, there is Pmail for Windows (version 4.2 already), and the
problem is that it doesn't handle Hebrew RTL correctly - I was
wondering whether there's any solution to this that you know of.
Thanks,
Leib Moscovitz
Is it only on Wine that it doesn't, or also on Windows?
Please keep posts on list.
Shachar
I only know about Windows - I am just an amateur, and as such I don't
even know what Wine is.
Wine cannot solve incomplete functionality Windows applications have. It
will not help you. Wine is aimed at making Windows applications run on
Linux and other Unixes. It has nothing to do with what a given
application does or does not know how to do on Windows. More info on
http://www.winehq.org.
Please CC the list (wine devel) when replying.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: GetFontLanguageInfo patch.
Leib Moscovitz wrote: Dear Shachar, Yes, there is Pmail for Windows (version 4.2 already), and the problem is that it doesn't handle Hebrew RTL correctly - I was wondering whether there's any solution to this that you know of. Thanks, Leib Moscovitz Is it only on Wine that it doesn't, or also on Windows? Please keep posts on list. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: GetFontLanguageInfo patch.
Rein Klazes wrote:
On Tue, 17 Aug 2004 18:05:44 +0200, you wrote:
Dear Sir,
I am searching for a way to make Pegasus Mail for Windows (4.x) display
Hebrew correctly, from right to left, and I came across a post of yours via
Google which seems to deal with this issue.
Have you developed any solution to this problem, and if so, is it publicly
available?
Many thanks,
Leib Moscovitz
Unfortunately the issue that you refer to was fixing some left-to-right
problem. I do not know if or how it works for right-to-left writing.
I have cc' ed this message to the wine developers list, perhaps the
developer that is working on/with this, Shachar Shemesh, can shine a bit
of light on the issue.
Rein.
Oooh, pmail. Haven't touched it since I was a Novel sysadmin, back in
1996. So, there is a Windows version now?
What is, exactly, the problem you are experiencing with pmail? What
version of Wine?
Shachar
P.s.
People, if you want to make sure I read mail addressed to me, please CC
me specifically.
Sh.
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Large memory reporting
Ivan Leo Puoti wrote:
Wine will have to unfortunately do the same to achieve 100% compatibility for
all the apps that work on windows only thanks to specific hacks.
While you are, no doubt, correct that 100% windows compatibility means
that we will have to, eventually, do that, I don't think the time is
"now". We are not yet confronted with bugs that require detecting what
application is currently running and hacking accordingly.
I'm not saying that it's a good solution in this case, but at some point this
sort of stuff will have to be done.
Ivan.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Large memory reporting
Hi list, I have a Windows program that tries to find out how much memory it has at its disposal using "GlobalMemoryStatus". The machine has 4GB of physical memory and about 100MB of swap. GlobalMemoryStatus returns 2GB of physical memory and 0 available swap. It seems the problem is at dlls/kernel/heap.c, around lines 1150. First we make sure we never report more than 2GB of total or available memory, and then we make sure that we never report more than 2GB combined available physical+swap memory (which effectively zeros the available swap if there is more than 2GB of available memory). The comment next to this is: /* work around for broken photoshop 4 installer */ While I understand the need for the workaround, this significantly reduces the usefulness of the whole function. My question: Can we make these two rounding conditional on the application not wishing to work with more than 2GB? I.e. - can we let applications that were linked with LARGEADDRESSAWARE see the true state of the machine? If so, is there a way for me, when at the heap.c code, to know whether that flag was set on loading the current process? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Acknowledgment page
Brian Vincent wrote: 4) Who's Who does need an update, and I can think of quite a few people who deserve to be on there. I'd encourage anyone who isn't on there to speak up and add themselves (patch to wine-patches, or email to me). The most likely for someone not being on there is simply an oversight on my part. Names that immediately come to mind include Rob Shearman, Robert Reif, and Filip Navara. There's probably a dozen more. The guideline for a Who's Who entry is shameless self-promotion. The problem with wine hackers is that they are too modest. They appreciate the publicity, but won't typically go looking for it. I think it would be best to call upon all wine hackers to think of names of people who deserve to be there and are not. 5) On our FAQ page we say this: People and organizations who have given generous contributions of money, equipment, or licenses, include: David L. Harper Bob Hepple Mark A. Horton Kevin P. Lawton The Syntropy Institute James Woulfe Here's a question for you - should money contribution's credit expire? If someone donated 100$ some five years ago, should we still list them? This is not about code contribution. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: DOOM 3 misses some opengl32 wgl* and Cg functions
Ove Kaaven wrote: BTW, DOOM 3 crashes at program start in Cedega, you made it better! here's a howto from someone who did make it start with Cedega CVS: http://www.linux-militia.net/howtos/doom3/doom3.html Since there's some level of pbuffer support in Cedega, it might provide better graphics. http://linux.israel.net/linuxgames/modules.php?name=News&file=article&sid=55 Translated into English: War games: Yes, it's true, Wine can run the new DOOM3 Several days ago I installed Mandrake 9.2 and was very impressed with Wine. This little program really does wonders. So i said to myself "it can run small Windows apps, but there is no way it can run Doom 3". I did this: cd /mnt/win_f/Doom3 and wrote "wine Doom3.exe", and what did my eyes see? Yes, it is Doom3 running on my computer!!! And with pretty nice graphics Linux should not be ashamed of, to boost! Only one little detail - the in games movies won't work. It probably has something to do with Windows' Direct X. So there you have it. I hope that it will work for you as it has for me There is also a screen shot there. So, if you want me to relay any questions to the user regarding how he did it? :-) -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wine and locales
David Lee Lambert wrote: I don't agree. Mixing default codepages across simultaneously running programs is not possible on Windows, and sounds horribly difficult to implement. Clipboard handling and cross-file using are two examples of things that are likely to go horribly wrong if we tried. If a program does a an ANSI call, it gets changed to Unicode. If that data gets passed back to another program using an ANSI call, it gets converted to the target codepage, as much as possible. If Wine is doing console output to a non-Unicode codepage, it gets converted there too. Ok, you convinced me. Implement that in a way that Alexandre will deem fit for commit, and I won't object too loudly. I do believe that you will not succeed with the first part, however. I'm not sure about mixing codepages under Windows, but input-method switching is easy. True, but irrelevant. Having one setting applicable to all running processes sounds good enough. I don't object to a config setting overriding what LC_CTYPE says, but I don't see a use for it either. Let's say I want to run an Arabic dictionary program and Spanish dictionary program as I'm typing a report in Word. Furthermore, the arabic dictionary program would use ANSI calls and expects to run on Arabic windows (with MS-ARAB encoding); the Spanish program would use LATIN1. Word uses wide-character calls. How would I run all these programs at the same time under Wine? Forget that. How would you run that under Windows? As far as I know, you can't do it there either. Coming from a country where a large portion of the population are native Russian speakers in a country where the dominant language is Hebrew, I'm pretty sure that I'd hear about it if it were possible. (I'm not saying I actually have such a set of programs. Actually, I own a copy of a standalone program that allows typing of Arabic programs on Western windows, and also have access to systems where Office XP with the Arabic and US-International input methods is installed.) Yes. That's because they either use the Unicode interface, or implement their own rendering engine. In short, I think what you're trying is impossible under Windows. I can also see some immediate implications to trying to do it in Wine. If it's important to you, you're welcome at it. It will not enter my personal todo list, however. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wine and locales
slation gets rid of the typical user's need to have other variables besides LANG set. Consider locales I might use: LANGLCIDLangID -- en_US 1 9 es_MX 52 10 es_US 1 9 ar_SA 966 1 Let's say I have a program that prints "Hello, World" in the current language, using wide calls. When I run it in Linux, it should print that string out using the current language and codepage. Suppose I also have a database program that was written in outer burgoslavia and keeps its data files in the encoding for outer burgoslavian, which is supported only by Windows 95 for Burgoslavia and Windows Server 2003. I don't want to change Linux to support Burgoslavian, but if Burgoslavian is encoded in some Unicode font I can add a section to [AppDefaults] and let that perticular program think it is running on an all-Burgoslavian system. For (5), the functions act the same no matter what locale the user is in. -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: cleanup a->w cross calls in advapi32/crypt.c
James Hawkins wrote: - strcpy(keyname + strlen(KEYSTR), pProvName); I changed that line to strcatW(keyname, pProvName). That makes a lot more sense Mike, thanks for the tip. I'm wasn't exactly sure on this one so it would be great if you could help me on this one. When using pointer arithmetic, do the operations such as --, ++... increment or decrement by the size of the pointer type? For example, *(ptr - sizeof(WCHAR)) = (dwType % 10) + '0'; *(ptr - sizeof(WCHAR) * 2) = ((dwType / 10) % 10) + '0'; *(ptr - sizeof(WCHAR) * 3) = (dwType / 100) + '0'; Is the sizeof(WCHAR) multiplication redundant because --ptr actually moves ptr down one WCHAR? I understand that if that's the case, but what about when the pointer is first initialized? ptr = keyname + strlenW(keyname); I guess it holds true here as well because keyname is a pointer and we're adding ot it. If that is the case, the included patch fixes the two things mentioned. Ok, whenever such matters come up, it's always wise to go to the source and ask the most authorative book there is. This is what the bible has to say about this (bible = "The C Programing Language, 2nd edition"): Page 98 bottom: "These remarks are true regardless of the type or size of the variables in the array a. The meaning of "adding 1 to a pointer," and by extension, all pointer arithmetics, is that pa+1 points to the next object, and pa+i points to the i-th object beyond pa." In other words, ANY time you add or subtract and integer from a pointer, the result is to move the pointer to another array element. No need to perform these "word size" calculations anywhere. Question: Did you compile and check you patch? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: USB?
Alex Zeiger wrote:
I'm interested in possibly working on USB support for Wine. I'm not
particularly familiar with USB programming, but I'm fluent in C and
C++. Where do I start?
Hi Alex,
Wine is not an operating system. As such, what do you mean by "USB
support"? If you mean that you can use Windows USB drivers on Wine, then
I'm not sure that it is within Wine's charter to do that.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Wine and locales
Filip Navara wrote:
Dmitry Timoshkov wrote:
We should not complicate things, especially since it's not clear at all
what APIs are affected by system/user locale differences.
System locale affects
System locale affects all *A functions. I.e. - it affects all ANSI
functions. Aside from this affect:
- String comparsions
(IntlStrEqWorker[AW], lstrcmp[AW], lstrcmpi[AW])
Uses system locale after trying thread locale (which is
derived from user locale on thread creation).
Uses User locale. Not system locale. It determines the collation (sort
order). Obviously, it affects the A functions (lstrcmpA, etc.), but no
more nor less than it does CreateWindowA, FormatHardDiskA, or
AnyOtherFunctionA.
- Resource loading
(FindResource & friends)
Uses system locale after trying Default UI Language (see
GetSystemDefaultUILanguage and GetUserDefaultUILanguage
or NtQueryDefaultLanguage) and user locale.
Actually, here I don't think system locale affects at all. I'll be able
to tell with more certainty later, though.
- Input locale identifier
The thread default input language for system applications
(that are started before user logins) is derived from the
system locale setting. This probably isn't relevant for
Wine.
And if you ask, no, I will not write a testcase, because it's
sometimes hard for me to even understand the problems caused
by different locales.
Regards,
Filip
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
