Re: [RESENT] TIME_GetBias
Uwe Bonnes wrote: I think that's the way to go. Winesetup should determine and set the timezone. Who is going to implement it? Do you realize that time zone information is hardly a static thing? For some countries, such as Israel, time zone is something that changes annually. Do we really need the chore of keeping that up to date? Also, how are people going to update their local setup? Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: cards.dll
Joerg Mayer wrote: On Tue, Mar 16, 2004 at 12:09:24AM +0200, Shachar Shemesh wrote: Can someone remind me again why we can't have GPL DLLs in the tree? Doesn't the "call through documented interface blah blah blah not derived work" argument cause the license for each two DLLs in Wine to be independant? Basically it goes like this: LGPLed code can be run as a library, i.e. a function of an LGPLed dll can be called as a function call. GPLed code must be run as a (Unix) process if you want to use it from non-GPL-compatible code. See the GPL and especially the GPL FAQ for details. Ciao Jörg Hmm. All I could find about it is at http://www.fsf.org/licenses/gpl-faq.html#MereAggregation. They do suggest that. However, as that point says so well, they are not to judge. I'll give a counter pointer, but not go into the discussion. I think it's unsuitable for wine-devel, and wine-license is dead. Anyone interested in continuing this discussion - please email me privately. I'll be happy to cross CC everyone who do. The counter pointer - http://www.linuxjournal.com/article.php?sid=6366 Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: cards.dll
I'm sorry if this turns out to be a troll. That is not my intention.
Can someone remind me again why we can't have GPL DLLs in the tree?
Doesn't the "call through documented interface blah blah blah not
derived work" argument cause the license for each two DLLs in Wine to be
independant?
Shachar
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Re: In Vino Veritas!
Mike Hearn wrote: [1] OK I admit, I wrote this script for myself before I read Alexandres reply. Obviously this is a developer only script, it's not intended to be a part of Wine itself. Or, as it appears, part of wine-devel. Or is there some other reason you did not attach it? -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Contribution offer: Localization work
Ivan Leo Murray-Smith wrote:
Look at the programs directory, most programs can be translated. You're usually
looking for a De.rc file, if it's missing, make a second copy of the En.rc file,
and call it De.rc. Now translate the strings in the file. You then have to edit
the header file, this may be another rc file. In can case you can find the file
by running
grep En.rc *
in the programs directory.
Open the file, and add
#include "De.rc"
in alphabetical order in the list of language rc files. Once you've done this,
make a patch, so your work can be easily applied to the wine source tree, a
howto is at http://www.winehq.com/site/sending_patches.
Also note that quite a few dlls need translating too. The file may not always be
En.rc, for example in dlls/commdlg it's called cdlg_En.rc
Finally, one important thing is keeping the translations up to date, so you
should update the translation every time there is a change in the english
resource file. Don't forget to check that the existing translations are up to
date and correct.
Once you've done a patch, send it, in the email body or as an attachment, to
[EMAIL PROTECTED]
This should give you plenty of work for now :-)
Ivan.
Adding a small piece of detail to Ivan's excellent explanation - You
will also need to change the resource langauge ID when starting the
translation. These come after the "LANGUAGE" directive. English
resources will typically have "LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT".
If you are going to do German, you will need LANG_GERMAN,
SUBLANG_DEFAULT for most cases and for the Germany's German version.
If you want to go into the details of creating dialects, for example,
because a certain term is said differently in Swiszerland than in
Germany, you will need to set a different sublang for it
(SUBLANG_GERMAN_SWISS in this case). All sublanguages are defined in
include/winnt.h. If you do decide to go into sublangs, make sure that
SUBLANG_DEFAULT always exists.
Also, when you translate menus and other UI texts, you may come across
an apersand in the text ("&Ok"). This marks where the underline goes
when the text is displayed (for keyboard shortcuts). Move it to whatever
seems apropriate to you, but make sure that the same menu doesn't have
two entries with the same character underlined.
Last (and least), I don't think accelerators are used today in any of
the builtin winelib apps. If you happen to come across them, however,
let this list know and we'll instruct you how to handle those.
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Re: Contribution offer: Localization work
Fabian Cenedese wrote: Wine ist Freie Software, die unter der GNU LGPL veröffentlicht wird; Bitte lesen Sie die Details in der Datei LICENSE nach. If there is a translated Readme shouldn't there also be a translated licence file? No. The FSF cannot approve any translation as legally binding, which means that all translations are for information only, and are not the actual license. The problem is that the FSF cannot sufficiently verify that the ancient greek translation is 1-1 identical in limitations to the English original. As such, if the ancient greek version has a loophole, this hole is suddenly applicable to all versions in all languages. They were considering saying something along the lines of "This German translation is only applicable to German speaking countries", but I guess that has lots of loopholes too. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Contribution offer: Localization work
Dimitrie O. Paun wrote: On March 5, 2004 6:51 pm, Christian Britz wrote: Because I like writing, I offer to you to participate in the translation of wine documents to german. A good start would be the README I think. If you are interested in my help, please contact me! Christian, Thank you for your offer, much appreciated! Translations are tricky -- it's nice to have them, but it's not good if they are not maintained. For this reason, we don't want to translate stuff that's in-flux -- it's just wasted time and effort. The README is indeed a good start. It's been fairly stable lately, and we don't plan any major overhauls for it. The other documentation (our various Guides) are changing significantly at this time, so are not good candidates for translation. In other words, let's start with a documentation/README.de, and we'll take it from there. Welcome to the team! Also, translating UI for the winelib applications will be welcome. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: ccache gives winebuild errors?
Rein Klazes wrote: Hallo, Since a couple of days make fails without giving much reason why: | make[3]: Entering directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | WINEBUILD=../../../tools/winebuild/winebuild ../../../tools/winegcc/winegcc -mconsole ddrawmodes.o testlist.o -o ddraw_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lddraw -luser32 -lgdi32 -lkernel32 -lm | Error: ccache gcc failed. | make[3]: *** [ddraw_test.exe.so] Error 2 | make[3]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | make[2]: *** [tests] Error 2 | make[2]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw' | make[1]: *** [ddraw] Error 2 | make[1]: Leaving directory `/usr/home/projects/wine/mywine/dlls' | make: *** [dlls] Error 2 This is after a "make clean". Wine is configured to use ccache by setting CC="ccache gcc" before the ./configure && make depend && make. After another make clean and setting CC=gcc, the make succeeds. Any idea? Rein. Is it possible that you changed either gcc or ccache versions? Try erasing the ccache cache folder (~/.ccache, if I remeber correctly), and then running it again. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Help needed to get the application work for native linuxeditors
saravanan wrote:
Hi,
Can you tell me where I can get the help on X APIs. I am very new to
Linux programming.
I feel that replacing windows GetFocus API & Postmessage API with that of
Linux APIs might work.
Saravanan
Man, I feel old in the face of such enthusiasm.
Hi Saravanan,
Please, the last thing I want is to pour cold water on your enthusiasm.
However, I'm afraid the project you are contemplating on doing here is
in the order of magnitude of Wine itself.
You see, the thing about X windows is that they don't have an HWND, for
the very simple reason that they are not Windows windows (not a generic
name my %$&!@). As such, you will find that in order to do what you are
trying to do, you will have to create a HWND representation for windows
you don't control. It gets worse - X gets events, not messages. You will
have to create message loops for each window you want to create a Win32
identity for, and then figure out for each individual message how to
translate it into the X API space. This is not a trivial job to do, and
so far as far as I know, Wine has not handled this aspect at all. It
just didn't seem important enough to anyone.
Wine is currently mostly handling the Windows->X translation, not the
other way around. This means that Wine is currently figuring out how to
make the Win32 constructs appear inside the X world. Making the X
constructs appear in the Win32 world has never came up, as far as I know.
That said, you can search some of the following sites for the docs you
want. http://x.org, http://xfree86.org, http://freedesktop.org.
Shachar
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Re: Big hex numbers negative?
Fabian Cenedese wrote:
Hi
While testing more variant functions I tried this on Windows:
double dVal;
OLECHAR test1[]={'&', 'H', '8', '0', '0', '0', '0', '0', '0', '0', '\0'};
ok=VarR8FromStr(test1, LANG_NEUTRAL, NUMPRS_STD, &dVal);
The result for dVal was -2147483648. But as a real value it shouldn't
have any problems holding the "real" value 2147483648. So why has
it become negative? Is it because the source form was a hex number?
Are all hex numbers automatically signed if converted to int/real? Or
just because of the 32nd bit? The documentation wasn't that informative.
(The funny thing though was this remark in my VC6 help, it's not
in the online version of MSDN anymore:
Passing into this function any invalid and, under some circumstances, NULL pointers
will result in unexpected termination of the application. For more information about
handling exceptions, see Programming Considerations.
...now I understand many things :)
Thanks
bye Fabi
I'm not sure I understood your question properly.
A signed 2 complement 32 bit var can hold the numbers (-2^31) to
(2^31)-1. That's just how the encoding works. Was that your question?
Shachar
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Re: Linking against Wine under Linux
Tim Teulings wrote:
Hello!
I'm writing on a software that supports different (GUI) drivers for
different OSs. "Driver" refferes to my software (GUI library) having
different plugins (by implementing a subclass of an abstract base
class) for different OSs. I have an X11 plugin for doing X11 calls on
X11, one for Mac OS X, one for Curses and one for Windows. I now would
like to compile the Windows specific classes of my library under Linux
using Wine. The Windows version does use low level 2D graphics calls
(WIN32). This works fine if using f.e. Cygwin as compiler environment
under Windows (rest of the software is a little bit unix centric).
I now would like to use the Windows driver under Linux but I have a
problem finding the correct linker call. This is more difficult, since
I do not use C/C++ directly but another compiler that generates C code
wich in turn gets compiled using gcc. So I cannot use winemaker, for
which I found some documentation.
The Windows Version links explictely against kernel32, user32 and
gdi32 DLLs. If I under Linux just leave them away and link only
against wine (-lwine) I got unresolved symbols during linking for the
Win32 API calls.
After that I tried to link against the .dll.so files I
found (under /usr/libwine, using the Debian testing packages), too,
since I assume that these contain the functions I use. But I cannot
get the linker to find them. strace shows that it is always searching
for lib.dll.so. For example it searches for
libuser32.dll.so while I only have a user32.dll.so.
Is it correct, that I have to link explictely against this libraries?
If yes, how can I get the linker to search for the correct names? If
no, how to get my stuff to link?
Hi Tim,
I'm afraid I have some bad news for you. What you are trying to do is
not as trivial as you took it to be.
The problem has to do with the fact that a winelib application (i.e. -
an application that uses the Win32 API using Wine, compiled natively)
requires much more than the static libraries. It requires a different
loader, supporting services (such as registry and wineserver), etc. This
means that wine will have to be installed for the win32 APIs to work,
even if they were compiled into your app.
The other part of the problem is that we have been, as of yet, unable to
make the entire construct work as a normal ELF executable. Instead, you
have to load such an application (a winelib app) through a wrapper. When
you use the wine build tools (winebuild, winemaker, winegcc), such a
wrapper is automatically created for you. However, this means that your
entire application must now be a winelib app. I'll leave it to the
winelib masters to fill you in on the details of how one goes about
doing that.
Shachar
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Re: Setup .inf files
Chris Morgan wrote: The best documentation I've found thus far for inf files, http://www.leeos.com/infdoc.html#Top, doesn't have anything about running programs from inside of an inf file. If this is possible it would probably make more sense to have the inf file register the dlls. The way to have an INF run a file is by registering it with (if I recall correctly - it has been over four years now) RunOnceEx/Setup in the registry. For those who don't follow - RunOnceEx/Setup is a list of programs to run, executed synchroniously (i.e. - one does not start until the previous one exits), and displaying a small window showing where we are along the process). This brings up a small window with the list of tasks to carry out immediatly after the INF processing is done. There are two problems with this approach: 1. While RunOnceEx/Setup is being processed after each login, the mechanism that runs it after INF processing has always been a mystery to me. I have found no method, other than running an INF, of triggering a processing of RunOnceEx/Setup. 2. Wine(boot) does not currently handle that at all. We currently rely on some helper application that does that for us, that usually gets installed as part of the IE installation. The combination of 1+2 means that it'll probably take some time for Wine's INF processing to work like Windows on this one. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Windows 2000 source code has been leaked
Rein Klazes wrote: On Sat, 14 Feb 2004 11:32:05 +0200, you wrote: What you are saying is applicable to copyright law. I.e. - if you reverse engineer the code (say, by disassembling it). If that's what you did on LEGALLY OBTAINED CODE, then you are probably ok. The reverse engineering itself needs to be legal where you do it, but that is still possible. For example, in Israel, as far as I have found out, it is still legal to rev-eng the code. This original MS source code, on the other hand, is covered by trade secret laws, which are far stricter. Putting it bluntly - if you touch it knowing where it came from, or even unknowingly but ignoring common sense warnings that this is an illegally leaked version, you can probably not work on Wine again. The thing that is protected is not the expression (the code itself), as with copyright, but the ideas, which are deemed secret unless uncovered LAWFULLY. Concerning the trade secret law vs copyright law, there is at least one Professor of Law who is disagreeing with you. This is (by US trade secret law) not a trade secret anymore: http://www.groklaw.net/article.php?story=20040213181852642 The copyright issue is tricky enough though. Rein. What I suggested, and I still do, is this. Decide that you do not touch this code. If you are presented with info, if warning bells ring, avoid it. If not, don't feel bad about it even if it turns out afterwards that the info DID originate at the stolen code. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Windows 2000 source code has been leaked
Viktor Nilsson wrote: On 2004-02-13, at 18.02, Shachar Shemesh wrote: [EMAIL PROTECTED] wrote: Use common sense. IANAL The intelectual property law governing this case is the trade secret law. It says that the information is illegal to use if the recipient knows, or should have known, that it originated with illegally distributed trade secret. Well, if you read through the code, to understand it, but you not even try to imitate or copy it. Just write brand new code, that does the same thing but in a slightly other way? NO What you are saying is applicable to copyright law. I.e. - if you reverse engineer the code (say, by disassembling it). If that's what you did on LEGALLY OBTAINED CODE, then you are probably ok. The reverse engineering itself needs to be legal where you do it, but that is still possible. For example, in Israel, as far as I have found out, it is still legal to rev-eng the code. This original MS source code, on the other hand, is covered by trade secret laws, which are far stricter. Putting it bluntly - if you touch it knowing where it came from, or even unknowingly but ignoring common sense warnings that this is an illegally leaked version, you can probably not work on Wine again. The thing that is protected is not the expression (the code itself), as with copyright, but the ideas, which are deemed secret unless uncovered LAWFULLY. Please, guys. Let's take this issue seriously. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Windows 2000 source code has been leaked
[EMAIL PROTECTED] wrote: Zitat von Jonathan Wilson <[EMAIL PROTECTED]>: I heard news that windows 2000 source code was leaked and have seen what proports to be a filelist. Dont know if its genuine but for everyones sake I suggest that all people here completly ignore it (same as I will be doing) It looks like its the real thing this time. You advice is good but from what I hear (/.) it's allready spreading wide over 2p2 networks and I expect bits of knowledge comming from this code showing up on many places soon. What will you do if somebody posts bits of it as a answer of a question you asked? juergen Use common sense. IANAL The intelectual property law governing this case is the trade secret law. It says that the information is illegal to use if the recipient knows, or should have known, that it originated with illegally distributed trade secret. If someone answers a question on this list, you use common sense to figure out. If the answer is something along the lines of "MS uses a variable named hSoAndSo to pass the handle from InternalGetSoAndSo to UndocumentedSomethingOrOther", you use your common sense and ask where that info comes from before you put it in. If the information seems like something someone reasonably versed in the internals of Windows would know without breaking confidentiality contracts, go ahead and use it. The way I understand it, if everyone on this list avoid doing things we all know are not proper, Wine will be ok. Shachar
Re: Shlwapi: Add IntlStrEqWorker Functions and StrCmp Tests
Robert Shearman wrote: Alexandre Julliard wrote: DBCS chars depend on the locale, you cannot hardcode them in the test. Any way of generating them based on the locale or should I just remove the DBCS tests? DBCS is only meant to work if the current locale is an MBCS locale. What I would try and do is perhaps hard code the Unicode characters, and convert them to ANSI in runtime. This will let you know whether the current locale has the relevant characters or not. I'm not familiar with the exact semantics of the CJK setup, so I can't tell you whether there is a single Unicode character that exists in all MBCS locales. In any case, whatever you decide, take into account the fact that an English setup will, most likely, fail this test. Shachar
Re: WineConf movie
Boaz Harrosh wrote: Hi guys I'm back home. WineConf has been a profound experience for me. Thank you all. It is my intention to edit a 4-7 minutes of a WineConf2004 movie. to post on the web. I am browsing through the 8 hours of WineConf videos and I need your help: Please from the top of your head, be totally associative, what are the couple of moments you most remember / where profoundly moved by, at WineConf2004? I will try and use every ones feelings that way to guide me through the edit process. I'm not sure it will make it easer but it looks like a short cut. Free Life Boaz You mean, like the point where about 15 wine hackers all crowded into the same elevator and hoped that noone from MS sabotaged it? I mean, when people say that "you cannot kill an open source project", I don't think they mean "set up a conference, and then sabotage the elevator when everyone crowds in". Shachar p.s. Speaking of memorable moments - One of Dimi, Michael (Stefaniuc), Marcus or Brian had a camera, and we took a picture in front of the Ice palace. Can that someone please step forward and send me the pic? Sh. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Wineboot should process RunOnceEx Entries
Geoffrey wrote: Sorry about the confusion... 1. I do not know if wineboot handles RunOnceEx\\Setup, I have no need for any such programs anymore. IE uses its own utility for this. 2. Wineboot does not register the DLLs, because Steam gave "Could not connect ..." errors without the RSA Encryption dll from IE6 registered. (rsabase.dll) 3. If wineboot handles the executables in RunOnceEx, it does not delete them. After running wineboot 10+ times after installing IE6, an entry for "grpconv.exe -o" was still listed in a RunOnceEx key. 4. I would not mind writing a patch, but I am unfamiliar with winelib, but could probably work on it bit by bit. Apparently, while I may have been a bit lazy, I was at least ordered. The comments at the begining clearly state RunOnceEx, and clearly state it is not currently implemented. The soonest I'll have time to look into it is in a month from now. You are most welcome to have a go at it. Winelib should not frighten you in that respect - it's quite simply Win32 programming done on Linux (or whatever OS you are running). The sources for wineboot are all in the one file (programs/wineboot/wineboot.c under the wine source tree). Feel free to ask questions if you have them. If you don't touch that, I'll try to get it done when I have the time. As for RunOnceEx\Setup, I wouldn't touch that if I were you. It's not part of wineboot, as far as I know. As you have correctly said, IE installs a special program to handle that. SetupAPI has some method of triggering it to run, but I have never been able to do that outside of INF processing. I think we currently have it working "well enough", and should let leave it at that. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Wineboot should process RunOnceEx Entries
Hi Geoffrey,
I'm sorry, I may just still be jetlagged from wineconf. I failed to
understand your bug report.
Is that "wineboot does not handle RunOnceEx", does handle it but doesn't
run DLLs when using the pipe, runs everything, but the windows version
is set incorrectly, or doesn't handle RunOnceEx\Setup?
Shachar
Geoffrey Antos wrote:
I saw early postings about RunOnceEx in this mailing list circa
January 2003, however the problems they presented were never fixed.
Some programs come with simple INF installers because
people can cheaply create an INF file, and use a free Setup.exe
bootstrap file that reads the name of an INF file from Setup.ini or
something similar. These programs do not have any way of processing
RunOnceEx themselves.
In the distant past before I had converted to Linux and wine, I used to
deal with such programs quite a bit;
RunOnceEx was Microsoft's way of allowing simple installers to register
files, especially if a reboot and wininit was necessary to overwrite files.
The basic structure of the registry format is:
[Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Number]
"Number"="program.exe arguments"
"Number"="c:\\somepath\\somedll.dll|SomeExportedFunction"
Number is nothing more than a number. All commands are processed in
sequential order, first by key, then by value.
If there is no pipe symbol in the line ('|'), the data of the value is
executed as a program, with all following tokens passed on as arguments.
However, if the pipe symbol is included, the portion to the left is treated
as a DLL, and calls the exported function of the name to the right of the
symbol.
Once all values in a key are processed, the key is deleted, and the
process starts with the next key.
There is one subkey that has a special meaning: All keys/values in
[Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Setup]
are not processed at boot-up. Rather, they are read by the program
runonce.exe, not included in wine. It is through this key that one
gets the annoying "Updating Windows" box in the upper left corner of
the screen, listing tasks being performed. I believe Powertoys for
Windows 98 utilized this feature, but I do not remember how.
However, these days RunOnceEx still has one important feature:
Some people, like me, have programs that fail to load objects
because the OS version is not set to XP. When the OS is set to
xp, the install-ie6 script does not automatically process the
RunOnceEx keys, failling to register all of the DLL's, including
the Crypto support needed for programs such as Steam.
As such, for IE6 alone, users have to process 50+ lines by hand,
in something that SHOULD be processed at bootup, via wineboot.
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
Orkut community for wine
Hi all, Just so noone else create another community, I have created an Orkut community for Wine. It's located at http://www.orkut.com/Community.aspx?cmm=8767. Sorry about the noise. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Telux wine presentation slides (modifiable source)
Hi all, I have sent the Telux Wine presentation slides to Jeremy Newman so he can put them on the winehq site. Feel free to use them (and change them) for similar presentations, but please give me some sort of credit for them. Shachar
Re: Wineconf Webcast
Uwe Bonnes wrote: Hallo, could it be that the site is overloaded? ping wine.codeweavers.com PING wine.codeweavers.com (198.144.15.226) 56(84) bytes of data. no reaction... Someone ran ifdown on the server which was at colo. The server is back online now, and you can use the streaming. Shachar
Re: Posix Subsystem for ReactOS - Project 2010
Steven Edwards wrote: My plan is to work with the CoLinux team to integrate CoLinux in to Windows and ReactOS as a POSIX subsystem. They are very interested in working with us on this project and have linked to reactos.com on the website. My entire experience with CoLinux has to do with Dan Aloni grabbing me at a random hall a few weeks ago and telling me about it (actually - the first he did it was about half a year ago, but he really got my attention, making me late for a meeting, this time around). While it's certainly an exiting project, I understood that it was NOT based on the Windows subsystem mechanism, but rather hacking your way into Windows NT's ring 0 using a device driver. While I'm a great fan of "if it works", wouldn't it be nicer, long run, to have a proper subsystem of it? Also, what are you planning on doing with graphic applications? CoLinux works by running a X server on the windows machine. That's probably not the best solution there is. How is the ReactOS windowing back-end implemented? Shachar
GPG key party
Hi all, I'm going offline in preparations for the flight. As only two people expressed their interest in the party, I'm cancelling the centreally managed party. People are still welcome to do a distributed party. In order to do that, just bring along several copies of your key's fingerprint printed on paper along with your name, and hand them out to anyone willing to sign them. If Jeremy will allow me to use codeweaver's printers, and more people express interest in the party by my arrival, we can switch back. Shachar
Trolling and helping a spammer (was Re: New Open Source License: Single Supplier Open Source License)
Hi guys, First, someone who sends the same email to at least four mailing lists (freebsd, wine-devel, postgresql-hackers and ossi) is a spammer in my book. Replying to his email, especially to lists that are not relevant (i.e. - any but ossi) is helping him along. To answer his (asked) question - since this license is clearly LGPL incompatible, I don't think he is likely to make contributions to Wine under this license. At least, not contributions that will be accepted. As his license is also BSD incompatible, I dare say it is equally off topic for FreeBSD and postgresql. This guy is obviously trying to solve the "how can I make money from free software" dillema by introducing a proprietary license and calling it "OpenSource". Interesting idea, but it has been tried before (http://www.microsoft.com/resources/sharedsource/default.mspx, except they didn't have the audacity to call it open source). This is just a proprietary license. Nothing more to see here. Move along. Shachar P.S. I am not subscribed to the [EMAIL PROTECTED] mailing list. A search of the archives did not show this particular Richard Schilling post. I was not sure whether to dump this mail (which is just as off topic as the original one) on that list as well. I'm sorry if I chose wrong. I did notice that on [EMAIL PROTECTED], Richard is at least an occasional poster. Here on Wine-devel he is a first time poster as far as I can see. This may explain the difference in responses between the lists. Sh. Chuck Swiger wrote: Richard Schilling wrote: I would like to present to you all a new Open Source software license I've written up. [ ... ] One the face of it, Section III, "Distribution Restrictions and Obligations." of your license fails to comply with OSD #1 & 2: "1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form" See http://www.opensource.org/docs/definition.php. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: New Open Source License: Single Supplier Open Source License
Not only is he spamming, he is also advocating a non-open source license as if it is. Do we have any recource against him? Shachar Richard Schilling wrote: I would like to present to you all a new Open Source software license I've written up. It's called the Single Supplier Open Source License. I will be distributing software under this license as well as the traditional Open Source licenses found at opensource.org. You can see a copy of the license and its associated FAQ at http://www.rsmba.biz/licenses . A link on the homepage at rsmba.biz will also direct you there. I will also be working directly with opensource.org to address any issues they have with the license wording. The license has the following features: # Users have freely available access to source code, documentation just like the GPL. # Users may use, modify, and install the software on as many computers as they want within their organization. # Any changes made by the user and others get contributed back into the base product # The developer's right to control who provides services using the product is protected. # The developer's right to control who can distribute the software is protected. # The developer has complete control over the product forking. # The developer and all contributors retain copyright of their individual works. # The software is always downloaded from the same place by the end user even if it's used as part of a larger product, protecting the quality of the software. Please feel free to contact me on or off list about this announcement. Richard Schilling -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: I'm off to Cuba!
Brian Vincent wrote: I hope it's going to be sweet, but I'll be off the web until next Sunday. Until then, hasta la vista amigos! :) Excelente! Just in time to bring us souvenirs at Wineconf. -brian I think you are forgetting we are getting quite a few people travelling from abroad anyways. I can bring a couple of Israeli wine bottles - I think we cannot have a wine conference without wine. If Francois is coming, bring something too. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Key signing party at wineconf
Hi all, I'm organizing a key signing party at wineconf. Anyone who wishes to participate, please email me the following details: Your full, real, name. It is not possible to participate in a key signing party using a nickname or a virtual identity. Sorry. Your key's fingerprint. Your actual key. Again, the key must have your real name on it (I am talking public key, of course. You should never send your private key to anyone). I am going to compile the list of names into a keyring and post it to a public key server. If, for any reason, you wish your key to remain unpublished (highly unrecommended), please note so in your mail. For more info about GPG key signing parties, check out the howto at http://www.cryptnet.net/fdp/crypto/gpg-party.html Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Wineconf update, RFC re remote participation
Ivan Leo Murray-Smith wrote: One thing I would like to do is to stream audio This would be a regression, the last wineconf had a video stream. Ivan. Do you have the date for the previous wineconf? I can try and find the patch that broke it :-) -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Winetest progress bar
Mike Hearn wrote: On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote: 1. If compiled with Winelib, the dialog stays on screen after the main thread finishes with the tests; under Windows, it disappears at once. This is a bug in Wine, don't worry about it for now. Having a Winelib version is important so that others that don't have Windows can contribute, and while this is a little annoying, it's no showstopper. Of course, we should eventually fix this... I think we're tracking this in bugzilla - I was poking at it the other day: http://bugs.winehq.com/show_bug.cgi?id=1918 Basically it's not at all obvious from MSDN how WM_QUIT is generated from a window being destroyed. I rather suspect that Microsofts defwndproc notices when the window being destroyed is the last one owned by the thread and then does a PostQuitMessage (which we do not). That behaviour should be verified by test case first though. When you click the close button, a message (I'm not sure which - possibly WM_CLOSE) is sent to the window. DefWndProc takes that message and asks to close the window. This, in turn, sends WM_DESTROY to the window. That's all that happens in Windows. If you want your application to quit at that stage, you have to manually trap WM_DESTROY and call PostQuitMessage. I found that out the hard way. As a bare minimum, each and every application must handle the following event: It's main window being closed with WM_DESTROY (usually by calling PostQuitMessage). The window session it's in quiting WM_ENDSESSION (the application will NOT receive WM_DESTROY in that case). Paint requests WM_PAIN (no, defwndproc doesn't do beginpaint and endpaint, and if noone else does that, they queue up). Each and every application must handle all of the above cases, or things go wrong. Not handling WM_DESTROY, for example, causes your app to continue running after all of its windows have closed. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
Re: Implement RegFlushKey
Gregory M. Turner wrote:
On Saturday 27 December 2003 09:23 am, Shachar Shemesh wrote:
Mike Hearn wrote:
This implementation is a little inefficient but without using a random
access binary db as Windows does (which I am not going to advocate) it's
the best we can do.
Ok, I'm going to be flamed for this, but I'm going to go ahead and ask.
This is a request to understand, not a suggestion (yet?).
Why not use a general purpose DB system? (postgresql, mysql, whatever)
After all, the registry is just a tree shaped database. We can do that
using standard SQL, and fall back to our current method if a proper DB
is not found.
Shachar
The SQL thing is not an inherently bad idea, but why /not/ implement the NT
"hive" format (the random access binary db mentioned above) instead? This
might involve some ugly reverse engineering, but I think this would allow
registries saved out via Reg{Save,Restore}Key to work in fact, doesn't
wine already read this format when using a "Windows" installation? Some
months ago I tried to run an application I wrote for my employer, which used
those API's to import prefabricated chunks of registry stored in this format,
but it failed to read them in.
I guess this is another "hey, somebody other than me should do a crapload of
work" type of post... but I thought I'd mention it to remind everyone that
there is a Windows-API-compatibility justification suggesting that approach.
First, I would like to mention that having binary compatible registry
implementation is not stricly necessary for load/save compatible to
Windows. We can do import on load and export on save, for example. There
is also the fact that, if I understand correctly, Windows 9x has
different registry syntax from Windows NT, and other ugly stuff.
If I understood the discussion so far, it boils down to these options:
A. Ascii file - bad performance, easy editing. I'm unclear about Unicode
support.
B. Our own format - difficult editing, may have good performance if we
invest LOTS of hard work. Lots of potential bugs and places to go wrong.
C. SQL - good performance, jury is still out on ease of editing (in any
case - not as easy as A, but I'm not sure how unicode plays in).
Requires configuring yet another software component (but we may make
that optional).
D. Windows compatible - all the down sides of B plus bad performance.
Yes, I can defenitely see how D will be our favourite choice.
Just so I do not dump work on other people myself, I may not have time
for implementing C start to finish, but I can defenitely help a lot. I'm
already familiar with PgSQL, for one thing.
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: Implement RegFlushKey
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found. An idea behind current implementation is that everyone can easily fix the things in the case of corruption, which is a weak point of MS Windows. Ok, let's offer that as an option. The other thing is that, as far as I can tell, the database is awfully simple. Two tables - one for keys, one for values. The keys table: key ID, primary key (serial type in PGsql). Key name, varchar (or whatever). Parent key (foreign key to key ID). unique index on key name (if the database support the collation where things are case insensitive, which most databases should). The values table: Key - foreign key to the Key ID in the keys table Value name, varchar. Value type - long int Value data - binary Primary index - key+value name (unique). Alternatively, if you want easier editing of the DB itself, you can split the data into seperate tables - one for strings, one for numbers, and one for everything else. I believe this design is still simple enough for the DB to maintain data integrity even when editing outside of the scope of Wine, which means you can use the standard DB tools to fix it if something goes wrong (may require triggers, which are generally frowned upon these days. Also means that MySQL is out, as it doesn't have these IIRC). What you gain - fast, efficient, Unicode aware manipulation. Data integrity taken care for you. Concurrancy taken care for you. Seems too good to be true, I think. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Implement RegFlushKey
Mike Hearn wrote:
This implementation is a little inefficient but without using a random
access binary db as Windows does (which I am not going to advocate) it's
the best we can do.
Ok, I'm going to be flamed for this, but I'm going to go ahead and ask.
This is a request to understand, not a suggestion (yet?).
Why not use a general purpose DB system? (postgresql, mysql, whatever)
After all, the registry is just a tree shaped database. We can do that
using standard SQL, and fall back to our current method if a proper DB
is not found.
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: Status ToDo's
Tom wrote: Anyone have any comments, or something they believe I should add before I send the patch? Tom National Language Support * Better support of Chinese, Korean, Japanese...(currently in works) Better support of BiDi - Arabic, Hebrew... Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Problems with x11drv_main.c version 1.83
Sami Aario wrote: I did some Googling and found this link which I believe is relevant: http://lists.debian.org/debian-kde/2003/debian-kde-200305/msg00357.html. I've been launching applications from the console, where DISPLAY is not set. Under an X bash shell however, 'echo $DISPLAY' gives me ':0.0' as expected, and I don't get the error I mentioned previously when launching wine. Is this how it's supposed to work, i.e. should I specify DISPLAY explicitly on the console if I want to launch wine applications from there? When launching X applications the "DISPLAY" variable should be set. Wine is such an application. When you launch Wine from a term launched within the X environment, this variable is already set. If you want to launch an X application from outside that environment, you need to make sure that the app knows which X server to connect to (the DISPLAY variable), as well as have the proper authorization. In your case, the authorization was probably not an issue, because the same user that was running the app from X is the one who started the server (and thus had authorization to do so). As such, nothing besides setting the DISPLAY var is neccessary. If you are going to complicate your setup further, however, I would recommend you RTFM "xauth", as well as the XAUTHORITY environment variable. A simpler but less safe solution is to use "xhost". I would recommend against, however. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Problems with x11drv_main.c version 1.83
Sami Aario wrote: Sami Aario wrote: Hi list, Version 1.83 of dlls/x11drv/x11drv_main.c does not work for me. This patch removes the Display option in the config file, and now I get this error message: "x11drv: Can't open display: " (and no display name given). I've had to revert to version 1.81. Is the display name supposed to be given somewhere else (e.g. the registry) or are things supposed to happen automagically? My system is a debian woody, and XFree86 -version reports 4.1.0.1. Is it possible that your DISPLAY environment variable is not set? What do you get when you do (in the shell) "echo $DISPLAY"? I get an empty string. So DISPLAY is not set... A platform dependent thing? No, I don't think it is. X applications (and that's what Wine is) get the display to you from the DISPLAY environment variables. Does other X applications work for you? Are you running an X server at all? What did the "display" option in your config file used to say? Try setting the DISPLAY environment variable to the same value, and see if that solves your problem. Again, I'm suprised that other X application do not exhibit the same problem on your setup. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Problems with x11drv_main.c version 1.83
Sami Aario wrote:
Hi list,
Version 1.83 of dlls/x11drv/x11drv_main.c does not work for me. This patch
removes
the Display option in the config file, and now I get this error message:
"x11drv: Can't
open display: " (and no display name given). I've had to revert to version
1.81.
Is the display name supposed to be given somewhere else (e.g. the registry)
or are
things supposed to happen automagically?
My system is a debian woody, and XFree86 -version reports 4.1.0.1.
Is it possible that your DISPLAY environment variable is not set? What
do you get when you do (in the shell) "echo $DISPLAY"?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: win16 app crashes in SCROLL_GetScrollRange()
Saulius Krasuckas wrote: On Sat, 13 Dec 2003, Alexandre Julliard wrote: In this case, you have to write a 16-bit app, create a 16-bit scrollbar window, and send it various SBM_GETRANGE16 messages and see what happens. The code itself is simple, the main problem is probably finding a development environment for 16-bit code. ok. oh yeah, i was afraid i will need such extraordinary environment. eghm, only OpenWatcom v1.1 comes to my mind: http://www.openwatcom.org/product/features_content.html does anyone have reports about running it on WINE =)? The MSDN universal subscription also includes a Win16 compiler (MSVC 1.52, IIRC). I have not worked with OpenWatcom, but Watcom 11 had, I think, a better IDE. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: More deadlocks + backtrace
Mike Hearn wrote: There was recently (within the last few days) a commit to CVS by Alexandre that works around a threading bug in Xlib - how recent was the build you were using? Next time - read my mail ;-) I said spyxx was running for about 48 hours. That is, before Alexandre commited that patch. I'm recompiling at the moment to see whether the problems stop recurring. I submitted the backtrace, partly in the hope that someone will say "I know this - it's now fixed", and partly so that if it's not fixed (but I don't manage to backtrace it), I'll have it on record (following Linus' backup methodology). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
More deadlocks + backtrace
.DLL) (ebp=419eb668) 8 0x004232fa (SPYXX.EXE..text+0x222fa in SPYXX.EXE) (ebp=40aab4df) 9 0x0168ec81 (SPYXX.EXE..rsrc+0x1221c81 in wine-kthread) (ebp=53e58955) *** Invalid address 0x53e58955 (_end+0x121f453d) I hope this helps someone. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Deadlock?
c.so.6) (ebp=40032c60) 1 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x0, handles=0x0, flags=0x8, timeout=0x40032d10) [sync.c:578] in NTDLL.DLL) (ebp=40032cf8) 2 0x401f1edd (usr1_handler+0x4e(__signal=0xa, __context=0x4f) [signal_i386.c:1123] in NTDLL.DLL) (ebp=40032d1c) 3 0x4006e498 (NTDLL.DLL.toupper+0x6208 in libc.so.6) (ebp=4076d78c) 4 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x1, handles=0x4076d878, flags=0xc, timeout=0x4076d8ac) [sync.c:578] in NTDLL.DLL) (ebp=4076d824) 5 0x401f40ae (NTDLL.DLL.NtWaitForMultipleObjects+0x74 in NTDLL.DLL) (ebp=4076d84c) 6 0x401f40fe (NtWaitForSingleObject+0x42(handle=0x1a4, alertable=0x0, timeout=0x4076d8ac) [sync.c:611] in NTDLL.DLL) (ebp=4076d870) 7 0x401cda35 (RtlpWaitForCriticalSection+0x127(crit=0x4020fc60) [critsection.c:193] in NTDLL.DLL) (ebp=4076d910) 8 0x401cdc25 (RtlEnterCriticalSection+0x51(crit=0x4020fc60) [critsection.c:255] in NTDLL.DLL) (ebp=4076d928) 9 0x401d92dc (LdrLockLoaderLock+0x92(flags=0x0, result=0x0, magic=0x4076db94) [loader.c:926] in NTDLL.DLL) (ebp=4076d958) 10 0x404dd58f (GetModuleFileNameW+0x38(hModule=0x0, lpFileName=0x436e0bc8, size=0x104) [module.c:482] in KERNEL32.DLL) (ebp=4076db9c) 11 0x404dd4d7 (GetModuleFileNameA+0x72(hModule=0x0, lpFileName=0x4076e574, size=0x104) [module.c:465] in KERNEL32.DLL) (ebp=4076dbd0) 12 0x0101db7e (pi.exe..text+0x1cb7e in pi.exe) (ebp=4076dc70) This one doesn't look like strictly deadlock in Wine. In thread 0x16 it appears the application called "WaitForSingleObject" directly. I wonder what object that may be, however, and how come we are blocking on it on called to "GetModuleFileNameA". This is NOT the problem I was reporting before, but I figured I'll report it while wer'e here. Thread 16 seems to be calling "WaitForSingleObject" on an event it created not long before. It does create another process between creating the event and waiting on it. I'm not sure what process, though. I hope someone is able to glean useful information of this. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: I made a wish, wrote a letter to Santa...
Ove Kaaven wrote: Consider that the reason could be that C++ has too many interoperability problems to solve any within an interoperability project like Wine. Just try to compile something like MFC with g++ and see how well the result would run MSVC++-compiled programs. I don't think anyone was talking about MFC. MFC is written in some strange language MS made up using CPP macros and visual studio wizards. Calling it C++ is an insult to C++. There's nothing wrong with having a separate FreeMFC project outside Wine using C++ (and compiling their FreeMFC libs with MSVC++ for the benefit of Wine users) I believe you meant winelib. I'm with you on that one. As for COM/DCOM, having implemented big parts of it myself, I'm not so sure C++ would have helped a whole lot in any case. It's a mess and the only thing you'd achieve with C++ is a different style of mess (a more unreadable one, for starters). I'm sorry, it has been YEARS since I wrote anything OLE related (my very first Windows program was an OLE server, hand coded, that did a shell extension. That was my only interaction with OLE). As such, I will not presume to decide whether that statement is correct or not. I do know, however, a thing or two about C++. I have coded quite a lot in C++, and I believe I am pretty much aware of the things the language does well, and the things it is poor at. It all boils down to this - C++ is a language (much much) more difficult to learn well than C, and OOP is something that is difficult to do right. Add to that the fact that there are (quite a few) jobs for which OOP is the wrong tool, and you get the origins of the common belief that C++ is evil. Personally, I *love* C++. I don't use it for OOP much, because I spent the last 3/4 year trying to set up a business, and the preceding 2 1/4 years writing kernel level code for CheckPoint's FireWall-1. Not much C++ used there, for reasons purely technical. I do believe that, ABI interface problems aside (nothing unsolveable with extern "C"), C++ is a superior language to use to C for almost any task, provided you can master the art of not getting carried away with using features you don't need (with OOP being one of those). Granted, it's a difficult art to master. When working with environments where most of those differences would amount to just more warnings for logic errors when using C++, I don't mind saying "everyone knows C, let's use only that". However, when really complicated stuff is involved (Boaz mentioned Direct something codecs), I believe there is room to use the best tool for the job. To sum it all up - it may not be MFC (as I agree with Ove that MFC can be saftely left out of Wine proper), and it may not be OLE (as I don't know it well enough to judge), but I think C++ does have a place in certain parts of Wine. I do believe that most of the "less readable" claims are a result of either over-engineering the solution or people's expectance to "just read" the code. OOD will, occasionally, require you to read the docs before messing with the code. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: I made a wish, wrote a letter to Santa...
Alexandre Julliard wrote: "Subhobroto Sinha" <[EMAIL PROTECTED]> writes: However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. You don't need Santa's permission for that, just go ahead and implement DCOM in C++ and show us how easy it is. I suspect you will quickly realize that the complexity of the problem does not come from having to explicitly pass the this pointer around... While You are, no doubt, right about the complexity problem, I fail to understand the "no C++ in the wine source tree" rule. We are meant to pick the best tool for the job. While I 100% agree with "no C++ in the core Windows DLLs" rule, I think some other areas make more sense to use C++ than C. I have not been able to find the prior discussions about this matter, though I know we had them. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Winewrap change
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
Slight change to winewrap
Changelog
Shachar Shemesh <[EMAIL PROTECTED]>
tools/winewrapper
* Add tools into path for wine
Hmmm, which program do you need from tools at run time?
Did I put my foot in my mouth again? This is becoming a habit of mine of
late :-(
I don't remeber what it was that didn't work. Could it have been
wineshelllink?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: Deadlock?
Mike Hearn wrote: On Tue, 2003-12-09 at 13:51, Shachar Shemesh wrote: When trying to run Microsoft Digital Image Pro, I occasionally get problems when loading it. The splash screen comes up, and then it hangs. This problem only happens occasionally. I have not, to date, managed to reproduce it with relay turned on. You might want to do a run with +tid,+seh,+debugstr I'm not sure I'll manage to do that. The problem happens so rarely, and I'm working on other problems in the program, that I'm not sure the added output is something I can do that over time. Not to mention that when I exit the program with these settings, I get a long loop of: 0009:trace:seh:EXC_CallHandler calling handler at 0x66e5d029 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x66e5c8c2 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x102e826 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x401cfca8 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 2 0009:trace:seh:EXC_CallHandler calling handler at 0x7c34240d code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x66e5d029 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 it's followed by 0009:trace:seh:EXC_CallHandler calling handler at 0x401cfca8 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 2 0009:trace:seh:EXC_CallHandler calling handler at 0x401d0981 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x401cfca8 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 2 0009:trace:seh:EXC_CallHandler calling handler at 0x6759352c code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x102bfd8 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x102ffb3 code=c005 flags=10 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x102bfd8 code=c005 flags=10 0009:warn:seh:setup_exception exception outside of stack limits in thread 0009 eip 401db925 esp 4071123c stack 0x4071-0x4081 0009:trace:seh:EXC_RtlRaiseException code=c005 flags=0 addr=0x401db925 0009:trace:seh:EXC_RtlRaiseException info[0]= 0009:trace:seh:EXC_RtlRaiseException info[1]= 0009:trace:seh:EXC_CallHandler calling handler at 0x401d0981 code=c005 flags=0 0009:trace:seh:EXC_RtlUnwind code=c005 flags=2 0009:trace:seh:EXC_CallHandler calling handler at 0x401cfca8 code=c005 flags=2 0009:trace:seh:EXC_CallHandler handler returned 1 0009:err:seh:setup_exception stack overflow 2692 bytes in thread 0009 eip 7c34b55e esp 4071057c stack 0x4071-0x4081 I'm not sure what seh does, but it's triggering other problems as well. and then when it deadlocks (hopefully it will, sounds like a race) I don't know of other causes for problems that only happen OCCASIONALLY. Yes, it's a race. attach with winedbg then get backtraces of the threads that stopped. How can I attach to two threads? BTW it looks like something died inside a PROCESS_ATTACH or THREAD_ATTACH as evidenced by the presence of the loader section there. Perhaps it tried to access GetScrollBarInfo? Wouldn't that cause it to bomb each and every time? Like I said before - usually it works fine. I've noticed that sometimes operations that should cause a crash are silently swallowed and simply cause a deadlock somewhere. This program sets up tons of error handlers. Usually, however, they just bring up a dialog that says "this program has crashed. Do you want us to rerun it for you?". Another fine Microsoft invention. However, even when that happens, I can usually see the error on the debug output. I have had lots of those when trying out the unicows solution (which Alexandre replaced with something both simpler and more elegant - frustrating). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Deadlock?
When trying to run Microsoft Digital Image Pro, I occasionally get problems when loading it. The splash screen comes up, and then it hangs. This problem only happens occasionally. I have not, to date, managed to reproduce it with relay turned on. This is what I do get on screen: err:module:import_dll No implementation for USER32.dll.GetScrollBarInfo imported from L"C:\\Program Files\\Microsoft Picture It! 9\\piutil.dll", setting to 0xdeadbeef err:font:ReadFontDir Can't open directory "/win/windows/fonts" err:imagelist:ImageList_LoadImageW Error loading image! err:toolbar:ToolbarWindowProc unknown msg 204e wp=00ca lp=4080deec err:toolbar:ToolbarWindowProc unknown msg 204e wp=00ca lp=4080ea54 err:toolbar:ToolbarWindowProc unknown msg 2210 wp=00ca0001 lp=00010051 err:toolbar:ToolbarWindowProc unknown msg 204e wp=40c757d8 lp=4080eaa4 err:toolbar:ToolbarWindowProc unknown msg 2210 wp=57d80001 lp=00010053 fixme:toolbar:TOOLBAR_SetPadding stub - nothing done with values, cx=7, cy=9 fixme:imm:ImmAssociateContext (0x10056, (nil)): semi-stub fixme:imm:ImmAssociateContext (0x10058, (nil)): semi-stub fixme:imm:ImmAssociateContext (0x1005a, (nil)): semi-stub fixme:hook:NotifyWinEvent (32784,0x10056,-4,0)-stub! fixme:hook:NotifyWinEvent (32784,0x1005a,-4,0)-stub! fixme:hook:NotifyWinEvent (32782,0x10058,-4,0)-stub! err:toolbar:ToolbarWindowProc unknown msg 204e wp=00ca lp=4080e61c fixme:imm:ImmAssociateContext (0x1009d, (nil)): semi-stub err:ntdll:RtlpWaitForCriticalSection section 0x4020fc60 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000c, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7c38b208 "?" wait timed out in thread 000c, blocked by 0009, retrying (60 sec) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: I made a wish, wrote a letter to Santa...
Being Jewish, and growing up in a Jewish majority environment, I don't connect much to the spirit of christmas. Sorry. However, I do have the vague recollection that Santa brings presents to boys who have been good. I don't see how sending the same message over and over and over again can be considered "Good". You may be shooting yourself in the foot here. Shachar Subhobroto Sinha wrote: With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..) We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" ! Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: regedit: consistent formatting
Geoff Thorpe wrote:
On December 8, 2003 03:58 pm, Shachar Shemesh wrote:
Lionel Ulmer wrote:
2) or even better, write a re-tabulator which produce source code
following THE RULES (tool that would be applied to all source code on
each commit).
So it's certainly possible to have it working :-)
Lionel
Not to mention that, a while back, I offered to write a small perl
script that will bring all sent patches into a consistent format. I
never even heard back from anyone what format this patch can expect to
receive and send the mail, nor what the system is running.
Um, there was a fair bit of discussion as I recall - and Alexandre
expressed an interest along the way too. For my part, I may have thrown
too many spanners into the works (having the script customisable for
individual users to rewrite mails into their preferred layout - eg. Dimi
doesn't like attachments). However I'm curious that you thought noone was
interested, because I for one have been very much looking forward to
seeing how it works out! :-)
On the contrary. I said that, except for Dimi (who doesn't like
attachments), everyone WERE interested. It's just that, in order to
write such a script, I need to know whether I can ask for perl modules
installed on the server, how is my script going to interact with the
mail system, etc. I never got answers to those questions.
Cheers,
Geoff
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: regedit: consistent formatting
Lionel Ulmer wrote:
but this is still not feasible because a lot of people touch the code,
and even the same person touches it using different editors, from different
boxes, etc. How are you going to make sure everyone has their editors
setup just so (if at all possible!)? Face it, there's no way it can
work, especially in an internet-like setting where you simply can not
impose such strict environmental constraints on people.
Of course we can : we have a nice quality gate called 'Alexandre' which
commits all the patches. So we just need to, either :
1) write a tool that checks the source code for correct tabbing and rejects
the patch if it does not follow THE RULES
2) or even better, write a re-tabulator which produce source code following
THE RULES (tool that would be applied to all source code on each
commit).
So it's certainly possible to have it working :-)
Lionel
Not to mention that, a while back, I offered to write a small perl
script that will bring all sent patches into a consistent format. I
never even heard back from anyone what format this patch can expect to
receive and send the mail, nor what the system is running.
And that was a non-controversial change (well, Dimi objected, IIRC. Like
I said).
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: Question about simple profiling implementation
Dimitrie O. Paun wrote:
On December 2, 2003 08:52 am, Andrew de Quincey wrote:
As you say, relay debugging adds a huge overhead... however, would you say
that this overhead would be fairly constant for each particular function?
And herein lies the problem: we're adding a _big_ constant overhead (O)
to a variable cost (c).
When you are trying to profile an application, you don't really care how
much it takes to run. A profiling that makes the program run slower is
not really a problem. Profiling that changes the relative weights of the
program's parts are.
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: FontDlg sample text
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Please explain:
1. What kind of a resource should I use, in your opinion?
String resources.
2. How should I select which resource to load, given a specific locale?
Font charsets doesn't depend on the current user locale. So, just create
LANG_NEUTRAL resource with strings for each charset you want and IDs something
like:
#define CHARSET_BASE 1000
STRINGTABLE
{
ANSI_CHARSET+CHARSET_BASE"AaBbYyZz"
DEFAULT_CHARSET+CHARSET_BASE "AaBbYyZz"
SYMBOL_CHARSET+CHARSET_BASE "Symbol"
...
}
How do I put Unicode there? I need to put in characters that, by
definition, are taken from very varied parts of the unicode charset table.
If that problem is *easilly* solveable, I'll glady do the change. Note,
however, that this is no reason not to commit the patch I sent, as the
scheme currently used has been in place since February. All the current
patch did was enhance the sample text for more charsets.
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: FontDlg sample text
Shachar Shemesh wrote:
I can't believe it. I did it again.
Please explain:
1. What kind of a resource should I use, in your opinion?
2. How should I select which resource to load, given a specific locale?
Make that: "How should I select which resource to load, given a specific
charset?"
3. What is the advantage of this mechanism?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: FontDlg sample text
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: The main reason is that they are loaded based on encoding, rather than language. This has several implications that caused me not to go that route: 1. The mapping between encoding and charcter encoding is not a straightforward one. The reverse mapping is even less so. Well, GetTextCharset() does exactly what you want. I seem to have been totally misunderstood, possibly because of the wrong use of "locale" instead of "charset" in my previous mail. The situation is this: We have a font. This font supports several charsets. (Almost) each charset is used by several locales, but that is besides the point. We need to know which characters to use as a sample text demonstrating each charset. We need some kind of a table. This table does not depend on the current locale. You suggest resource. I say that this seems like the wrong tool for the job, as the resource information seems based on locale, and the locale does not play a role here. Maybe I misunderstood what you meant. Please explain: 1. What kind of a resource should I use, in your opinion? 2. How should I select which resource to load, given a specific locale? 3. What is the advantage of this mechanism? These two mean that placing the sample text in a resource will only server to confuse the issue. The first point is even harder - what if you want different sample text for Chinese BIG-5 and the other Chinese encoding? Which language should I try to load for centeral Europe? French? German? I can only load one. Exactly. GetTextCharset() is your friend here. Just have different strings for different charsets in the resources and load them at appropriate time. You lost me there. How does GetTextCharset help me, in any way? I'll just remind you that thing I have given is the charset, and what I'm searching for is the text. In short, doing that through resources seems like an unnecessary complication to me. Add to that the fact that you still need the mapping table, and you get "ain't worth the hassle". I hope you will reconsider. I'll be happy to. Just let's try and understand the implications. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Re: FontDlg sample text
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
Likewise, the Japanese sample text only has Aa (and not AaBb) of
Romanji (latin characters). For similar reasons, I left AaBb in place
(why remove it?).
The question should be why do we go to the trouble of having parts of
the string handled in two different places, when we could simply store
the full string in the sample text array. It would make the code
simpler, more flexible, and more compatible. Is there a good reason
for doing it the way it is now?
The reason is the unicode version of the dialog. In Unicode, you may
need to display several "character sets" simultaniously. When that
happens, you don't want to repeat the AaBb string over and over.
As for the strings themselves - they are 100% language independant, as
far as I can tell. After all, they don't spell a word in any language
that I actually speak (Arabic may be an exception here, as may
Japanese). Even when they, do, it's a word in that language.
I failed to understand how you wanted to make it into a resource.
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: FontDlg sample text
Rein Klazes wrote:
On Sun, 30 Nov 2003 03:43:04 +0200, you wrote:
+{'C','c','D','d',0}, /* Symbol */
With native win98, ME and win2k the example string for symbol I get is
spelled 'S','y','m','b','o','l'
BTW, I have a patch for this and other fontdlg enhancements as well. Do
you plan to submit any more patches soon?
Rein.
Well aware of that. However, doing that would require me to introduce a
significant change into the code, and I don't see the reward. It's not
as if you can read the resulting string anyways.
Likewise, the Japanese sample text only has Aa (and not AaBb) of Romanji
(latin characters). For similar reasons, I left AaBb in place (why
remove it?).
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: FontDlg sample text
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
* Add sample text characters for Symbol, Japanese, Greek, Turkish,
Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages.
Why to not add them into resources? That would simplify locale
handling a lot, and make our translators actually notice that
strings as well.
The main reason is that they are loaded based on encoding, rather than
language. This has several implications that caused me not to go that route:
1. The mapping between encoding and charcter encoding is not a
straightforward one. The reverse mapping is even less so.
2. The mapping is based on the selected locale, and does not care about
the current language.
These two mean that placing the sample text in a resource will only
server to confuse the issue. The first point is even harder - what if
you want different sample text for Chinese BIG-5 and the other Chinese
encoding? Which language should I try to load for centeral Europe?
French? German? I can only load one.
In short, doing that through resources seems like an unnecessary
complication to me. Add to that the fact that you still need the mapping
table, and you get "ain't worth the hassle".
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Re: Nice work - OpenOffice 1.1 under WINE
Steven Edwards wrote: Hello, I have just compleated a full install of OO 1.1 under WINE. No outsite packages are required to install and configure OpenOffice for Win32 under Wine. There are a few minor bugs with some of the strings in menus but I would rate it at 99%. If anyone is interested in a good hobby project a Winelib port of this would be nice to see. With a little luck we may be able to have this running for WineConf under ReactOS. Thanks Steven Is this in NT or Win9x mode? If the later, did you have to manually do anything regarding unicows? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Re: Dropped wildcards patch
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: Are you sure you want the functions to only return the invalid argument error if the file is actually not found? It creates inconsistancies. An invalid argument is invalid whether the file is there or not. It's not invalid on Unix, that's the whole point. If we make them illegal right away it means you won't be able to access legally named Unix files. While checking for existence first will make no difference in 99% of the cases, it will do the right thing when a file with a wildcard exists in the file system, and I think that's worth a little inconsistency. I'm not sure I agree, but this is one of those cases where I guess we won't convince each other. As your'e the boss on that one, that's what I'll do. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Re: Dropped wildcards patch
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
Just wondering whether there was a reason that the patch at
http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not
commited. My understanding of the ensuing debate was that it was
acceptable.
No, I'm afraid it's not. As I explained, you need to check that the
file exists first. Also, DOSFS_GetFullName is called all over the
place, so we need to go through all of them to make sure the behavior
is correct; for instance your patch will break FindFirstFile since we
have to allow wildcards there.
Ok, that wasn't clear. I'll have a look.
Are you sure you want the functions to only return the invalid argument
error if the file is actually not found? It creates inconsistancies. An
invalid argument is invalid whether the file is there or not.
Maybe there are other ways to deal with the FindFirst/Next?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
The opinions expressed in this mail are my own, and do not necessarily
represent the opinions of my employer.
Wait! I am self employed! Hmm...
Dropped wildcards patch
Hi Alexandre, Just wondering whether there was a reason that the patch at http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not commited. My understanding of the ensuing debate was that it was acceptable. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Re: More slides - final draft?
Maxime Bellengà wrote: Is it just me or some pages of the slides don't display correctly (both openoffice and pdf version). Slide 13 and slide 14 are too long, the last line is not displayed. Slide 13 is just meant to give a snippet of code. Read the P.S. of my original post for slide 14. Shachar, maybe a picture of a running app would have been nice ? I'm giving this as a frontal presentation. I'm going to SHOW them a running app :-) What I usually do (hoping that the two people who read wine-devel and may attend won't spoil this for everyone else) is start the presentation on powerpoint, before I hook the laptop to the projector. Whenever someone gives a presentation on PowerPoint in a LUG, someone is bound to say something. You then stop the presentation and show them that, yes, this is powerpoint, but running on Linux :-D Personally, I usually switch back to OpenOffice at the point. Max On Fri, 2003-11-28 at 00:45, Shachar Shemesh wrote: This time, I actually installed a spell checker. Believe it or not. http://www.shemesh.biz/wine holds the PDF and the openoffice of the slides. I'm hoping this is the last draft. You know youv'e stayed up for too long when you start putting stuff into your sig. A huge thanks for everyone for their input. Shachar P.S. Don't complain about "challenges" rolling off the page. That's on purpose. We have lots of challenges :-) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
More slides - final draft?
This time, I actually installed a spell checker. Believe it or not. http://www.shemesh.biz/wine holds the PDF and the openoffice of the slides. I'm hoping this is the last draft. You know youv'e stayed up for too long when you start putting stuff into your sig. A huge thanks for everyone for their input. Shachar P.S. Don't complain about "challenges" rolling off the page. That's on purpose. We have lots of challenges :-) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Wine lecture slides
Hi all, The updated slides for the lecture I'll be giving on Sunday are at http://www.shemesh.biz/wine/slides.pdf. I tried to incorporate all of the feedback from you guys. I would, still, appretiate any further feedback you may wish to give. I also have specific questions, if anyone knows the answers: - What is the current status of "--with-nptl" on RH9? Is it positively necessary to include that when running ./configure? I know it's not necessary when running wineinstall. - Can someone please verify my knowledge of Corel's wine history Hmm, that list turned out shorter Corel-wine: As far as I could discern from the good ol' web, Corel started it's Wine initiative in 1999 as an alternative to actually porting WordPerfect and friends to Linux. They created a branch called "Corel-wine", which was also open source (wine was X11 at the time, so they did have the choice). At some point, corel-wine died. Why did it die? When did that happen? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Prevent wildcards from being accepted in filenames (NT mode)
Dimitrie O. Paun wrote: On November 26, 2003 11:22 pm, Dmitry Timoshkov wrote: (GetVersion() & 0x8000)==0) construct is very inefficient. It forces compiler generate both a bit mask test and a comparison operation. While many modern processors have very effective bit test instructions, and we have to tell to the compiler that we want only a bit test. Simple !(GetVersion() & 0x8000) is much better IMO. Do you honestly think that a compiler can't figure out this is the same thing?!? Even if it didn't, you'd be hard pressed to even measure such minute differences, so no, it's not very inefficient by any means. ... So while I prefer your version for stylistic reasons, I can't agree with the spirit of the complaint. Something that does affect efficiency, which I debated with myself for some time, is the order of the tests. As the "if" is, by far, much more likely to be false than true, we should order the condition using a cost function that takes into account how much each condition costs to test, and how likely it is to fail (as that's the case wer'e trying to optimize - we don't really care how long it's going to take in case the "if" is true). My original gut feeling was to place the conditions in reverse order. That is, first test for version, only then test whether there are any wildcards in the string. The reason I submitted it as I did was that the first attempt would not work. It appears that "DOSFS_GetFullName" is called before the structs needed for "GetVersion" to function are initialized. As such, reversing the order was necessary to make it work (that, or insert complicated changes throughout the entire kernel initialization). In retrospect, this form is better. GetVersion is not a simple function, and is far less likely to fail than strchr. I guess ideal would be to have a global inside kernel.dll that tells us whether wer'e NT or not. There is no such global at the moment, however, and I did not wish to introduce one. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Prevent wildcards from being accepted in filenames (NT mode)
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: +/* If wer'e in NT mode - don't allow wildcards in file name */ +if( (strchrW(name, '?') || strchrW(name, '*')) && (GetVersion()&0x8000)==0 ) (GetVersion() & 0x8000)==0) construct is very inefficient. It forces compiler generate both a bit mask test and a comparison operation. While many modern processors have very effective bit test instructions, and we have to tell to the compiler that we want only a bit test. Simple !(GetVersion() & 0x8000) is much better IMO. Alexandre and Dimi already answered the technical aspect. I will just mention that my stylistic preferences say that you should only use boolean operators on things that are conceptually boolean. Since C (unlike modern C++) doesn't have a bool type, that means merely referring to the BOOL type, and the result of boolean returning operators (==, &&, etc.). In this case the test I wish to make is "is the uppermost bit clear?", and that translates to "(blah & 0x8000)==0". It was not boolean before the operator, and & is not a boolean operator. Now, this is not an attempt to force my style on anyone else. I do not intend this to become a religious war. This is just the rational behind my style. While I will be happy to hear Dimi's rational for his, I don't think there is much room for an actual "discussion", as these things tend to turn into religious flame wars. Shachar P.S. A good exam, I think, to see whether your reply is presenting your own style or is an argument is to see whether your reply relies on my reply. If Dimi says "I do that because", that's a reply, while if he says "My way is better because...", it's probably an argument. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Reject wildcards in directory names
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: My existing patch is in DOSFS_GetFullName, which is called by GetFileAttributes. Another thing, however, is that I'm begining to doubt whether it is indeed used for what you said it is. It seems that calling "GetFileAttributesW" on Windows 98 returns 120 (function not implemented). This casts a great doubt on whether that is indeed the purpose of calling "GetFileAttributesW". Why? I think it makes even more sense, obviously if the function is not implemented in Win98 then it will never return the proper error code, so it's a good detection mechanism. What other purpose do you think this would serve? I THINK, though I need to test that, that this code is only reached if it is already known that this is not Windows 98. I can test that. In any case, this doesn't really matter. Because I don't seem to be able to define a function called "GetProcAddress" in a winelib dll. I don't see why not, unless maybe if you are using delayed imports, but you shouldn't need that. How exactly are you defining it? What do you mean by "delayed imports". When I defined, proper, the entire spec as actual functions, I got conflicts when I tried to define GetProcAddress. In any case, even then I'm going to need to call GetProcAddress (yes, I guess I can use the same strange macros to do that, or call the native NT function. I'd rather not do that, however). These problems are apparent in the experimental patch I sent (http://www.winehq.org/hypermail/wine-devel/2003/11/0098.html). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Reject wildcards in directory names
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: I'll send a patch, then. Note that this needs a general solution. Please don't just add a special case in GetFileAttributes. My existing patch is in DOSFS_GetFullName, which is called by GetFileAttributes. Another thing, however, is that I'm begining to doubt whether it is indeed used for what you said it is. It seems that calling "GetFileAttributesW" on Windows 98 returns 120 (function not implemented). This casts a great doubt on whether that is indeed the purpose of calling "GetFileAttributesW". In any case, calling "GetFileAttributesA" on Windows 98 indeed yields "2" (file not found). I already have a plan for doing that. Unfortunetly, it's not a nice one. Basically, it means changing unicows.spec.c after it's generated. I'll try to create the makefile so that this will still support dynamic changes. Why would you need to do that? Because I don't seem to be able to define a function called "GetProcAddress" in a winelib dll. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Reject wildcards in directory names
Alexandre Julliard wrote: It seems to be a way to detect NT/Win95, I suspect Win95 returns a different error code in that case. Using GetVersion() would of course have been too easy... And that, after they DO call "GetVersion", and do keep a variable telling whether it's NT or not. Oh well. Would you say that returning the error in the patch only if the platform is NT type will be a correct thing to do? If so, I'll send a patch. One possible workaround that may satisfy both Alexandre and unicows may be to put the wildcards checking code into the error part of the function. In other words, if we have not found such a file, return ERROR_INVALID_NAME if the name contains wildcards, and ERROR_FILE_NOT_FOUND if not. This way, if the file IS found, it will be handled correctly. Well, yes, that was the idea. The normal case is that the file doesn't exist, and in that case we of course need to return the proper error (also taking Windows version into account apparently...) I'll send a patch, then. Anyway, I looked into your unicows exe, and I believe the problem is that the home-made GetProcAddress that unicows.lib is using doesn't support forwarded ordinals, so I'm afraid we'll need to export real functions from unicows.dll. I already have a plan for doing that. Unfortunetly, it's not a nice one. Basically, it means changing unicows.spec.c after it's generated. I'll try to create the makefile so that this will still support dynamic changes. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: unicows update and PE memory format
Rolf Kalbermatter wrote: Now here's the puzzle - GetProcAddress is never called. Neither are these functions imported from the DLL in the PE header. In fact, unicows.dll does not even appear in the PE header (which makes sense - on NT you don't even want to install it). This means that unicows.lib manages to call GetProcAddress, without actually calling GetProcAddress. Some tracing leads me to suspect (I have not done enough research to determine yet) that it accesses the PE header of kernel32 directly. It appears that unicows.dll enountered the exact same problem we have vis a vis GetProcAddress, and have happily hacked their way around it using direct memory access. What I see them do is call "GetModuleHandle" on "kernel32.dll", and then use the resulting handle as a struct/array pointer, and access offsets into it. This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly. The problem is not that I cannot call GetProcAddress. The problem is that I cannot even define such a function. The moment I define a function called "GetProcAddress", I get link errors due to conflicts in the spec.c file. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Small fontdlg fix.
Rein Klazes wrote: - How did you see the example before, as screen coordinates and client coordinates where mixed up: I never saw the example text. I applied your patch. I don't know what happened to the font dialog. It did work back when I made the changes. something must have happened to it over the intervening time. Rein. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Small fontdlg fix.
Rein Klazes wrote:
HPEN hOrigPen;
HFONT hOrigFont;
COLORREF rgbPrev;
-WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'};
+WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'};
This is wrong. "YyZz" are only added if it's a western encoding. This
already happens (a patch I submitted earlier this year, and forgot to
add my copyright to the file). With this patch, if you view a font in
it's Western encoding, you get a sample that says "AaBbYyZzYyZz".
If you view a font in another encoding (say, Hebrew, because that's the
only one that was fed in), you get "AaBbYyZzנסשת", instead of
"AaBbנסשת", like it is on Windows 2000, and like it makes sense (we want
to spare some space).
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
<>
Re: Reject wildcards in directory names
Alexandre Julliard wrote:
"Rolf Kalbermatter" <[EMAIL PROTECTED]> writes:
My tests show that RemoveDirectory just as CreateDirectory rejects all
paths which contain one of the wildcards ": * ? \" < > |" with error 123
completely independent where that character occurs (not just in the path
element which is created).
And as far as I can say DeleteFile just as much behaves also this way.
So should we attempt to be smarter than Windows in this case?
Yes, because under Unix you can actually create files that contain
wildcards, so it should be possible to access them. We just need to
prevent the Windows app itself from creating them.
How on earth can a discussion about wildcards be related to unicows???
It appears that applications using unicows will not work in NT mode on
wine unless the attached patch is applied. Unicows' init calls
"GetFileAttributesW" with "???.???". It expects, if it fails, to get
error code 123 (ERROR_INVALID_NAME), otherwise it simply doesn't work.
Wine returns 2 (ERROR_FILE_NOT_FOUND). For that horrible sin, the entire
application misbehaves. It also misbehaves, in the same way, if
GetFileAttributes succeeds for this file. I can't escape the feeling
this was meant specifically as a trap for Wine. I am yet to find any
other use for this test. Any other explanation will be greatly appretiated.
One possible workaround that may satisfy both Alexandre and unicows may
be to put the wildcards checking code into the error part of the
function. In other words, if we have not found such a file, return
ERROR_INVALID_NAME if the name contains wildcards, and
ERROR_FILE_NOT_FOUND if not. This way, if the file IS found, it will be
handled correctly.
Personally, I don't like this workaround. It means that a perfectly
legal file name is reported as illegal. I am, however, open to suggestions.
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Index: files/dos_fs.c
===
RCS file: /home/sun/sources/cvs/wine/files/dos_fs.c,v
retrieving revision 1.142
diff -u -r1.142 dos_fs.c
--- files/dos_fs.c 15 Nov 2003 00:13:21 - 1.142
+++ files/dos_fs.c 25 Nov 2003 13:22:23 -
@@ -1047,6 +1047,12 @@
return FALSE;
}
+if (strchrW(name, '?') || strchrW(name, '*'))
+{
+SetLastError(ERROR_INVALID_NAME);
+return FALSE;
+}
+
if ((full->drive = DOSFS_GetPathDrive( &name )) == -1) return FALSE;
flags = DRIVE_GetFlags( full->drive );
Re: unicows update and PE memory format
Steven Edwards wrote: --- Shachar Shemesh <[EMAIL PROTECTED]> wrote: If anyone can help me shed more light on this, I would be most grateful. I dont know if you've seen this or not. Maybe it will be of some help. http://libunicows.sourceforge.net/ Thanks Steven I guess the same problem is haunting everyone. *version 0.6.2:* * added more symbols (only /GetProcAddress/ is missing, let me know if you can figure how to add it...) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: unicows update and PE memory format
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: It seems that I won't be able to use the forwarding inside the spec file. I'm not sure exactly why that is, but I think the unicows.lib link time library tries to load stuff by doing "GetModuleHandle", and then fetching relative values from that place. Is there a plausable assumption about PE memory layout? Is this something that Win32 properly defines? Do we have such a format for winelib dlls? Yes, builtin dlls have a PE header, so this kind of thing is supposed to work. Could you please give us more details on what happens here? I'm a bit sketchy on details myself. Basically, what I've done is to download the SDK that includes unicows.lib, and compile my own (very simple) program, and then try to figure out why that (very simple) program doesn't work. Microsoft's environment for their own developers seems to be in constant deterioration. It is unbelievable what they expect the developers that give them their power to go through. I can't believe I did that for a living for over four years! Linking with unicows.lib prevents Visual Studio 6 from linking your program in Debug mode. That's right - you had better not have bugs in your programs. If you must have bugs (you whiny little thing), make sure these are bugs that are reproduceable on an NT variant, and you can simply compile the debug version without unicows. All of that for an infrastructure that is so buggy and unstable that their loader refuses to load unicows.dll unless it's located in the same directory as the program (i.e. - not shared with other applications), so that upgrading another program's unicows.dll will not break this one. Amazing! To recap my previous whining posts on this list - I tried the spec forwarding to implement unicows.dll. That simply didn't work. As the forwarding mechanism doesn't have any debug outputs (in fact - I have not even been able to FIND it), I was not able to tell anything about the situation other than to say that the functions that were supposed to be called, were not. I then tried to implement explictly forwarding functions. These are simple functiont that (print a trace and) call the original funciton in the original DLL. This, suprisingly, DID work. However, this failed for GetProcAddress. It appears that the spec mechanism needs the original GetProcAddress, and trying to implement another function with that name creates link errors. Taking the lead from you guys, I tried to find out why forwarding did not work. To that end I created a unicows.dll.so file that tries to forward just DrawTextW, GetCPInfo, GetEnvironmentStringsW, GetStringTypeW, LCMapStringW and LoadStringW. By stubbing out everything, I could ascertain that these are all that are required for my test program. Not only would my program not run, but I have found out that, somehow, unicows.lib failes to get the proper pointers for the functions. This does not happen when these very same functions are either stubbed or implemented in unicows.dll.so. I am now in the process of trying to figure out why and how. Now here's the puzzle - GetProcAddress is never called. Neither are these functions imported from the DLL in the PE header. In fact, unicows.dll does not even appear in the PE header (which makes sense - on NT you don't even want to install it). This means that unicows.lib manages to call GetProcAddress, without actually calling GetProcAddress. Some tracing leads me to suspect (I have not done enough research to determine yet) that it accesses the PE header of kernel32 directly. It appears that unicows.dll enountered the exact same problem we have vis a vis GetProcAddress, and have happily hacked their way around it using direct memory access. What I see them do is call "GetModuleHandle" on "kernel32.dll", and then use the resulting handle as a struct/array pointer, and access offsets into it. At point I am lost. I don't know what GetModuleHandle returns on Windows, and I don't know whether we return anything that is, in any way, meaningful outside it's use as a pure handle. If anyone can help me shed more light on this, I would be most grateful. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
unicows update and PE memory format
Hi list,
Here is a quick update.
It seems that I won't be able to use the forwarding inside the spec
file. I'm not sure exactly why that is, but I think the unicows.lib link
time library tries to load stuff by doing "GetModuleHandle", and then
fetching relative values from that place. Is there a plausable
assumption about PE memory layout? Is this something that Win32 properly
defines? Do we have such a format for winelib dlls?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: Japanese default GuiFont
Shachar Shemesh wrote: Hi, Are you the same guy who does maintains the ODBC driver for Postgresql? Shachar Hiroshi Inoue wrote: Oops - that was meant as a private message. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Japanese default GuiFont
Hi, Are you the same guy who does maintains the ODBC driver for Postgresql? Shachar Hiroshi Inoue wrote: -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: wn20031121_197.xml
Vincent BÃron wrote:
Le ven 21/11/2003 Ã 14:44, Shachar Shemesh a Ãcrit :
Wouldn't you say that it's time to give Vincent commit access to the web
site?
That'd be Brian, not me.
Vincent
Luckily, it has recently rained, and so there is plenty of mud for my face.
Sorry about that.
On a totally different subject - wouldn't you say it was time to give
Brian Vincent commit access to the web site?
Shachar
--
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/
Re: wn20031121_197.xml
Wouldn't you say that it's time to give Vincent commit access to the web site? Brian Vincent wrote: wn20031121_197.xml -brian Wine Traffic
Delay setting breakpoints
Hi list, Does anyone remeber how to delay setting a breakpoint in GDB? Due to human-machine incompatibilities, I am using GDB rather than winedbg, and setting breakpoints inside the actual program would be greatly simplified if I could ask for the breakpoint before starting Wine. Can anyone point me again to the doc describing running winedbg as a gdb backend? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Where has Freetype config gone?
When trying to compile CVS Wine, I don't have freetype support. The configure script claims that I don't have freetype-dev installed (I do). configure.log shows the message: In file included from conftest.c:95: /usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!" /usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use macros to include FreeType header files." /usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:" /usr/include/freetype2/freetype/freetype.h:23:2: #error " #include " /usr/include/freetype2/freetype/freetype.h:24:2: #error " #include FT_FREETYPE_H" This message repeats several times (for several tests). My system is a Debian Sid, and I have freetype2-dev installed properly. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: dutch keyboard support
Dmitry Timoshkov wrote: "grant williamson" <[EMAIL PROTECTED]> wrote: This patch offers better wine support for Dutch Keyboards. Most IBM computers sold in the Netherlands have Dutch keyboards. Well, then it would be nice to see the patch generated against current CVS, since the code has changed a bit. Can this be included please. Also, provide a reference to an actual X keyboard layout (setxkbmap xxx) and avoid phrasing like "contributed by xxx". Please. Ok, so my "answer" is unrelated to the post. Dmitry/Alexandre - What happened to the patch you (Dmitry) CCed me? I have not seen it go in. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Netmeeting under wine
Tom wrote: Jérôme Bouat wrote: use GnomeMeeting: http://www.gnomemeeting.org/ Hi, Time for me to get into trouble again :) Not only that, but I'm somehow dragging myself too. Your'e good :-) This guy ask if we could help him to get a win app that he uses "Netmeeting" in this case to work with the vine "wine" but instead of help he got use this... as its native to linux! Well, I guess making a new app work on Wine is a non-trivial task, and so people prefer to focus their efforts where the app is truely needed - i.e., where no native free software alternative is available. This does not mean that David can't hack wine to make NetMeeting work himself, or that Alexandre won't commit it. It just means that I, for one, have little incentive to jump in at the moment. Once Jérôme pointed (me) to GnomeMeeting (how did they skip the chance to call it Gnomeeting??), it's not my itch any more. People Wine is for Win apps!! I know there are many native apps that will replace win apps, fulfill your needs but.. WTF is this project about??? running win apps on linux?? Certanly for some people. I know that's a lot of what it is to me, in any case. Without trying to claim that ReactOS guys are not doing a wonderful job, I'm still after using Linux (or any other free OS, I don't care that much) for as much of my day2day activities as possible. Wine is one of the tools to do that. Not you should use this or that app in its place, but you should use what your comfortable with.. what you spent your hard earned money on.. But what about the not-yet-spent money? Will it be cheaper to learn a new app, or to support NetMeeting? Remeber, that app is integrated into the Windows OS in levels I don't think even IE can rival. I know that I found Jérôme's post useful. One may adopt a more "FYI" tone in the future. So to sum this rant up. In the future dont say use what I use, but help them use what there use to and Wine will fulfill its goal... I can speak only for myself. I won't invest huge amounts of time in helping someone else use an application *he* is used to, while I have perfectly acceptable (to me) alternatives. If he'd be paying me - that's something else. If he'd come with specific questions - that's something else too. Just my $.02 Tom My 0.09 ILS (http://www.xe.com/ucc/convert.cgi?Amount=0.09&From=ILS&To=USD) Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Potential forum at linuxquestions.org
Mike Hearn wrote: On Tue, 11 Nov 2003 18:15:09 -0800, Sir Dan Kegel scribed thus: A web interface that let you post to the mailing list would be fine. A web forum would not. It would mean that, if I wanted to answer user questions, I'd have to get used to another strange interface that probably has crappy indexing and is full of fruity HTML that gets in the way. Actually, the LQ archives are indexed very well by Google (and they use a heavily stripped form of HTML). It also has a built in search feature, as well as an instant "threads similar to this one". But they don't solve the fundemental problem for me - I need a "push" interface. Experience has shown that I am totally unable to follow a forum where I need to go out and check whether anything got updated. With mailing list (and also nntp), new stuff automatically arrives at my box, and is clearly marked as new. For that reason, any web only interface is totally unacceptable. I understand that many people, mostly newbies, find the mailing interface every bit as confusing. That's fine with me. That's why a both solution is necessary. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: asm help
Marcus Meissner wrote:
On Tue, Nov 11, 2003 at 04:51:12PM +0300, flyker wrote:
Can anybody help me write the function for Linux :
__declspec(naked) BOOL WINAPI
_InitCommonControlsEx(INITCOMMONCONTROLSEX* lpInitCtrls)
{
if(!dwLPA_InitCommonControlsEx)
{
__asm mov eax, 0
__asm ret 4
}
else
{
__asm jmp dwLPA_InitCommonControlsEx
}
}
Would be something like:
BOOL WINAPI
_InitCommonControlsEx(WINGS_INITCOMMONCONTROLSEX* lpInitCtrls)
{
if(!dwLPA_InitCommonControlsEx)
{
return FALSE;
} else {
return dwLPA_InitCommonControlsEx();
}
}
But you shouldn't use reverse engineering like this for WINE development.
Ciao, Marcus
Actually, it would be:
BOOL WINAPI
_InitCommonControlsEx(WINGS_INITCOMMONCONTROLSEX* lpInitCtrls)
{
if(!dwLPA_InitCommonControlsEx)
{
return FALSE;
} else {
return dwLPA_InitCommonControlsEx(lpInitCtrls);
}
}
The "jmp" is an optimization step, where the new function is called with
the same parameters as the old one.
I do agree with you about not using direct ASM->C conversions like this.
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: mailman list problems
Jeremy Newman wrote: Hey all, just dropping a note about the recent inactivity on the list. Apparently mailman has a bug where a spam with a malformatted header can crash the queue processing. This is easy enough to fix, just delete the offending message from the queue. It happened for a second time in a week now. Just thought I'd let you all know. *cough* ezmlm *cough*? -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine lecture
Jeremy Newman wrote: Actually is the date of the post. So setting it to November 30th would be bad. I propose this instead: --- /dev/null 2003-09-08 21:59:07.0 +0200 +++ news/2003111002.xml 2003-11-10 20:12:23.0 +0100 + + November 10, 2003 + Wine presentation at the Tel-Aviv University Linux Club (Telux) + +Shachar Shemesh will be giving a Wine presentation in Hebrew +on November 30th at the Tel-Aviv University Linux Club. +For more details see the +http://www.cs.tau.ac.il/telux/";>Telux website. + + Go for it. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine lecture
Francois Gouget wrote:
Great. I propose to add the following news item. Shachar, does it
look ok to you?
Newman, it's the first I hack the news items so I hope I got it right. I
was not sure about the date in particular: we want users to see the date
of the presentation so I was not sure whether the filename should have
today's date, the date of the presentation or what.
--- /dev/null 2003-09-08 21:59:07.0 +0200
+++ news/2003113001.xml 2003-11-10 19:15:44.0 +0100
@@ -0,0 +1,9 @@
+
+ November 30, 2003
+ Wine presentation at Telux in Tel-Aviv
+
+ Shachar Shemesh will be giving a Wine presentation in Hebrew at
+the Tel-Aviv University Linux Club. For more details see the
+http://www.cs.tau.ac.il/telux/";>Telux website.
+
+
Make that "Tel-Aviv University Linux Club (Telux)", and I'm great with it.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Wine lecture
Hi all,
Last time the subject came up, someone suggested I make the date
available so it can be published on the winehq.org site.
I'm going to give a lecture about Wine in a club called "Telux". The web
site is at http://www.cs.tau.ac.il/telux/ (supposedly in Hebrew, but if
you click the "Advanced lectures" english link at the left, you will get
a pretty readable schedule even for non-Hebrew speaking).
The lecture will be on Nov 30th, at the Tel Aviv University. The lecture
will be given in Hebrew. It will start 18:30 in the math building at the
university. No advance registration is required, and no fee.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Add preliminary support for keyboard layout APIs
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: The idea I had, for which I cannot state whether it's feasible or not, is to get the mapping from XKB, and prepare a list (group 0 - US, group 1 - IL, group 2 - RU). Then, whenever we get a "next group" or "prev group", just send out the proper messages. This way, we can also switch keyboard language at an application's whim (I actually have a small snippet of code that does that, if your'e interested). I'm afraid that will not work, since we need to attach an XKB mapping Anyhow, your current code (which I have not dived into, yet) should probably go in. It seems to prepare important infrastructure for handling keyboard languages by the X11 driver. Perhaps I exaggerated a bit a problem for you. After a little of thinking I believe you could try: 1. remove all existing israelian keyboard layouts from x11drv/keyboard.c 2. create a new israelian layout (by simply editing an existing one and removing english characters) which will work in Wine after 'setxkbmap il'. 3. configure your XFree86 to have distinct "us" and "il" layouts. #3 possibly is a most difficult step. At least I don't know how to do that using standard approaches provided by XF86Config. After that, MappingNotify should really do its work and make Wine to change internal keyboard layouts and therefore HKL identifier. XFree 4.3 would do about this. setxkbmap il would only give Israeli keyboard layout. In order to get the current behaviour, one would have to do "setxkbmap us,il". Is that what you mean? If that is the case, then merely removing the English part of the keyboard from the Israeli Wine mapping should identify it as a US keyboard followed by an Israeli keyboard. Is that what you mean? -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Add preliminary support for keyboard layout APIs
Dmitry Timoshkov wrote: Hello, note to Shachar: this implementation doesn't really work due to "merged" keyboard layouts we have. I.e. since we have Israelian keyboard layout with both english and hebrew characters, after the MappingNotify event we're still using the same keyboard layout with same LCID identifier, and applications receive WM_INPUTLANGCHANGE(REQUEST) with the same, not changed keyboard layout identifier. You can make it work though, using an ugly workaround: setxkbmap us wine WINWORD.EXE type something in Word, then in another xterm and run setxkbmap ru switch back to Word and continue typing. Word will see the change and kindly reflect that in the status bar. In order to experiment with Hebrew you need to create a pure Hebrew keyboard layout in Wine, and use 'setxkbmap il'. Perhaps a way to go is to handle X layout switch notification event and figure out what layout is really used from the merged mapping we currently have. So far I have no an idea how to do that. I had an idea, but I have not even began to look at it. I'm currently still sharing my time on Wine between the unicows thingy and revamping the BiDi support. The idea I had, for which I cannot state whether it's feasible or not, is to get the mapping from XKB, and prepare a list (group 0 - US, group 1 - IL, group 2 - RU). Then, whenever we get a "next group" or "prev group", just send out the proper messages. This way, we can also switch keyboard language at an application's whim (I actually have a small snippet of code that does that, if your'e interested). As far as I see it, using "setxkbmap" with a new layout is akin to entering the keyboard control panel applet and changing the layout, rather than to using "alt-shift". I fully understand that some applications do that anyhow. In particular, KDE's keyboard switching is based on calling setxkbmap. I think that would still work (though it may send an "settingschanged" message). Anyhow, your current code (which I have not dived into, yet) should probably go in. It seems to prepare important infrastructure for handling keyboard languages by the X11 driver. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: More DLL spec forwarding issues
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
I got no reponse for the previous issue I posted (where placing
forwards in a spec file did not perform as expected). I have tried to
create actual functions that perform the forwards.
You shouldn't have to do that, the forwards should work. If they don't
you should debug it and find out why, that's not normal.
The problem with that is that forwards do not show on +relay logs. I'm
not sure why. This makes it almost impossible for me to check what went
wrong.
The current solution started as a debugging aid, and then I found out
that it (unlike the forwarding one) actually works.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Help with forwarding .spec and DLL overrides for a new DLL
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why. Why do you need to add unicows.dll to Wine? That dll is not supposed to be a part of Windows, it's just an addtion provided by an application to circumvent the absence of the unicode APIs on win9x platform, and must be installed by that application. Because it has bad intereffect on Wine. I'm not sure where, exactly. Things misbehave (sometimes) with this DLL present. You get Unicode data sent to ANSI functions and other strange stuff. The thing about this DLL is that it is very easy to implement in Wine (so things will not misbehave). All you have to do is direct all calls to the real Unicode versions already in Wine. I'm just having problems with the fine details of the forwarding mechanism. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
More DLL spec forwarding issues
Hi, I got no reponse for the previous issue I posted (where placing forwards in a spec file did not perform as expected). I have tried to create actual functions that perform the forwards. This works great when I use my own program. However, whem I try to use another program, it tries to call "GetProcAddress". Unfortunetly, there is no way to reimplement GetProcAddress in Wine, as the .spec.c file generated needs that function! This is a very problematic thing for me. I tried forwarding GetProcAddress to GetProcAddress_unicows, but that did not help either. I get linker error (function redefined). Please, can anyone help? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Question: Is secdrv.sys a "Protection Mechanisim"
Jonathan Wilson wrote:
3.neither of 1 or 2 is true and therefore the clone of secdrv.sys is
not a DMCA violation and can go into the WINE tree.
4. Neither 1 nor 2 are true in the strict sense of the word, but wer'e
not sure that safedisk's manufacturer will think the same. So the code
still cannot go in because we are afraid of being sued.
*sigh*
Like I said, I'm more worried about the cases that are NOT DMCA
violations, but people still don't do them for fear of the DMCA (because
it "sounds like").
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: [wineinstall] make nice value
Ivan Leo Murray-Smith wrote: This depends, it can go from 15-20 minutes to over 4 hours. A company in Israel has built a 8000 Ghz (Not a typo, it's Ghz) processor, that may take it down to a few seconds. I think you just pointed to the local technology press being negligent to a degree never before seen. This is the first I have heared about such a thing (these things usually make it all the way into the mainstream press). Do you know the company's name? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: copy protection - was: Re: Is it time for playing games on WINE?
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens. The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written. So the question is whether the code in question is "circumventing" the protection or not. If the code in Wine still doesn't allow unprotected CDs from running, there can be no problem. I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original. If the resulting behaviour is that copied CDs don't work, while original ones do, there is no circumvention (the mechanism that protects access to a copyrighted work is still in place). If this driver works with a CD, regardless of whether it was or was not copied, then we have a problem, yes. If this becomes a real issue, I can offer to host the Wine sources in a DMCA free country. I'm sure you'll all agree with me that the sources are the only prolematic part (if a given binary does not allow copied discs to run, it cannot be said to be infringing). No, a binary is problematic too. The DeCSS exe is just as illegal as the source. That's because of what DeCSS does. DeCSS is the circumvention device itself. It takes an encrypted DVD and produces unencrypted MPEGs. For example - I'm pretty sure that if you statically link Xine with libdecss, you will get a binary that is perfectly legal (region codes non-withstanding). It doesn't strip away (circumvent) the protection, it's just a player (i.e. - used the same way as it was meant to be used). I'm not sure how legal the source for that will be, but like I said, I think I can provide a place where the sources should be safe. Personally, I think the sources should also be legal, so long as we don't place a prominant #ifdef that, if set, produces a circumvention device. Remeber, the "chilling effect" is when we let the DMCA control what we do further than what it was meant to do to begin with. I can't see anyone taking you to court saying "look, it's true that with Wine you can't do anything that you can't do without, but it's an unlicensed version, so it's a DMCA violation". -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Help with forwarding .spec and DLL overrides for a new DLL
One more point. You can download the Windows program used to check this (source+exec) from http://shemesh.biz/wine. Shachar Shemesh wrote: The second had to do with the forwarding call. I generated (using a small perl script) the spec file for the DLL. It forwards all Unicode calls to the relevant Unicode call. Strangely, when the entries for LoadStringW and DrawTextW were pointing to the corresponding calls in user32, the program wouldn't run correctly. When I replaced them with explicit loading of user32.dll and GetProcAddress, everything works (that's the way it's currently in the diff). This suggests, to me, that the spec file is incorrectly set up. Can anyone please point me to my mistake? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Help with forwarding .spec and DLL overrides for a new DLL
Hi list, I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why. I am attaching the diffs for my current unicows patch (not working though it is). I'm trying to run it with a program I wrote. This program is the plain "Hello world" Visual Studio 6 produces when you ask for a Win32 application, with two changes. I changed the link order according to the instructions for using MSLU (http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx), so that the app will use unicows.dll on win98. The second is that I modified the LoadString and DrawText to specifically call LoadStringW and DrawTextW. The application is, otherwise, an ANSI application (only two Unicode functions called). The resulting app works ok on Windows 2000 and on Windows 98 (the later only when unicows.dll is in the same directory as the application - as it should). When trying to run the app on Wine with os=nt4, or with os=win98 and the native unicows.dll in the same directory as the app, everything works. So far, so good. Now comes the part things stop to work. First - I couldn't get my DLL overrides to take effect. I tried adding "UNICOWS.DLL"=b, but it wouldn't load my winelib dll over the standard one. I eventually created a symbolic link from a file called "unicows.dll" in the apps' dir to my unicows.dll.so file. That caused my dll to load. The second had to do with the forwarding call. I generated (using a small perl script) the spec file for the DLL. It forwards all Unicode calls to the relevant Unicode call. Strangely, when the entries for LoadStringW and DrawTextW were pointing to the corresponding calls in user32, the program wouldn't run correctly. When I replaced them with explicit loading of user32.dll and GetProcAddress, everything works (that's the way it's currently in the diff). This suggests, to me, that the spec file is incorrectly set up. Can anyone please point me to my mistake? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/ wine.patch.gz Description: application/gunzip
Help with forwarding .spec and DLL overrides for a new DLL
Hi list, I'm having trouble with my unicows.dll implementation. I can trace this problem down to forwarding entries not working, but I can't understand why. I am attaching the diffs for my current unicows patch (not working though it is). I'm trying to run it with a program I wrote. This program is the plain "Hello world" Visual Studio 6 produces when you ask for a Win32 application, with two changes. I changed the link order according to the instructions for using MSLU (http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx), so that the app will use unicows.dll on win98. The second is that I modified the LoadString and DrawText to specifically call LoadStringW and DrawTextW. The application is, otherwise, an ANSI application (only two Unicode functions called). The resulting app works ok on Windows 2000 and on Windows 98 (the later only when unicows.dll is in the same directory as the application - as it should). When trying to run the app on Wine with os=nt4, or with os=win98 and the native unicows.dll in the same directory as the app, everything works. So far, so good. Now comes the part things stop to work. First - I couldn't get my DLL overrides to take effect. I tried adding "UNICOWS.DLL"=b, but it wouldn't load my winelib dll over the standard one. I eventually created a symbolic link from a file called "unicows.dll" in the apps' dir to my unicows.dll.so file. That caused my dll to load. The second had to do with the forwarding call. I generated (using a small perl script) the spec file for the DLL. It forwards all Unicode calls to the relevant Unicode call. Strangely, when the entries for LoadStringW and DrawTextW were pointing to the corresponding calls in user32, the program wouldn't run correctly. When I replaced them with explicit loading of user32.dll and GetProcAddress, everything works (that's the way it's currently in the diff). This suggests, to me, that the spec file is incorrectly set up. Can anyone please point me to my mistake? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/ Index: configure.ac === RCS file: /home/sun/sources/cvs/wine/configure.ac,v retrieving revision 1.178 diff -u -r1.178 configure.ac --- configure.ac11 Sep 2003 21:27:58 - 1.178 +++ configure.ac28 Oct 2003 13:40:18 - @@ -1498,6 +1498,7 @@ dlls/tapi32/Makefile dlls/ttydrv/Makefile dlls/twain/Makefile +dlls/unicows/Makefile dlls/url/Makefile dlls/urlmon/Makefile dlls/urlmon/tests/Makefile Index: dlls/Makefile.in === RCS file: /home/sun/sources/cvs/wine/dlls/Makefile.in,v retrieving revision 1.184 diff -u -r1.184 Makefile.in --- dlls/Makefile.in8 Sep 2003 19:32:14 - 1.184 +++ dlls/Makefile.in28 Oct 2003 13:47:11 - @@ -96,6 +96,7 @@ tapi32 \ ttydrv \ twain \ + unicows \ url \ urlmon \ user \ @@ -287,6 +288,7 @@ tapi32.dll$(DLLEXT) \ ttydrv.dll$(DLLEXT) \ twain_32.dll$(DLLEXT) \ + unicows.dll$(DLLEXT) \ url.dll$(DLLEXT) \ urlmon.dll$(DLLEXT) \ user32.dll$(DLLEXT) \ @@ -605,6 +607,9 @@ twain_32.dll$(DLLEXT): twain/twain_32.dll$(DLLEXT) $(RM) $@ && $(LN_S) twain/twain_32.dll$(DLLEXT) $@ +unicows.dll$(DLLEXT): unicows/unicows.dll$(DLLEXT) $@ + $(RM) $@ && $(LN_S) unicows/unicows.dll$(DLLEXT) $@ + url.dll$(DLLEXT): url/url.dll$(DLLEXT) $(RM) $@ && $(LN_S) url/url.dll$(DLLEXT) $@ @@ -767,6 +772,7 @@ libtapi32 \ libttydrv \ libtwain_32 \ + libunicows \ liburl \ liburlmon \ libuser32 \ @@ -1196,6 +1202,11 @@ libtwain_32.a: twain/twain_32.spec.def $(DLLTOOL) -k -l $@ -d twain/twain_32.spec.def +libunicows.def: unicows/unicows.spec.def + $(RM) $@ && $(LN_S) unicows/unicows.spec.def $@ +libunicows.a: unicows/unicows.spec.def + $(DLLTOOL) -k -l $@ -d unicows/unicows.spec.def + liburl.def: url/url.spec.def $(RM) $@ && $(LN_S) url/url.spec.def $@ liburl.a: url/url.spec.def @@ -1368,6 +1379,7 @@ tapi32/tapi32.spec.def: $(WINEBUILD) ttydrv/ttydrv.spec.def: $(WINEBUILD) twain/twain_32.spec.def: $(WINEBUILD) +unicows/unicows.spec.def: $(WINEBUILD) url/url.spec.def: $(WINEBUILD) urlmon/urlmon.spec.def: $(WINEBUILD) user/user32.spec.def: $(WINEBUILD) @@ -1487,6 +1499,7 @@ tapi32/tapi32.dll$(DLLEXT): tapi32 ttydrv/ttydrv.dll$(DLLEXT): ttydrv twain/twain_32.dll$(DLLEXT): twain +unicows/unicows.dll$(DLLEXT): unicows url/url.dll$(DLLEXT): url urlmon/urlmon.dll$(DLLEXT): urlmon user/user32.dll$(DLLEXT): user --- /dev/null 2003-08-25 19:02:45.0 +0300 +++ dlls/unicows/Makefile.in2003-11-04
