Re: Rethinking WineConf
On 01/09/2012 08:31 PM, Jeremy White wrote: Hi All, If you've been to a technical conference recently that you thought was well done, what did they do well? Anything we could emulate? I've gave you some of this feedback in person at WineConf in France. First, as long as it is aimed at Wine hackers, that's who'll show up. The stagnation in attendance is, therefor, more an indication of the state of wine hackers than it is of the conference. What I'd suggest: 1. Split the days. First day aimed at hackers, second day at users. Have a better defined schedule for that second day, so people would have an idea what to expect. 2. For the hacker's day, I expected the free form to take on the form of small working groups. For example, in France, I expected to have some time where Aric and I could sit on a laptop together and actually hack BiDi into a better working state. The conference didn't leave enough room for such an activity. 3. Have the schedule and location ride another conference (similar to the co-op we did with Samba in Germany). Either that, or schedule the conference at a place that has a strong local LUG. The conference at Germany had a great attendance, not only of Samba hackers, but also of local Linux enthusiasts who took the opportunity to attend. Having a non-Minnesota US conference might help, where there is an established LUG that will be interested to tag along. Any other ideas, or suggestions? On a practical note, I suggested to help organize a conference in Jerusalem. I had a specific location in mind, which is extremely close (easy walking distances) to the pubs and restaurants of the center of the city, and it's a combination of hotel and youth hostel, so prices can be expected to be cheap(er, at least in off-season). Israel at large, and Jerusalem in particular, have established LUGs that will probably contribute a lot of fresh eyeballs. Let me know if you want me to find out more. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: [RFC] Use ICU in wine ?
On 10/10/2011 02:48 AM, Rafał Mużyło wrote: Right now, wine claims to use DUCET data for lingustic sorting, but by section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong way. The result of it are bugs such as #10767 and #9583. A possible way around it would beby using ICU to get language specific tailoring and applying some of wine-specific for the parts addressed by #10767. I will not go into the part of the discussion that has to do with whether ICU will or will not resolve the issues. I will point out that Wine used to have a soft dependency on ICU (introduced, for my sins, by me) for the sake of BiDi processing. Everyone involved, myself included, were all too happy to see it go. ICU is impossible to dynamically link with, and it's size is quite huge if statically linked. The good news is that ICU's license seems to be compatible with Wine's LGPL, so if needed, the relevant part can be copied into Wine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Hebrew: update
On 08/29/2011 07:57 PM, Francois Gouget wrote:
On Sun, 28 Aug 2011, Shachar Shemesh wrote:
[...]
Yes. It's called "type". Take a Hebrew text stored in a Windows 1255 encoded file, and "type
file", see what happens. The order, if I understand this correctly, will be logical.
The Windows 7 console does not even support displaying the Hebrew
characters. My understanding is that this is because the only fonts it
lets you pick are lacking the required characters.
I tested this by creating a Unicode file with notepad (which displayed
everything fine, in Windows 7), containing:
Yes, it does not support Unicode. That's why I said "1255", as in
"Windows 1255", the ANSI encoding for Hebrew.
The first line was ok but the second one was either question marks or
squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida
Console' and 'Raster Fonts'.
It should let you pick any monospace font. At least one of those
should contain a Hebrew encoding. If not, you might need to set
the default locale to Hebrew in order to test this (which will
only be possible after clicking "add support for complex text
layout languages", or something to similar effect, in Regional
Settings). This will also install the Hebrew fonts.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
Re: Hebrew: update
On 08/28/2011 01:19 PM, Francois Gouget wrote:
On Sat, 27 Aug 2011, Yaron Shahrabani wrote:
[...]
Microsoft had this decision in Windows XP, many DOS apps that were
supported until Windows 98 were no longer supported and had to search
for alternative or keep using an unsupported operating system.
I did some tests in Windows 7. cmd, ipconfig and net are translated to
French but not to Russian (LTR), Japanese (LTR) or Hebrew (RTL). So I
don't know if it would support the output of RTL strings from console
applications such as usage or error messages. If anyone knows of an
application I could test.
Yes. It's called "type". Take a Hebrew text stored in a Windows
1255 encoded file, and "type file", see what happens. The order,
if I understand this correctly, will be logical.
For ease of use:
שלום
should display (top to bottom is left to right):
ם
ו
ל
ש
but will probably display:
ש
ל
ו
ם
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
Re: Hebrew: update
On 08/26/2011 04:35 PM, Yaron Shahrabani wrote:
It might sound weird but the Israeli community really doesn't
care
about this terminal bug
AFAIK, the Windows console does not do BiDi either (which would
mean that, in order to be bug compatible with Windows, neither
should wineconsole). To be fair, it has been quite a while since I
last checked, so something may have budged on that front.
The greater problem is that BiDi console is an unsolvable
problem. I have not played much with MLTerm, but with Konsole, I
keep it as a handy "turn on, look, turn off" feature. Without a
good semantic understanding of the string it is almost impossible
to perform BiDi reordering, and the results vary from barely
readable to undecipherable.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
Re: USB Osciloscope
I have a USB osciloscope (Link Instruments DSO 8002) that I am quite motivated to get working in wine. I have followed the instructions to install the USB patches. The osciloscope software works fine in demo mode, but it still cannot find the device. I have spent some time messing around with this, but I am new to wine, so I am a little lost. I am a half decent c programmer, so If somebody could point me in the right direction I should be able to get this working. I have gotten error message usbd.sys failed to load. I don't know if this program requires functions that wine does not support or I have just failed to install something correctly. I have attached lsusb and winedump -x output Any help would be greatly appreciated. usbd.sys sounds like a kernel driver. I'm not sure those are supported, even for USB. I had a logic analyzer that I managed to get working (sort of - the GUI did not work well with Wine). It used the FTDI drivers, so I found Linux version of the same drivers, and created a winelib wrapper for them under the same name as the Windows version. Your driver seems to be for a driver called ezusb. Try finding linux drivers for them (ezusb linux drivers returned http://www.linux-usb.org/ezusb/, for example. There is also http://www.cypress.com/?id=4rID=29746). Hope this helps, Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Pulling Patch
On 06/02/11 11:13, Damjan Jovanovic wrote: On Sat, Feb 5, 2011 at 5:48 PM, Shachar Shemesh shac...@shemesh.biz mailto:shac...@shemesh.biz wrote: On 05/02/11 00:24, James McKenzie wrote: Actually, the latest patch is what I don't want reused. And no, you don't put it in the LGPL until it is committed, which I don't expect AJ to do anyway. However, I'm moving in a different direction since my Mac needs more repairs than I'm willing to spend money on. Besides, I've been a big enough pain that my existence here is unwarranted and unneeded. As anyone who attended the last WineConf probably already knows, you have my complete sympathies in that regard. I also doubt very much anyone would use your uncommitted patches against your will, so in that respect, you probably have nothing to worry about. That said, I believe your claim to the right to demand no use is wrong. It is my understanding that by submitting your patches to wine-patches, you have placed them under the LGPL, which is a non-revocable license. Again, in all likely hood, this is a purely hypothetical question. If the LGPL is non-revocable, is code you've placed under it still re-licensable, by you, under another license, as long as you don't revoke the LGPL in the process? ie. could I submit a piece of code to Wine and to another project? First, IANAL. You do not give up your copyright when you license code under the LGPL (or any other open source license). You merely provide a license (which is irrevocable). As such, the answer is yes. You can license code for which you own the complete copyrights under as many licenses of any type you wish to as many recipients as you wish, even if the licenses conflict. That said, if the copyright is only for derivative work, then you also need a license for the original work. The only license you have for the original work in the case of Wine is the LGPL, and THAT LICENSE is conditioned upon the fact that you license your own code under the LGPL only. As such, you cannot license changes to wine under another license, despite the fact you have the copyright for it, as that would leave you without the license to create your derivative work in the first place. So the real question is how independent your code is that you wish to submit. As long as you do not copy code from wine, you can submit the same change to as many open source projects as you like (even if their licenses are conflicting), and even use it for a proprietary project. If, however, the code requires Wine code in order to make sense, then you are bound by the LGPL and need to only use the code in a compliant way. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Pulling Patch
On 05/02/11 00:24, James McKenzie wrote: Actually, the latest patch is what I don't want reused. And no, you don't put it in the LGPL until it is committed, which I don't expect AJ to do anyway. However, I'm moving in a different direction since my Mac needs more repairs than I'm willing to spend money on. Besides, I've been a big enough pain that my existence here is unwarranted and unneeded. As anyone who attended the last WineConf probably already knows, you have my complete sympathies in that regard. I also doubt very much anyone would use your uncommitted patches against your will, so in that respect, you probably have nothing to worry about. That said, I believe your claim to the right to demand no use is wrong. It is my understanding that by submitting your patches to wine-patches, you have placed them under the LGPL, which is a non-revocable license. Again, in all likely hood, this is a purely hypothetical question. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: PGP key signing party at WineConf
On 08/11/10 08:44, Austin English wrote: Howdy Shachar, I've noticed a few pgp/gpg websites that say the key should have the persons FULL name. Is the full name required, or is just my First/Last name sufficient? Thanks for organizing this, by the way :-). In a nutshell - it depends. I, as an example, have a middle name that I seldom (i.e. - never) use. It does not appear on my PGP key. The real rule for what a PGP key should contain is your identifying name. It might well be that some of the party's participants will refuse to sign your key if the names on your key and on your identifying certificate are not 100% identical. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
PGP key signing party at WineConf
Hi all, During WineConf we will be holding a key signing party, organized by your truly. The wiki page for WineConf has been updated with details on how to participate, and I have set up a page explaining the process for people who have never participated before. Please email your keys to me, with the subject WineConf key signing (so that my spam filters don't eat it up). The wineconf wiki page, in case you are not up to date, is at http://wiki.winehq.org/WineConf2010 The key signing page is at http://wiki.winehq.org/KeySigningParty Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Purist keyword?
On 30/10/10 19:25, Austin English wrote: I meant bugs that only occur by manually removing native dlls. The report summaries are usually clear enough, I was hoping to get an easy way to search for them and separate them from 'normal' bugs. I suspect your use of the word native is different than the one defined by Wine (see, for example, http://www.winehq.org/docs/wineusr-guide/config-wine-main). Native DLLs, in Wine, are DLLs that come from a real Windows system. This as opposed to built-in DLLs, that are DLLs compiled for Wine as winelib, carrying the .dll.so extension. To the best of my knowledge, Wine arrives with no native DLLs at all, and thus one cannot remove any. Can you point to a bug report you might tag as purist, so we can all get on the same page? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Linux kernel and game performance?
On 26/10/10 01:26, Dan Kegel wrote: The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms. I thought TICKLESS did away with the timer resolution issues. Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Linux kernel and game performance?
On 26/10/10 14:09, Dan Kegel wrote: On Tue, Oct 26, 2010 at 7:23 AM, Shachar Shemeshshac...@shemesh.biz wrote: I thought TICKLESS did away with the timer resolution issues. There might still be some, and there are lots of knobs to tweak on the kernel, perhaps default settings are not optimal. More details would certainly be welcome. Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use? I think he said Sleep(). My mistake. I was referring to sub-millisecond precision, which is irrelevant to this discussion. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: RTL in console windows
On 15/10/10 16:06, Yaron Shahrabani wrote: So my dillema is as follows: Should we continue helping improving the support of displaying RTL languages in wineconsole or should we just ignore the CLI strings like MS did with all of their OSes (Since Windows XP Hebrew is no longer supported officially, meaning that you have to apply 3rd party patches in order to make Hebrew text appear in cmd), Hebrew in command line is only used by some old healthcare services and lots of old games and ancient word processors and database apps (some of them died after Windows dominated the market). If Windows doesn't do it, I don't think we should. Then again, it is my understanding that in some places, Windows does do it. Powershell, was pointed out by Michael Kaplan (http://blogs.msdn.com/b/michkap/archive/2010/10/07/10072032.aspx - myth 6). I have not tested it myself, but if that is correct, we need to do it like Windows does it, under the same circumstances. Another vital question I want to to this message is to ask our fellow Arabic and Persian speakers what do they have to say about this issue and if their propriatery operating systems has the same issues... This is irrelevant. Our standard of operation is what Windows does. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Set base direction of web site to RTL language for Hebrew
On 17/10/10 13:52, Yaron Shahrabani wrote: Waste of time, there are several objects that should be LTR (like the news list) and some images that need to be flipped horizontally, plus I have already done all the stuff I said, basically this patch is useless... I will accept and admit your accusation of me not being psychic in sensing your incoming patches. Your patches are, indeed, more comprehensive than mine, but I believe they are inferior in at least one important aspect. You direct the code to load styles-rtl.css instead of styles.css. This encourages future site maintainers to perform changes to the CSS that will break the RTL version of it, due to not noticing the existence of the rtl version. I believe the approach I took, of including styles.css, and then including a second css only aimed at correcting the what needs to be corrected, would work better in the long run. Another manifestation of this difference can be seen when you place a dir= directive on the body tag of content_print.template. This is change does not pass strict HTML validation, and would be unnecessary had the two CSS approaches been used. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Set base direction of web site to RTL language for Hebrew
On 17/10/10 15:00, Yaron Shahrabani wrote: Another manifestation of this difference can be seen when you place a dir= directive on the body tag of content_print.template. This is change does not pass strict HTML validation, and would be unnecessary had the two CSS approaches been used. So they should be combined? I think, no. I think the RTL file should only contain RTL related stuff, and will therefor be okay to use it also in the content_print file, without adding a tag to the body. Just MHO. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 29/09/10 16:53, Scott Ritchie wrote: Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user... What do other packages that depend on ptrace do? In particular, what does strace do? I'd ask about fakeroot-ng, but it's in universe, and I'm the upstream maintainer (read - Debian), so I'm fairly sure that's just broken, but do have a look at that too. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 24/09/10 23:00, Alexandre Julliard wrote: Paul Vrienspaul.vriens.w...@gmail.com writes: I see you made great steps in getting the RTL stuff working. The Hebrew version of native winmine shows the menu's right-aligned now! What are the plans/ideas for the Wine builtin programs with respect to RTL languages? I mean, how are we going to make the distinction between LTR or RTL when builtin apps are run? The apps that are ready for it will have to call SetProcessDefaultLayout when appropriate. I don't think we want to use the version resource for this, the mechanism is badly designed and would be painful to use. If I might recommend something, I suggest not to use SetProcessDefaultLayout at all. Just localize whatever needs localization through the resources and that's it. Even for menus, the resources have an option to define the menus as RTL. The automatic mirroring process is, simply put, a broken idea, badly implemented (I'm talking about Windows here, not Wine). I'm not even sure that the Windows built-in applications use this hack, but even if some do, that is no reason to go down that path. Just my 2cents Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 18:21, Alexandre Julliard wrote: Shachar Shemeshshac...@shemesh.biz writes: If I might recommend something, I suggest not to use SetProcessDefaultLayout at all. Just localize whatever needs localization through the resources and that's it. Even for menus, the resources have an option to define the menus as RTL. Most applications are not dialogs, so you can't mirror the application window through resources. For instance with notepad, you'd most likely want the edit control to be RTL too, not just the main menu. Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? At the moment, the edit control does not even properly support BiDi. I do not have a Hebrew localized version of Windows on hand, so it's a bit hard for me to check how that works, but even if we had a BiDi text control, the only effect this localization would have is to set the default direction of the control. The user would then switch it anyways. Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 20:25, Alexandre Julliard wrote: Shachar Shemeshshac...@shemesh.biz writes: Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? What do you consider broken about it? Everything. The concept is that a RTL layout is just a LTR layout reversed. This is almost never the case. Almost always, some controls need to still be LTR (URL edit control, tree view of, basically, Latin registry keys, etc.) Defaulting to a mirrored UI means you need to base your redesign on something substantially different than the original, which I do not see as a good move. Microsoft's implementation of this idea is just as crappy as the core concept. The UI often contains images that are part of it. In order to keep the thing even slightly okay, Windows automatically mirrors every image (yes, EVERY image) displayed into a DC which has the RTL attribute set. The MSDN page discussing this has hilarious images of the Microsoft logo reversed. Their OFFICIAL recommendation is to create localized Hebrew/Arabic resources of the images, which are mirrored at the source, so that after the UI second mirroring they turn out okay. Two wrongs don't make a right indeed. All in all, it is my experience that starting with the LTR layout requires less work and is less error prone than starting with a mirrored LTR layout. This aside from the problems I've mentioned before on this list, of the utter stupidity of having some windows on the same desktop with a close button on the left and some on the right. I know no one who finds this convenient. Don't get me wrong. I'm not saying we shouldn't implement this (except the window decoration part, that i think we should not implement). I'm just saying that I would rather if Wine's built in applications not participate in this madness. Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Pretty much all of them. For example, Wordpad has combo boxes in the toolbars, those won't be RTL without changing the process layout. Winefile and Regedit have treeviews that would need mirroring, etc. First, I'm not sure what the proper way to RTLize regedit should be. See above. Less specifically, however, all controls that have BiDi settings can have those settings set through the resource for that control, without setting it for the entire application. In those cases that the layout is not control by a resource, we are pretty much in deep #...@$!@# anyways because of the reasons stated above. Whether it is Yaron doing the localization or someone else, they must have some way to change the layout in a way that is not merely mirroring, and whatever way that is, it will require being able to tell the system which controls need RTL and which don't. Shachar P.s. I am going over the built in wine applications, and would like to point out for whoever is thinking of localizing clock that clocks in RTL speaking regions still rotate in the same direction. -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 21:59, James Mckenzie wrote: And Microsoft Office appears different in RTL rather than LTR. I used to work with someone that had the Arabic version of these programs and it would switch from RTL when typing in Arabic to LTR when typing in a Latin-based language. I'm sorry, but you are confusing several issues here. The question is not whether to implement BiDi (yes, provided we find the working hands to do it) or mirroring (yes, except I don't think we need to bother with mirroring the window decoration UI components that Windows does, and I have not heard anyone else weight in on this issue lately). The question is whether Wine's built in application should set a specific flag to do automatic mirroring. Since Word is not a Wine built in application, what it does is irrelevant for this discussion, not because we don't intend to support it, but because it is undisputed we do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 21:52, Alexandre Julliard wrote: You can't do that in resources, apart from simple dialogs. Many controls are created directly in the code, so you need to change the source. Whether this is to set the process-wide layout or to set WS_EX_LAYOUTRTL individually on appropriate windows will depend on the app, but it needs code changes either way. Okay. No dispute about that. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: gdi32: use usp10 to optionally generate glyphs for bidi strings
Alexandre Julliard wrote: Which of course demonstrates that gdi32 calls usp10 on native too. Maybe it does it indirectly through lpk.dll, but the end result is the same, you have a dependency on usp10. I know I'm coming a bit late into the discussion, but just for the record, this is how Windows does it (as of Windows 2000): * GDI has a soft dependency on LPK.DLL. It tries to load it using LoadLibrary. * If it succeeds, and if there are no breakout flags, each call to ExtTextOut is redirected to the LPK version of that same call * LPK links with uniscribe for the actual BiDi processing, and also with GDI for the actual rendering of the result. Yes, this means a circular dependency. * The breakout flags are ETO_IGNORELANGUAGE and ETO_GLYPH_INDEX. If these are passed, GDI handles the request itself, without forwarding it to LPK. This prevents the infinite recursion that might, otherwise, happen. I believe the reason for this twisted design is twofold. First, in Windows 2000, CTL (complex text layout) was an optional component, to be installed by a checkbox in the regional settings dialog. This meant that the entire LPK dll could just be dropped in, along with some fonts, and the system would start supporting BiDi. The second reason is because BiDi is a rather multi-layered process. With BiDi, support for multi line rendering (as done by DrawText in User32) requires some fairly complex processing before the text could be passed off to ExtTextOut for actual rendering. This way, all the BiDi code could be placed in one place. Another reason, I believe, for this separation is that pre-Windows 2000 (and more importantly, pre-uniscribe) Windows still had BiDi code, which was scattered all over the place, and which became obsolete (for one example - GetCharacterPlacement, which supposedly does BiDi, has no mechanism to choose the paragraph direction, without which no BiDi processing makes sense. The MSDN docs even explicitly state it is obsolete). I believe the best route forward is to use an LPK *like* DLL. Not LPK itself, as that would require of us to reverse engineer a whole set of APIs that no one but us even call, but another DLL, injected into the dependency order at the same location, carrying a similar functionality. I would suggest winelpk.dll as the name, but that is, of course, entirely open. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
Paul Vriens wrote: Hi, I've been in talks with a Hebrew translator for some time now and I'd like to have Wine being able to start doing more RTL stuff. I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158 If I run an English winmine.exe on an Arabic box (thanks to the testbot) the main window will shows as normal LTR window layout with the menu's left justified as well. So eventhough the locale is set to Arabic it doesn't turn 'everything' into RTL. If we don't change the resource files for the RTL languages, that same logic will give us LTR Wine applications or am I wrong here? An English app running on a Hebrew Windows does not automatically get entirely reversed. There are two parts to this question, and I believe that Wine should handle those parts differently. One part are the Windows decorations - close button, minimize, maximize, etc. Under Windows, if an application is reversed, so are these. I believe Wine should not attempt to replicate this behavior for the following reasons: * It is a broken design decision. Its implications are that on the same desktop, some windows have their close button on the left, others on the right. In my experience, this does nothing to enhance the user's experience. * It is difficult to implement. The decorations on Wine windows are drawn by the X window manager. We would have to convince each window manager to reverse the window decorations on our say so. I am not aware of such an API existing, which means lots and lots and lots of bugs. * As an aggregate of the above two - the window decorations are, today, not defined by Wine to be part of the windows experience, and as such, if the Windows behavior is broken, we need not replicate it. The other part is the actual content of the window. Here there is a need to support exactly what Windows is doing, as that is the API. As a side note, I'll add that I think that is broken too. Mirroring should not be done automatically, and reading the MSDN article that Dmitry references just shows how many ways it can, indeed, break. That said, Wine did commit to being bug-compatible with Windows, so that part should, *eventually*, be implemented. I do agree with Alexandre that there are many things more pressing on the BiDi front to handle. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Summer of code and bidi
Maarten Lankhorst wrote: Hi Shachar, I've removed the bi-directional entry from summer of code. I don't think it is a good project because it involves a lot of changes in pretty much all wine user controls. Actually, I don't think any touching of the actual user controls is involved at all. I think the first bullet (which can be all we want for this year) only really involves the ExtTextOut function, as well as the Uniscribe functions. No user controls are touched at all. The only way to do this would be by using the pango library to do the laying out of text, I was about to say that the code is practically already there, but I really think you should know that, being how it was you who put it there :-). I really think that if we came this far, we had better split the Unicode algorithm into the components it requires and put it into Uniscribe. I don't think we need any reliance on external libraries (pango, fribidi, or any other) for that. but I'm not even sure whether that is a good summer of code idea, since it would need someone already very experienced with the plumbing of wine. It would require someone to learn the BiDi algorithm and the Uniscribe interface, but the reason I offered to mentor it was precisely so that the student not have to follow the entire Wine structure. I really don't believe this task is heavier than some of the Direct3D stuff on that page. Maarten. Just MHO Shachar
Re: Bow and question
Juan Carlos Montes wrote: Shachar Shemesh escribió: I think you should be aware that Wine is no replacement for a security tool. If you run a malware using Wine, it is possible for this malware to interact directly with your Linux machine, bypassing your protection. Shachar I know it, but we can control all actions that the malware make. If the malware bypass the protection and infect the machine... no problem, format, image and new malware to check, :) But what good is a malware study tool if the malware can trivially detect it's there? What if it doesn't infect the machine, but just run differently? There are Windows tools that do similar things to what you need (check out the sys-internals web site), where the environment is much more close to the real thing. Actually, Dan's question is the more interesting here - did the malwares work under wine? Shachar
Re: Bow and question
Juan Carlos Montes wrote: Hi all, I am new in this list, so... Hello!!! Well, I work in a CERT and we are create a automatic malware detection tool with wine. I think you should be aware that Wine is no replacement for a security tool. If you run a malware using Wine, it is possible for this malware to interact directly with your Linux machine, bypassing your protection. Shachar
Re: Wine and LD_PRELOAD
Sorry for answering a little late. Lionel Tricon wrote: In fact, we overload a lot of common system call from the standard libc. We have slightly modified the fackechroot library and we need to trap almost all system calls linked to the filesystem. I have just (a couple of weeks ago) started a project called Fakeroot-ng. You can get the (extremely preliminary) sources from SVN on http://sf.net/projects/fakerootng. Fakeroot-ng aims to achieve the same goal as fakeroot and fakechroot, except it uses the ptrace interface rather than the LD_PRELOAD interface, which, as you can see, has lots and lots of problems with non-standard applications. Fakeroot-ng is extremely far from being complete at the moment, but if you will find it useful, then I can use the extra programming skills. Shachar
Re: Valgrind results for Nov 12 13
Dan Kegel wrote: Oh, he'd undoubtedly prefer ignoring to memsetting. I believe the official answer is to teach valgrind which fields are important for which server request. Granted, it a lot more work, but it's the only way we will actually catch errors :-) Shachar
Re: Total bidi regression
Maarten Lankhorst wrote: I may have slightly misunderstood those flags then. I was under the impression that the FORCE flags would be similar to LRO/RLO. The only thing that behaves like LRO and RLO are LRO and RLO. Believe you me, no one was more surprised than me when I found out that Windows actually respected them - they are as far away from an end user's experience as you might get (though useful, if you know about them). The Unicode algorithm keeps talking about setting the paragraph direction based on the first strong direction character in the paragraph (P2). As nice as that may have sound to the people drafting it, it only sort of works in real life. Either way, Window's BiDi doesn't work that way. The paragraph direction is set explicitly by the calling program (or, failing that, by the HDC, or, failing that, by an EXT_STYLE in the Window, you get the picture). This means the end of section 3.3.1, instructing implementors to ignore P2 and P3 in case of higher-level protocol apply here. Instead, the paragraph direction is explicitly passed to BIDI_Reorder through the dwWineGCP_Flags argument. Instead they are probably more like LRE/RLE. It's better to say that LRE and RLE allows one to switch paragraph direction for a specific part of the paragraph. In other words, LRE/RLE are like the paragraph direction, not vice versa. If that is a real problem I will send in a patch. If? I would still rather prefer a real bidi implementation, so that selecting and deleting characters would work properly. Lost you there completely. What do you mean by selecting and deleting? If you mean a BiDi editor, I think you have the tasks confused. Reordering characters in order to get them out on screen for printing has very little to do with string editing. It's one minor small step to start with. Bidi editing is a lot more complex. To my defense, there was no real clarification for them in the source. The comments in the code used the same terminology used by Annex 9. The parameters were passed almost directly from the inputs in BIDI_Reorder to ICU's input functions, where they are documented in the ICU documentation. These parameters were also received, pretty directly, from ExtTextOut, again, where they are documented in MSDN. To my eyes, this is the level of documentation any Wine hacker should need. I don't believe code comments should start explaining algorithms, particularly algorithms implemented by a library and documented in an international standard. And I should warn you that edit control is several magnitudes more complicated. Questions such as cursor position when the cursor is between two letters that are, after reordering (i.e. - on display) not adjacent, what happens if a given cursor location is clicked which has two possible logical locations, and what to do if the user then clicks del or types a letter in an RTL or an LTR language. Editing is COMPLEX, and the road is not paved and documented. Matti Alluche wrote a document once that gives specifications for BiDi editing, but after Mozilla implemented it, I whole heartedly recommend that you avoid it. Your best course of action is to find out what Windows does for its edit control and copy that. Cheers, Maarten Shachar
Re: gdi: Fix meaning and use of bidirectionality flags
Maarten Lankhorst wrote: According to shachar shamesh they have a slightly different meaning. This should fix it. First of all, things seem much much better with this patch. I would direct your attention to the fact that, when I run it, I get: $ programs/notepad/notepad fixme:bidi:mirror stub: mirroring of characters not yet implemented fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 As far as I can tell, an assert should not be a fixme, but that's something else. Shachar
Re: Recent BiDi changes
Maarten Lankhorst wrote: On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters. Shachar I'm guessing utf-16, not 100% sure though. Ok. Just so you know, this means the reordering code is buggy for UTF-16 aggregates. I suspect the classification code is too. From the recent changes to bidi.c: if (odd(levels[lastgood])) for (k = j - 1; k = lastgood; --k) lpOrder[done + k] = done + j - 1 - k; An aggregate in an odd level will have its two part reversed, making it meaningless at best (at worst, the trailing part will match the leading part of the previous character, creating a totally unrelated legal character). I suspect you have a similar problem in the classification part of the code. I've gone over the tables (cursory glance), and haven't been able to find characters in the aggregate area that are naturally likely to receive an odd level. I also asked on the fribidi list several times, and got the reply that there are such letters, but no specifics. This has a lot to do with my inability to empirically test whether Windows handle these. My latest test was an attempt to run a string that has RLO through GetCharacterPlacement, but even that fails at the moment (not to mention that GetCharacterPlacement is an old interface under Windows, and is slightly depracated, despite not being documented as such). While it is true that the very fact that I'm having such a hard time in finding out whether aggregates are supported on Windows means that any bug we introduce because of lack of support for aggregates will be a rare one, I still would prefer not introducing bugs into Wine if they can be avoided. Maarten Shachar
Total bidi regression
Hi Maarten, It seems that since your last changes to the Bidi implementation, BiDi suffered total regression. At least on my system, no BiDi related text (neither Hebrew nor Arabic) gets reordered, at all. Placing breakpoints suggest that BIDI_Reorder is still getting called, so I can only assume that the problem is somewhere inside it (or in the classification) I haven't traced inside to see where things went wrong, nor do I know whether your work on that matter is done. I just wanted to point out that Wine, at the moment, performs no BiDi at all as far as the user is concerned. Shachar
Re: Total bidi regression
Maarten Lankhorst wrote: If you want it back try replacing this in font.c: WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR change FORCE to LOOSE, it should work then. I'm not sure what you are suggesting. WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads: case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; I'm not sure what you are suggesting I do with it. Either way, the change you are suggesting will only affect (if I understand the code correctly) the paragraph direction setting, where as I'm experiencing total lack of BiDi reordering of any kind. All codes taken from latest git. Cheers, Maarten Thanks, Shachar
Recent BiDi changes
Hi Maarten, Can you, please, explain the advantage of creating our own implementation of the BiDi algorithm over using existing implementations? I know ICU sucks (especially as far as linkage is concerned), but there are other implementations, major among which is fribidi, which are free, are C based, and have a compatible license. Is there any need to Wine to be aware of the inside working of the algorithm? Also, so long as you are picking up the BiDi glove I dropped oh so many years ago, it seems to me that the proper place to implement BiDi would be in unscribe, where it is for Windows. The GDI implementation Wine has is a hack that reached it's useful end the moment you realize that DrawText needs its own implementation, independent of ExtTextOut (mostly due to line breaking code). Thanks, Shachar
Re: Recent BiDi changes
Alexandre Julliard wrote: Actually the proper place would be libwine along with the rest of the Unicode support. I've spent the past hour downloading 12% of the git repository, so I'm unable to look at current Wine code for at least the next 24 hours :-(. From memory, libwine contains mostly tables and stuff, not actual algorithms. Wouldn't it be better to place the tables at libwine, but the algorithm at uniscribe, if only to follow Window's design of things? Also, I suspect it might be necessary, at some point in the extreme distant future, to do some deviation from the Unicode algorithm. It's pretty far away, as we're talking about nuances that are hard to pick if you don't know your stuff, but there are places where Windows can be said to be either implementing an old version of the standard, or implementing its own idea altogether. My original plan was to import the fribidi code into a subdirectory of the wine tree, and make the necessary changes there. On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters. Shachar
Re: Recent BiDi changes
Alexandre Julliard wrote: Actually the proper place would be libwine along with the rest of the Unicode support. I've spent the past hour downloading 12% of the git repository, so I'm unable to look at current Wine code for at least the next 24 hours :-(. From memory, libwine contains mostly tables and stuff, not actual algorithms. Wouldn't it be better to place the tables at libwine, but the algorithm at uniscribe, if only to follow Window's design of things? Also, I suspect it might be necessary, at some point in the extreme distant future, to do some deviation from the Unicode algorithm. It's pretty far away, as we're talking about nuances that are hard to pick if you don't know your stuff, but there are places where Windows can be said to be either implementing an old version of the standard, or implementing its own idea altogether. My original plan was to import the fribidi code into a subdirectory of the wine tree, and make the necessary changes there. On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters. Shachar
Re: Will ROS and WINE still be steady be synchronized ?
Shachar Shemesh wrote: Here's the law as I know it. As far as I know, it is quite identical in the US and in Israel in that regard: Just to make it clear, as far as I can see it, even with the above, it is still illegal to accept code from RoS (you are not allowed to copy code from the MS source code, or even from your own effort of translating the assembly to C, without violating copyright). All I'm saying is that the rules are not as strict as we sometimes play them to be. Shachar
Re: Will ROS and WINE still be steady be synchronized ?
Alexander Nicolaysen Sørnes wrote: ReactOS has been known for disassembling Microsoft binaries, which is illegal in some countries, notably the US. As far as I understand this, if I disassemble Microsoft binaries (it is legal in Israel), then the resulting knowledge is legal to use - anywhere (in other words - the only one who can be sued is me, and the jurisdiction is Israel, where the action is legal). Do RoS people disassemble binaries in countries in which it is illegal to disassemble them? Shachar
Re: Will ROS and WINE still be steady be synchronized ?
Dan Kegel wrote: I am not a lawyer, but I bet you're wrong there. The disassembled code is probably considered a copy, I'm not talking about moving disassembled code into our code. That is a copyright violation in Israel too. I'm talking about disassembling code in order to figure out what it does, and then reimplementing that (with or without going into the extremes of clean room). Do the RoS guys do the former? Shachar
Re: Will ROS and WINE still be steady be synchronized ?
Dan Kegel wrote: We've gone over this about a dozen times. Can we get back to programming Wine now (cleanly)? - Dan Here's the law as I know it. As far as I know, it is quite identical in the US and in Israel in that regard: - Any trade secret (say, algorithm, interface, subbehavior) loses its secret status the moment it is reversed engineered from a legally obtained copy. Once it loses its secret status, it is obviously legal to cleanly reimplemenet it. - Any trade secret loses its status the moment it is public. As far as I understand it, the MS source code that was leaked has no trade secret protection any more, and it is entirely legal for a Wine hacker to look at it in order to find out, for example, why a certain combination of parameters, when sent to a certain function, causes Windows to do something unexpected. It is NOT legal to copy code into Wine from it, as that code is still copyrighted. - Interfaces are not copy protectable. This means that it is, in principle, legal to copy a file that only has interface definitions (say, a header file) into Wine. We don't do it, and for a good reason (why risk it for such a small gain), but it is legal. - A programmer is only tainted if she signed an NDA or a non-compete. Even then, it's a contractual dispute, not a criminal dispute, whether she is allowed to work on Wine. Merely looking at publicly available code does not taint a programmer (this is unlike the IBM BIOS case, where they gave the BIOS source code under NDA, and thus retained trade secret status for it). Shachar
OT: Everyone at minnesota ok?
For those who have not head, there was a lethal bridge collapse and there are several casualties. Codeweavers is located near there. Just wanted to make sure everyone is ok. Shachar
Re: Wine keyboard driver+XKB. What am I to do?
Oleh R. Nykyforchyn wrote: Hello, I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts. Now patched keyboard driver allows user to: 1) have up to 4 XKB groups working (current code uses 1 or 2); 2) detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group; 3) freely combine available XKB layouts in any order, e.g. en,ru,fr; 4) list all layouts available at the system, and implement ActivateKeyboardLayout(); 5) notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box; 6) input characters that do not fit into current Unix locale, e.g. German and French accented letters at a system with Cyrillic (not UTF) locale; 7) override any of detected layouts via registry, if user is not satisfied with Wine driver choice. In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of functions in it were rewritten, and it now easier to read new keyboard.c than diff output to understand the changes. I got very reasonable advice from L.Rahyen to broke the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even very small one) will touch hundreds if lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code by a patch if we can benefit of it only after next patch. Now I will be grateful to any help. How can such big changes be introduced in Wine tree? I also attach a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about results. Oleh Also, have a look at http://bugs.winehq.org/show_bug.cgi?id=735, which is an independent attempt to solve the same problem. It's a pity I didn't know about your effort. Shachar
Advice on how to proceed - XKB keyboard handling
Hi all, I put up an intermediate version of my XKB patch. It is the last attachment for bug #735 (http://bugs.winehq.org/show_bug.cgi?id=735). The patch, as is, solves bug 735, as can be tested by compiling the test program. However, it does not play well with other areas of the keyboard handling. I'm posting this here partly to draw attention for those who need bug #735 fixed and can live with the regression, and partly to get feedback on how best to proceed. Thanks, Shachar
Why double translation on keydown?
Hi all, The current code for keyboard translation goes something like this, if I understood it correctly: * An X11 event arrives with the physical keycode for the key pressed. * Said code is translated into a VKey based on the current keyboard (fair enough) * Keycode is translated into a, well, keycode for Windows. 99% of the cases this is the same one, as it's the same PC keyboard as ever. * The vkey and translated keycode are sent as WM_KEYDOWN or WM_SYSKEYDOWN events. * In all probability, the process calls TranslateMessage * TranslateMessage calls (indirectly) X11DRV_ToUnicodeEx * X11DRV_ToUnicodeEx takes the virtual key, looks it up (using a for loop) in the same table consulted before to find out what the original X11 keycode was. * That vkey is passed, after some manipulation, to XKeysymToKeycode to produce a keycode * Said keycode is passed to XLookupString to get an actual key for it This process seems, to me, overly long and inefficient. It requires building fairly complex lookup tables for both vkey and Windows keycode. I fail to see what is gained. Why not use the following process instead: * An X11 event arrives * Use the native keycode as the keycode. * Translate the vkey as before. * Send WM_(SYS)KEYDOWN as before * In X11DRV_ToUnicodeEx: * Use the keycode to lookup with key using XLookupString I fail to see why the forward and backwards translation is good for. Explanation? Shachar
Re: Why double translation on keydown?
Dmitry Timoshkov wrote: X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes a virtual key code. I.e. ToUnicodeEx takes a predefined input and should return data very closely resembling what Windows does. Ok, then maybe we should have TranslateMessage not call that, and use something else instead? This is particularly prominent from this sentence in the ToUnicodeEx documentation (http://msdn2.microsoft.com/en-us/library/ms646322.aspx): The parameters supplied to the ToUnicodeEx function might not be sufficient to translate the virtual-key code because a previous dead key is stored in the keyboard layout. Maybe I don't understand the code well enough, but it seems to me that we report on the dead-key press, but not translate the following character. Is that correct? Shachar
What is the X11 lock?
Hi list, Can anyone please explain to me what the x11 lock is used for? I can see that SOME X11 functions (e.g. - read description on X11DRV_KEYBOARD_DetectLayout) require a lock, while others seem to call X11 functions with no lock. I can see that sometimes the x11 lock is obtained around a single X11 call. Is there any guideline I can follow that will tell me whether I need a lock for code I'm writing? What is the race this lock was designed to fix? Thanks, Shachar
Anyone working on XKB support for Wine (or any other Keyboard language detection enhancements)?
Hi all, The current keyboard detection and setting code is based on the traditional method of setting a keyboard in X11. It misdetects most any language that carries a US keyboard as the first group. While major work on other areas of Wine means that most programs today don't really care about that, it still confuses the $*([EMAIL PROTECTED]$ out of Word. It also has some pretty serious BiDi editing implications. I'm looking into replacing that with code based on the XKB X11 extension, today supported with any quasi reasonable X server. This should totally eliminate the guesswork done through keyboard change detection in wine today. The main question is this - is anyone today already working on this? Thanks, Shachar
Re: Work legalities
Jeremy White wrote: If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. Wouldn't a paper saying they keep their rights, but approve the LGPL distribution also work? Would that still require us to have a written statement? After all, we do not require written from other people. Shachar
Re: Writing a winelib plugin
Dan Kegel wrote: What application did you have in mind? I honestly don't know, yet. I'm meeting a prospective client on Sunday that is currently doing some browser plugin via ActiveX, and wants to support Linux and Mac OSX, as well as Firefox. They were thinking about using Wine for some of the stuff, and converting code for other. Obviously, I've heard the usual we'll use winelib as we don't want to bundle the whole of Wine, and had to break it to them that that is not how things work. At worst, I believe we can run the actual plugin code in a separate process (started by Wine), and have a stub as the actual plugin, and have the two communicate via some IPC. I was just asking in case the problem was miraculously solved by someone while I was away from Wine. What you describe sounds awfully similar to what I remembered, however. Shachar
Re: Work legalities
Nathan Williams wrote: but I did sign a contract and think there may be an issue with one of the sections. If you want, post those sections here. There are some contracts that say anything you do is ours. A reasonable contract, however, will say everything you do using work equipment and on company time is ours. This may still be a problem if, for example, you code Wine on a company provided laptop. When I finally come to submitting code, does wine need a copy of the agreement, or do I just hold onto it incase of future cmplications? (which is very unlikely as I see it) No. Ultimately, it's your responsibility to make sure that the code you submit to Wine under LGPL is yours to submit. As far as I understand, all that will be required of Wine in case of a violation is to remove the code. You, on the other hand, might find yourself on the wrong end of a copyright violation suite from your employer. Just get permission. Oral is ok if you can later prove that it happened (which is another way of saying get it in writing). Shachar
Re: Daylight saving changes
Francois Gouget wrote: Israel Standard Time At least with this one I can help. Feel free to use the data under LGPL: http://lingnu.com/support.html#timezone Which is not to say that I know what to do about it. :-) Shachar
Re: There May Be an End-run for Apple Around Windows After All
Hi Robert, I am an occasional reader of your column (truthfully, mostly when it comes up on slashdot). I usually find your comments insightful, or at least thought provocing. I'm afraid the column at the subject is a stark exception to this rule (http://www.pbs.org/cringely/pulpit/pulpit20060420.html). If you'll excuse the strong words, the claim made was nothing more then wishful thinking, with no possibility of basing it on anything real. Before I get to why, allow me to introduce myself. My name, as you can probably see from the email headers, is Shachar Shemesh. I am founder and CEO of a small Linux consulting company in Israel (http://www.lingnu.com). More to the point, however, I am (or, at least, used to be) a Wine hacker. Feel free to search for my name at http://www.winehq.com/site/who. As the task you claim Apple has undertaken is, in fact, identical to developing a second Wine, I think I have some authority in assessing how likely that is. I also took the liberty of CCing the wine-devel list, so that if anyone there wishes to claim me wrong, they can. And as for the likelihood, I can answer that question rather easilly. The answer is not very. I would even go as far as to say that the answer is extremely unlikely. Wine is a huge project. On last count it had over 1.5 million lines of code. Most of the code inside Wine is written in Win32. Yes, it's a Linux project written, mostly, in Win32. The reason is that the so called Win32 API is a convulted huge heap of layers upon layers of miscellanious implementations of anything Microsoft decided to give developers because it seemed like a good idea at the time. Some of these functions misbehave, and some programs rely on this misbehaviour in order to work. Not all of the functions, and hardly any of the misbehaviours, are documented in any way. The Wine project has been busy, for over ten years now, in duplicating said development. Despite what may appear in your column, the reason it has been taking so long is NOT Microsoft's disapproval. For all intent and purposes, MS has no technical means of slowing Wine down, and here is the main reason - Wine only cares about running actual applications. Microsoft is, of course, at liberty to change and add interfaces as much as it wants, but Wine will only care about these interface changes if and when actual applications start to use them. Over this last point MS has very little control. In that respect, I think it should be clear that Apple is in no better starting position to duplicate the Wine effort than Wine is, and there is no reason to think it will do better. Which brings us to the task at hand. Because the purpose of an API replacement is to be bug compatible with the original, we can already know how the first versions of such an effort from Apple will look. They will probably be able to run Solitare and notepad, but not much more. We know that simply because Wine used to be there itself. Getting from this 90% to 100% takes a considerable amount of time. It makes little sense, and has little return on investment, for Apple to take this herculean task upon itself, when it can get to 95% of the task by simply taking the Wine code and adapting it to Mac OS X. Don't understand this to mean that the next OS X on Intel will not be able to run Windows code without emulation. What I am saying is that it likely WILL be able to do so, but using Wine as its technology. After all, work to get Windows programs running on a Mac using Wine was underway long before Apple made the CPU switch, using thin emulation services. Dumping the emulation (and, more importantly, the endianity misalignment) is only likely to boost this effort. This, however, will happen whether Apple endorses it or not. Hoping your next column will bring us back to the level of writing you usually produce. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
request for Orkut wine forum manager
Hi all, If you don't know who I am, please do skip the rest of this paragraph. As you well know, I have not been as active on the Wine project as I wish. Unfortunately, this is not going to change much in the near future :-( I am currently the manager of the Wine forum on Orkut. I just got an email asking to do some operation (enabling email to members), which clarified to me that, perhaps, my lack of activity is to the disadvantage of the community members. And so, I would like to ask the esteemed members of this list. Is there anyone here who would like to take this responsibility from me? Please be sure to CC me on replies. Thanks, Shachar
Re: WooHoo get a load of this :-)
Michael Stefaniuc wrote: Tom Wickline wrote: Fom : http://archives.free.net.ph/message/20050921.093916.4717740b.en.html This can be because TurboLinux announced today that they will distribute the DAVID technology from SpecOpS: http://www.turbolinux.com/cgi-bin/newsrelease/index.cgi?date2=20050821173249mode=syosai bye michael I'd understand it more if I knew WHAT the David technology actually was! Did they release ANYTHING? Regarding the challenge, it seems that they will give you the application they want working if you contact them. Oh, and about David. Their web site claims to use a hybrid approach to the matter. They integrate emulation and Wine (and wine style) reimplementation. I have no idea how such a thing is supposed to help them along. Also, it will be interesting to see whether this turns out to be any different than what Win4Lin are doing. As a side track, Win4Lin contacted me a while back, and wanted Lingnu to represent them in Israel. I sent back a few technical questions, and NEVER HEARD FROM THEM AGAIN! Does the company still exist? Shachar
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine... Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment. If you give a scenario that is easilly reproduceable, it is rare that problems go more than a couple of days unfixed. Sometimes you hit something that requires a rewirte of half the relevant subsystem, but usually it's just a small ommision, and is easilly fixed. The thing that takes so much time is tracking the exact behavior that goes wrong. Also I remember you've just told that fixing bugs is easy - why does it still exist then? Fixing bugs is easy. Finding them is not. It's exactly the same with proprietary software too, btw. If a user reports this doesn't work, my experience is that you spend two weeks in QA trying to reproduce the problem, half a day fixing it, and a couple more weeks testing the solution. It's fairly rare that the relations are much different, but do let us in on your experience. All we are saying is pin-point the problem for us. Shachar
Re: calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
Saulius Krasuckas wrote: *FileW and *DirectoryW functions fail on every win9x box as they are unimplemented here. Makes sense. They succeed only when app is linked to MS Layer for Unicode (MSLU) and MSLU is installed. [1] A royal pain. I was trying to replace every failing unicode function with its ascii counterpart in one of the wt files [2], but that looked ugly to me. Maybe it would be really nice and possible to link wt to unicows.lib on windows. In this case we need a corresponding static lib in Wine too, right? It probably will be empty because UNICOWS.DLL shouldn't be loaded as Wine doesn't lack implementation of mentioned functions. Though, I have no guess if this could be done easily. Unicows is a pain. First of all, in order to link with it, you will have to remove all standard links (kernel, gdi, advapi, etc), put unicows.lib at the beginning, and then put all standard library links again. Unicows takes over all of the function calls, and on NT and above just redirects them to the usual places. On Windows 98 it does ugly simulations of the actual original call. What I am most afraid of, if using Unicows, is that we will be destroying the validity of the tests. The main question, I guess, is whether these are Unicode tests (i.e. - tests meant to find out whether the Unicode functions are working correctly), or whether these are unrelated tests that merely use the Unicode interface. As for defining unicows.lib - we could do that, sure. We could either export everything there (Unicows.dll today is merely a redirection to the other functions), or we could make it a lib exporting nothing. The first is truer to what the real unicows.dll does (not 100% the same still, thankfully), but the second would probably work better. I would really prefer it if unicows.dll was only ever referenced by PE programs compiled on Windows. What could be a clean and acceptable solution? Your comments, please. The these are Unicode tests, use the Unicode interface. If these are just file system tests, I suggest you use the TCHAR functions. In other words, define your buffers as TCHAR buffer[] (rather than char or wchar), and call the functions without any prefix (neither W nor A). When compiling under NT, define a compiler variable UNICODE, which will map TCHAR to WCHAR. Now, I know that Wine code is forbidden from using the non-suffixed calls, but the wine tests are not Wine code, they are winelib applications. I don't think there is any problem in using these functions there. We could even run the tests both in ANSI and in Unicode mode, to compare results. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: CrossOver licensing behaviour?
Andreas Mohr wrote: Hi and greetings from LinuxTag in Karlsruhe! At our booth we had a visitor who told me that the version of CrossOver Office that he had been using issued a timely warning about license expiration few months before finally actually ceasing to provide service exactly after one year. Could it have been an email sent to notify the user the the *support* is about to expire? I'm assuming it was not a demo version. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: List settings
Jeremy Newman wrote: Just double checked the settings. The lists are set with replies go to the poster. I also took a look at the mail headers for the messages being sent out. There is only the To: and Cc: fields. To: is set to the poster, and Cc: is set to the list. I think I figured it out. The list has a List-Id: field. As the list has two names (wine-devel@winehq.org and wine-devel@winehq.com), that may be confusing kmail. Still seems to be either a bug in kmail, or an attempt by kmail to work around a bug in the way some lists are set up (with reply-to: list). Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: CPU Emulation
Andreas Mohr wrote: Hmm, probably yes, since the whole Win32 API part would be done natively, but there's still the whole x86 program part remaining for translation. We've been through that one once already. You'de end up with horrific endianity problems. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Commercial support
Tom Wickline wrote: On 5/7/05, Shachar Shemesh [EMAIL PROTECTED] wrote: This is actually a very good point in favor of not charging money at all. If you charge money, you create obligation. That's the way the legal system works. If you do not, you can easily delist any known LGPL offender. It could be looked at as a minimum donation request, and any funds raised should go to the WPF. Or it COULD be looked on as a commercial transaction. They pay money, you provide ad space. If this goes to court, who's going to pick up the legal costs? Besides, what court will accept a compulsory voluntary donation theory? If you want to delist violators, make sure you either sign them up on a contract (expensive) or not take money from them. I believe giving away the only resource that winehq.org has for generating revenue for the WPF is insane. I don't know. It seems that WPF is doing sort of ok without this, and that wine at large is doing ok without the WPF. Having published commercial support is important for wine to do better, which is the real goal here. Not WPF. I think we should explore ways to raise money for future Wineconf's and other worth while expenditures. While 10k/yr may be a high target 100/yr is a bare minimum at best. Go ahead. It's just that entering a legal obligation with commercial companies we don't trust, and without a contract, is a bad idea in my very humble opinion. Or do you really think that Lingnu is going to hold back code from Wine? No I don't, I never have and as as Ive already said before I believe everyone in this discussion is responsible and supporters of OSS. But you are thinking of asking for an amount of money Lingnu will not pay, which means Lingnu loses (no visibility) and Wine loses (one less company that CAN provide support, will donate changes back, but is not listed). A good deal is one which is win-win, not lose-lose. Let's consider what we have so far: 10K/yr - lose lose 100/yr - win-lose (Lingnu doesn't mind paying 100/yr, but WPF will get, at best, 1000$ out of this, not enough for anything, and you can no longer easily threaten with delisting in case someone doesn't play fair. Can you imagine the PearPC page still listing CherryOS as a commercial support, even after they have been found to be violating the GPL?). I think 0/yr is a win-win in the short term. Maybe when wine is more attractive we can have a different optimum (I somewhat doubt it). Also, don't under estimate specific sponsorship of wineconfs. This year's wineconf was over sponsored - we had more companies willing to sponsor than actual money requirements. About what will happen if a rouge company shows up? I for see winehq.org setting up a page like PearPC and asking the community for help. But how will charging people money help here? It will make your position somewhat more serious because of 1 above. Also, don't forget that any company willing to pay for ad space is also a company who has an interest in other companies not violating the Wine copyright. In short, I think you worry about this at the wrong place. But some people here think we should have trust and faith in people and not be pessimistic like myself. http://starport.dnsalias.net/index.php?show=articleid=352 And on the out come of this discussion, read the entirety of this thread and apply bays theorem and a result will soon follow. http://psych.rice.edu/online_stat/chapter5/probability.html While it's very nice of you to send me to a 10 page explanation on a topic I already know something about, I really don't have the time to read it just so I'm enlightened by some inner knowledge you think I will gain. Care to explain what it is that you are trying to say here? Please do work out the math for me. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Now hiring
Dustin Navea wrote: Jeremy, guys, it seems we have run low on official janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to [EMAIL PROTECTED] Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle interviewing and hiring, and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin I think recruiting is a better term. After all, most armies don't pay salaries worth of anything, and neither do we :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Bug 2131 - 16-bit support?
Andreas Mohr wrote: Hi, On Sat, May 07, 2005 at 08:09:39PM -0500, Dustin Navea wrote: I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit. Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason. As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake. And I, personally, will not see the lose of the 16 bit version as too much of a problem. However: Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version? A real PE file has an NE header, which has a MZ header. Usually, these headers just tell whoever is trying to run the application that this is a 32 bit application. One can, however, generate a DLL which is both a 32 and a 16 bit DLL. Does our loader support such a format? If we call LoadLibrary16 on a DLL that has both PE and NE, will it use the NE? If so, we can create both DLLs inside the same file, and problem solved. OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway. I'm with you on this one, but if the Windows loader can do the 16/32 separation and we can't we may need to fix that. I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation. I'm with you. Andreas Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Winelib's role in converting Windows applications
Ira Krakow wrote: As many of you know, Brian and I are writing a book on Wine and Winelib for Prentice Hall. Brian's doing the Wine part; I'm doing the Winelib part. At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires. This is the approach I plan to take. I welcome all feedback. What I found, when I suggested to clients to work this way, was that the debugging tools were wholly and utterly inadequate. With all due respect (and I have TONS of respect) to winedbg, it's not up to the standards of working with ddd or the Visual Studio integrated debugger. Maybe running the remote Visual Studio debugger will work. I know it worked for me on some occasions. I also know that when I tried to run it in the most crucial of cases, it crashed the parent Visual Studio (i.e. - the part that ran on Windows). As such, there are occasions where compiling natively is, more or less, the only choice. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
Tom Wickline wrote: On 5/3/05, Dimitrie O. Paun [EMAIL PROTECTED] wrote: Yes, I think being inclusive is better. However, I also think that we need to pick the rules carefully so we don't set up a bad precedent when half the world will be using Wine :). So here is what I propose: 1. The list should be capped to n entries (n=50, 100?) 2. It should be kept up to date, and refreshed at least yearly 3. Any list has an order by definition, this one should be ranked by how much each company benefits the project. Hello All, Here is my proposal... 1) a token monetary fee of around $10,000 per year. 2) at least 1,000 lines of code or some major contributions to documentation. 3) a link back to winehq.org from there site and not twenty pages into there site. 4) a clear and thought out business plan (there company goal) and have links to it. 5) they agree to be bound by the LGPL license and to give back all code changes that apply under this license. 6) anyone found in contempt of the LGPL will be banned from all future winehq.org listings. 7) if a banned party wants re-instatement they must pay a fine of $25,000 and post a written apology to the community for there actions. 8) each party should contribute to the Wine party fund to fund future Wineconf's. Tom Wickline Before going into elaborate schemes here, I suggest that everyone consider the following points: 1. Sure, commercial companies have something to gain from being listed on the WineHQ page, but so does Wine. 2. If I, as a business owner, am going to be charged more than a token amount, I had better get a receipt. Otherwise the actual cost to me is about double the amount I pay Wine. I don't mind if it's 50$ or 100$, but more then that, and I'd want it as a deductible expense. As Wine is not a legally existing body, however, there is no one to issue said receipt. 3. On the flip side, if Wine is going to be receiving such amounts, it will have to report them to some tax authority. Who will do the reporting, and how? 4. If we are going to go into 8 steps programs, a contract had better be involved. Creating one costs money. Keeping it enforced costs money. This money, a.k.a. overhead, had better come from somewhere. 5. More importantly than money, keeping the contract and money matters enforced requires human supervision. This means that someone who could really spend their time hacking wine will need to make sure that the commercial companies adhere to our standards. I really suggest we adhere to KISS - Keep It Simple. I actually liked the hackers rating idea. If a company is well known among the wine hackers, they'll vote for it. If not, list it alphabetically at the end of the former list. As I said before, the token cost was meant mostly to make sure that the company is still alive, but as Andrew said, sending an email once a year to make sure someone responds also works, and does not get anyone in trouble with any tax authority. Having said all of that, I think I'll actually go with Brian's idea. Let him phrase the criteria. Unlike me, he does not have a commercial interest in Wine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
Tom Wickline wrote: At any rate you didn't answer the question of what will happen if wine is ever hijacked. But I guess it could happen even without this referral page, if it does ever happen lets just hope its not by someone listed here. This is actually a very good point in favor of not charging money at all. If you charge money, you create obligation. That's the way the legal system works. If you do not, you can easily delist any known LGPL offender. Having said that, I think the focus on code contributions to wine may be exaggerated. Looking from what we know right now, there are just three companies that have the capability to change wine to fit a specific client. Of these three, CodeWeavers is the only one who is doing any significant work on wine on a regular basis. They may be some freelance work going on as well, but it seems to me most of it is for Code Weavers anyways. But of course, $ 100 per year is a nice price, but than everybody can. Yea a nice referral for only $8.00 a month... hold on I just read Brian's mail and now the cost has just went to $0.00 sign up now at this everyday low price folks.. Then again, it seems we have heard on this thread alone of three different companies that either package wine or play with it's deployment. As we learned at wineconf, not having these companies listed is a major hurdle for commercial Wine adoption, which is where money for more wine improvement ultimately comes from. This does tell us that worrying about LGPL violation should not be too serious. It seems that most commercial wine deployers don't mess with the code anyways. Now, you might say that I'm biased because I have an interest. That would certainly be true. After all, if David's company is listed, and they get much more business then they do today, as there are only three companies that can provide second tier support, I obviously stand to win. The thing is, that so does WineHQ. I don't think I have to convince anyone that I give back what I do (and sometimes fight Alexandre ferociously about getting it included), and so does Dimi. As for CodeWeavers, well, I don't think anyone involved with Wine can raise anything against them. So, ultimately, we ALL get to win from getting more money into Wine, and charging an amount that will actually allow companies to get listed (and, yes, between zero and 100$/yr, zero is more flexibile to us in getting violators delisted without mucking with the legal system). If that doesn't convince you, then try this for size. If we do charge 10K/yr, Lingnu will not be listed there. It's simply not worth it for me. If ANYONE is going to be listed there, then, it will be some huge company, with very little actual Wine involvement. Being as it is that Wine would like the commercial vendors listed too, I think that's a lose-lose. Don't you? Or do you really think that Lingnu is going to hold back code from Wine? To bad this project will never have sponsoring like blender3d.. http://www.blender3d.org/cms/Sponsoring_prospectus.58.0.html As far as I know, blender was sponsored by it's clients, not by the people who sold services for it. That is what, I believe, most free software will eventually gravitate towards. Wine, however, is not there yet. In fact, many wine hackers hardly even run wine. Tom Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Make test status - latest CVS
Robert Reif wrote: Shachar Shemesh wrote: The problem is that I'm not interested in this test. I just think that, off the shelf, tests should not fail. My opinion is that if this is not a problem with Wine, it shouldn't fail the test. Does this patch help? It should fail the same way windows does now. No, it regresses tests that used to pass: -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html capture.txt Description: application/stream
Commercial support
Hi Jer, When you finally get around to adding a commercial support to Winehq, I would love this list to include: Lingnu Open Source Consulting, web at http://www.lingnu.com. On a different note. There is a page at http://www.winehq.org/site/support, but there does not appear to be any link to it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
MediaHost (TM) wrote: Hi All, I'm not sure, if winehq should be a platform for advertisements of commercial services (except maybe codeweavers), otherwise there will be a very long list there, very soon. That's good, in principle. The problem brought up during wineconf was that the lack of commercial support is viewed by potential deployers as a minus, making wine a dangerous technology. Saying here is a list of companies willing to take your money and give you support is actually a good thing for Wine. And who to include and who not? Ah, there you have hit a more serious problem. For example, there is no doubt that CodeWeavers has been both a^Hthe major wine driving force, AND a financial sponsor. However, if we don't allow other companies room, we are unfair towards the other companies, towards CodeWeavers (why should they continue to be practically the only ones carrying the load), and towards Wine (and we don't want Wine to become a CodeWeavers subproject, do we?). I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to in the past year. At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). Alternatively, we can have several lists. A Gold list, which includes companies that have the means to produce fixes to wine itself if necessary (as judged by the above criteria), and a normal list, which merely includes anyone who declares that they are willing to provide commercial support. I would have suggested a nominal fee (i.e. - a $50 contribution to the wine fund per year, or some such thing) from the last list. On the up side, it allows us to know the company is still active in this field. On the down side, I don't think we have the resources to start tracking who paid and who didn't. I could even suggest a platinum list, which would include any company that employs the equivalent of a full time Wine developer or up. Of course, this currently only includes CodeWeavers. The idea I'm trying to push here is that we can do such a list, so long as we keep clear objective criterias for who gets listed where. Are there such plans to include such links on the website, except for community based support? That's what we talked about over wineconf. It seems that such a list gives credibility to a project, and as such is a wanted thing. A company considering wine deployment is more likely to accept wine if they know they can get support for it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: short-circuting a dialog box?
Kees Cook wrote: I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to traps calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the Ok button, and finally trap calls to EndDialog. It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly. Is there a simpler way to programatically click Ok on a dialog box? (The dialog box coming from code that I don't have source for...) For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using FindWindow. I've done such things before. For simple things, this works very well. As soon as things stop being simple, this gets very hairy very fast. Just hope that your case is a simple one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
David Gmbel wrote: I cannot say I am convinced this is a good rule to follow. First of all, maybe I got things wrong at wineconf, but I remember something like anyone who wants to be listed there should be being the last statement I heard in the lecture room. I'm actually in favor of this. I too think that having as many companies listed would be a good thing. While it seems to me that the selection by code contribution as proposed would not be quite feasible (what exactly is a non-trivial patch?), I also think that there is a lot more to Wine than just code, starting from documentation, including stuff like donations, helping out on wine-users, or training (commercial or not) are important, too, and won't directly bring any code into the project - which does not make these things less valuable IMHO. I agree, but I was really thinking about a different thing. Wine deployment based on existing solutions is different than a deployment that can actually change wine to solve problems. My suggestion was based on the assumption that a client would care to know that. I do think that everyone should be listed, though. So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. Agreed. I don't even mind listing EVERYONE, whether or not they contributed anything at all. My token monetary donation idea was based on past experience, where making a list too easy to include you and too easy to stay on it means that it becomes obsolete, and therefor not useful. We tried to run a list of consultants supporting Linux in Israel, and nobody uses it any more, for precisely that reason. Making a token donation once a year eliminates this problem (though it creates other problems, such as actually collecting the money). If, instead of money donation, we merely ask each company to reaffirm it belongs in the list once a year, that would work as well. That said, I definetly think we could allow code contributors a sentence or two of space that describes their area of expertise in Wine (i.e. what part they contributed to), as this is certainly valuable information for customers, and good advertising for those companies. Yep, that is definitely one way to do it. Cheers, David Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
MediaHost (TM) wrote: Wine is going to play a major role by Linux Vendors, where support is the major income; it does it already now. Wine is integrated into migration plans quite tightly for applications with no alternative around. Now, a company giving support for wine should have enough experience and support personnel in both, Linux and Wine in order to qualify, if at all. I guess that would have been true, if Wine did not need so much work still. At the moment, I really don't see how you can give support for Wine without being able to work out areas where Wine is simply not good enough. There is no better way to show you can than to actually have done such a thing in the past, hence the patches suggestion. But than again, the question remains, who to list!? Does submitting a patch qualify for better listing? I don't think there is any connection between them...coding is coding and support issues are something else In my experience, you can solve 0% of enterprise support requests (which is what commercial support about) without doing some level of hacking on Wine. I'd love to hear Jeremy's input on that one, as they have MUCH more experience at it then we. It may be that it's just because we know how to hack wine that we resort to that. Then again, that does mean the customer gets a different level of support from companies that have wine hacking abilities and companies that don't. Either way, telling site visitors who can and who can't seems like useful information to me. But I prefer to not have any such list at all, something needing support for wine will find it But, as discussed at WineConf, not having such a list at all hurts wine, which is clearly not what we are trying to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
Andrew Bartlett wrote: I think it is worthwhile to expand on the Samba Team's experience with commercial support lists. The primary experience is that such lists much be maintained, and current. For many years, our list was unmaintained, but over the last year we have had a new website maintainer, and at least companies that don't reply to e-mail are removed. Hmm, similar to my refresh once a year idea. Who's in charge of making sure that the companies do still answer email? We do not 'vet' our list, and we don't try to rank the providers. This avoids a number of issues (how would you rank them?), and this is a policy I support. I guess the reason both Andreas and myself think it is a good idea to rank them has to do with the maturity of wine vs. Samba. While it is true that both Andreas and myself believe that our companies should be ranked high (and, at least for me, I also think that the company Andreas work for should be rated high, and even higher), it is also because we believe that this measurement is actually relevant to the service we sell. I am yet to encounter a program that just works on wine. Even if there are, they still enjoy a large amount of customizing and adapting. As such, there should be an advantage to companies that know how to do that. Almost all wine hacking done for clients are generally useful. Lingnu once produced a whole DLL due to a specific client support need (Unicows). This means that the people best situated to know who is who are the people who receive the patches. While I don't think other companies should not be listed at all, but the potential customers should be able to tell them apart. We have a broad list of providers in many localities, and this does provide us a place to point users in need of paid help. I don't think it draws away from the 'top tier' providers, who distinguish themselves in the way they always have - by being relevant to their customers, and competing on their own best merits. I guess neither Andreas nor myself see the way you can provide commercial support for Wine if you can't hack it. I would love to hear from such companies, though, what is their typical support scenario. Maybe it's me who is deluded here. Andrew Bartlett Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Make test status - latest CVS
The thing to understand is that any failure of make test due to either default configuration or a bug in anything other than wine is a failure of the test system. If make test passed, and Alexandre committed a patch, then this patch MUST pass on all machines. If that's not the case, then people will (and do) not use the test infrastructure, and more tests fail. That's not good! As such, I think you should fix your test to not fail (or mark it as a test wine does not pass). If you have different behaviors whether the driver bug exists or not on my system, split the test into two parts. This way, you can have one test that passes on wine whether or not the driver is broken (i.e. - if the bug in wine comes up, ignore it). The second test is one that fails if the bug in the driver doesn't come up, and if the bug in the driver does come up, fails if wine handles it differently from Windows. Mark this test as fails on wine until you fix it. This way, the tests won't fail on my machine, regardless of how it is set up. Like I said, getting the tests to pass on all wine hackers machines is crucial to build confidence with the tests, thus allowing people to run the tests prior to sending patches. If you are in Stuttgart, feel free to grab me and talk about it. Shachar Robert Reif wrote: Shachar Shemesh wrote: The problem is that I'm not interested in this test. I just think that, off the shelf, tests should not fail. My opinion is that if this is not a problem with Wine, it shouldn't fail the test. The issue from a test perspective is that wine fails differently than windows under this situation. Wine really does initialization at CoCreateInstance and our Initialize really does nothing. Wine should fail at Initialize, not CoCreateInstance. Moving initialization to Initialize will require some restructuring of the code in dsound.dll. I'll look into it but won't promis any fixes real soon. -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test fails on pristine CVS checkout
Shachar Shemesh wrote: Hi, Following the discussion in Wineconf, I'm forwarding test failures to the list. Methodology - Debian SID. I did apt-get build-dep wine (install most wine dependencies), and checked out a pristine CVS. ./configure (no parameters), make depend, make. Next problem: make[3]: Entering directory `/home/sun/sources/wine/dlls/oleaut32/tests' ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so olefont.c touch olefont.ok ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so safearray.c touch safearray.ok ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so typelib.c touch typelib.ok fixme:ole:LoadTypeLibEx Wanted to load Lolepro32.dll as typelib, but file was not found. typelib.c:39: Test failed: Could not load type library ** You must copy a 'stdole32.tlb' file to your Windows\System directory! You can get one from a Windows installation, or look for the DCOM95 package on the Microsoft Download Pages. ** fixme:ole:LoadTypeLibEx Wanted to load Lstdole32.tlb as typelib, but file was not found. typelib.c:39: Test failed: Could not load type library make[3]: *** [typelib.ok] Error 2 make[3]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32' make[1]: *** [oleaut32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 It seems to me there is no reason to halt the tests over this one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test fails on pristine CVS checkout
Shachar Shemesh wrote: Hi, Following the discussion in Wineconf, I'm forwarding test failures to the list. Methodology - Debian SID. I did apt-get build-dep wine (install most wine dependencies), and checked out a pristine CVS. ./configure (no parameters), make depend, make. Next I deleted the ~/.wine directory, and ran make test. Here's another one. make[3]: Entering directory `/home/sun/sources/wine/dlls/oleaut32/tests' ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so typelib.c touch typelib.ok fixme:ole:LoadTypeLibEx Wanted to load Lolepro32.dll as typelib, but file was not found. typelib.c:39: Test failed: Could not load type library fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects make[3]: *** [typelib.ok] Error 1 make[3]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32' make[1]: *** [oleaut32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 Copying olepro32.dll from a native windows solved that one, but I think the tests should pass on pristine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test fails on pristine CVS checkout
make[3]: Entering directory `/home/sun/sources/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so msg.c touch msg.ok err:mdi:get_client_info client 0x9009c belongs to other process msg.c:788: Test failed: WM_LBUTTONDOWN on a button: the msg 0x0007 was expected, but got msg 0x0005 instead msg.c:788: Test failed: WM_LBUTTONDOWN on a button: the msg 0x0135 was expected, but got msg 0x030f instead msg.c:788: Test failed: WM_LBUTTONDOWN on a button: the msg 0x00f3 was expected, but got msg 0x0046 instead msg.c:788: Test failed: WM_LBUTTONDOWN on a button: the msg 0x0135 was expected, but got msg 0x001c instead msg.c:810: Test failed: WM_LBUTTONDOWN on a button: the msg sequence is not complete: expected - actual 0086 make[3]: *** [msg.ok] Error 5 make[3]: Leaving directory `/home/sun/sources/wine/dlls/user/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/user' make[1]: *** [user/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 This one seems like a strange failure. I'm not sure how that came about, or why it fails on my system and not on Alexandre's. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Sorry about the noise (was: Make test fails on pristine CVS checkout)
Shachar Shemesh wrote: Hi, Following the discussion in Wineconf, I'm forwarding test failures to the list. Methodology - Debian SID. I did apt-get build-dep wine (install most wine dependencies), and checked out a pristine CVS. ./configure (no parameters), make depend, make. Next I deleted the ~/.wine directory, and ran make test. Please ignore this thread, as it was ran on old Wine code. I'll repeat the experiment with latest CVS, and report. Sorry about the noise. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote:
The results, this time really from CVS tip:
This time:
make[3]: Entering directory `/home/sun/sources/wine/dlls/dsound/tests'
../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p
dsound_test.exe.so dsound.c touch dsound.ok
err:wave:DSDB_MapBuffer Could not map sound device for direct access
(Input/output error)
err:wave:DSDB_MapBuffer Use: HardwareAcceleration = Emulation in
the [dsound] section of your config file.
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x80004005
dsound.c:175: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
E_FAIL
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x8878000a
dsound.c:184: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
DSERR_ALLOCATED
fixme:ole:CoCreateInstance no instance created for interface
{279afa83-4981-11ce-a521-0020af0be560} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x8878000a
dsound.c:193: Test failed: CoCreateInstance(CLSID_DirectSound) failed:
DSERR_ALLOCATED
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
err:wave:DSDB_MapBuffer Could not map sound device for direct access
(Input/output error)
err:wave:DSDB_MapBuffer Use: HardwareAcceleration = Emulation in
the [dsound] section of your config file.
fixme:winmm:MMDRV_Exit Closing while ll-driver open
fixme:winmm:MMDRV_Exit Closing while ll-driver open
make[3]: *** [dsound.ok] Error 3
make[3]: Leaving directory `/home/sun/sources/wine/dlls/dsound/tests'
make[2]: *** [tests/__test__] Error 2
make[2]: Leaving directory `/home/sun/sources/wine/dlls/dsound'
make[1]: *** [dsound/__test__] Error 2
make[1]: Leaving directory `/home/sun/sources/wine/dlls'
make: *** [dlls/__test__] Error 2
Seems to be a missing interface. I don't think the Emulation warning
has anything to do with it, as some tests before it printed the same
error, but passed.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote: The results, this time really from CVS tip: make[3]: Entering directory `/home/sun/sources/wine/dlls/gdi/tests' ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so metafile.c touch metafile.ok metafile.c:468: Test failed: (0,0)-(1000,1000), expected (0,0)-(1819,6675) metafile.c:468: Test failed: (0,0)-(1000,1000), expected (0,0)-(1819,6675) fixme:dc:GdiIsMetaPrintDC (nil) fixme:dc:GdiIsPlayMetafileDC (nil) fixme:dc:GdiIsMetaPrintDC 0x18c fixme:dc:GdiIsPlayMetafileDC 0x18c fixme:dc:GdiIsMetaPrintDC 0x19c fixme:dc:GdiIsPlayMetafileDC 0x19c make[3]: *** [metafile.ok] Error 2 make[3]: Leaving directory `/home/sun/sources/wine/dlls/gdi/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/gdi' make[1]: *** [gdi/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 I'm not sure what is the cause of this one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote: The results, this time really from CVS tip: make[3]: Entering directory `/home/sun/sources/wine/dlls/kernel/tests' ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so file.c touch file.ok fixme:vxd:VXD_Open Unknown/unsupported VxD Lbogus.vxd. Try setting Windows version to 'nt40' or 'win31'. epoll_ctl: Operation not permitted file.c:1392: Test failed: ret = 1, error 12345678 make[3]: *** [file.ok] Error 1 make[3]: Leaving directory `/home/sun/sources/wine/dlls/kernel/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/kernel' make[1]: *** [kernel/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote: The results, this time really from CVS tip: make[3]: Entering directory `/home/sun/sources/wine/dlls/ole32/tests' ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so stg_prop.c touch stg_prop.ok err:heap:HEAP_ValidateInUseArena Heap 401e: in-use arena 40218fc8 next block has PREV_FREE flag err:heap:HEAP_ValidateInUseArena Heap 401e: prev arena 40218f60 is not prev for in-use 40218fc8 err:heap:HEAP_ValidateInUseArena Heap 401e: prev arena 40218f60 is not prev for in-use 40218fc8 err:heap:HEAP_ValidateInUseArena Heap 401e: in-use arena 40218fe8 next block has PREV_FREE flag err:heap:HEAP_ValidateInUseArena Heap 401e: in-use arena 40218fe8 next block has PREV_FREE flag stg_prop.c:372: Test failed: Didn't get expected type or value for property make[3]: *** [stg_prop.ok] Error 1 make[3]: Leaving directory `/home/sun/sources/wine/dlls/ole32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/ole32' make[1]: *** [ole32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote: The results, this time really from CVS tip: Shachar ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so typelib.c touch typelib.ok err:ole:TLB_ReadTypeLib Loading of typelib Lolepro32.dll failed with error 1812 typelib.c:39: Test failed: Could not load type library fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects make[3]: *** [typelib.ok] Error 1 make[3]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/oleaut32' make[1]: *** [oleaut32/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 Copying olepro32.dll from a windows solves this one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
Shachar Shemesh wrote: The results, this time really from CVS tip: make[3]: Entering directory `/home/sun/sources/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2165: Test failed: wrong focus window (nil) win.c:2173: Test failed: wrong focus window (nil) win.c:2176: Test failed: no message available win.c:2177: Test failed: hwnd (nil) message 0100 win.c:2203: Test failed: no message available win.c:2204: Test failed: hwnd (nil) message 0100 win.c:2642: Test failed: wrong update region win.c:2655: Test failed: wrong update region win.c:2695: Test failed: wrong update region win.c:2704: Test failed: wrong update region win.c:2713: Test failed: wrong update region win.c:2728: Test failed: wrong update region make[3]: *** [win.ok] Error 12 make[3]: Leaving directory `/home/sun/sources/wine/dlls/user/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/user' make[1]: *** [user/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Make test status - latest CVS
make[3]: Entering directory `/home/sun/sources/wine/dlls/winmm/tests' ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c touch wave.ok wave.c:594: Test failed: The sound played for 1169 ms instead of 1000 ms make[3]: *** [wave.ok] Error 1 make[3]: Leaving directory `/home/sun/sources/wine/dlls/winmm/tests' make[2]: *** [tests/__test__] Error 2 make[2]: Leaving directory `/home/sun/sources/wine/dlls/winmm' make[1]: *** [winmm/__test__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/dlls' make: *** [dlls/__test__] Error 2 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: WoW, er Wine on Windows--Re: Still more fun?
Mike McCormack wrote: Augustus Saunders wrote: As for what we hope to accomplish, well, it might seem like massive overkill to try using WINE, but it's the only plausible way I've come up with. Basically, we want to substitute all the graphics/windowing/GDI etc so that we can record all the painting/rendering into some kind of WMF type thingy. The idea is to get screen captures as metafiles that are perfectly screen-accurate. Sounds like a modified screen driver would do a better job at what you want. I don't know whether a modified graphic driver will capture EVERYTHING he's trying to catch, but using Wine does not sound like the right solution either. I'd use the same injection technique Wine uses to inject my own DLLs that just forward everything on to native, and then use that to record whatever is interesting to me. It sounds like what Wine is doing will only hurt what Augustus is trying to do, not help. There are also more Traditional ways to inject your code into a process's import table. Mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Last call for PGP key signing party
Hi all, This is your last chance to get your very own PGP key signed by your community. So far, we have 6.5 participants (hoping to get it to 7 by tomorrow). This means 7 brand new signatures on your PGP key. Read the previous announcement (http://www.winehq.org/hypermail/wine-devel/2005/04/0057.html and http://www.winehq.org/hypermail/wine-devel/2005/04/0084.html) for details on what you need to do. New submissions should be possible to get right up to the party itself, assuming I can get our hosts to lend me the use of a printer (Will you?). Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Calc
[EMAIL PROTECTED] wrote: I've ported M$ Calc using winelib. Is this program needed for wine? Did you port it, or reimplemented it? Porting means taking the original source and compiling it using winelib. As calc is a MS intellectual property, we would very much prefer it if you did not post it to Wine, or even got it anywhere near us. If you wrote your own version of Calc it may be an amusing thing to add to Wine. We have a minesweeper clone, after all, and I'm sure that the reactos guys would appreciate it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: PGP signing party
I'm replying to my own email, as people are responding and it seems that some clarification is going to be required. Shachar Shemesh wrote: 1. Have a PGP key. You can generate one for yourself using gpg. Make sure to keep it somewhere safe afterwards, and not forget the password for it. 2. Send the PGP key finger print to me AT LEAST A WEEK BEFORE THE CONFERENCE. Any later then that, and it is not certain that we'll manage to get your key on the printed piece of paper that is necessary for carrying out the party. My mistake. I'm going to need both the finger print AND the actual key. Also, if you DON'T want the key published to a key server (I use http://pgp.mit.edu), please let me know well in advance. Obviously, your key will be published to all the people present at the key party. If your name's not there on your email headers, include it in the body. The name must be the same as appears on your formal IDs. The purpose of a pgp signing party is to establish a link between your virtual identity (your key) and your real one (as verified by an ID). For that reason it is impossible to participate by proxy, or under an alias. 3. Bring a copy you can trust to wineconf, to make sure other people are really signing your key (i.e. - that I'm not pulling anybody's leg). What you need is to do one of two things. A week before the party I'm going to send to everyone who is participating in the pgp signing party a text file which has everyone's names and fingerprint on it. You will need to go over this page and make sure that your own name is spelled correctly. Also make sure that the fingerprint on the page is the same as the one you sent me. The full details of what a key signing party is, why are the procedures as they are, and what's so important about *not* signing the keys with your laptop at the party can be found at http://www.cryptnet.net/fdp/crypto/gpg-party.html Already this is turning out to be a better success than last year. Make sure to join the web of trust and get your key recognized. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Should all A functions forward to their respective W's?
James Hawkins wrote: Hi, In the current state of wine, we have several A/W functions. Sometimes both the A and W functions are separately implemented with an ansi and unicode implementation respectively. Other A/W functions have the A forward to the W, converting the ansi to unicode. For all the functions that can, should we forward all A to their W counterparts? When it comes to the conformance test suite, this would be ideal. Only the A functions would have to be tested and in doing so, we test the A/W conversion and the functionality of the W functions (we're striving for all-unicode internally anyway). This would reduce the number of bugs, and the time it takes to fix current bugs. When both A and W are implemented and we find a bug in one of them, we have to remember to fix the same bug in the other function. For most of the functions, converting ansi to unicode is boilerplate code. This process could even be a janitorial project. What do you think? I think that for all functions we can, but care should be taken about what can means. For example, some experiments on Windows lead me to believe that GetCharacterPlacementW calls the A version, instead of vice versa (that is, on Windows 2000). Trying to reorder a string with Unicode characters not in the locale simply doesn't work. Obviously, is almost no one calls GetCharacterPlacement at all, this is not something we should be overly worried about, but I'm just trying to point out that such situations exist. Other places where converting the dependent calls have been tricky is with all the functions that put up a dialog box (and thus require a message handler function). These are fairly tricky to get right without repeating code, and in many places we preferred not to. What I'm trying to say is that I'm with you on that one, but stating it as you have may lead some people to be overly enthusiastic about things. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Automatic installation rev-eng utility
Hi all, I said this in a reply in one of the threads (the one about Windows registry), and got zero reply. I'm bringing the subject up again here. Back in 1996 (and until around 2000) I was project manager for a project called GTFormat. This was a project used by the late Packard Bell, as well as NEC in Japan, to put the programs bundled with the machines on the hard disks shipped out to customers. The tools consist of a tool that understands what the original installation did, a database to do offline conflict resolution and other stuff, and a front end to perform a (silent) installation of the result. I have written most of the code in the last part of this project, and as I said before, managed the entire thing. We also had a tool the generated files for the last part directly from the first part, without going through the database. Now, the tool was written when I was an employee of the company that produced them (G.Tek Technologies, today called gteko), but I believe that given enough persuasion I can get their approval to either freely distribute or actually open source the detection and the installation tool. I believe most of the distinguishing value of the tool as far as Gteko is concerned is in the database, which is not relevant for Wine in any way. The tool is written mostly in C++ for Visual Studio 6. It may require pulling out a single proprietary library (compression), but should not pose a problem (zlib does a wonderful job, after all). The question, therefor, is this. Should I try? The tool has proven itself over a long period of time, and is fairly reliable (at least was back at the time). It CAN solve some of our installer related problems. Your opinions are welcome. So, what say you? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Automatic installation rev-eng utility
Brian Vincent wrote: Now, a program that monitored a Windows install, copied all of the files created, generated a .reg file with registry changes, noted INI file changes, and then built an RPM that would install on Linux.. that would be cool. -Brian Thinking about it, maybe it would be easier to write one than to get my ex-boss to change copyright on the existing tool + renovate it. Also, as the current tool is C++, it is bound to be an external tool anyways. Hmm 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: lt;rantgt; ... lt;/rantgt; But it does not get through in the HTML page because it's getting transformed into rant.../rant 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 amp;, so you would get: amp;lt;rantamp;gt; 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 lt; 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
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: 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: 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
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: 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: 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/
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/
