Re: Make wine honor LC_CTYPE and LC_MESSAGES
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > >As far as I understand what you are trying to do and what the patch > >Alexandre committed does is to make the user interface use english > >while you still have an ability to type in your native language. > > > > > No. What I'm trying to do is have none-unicode applications use the > correct codepage according to their LC_CTYPE. That's all I'm trying to > do. While my original patch tried to also choose the interface language, > I removed that part. I think you are simply reading into this patch's > intentions things that are not there. Why LC_ALL or LANG don't work for you then? > >That's not how Windows does this, at least to my understanding. > > > That is precisely how windows does it. > > > On my > >english win2k with locale set to russian both GetSystemDefaultLCID and > >GetUserDefaultLCID return 0419 (russian). > > > Now I'm not following what you are trying to say. According to my > understanding of Windows, if you installed an English Win2k and set > system locale to Russian, all non-unicode applications you run will > interpret the string of bytes they read from files etc. under a Russian > codepage. No, data from any sources doesn't get interpreted by apps, the strings are interpreted when they are passed to A family of APIs. > If you set the user locale to Russian as well, you will get > dates in European order etc. as well. Your interface language should > remain English. That is the behaviour you are seeing, right? You are confusing two different things: language of the user interface (you call it the system locale) and current ANSI code page (you call it the user locale). There only one locale of the system which defines current ANSI code page, language of the user interface has nothing to do with it. > > I don't know how MUI enabled > >Windows versions implement that functionality, but I don't think that > >it's just the system locale. > > > > > It's not. I've installed MUI, and am currently investigating this. I'm > thinking of either having "FindResource" > use the interface language as defined by MUI instead of "LANG_NEUTRAL, > SUBLANG_NEUTRAL", or replace entry 9 in "find_entry" with the above > mentioned language. I still have to see how that is defined on Windows > MUI. In any case, I trust there is no argument that Wine should behave > like MUI, right? Right, it just should be implemented properly, and not like an one liner hack. > Either way, the patch above (second version) had no presumptions to do > what you claim it tries to do, and I therefor think your objection to it > is unfounded. My objection is that your patch aiming a good intention does the things in the wrong way. -- Dmitry.
Re: Scrollbars, an application bug or a wine regression ? (#2314)
"Nicolai Kuntze" <[EMAIL PROTECTED]> wrote: > > Are you sure that your app really regressed and had not shown the same > > behaviour before my scrollbar fixes? > > > > > No I am not sure but I think this is no regession. I think there is an > error in the detection in the heigth of the bitmap. But I don't khow > where to start to search the error. can you give me a hint? The > downloadeable archive (http://hubrichn.dyndns.org/bmed.tar.gz) is still > there. There is also a readme discribing my problem. (I already said > this...) Can you please have a look at this. As far as I can see all > calls of BitBlt and CreateWindowEx and so on are correct implemented in > bmed. I have that app already and had a look at it. It looks like a problem with listview control, but besides I'm not an expert in that area, I have lots of other things assigned to me to do. -- Dmitry.
Re: add autodetect audio driver capability to winmm
On Sun, Jul 25, 2004 at 05:08:04PM -0500, James Hawkins wrote: > Changelog: > * take audio autodetection out of winecfg and put it in winmm > * if driver is not found in the registry or the driver fails to > load, then autodetect driver This would make artsd the default driver on KDE systems. Most are still using the OSS driver, which might be of a better state. Ciao, Marcus
Re: add autodetect audio driver capability to winmm
On Mon, 26 Jul 2004, Robert Shearman wrote:
[...]
> >Actually this is the start of a block of code since the character
> >preceeding 'BOOL' is '{'.
>
> Not quite. After applying the patch, this is what you get:
Ah, sorry. It the '-' I missed.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
"Utilisateur" (nom commun) :
Mot utilis\xE9 par les informaticiens en lieu et place d'"idiot".
Re: add autodetect audio driver capability to winmm
Francois Gouget wrote:
On Mon, 26 Jul 2004, Robert Shearman wrote:
[...]
size = sizeof(buffer);
-if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) {
+BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
- all variable declarations must be done at the very
start of a block of code.
Actually this is the start of a block of code since the character
preceeding 'BOOL' is '{'.
Not quite. After applying the patch, this is what you get:
/**
* MMDRV_InitFromRegistry[internal]
*/
static BOOLMMDRV_InitFromRegistry(void)
{
HKEYhKey;
charbuffer[256];
char*p1;
char*p2;
DWORDtype, size;
BOOLret = FALSE;
TRACE("()\n");
if (RegCreateKeyA(HKEY_LOCAL_MACHINE,
"Software\\Wine\\Wine\\Config\\WinMM", &hKey)) {
TRACE("Cannot open WinMM config key\n");
return FALSE;
}
size = sizeof(buffer);
BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
(LPVOID)buffer, &size);
Re: add autodetect audio driver capability to winmm
On Mon, 26 Jul 2004, Robert Shearman wrote:
[...]
> >>>size = sizeof(buffer);
> >>>-if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) {
> >>>+BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
> >>>
> - all variable declarations must be done at the very
> start of a block of code.
Actually this is the start of a block of code since the character
preceeding 'BOOL' is '{'.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
Indifference will certainly be the downfall of mankind, but who cares?
Re: add autodetect audio driver capability to winmm
James Hawkins wrote:
This is only available in C99. We try to make Wine compile with as many
C compilers as possible, including gcc 2.95, which doesn't allow this
sort of thing.
What part of the code is only availabe in C99? I'll try to fix it so
we can be compatible with other compilers.
size = sizeof(buffer);
-if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) {
+BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
- all variable declarations must be done at the very
start of a block of code.
+(LPVOID)buffer, &size);
This is only available in C99. We try to make Wine compile with as many
C compilers as possible, including gcc 2.95, which doesn't allow this
sort of thing.
Rob
Re: add autodetect audio driver capability to winmm
On Sun, 25 Jul 2004 17:33:19 -0500, James Hawkins wrote: > What part of the code is only availabe in C99? I'll try to fix it so > we can be compatible with other compilers. You can't declare variables in the middle of a block. They have to go at the start.
Re: add autodetect audio driver capability to winmm
> This is only available in C99. We try to make Wine compile with as many
> C compilers as possible, including gcc 2.95, which doesn't allow this
> sort of thing.
What part of the code is only availabe in C99? I'll try to fix it so
we can be compatible with other compilers.
On Sun, 25 Jul 2004 23:25:57 +0100, Robert Shearman <[EMAIL PROTECTED]> wrote:
>
>
> James Hawkins wrote:
>
> >Changelog:
> >* take audio autodetection out of winecfg and put it in winmm
> >* if driver is not found in the registry or the driver fails to
> >load, then autodetect driver
> >
> >
>
> Thanks for another cool patch. It lessens the burden on the user.
> CC'ing ros-kernel as explained below.
>
> >Index: dlls/winmm/lolvldrv.c
> >===
> >RCS file: /home/wine/wine/dlls/winmm/lolvldrv.c,v
> >retrieving revision 1.58
> >diff -u -r1.58 lolvldrv.c
> >--- dlls/winmm/lolvldrv.c 1 Jun 2004 19:40:48 - 1.58
> >+++ dlls/winmm/lolvldrv.c 25 Jul 2004 22:05:54 -
> >@@ -30,6 +30,8 @@
> > #include "winver.h"
> > #include "winemm.h"
> > #include "wine/debug.h"
> >+#include "config.h"
> >+#include "wine/port.h"
> >
> > WINE_DEFAULT_DEBUG_CHANNEL(winmm);
> >
> >@@ -711,6 +713,80 @@
> > }
> >
> > /**
> >+ * MMDRV_AutoDetectDriver [internal]
> >+ *
> >+ * modified from programs/winecfg/audio.c
> >+ */
> >+BOOL MMDRV_AutoDetectDriver(void)
> >+{
> >+struct stat buf;
> >+const char *argv_new[4];
> >+int fd;
> >+
> >+char *driversFound[10];
> >+char *name[10];
> >+int numFound = 0;
> >+
> >+argv_new[0] = "/bin/sh";
> >
>
> I think the ReactOS people may have a few comments to make on this, now
> that they are using this DLL in ReactOS.
>
> >+argv_new[1] = "-c";
> >+argv_new[3] = NULL;
> >+
> >+/* try to detect arts */
> >+argv_new[2] = "ps awx|grep artsd|grep -v grep|grep artsd > /dev/null";
> >+if(!spawnvp(_P_WAIT, "/bin/sh", argv_new))
> >+{
> >+driversFound[numFound] = "winearts.drv";
> >+name[numFound] = "aRts";
> >+numFound++;
> >+}
> >+
> >+/* try to detect jack */
> >+argv_new[2] = "ps awx|grep jackd|grep -v grep|grep jackd > /dev/null";
> >+if(!spawnvp(_P_WAIT, "/bin/sh", argv_new))
> >+{
> >+driversFound[numFound] = "winejack.drv";
> >+name[numFound] = "jack";
> >+numFound++;
> >+}
> >+
> >+/* try to detect nas */
> >+/* TODO */
> >+
> >+/* try to detect audioIO (solaris) */
> >+/* TODO */
> >+
> >+/* try to detect alsa */
> >+if(!stat("/proc/asound", &buf))
> >+{
> >+driversFound[numFound] = "winealsa.drv";
> >+name[numFound] = "Alsa";
> >+numFound++;
> >+}
> >+
> >+/* try to detect oss */
> >+fd = open("/dev/dsp", O_WRONLY | O_NONBLOCK);
> >+if(fd)
> >+{
> >+close(fd);
> >+driversFound[numFound] = "wineoss.drv";
> >+name[numFound] = "OSS";
> >+numFound++;
> >+}
> >+
> >+
> >+if (numFound == 0)
> >+{
> >+TRACE("Could not detect any audio devices/servers");
> >+return FALSE;
> >+}
> >+
> >+/* TODO: possibly smarter handling of multiple drivers? */
> >+TRACE("Found driver %s\n", name[0]);
> >+
> >+return MMDRV_Install(driversFound[0], driversFound[0], FALSE);
> >+}
> >+
> >+/**
> > *MMDRV_InitFromRegistry [internal]
> > */
> > static BOOL MMDRV_InitFromRegistry(void)
> >@@ -729,7 +805,9 @@
> > }
> >
> > size = sizeof(buffer);
> >-if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) {
> >+BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
> >+(LPVOID)buffer, &size);
> >
>
> This is only available in C99. We try to make Wine compile with as many
> C compilers as possible, including gcc 2.95, which doesn't allow this
> sort of thing.
>
> >+if (keyQueried) {
> > p1 = buffer;
> > while (p1) {
> > p2 = strchr(p1, ';');
> >@@ -738,7 +816,11 @@
> > p1 = p2;
> > }
> > }
> >-
> >+
> >+/* if no driver specified in reg or driver fails to load then autodetect */
> >+if (!keyQueried || !ret)
> >+ret |= MMDRV_AutoDetectDriver();
> >+
> > /* finish with mappers */
> > size = sizeof(buffer);
> > if (!RegQueryValueExA(hKey, "WaveMapper", 0, &type, (LPVOID)buffer, &size))
> >
> >
>
> Rob
>
>
--
James Hawkins
Re: add autodetect audio driver capability to winmm
James Hawkins wrote:
Changelog:
* take audio autodetection out of winecfg and put it in winmm
* if driver is not found in the registry or the driver fails to
load, then autodetect driver
Thanks for another cool patch. It lessens the burden on the user.
CC'ing ros-kernel as explained below.
Index: dlls/winmm/lolvldrv.c
===
RCS file: /home/wine/wine/dlls/winmm/lolvldrv.c,v
retrieving revision 1.58
diff -u -r1.58 lolvldrv.c
--- dlls/winmm/lolvldrv.c 1 Jun 2004 19:40:48 - 1.58
+++ dlls/winmm/lolvldrv.c 25 Jul 2004 22:05:54 -
@@ -30,6 +30,8 @@
#include "winver.h"
#include "winemm.h"
#include "wine/debug.h"
+#include "config.h"
+#include "wine/port.h"
WINE_DEFAULT_DEBUG_CHANNEL(winmm);
@@ -711,6 +713,80 @@
}
/**
+ * MMDRV_AutoDetectDriver [internal]
+ *
+ * modified from programs/winecfg/audio.c
+ */
+BOOL MMDRV_AutoDetectDriver(void)
+{
+struct stat buf;
+const char *argv_new[4];
+int fd;
+
+char *driversFound[10];
+char *name[10];
+int numFound = 0;
+
+argv_new[0] = "/bin/sh";
I think the ReactOS people may have a few comments to make on this, now
that they are using this DLL in ReactOS.
+argv_new[1] = "-c";
+argv_new[3] = NULL;
+
+/* try to detect arts */
+argv_new[2] = "ps awx|grep artsd|grep -v grep|grep artsd > /dev/null";
+if(!spawnvp(_P_WAIT, "/bin/sh", argv_new))
+{
+driversFound[numFound] = "winearts.drv";
+name[numFound] = "aRts";
+numFound++;
+}
+
+/* try to detect jack */
+argv_new[2] = "ps awx|grep jackd|grep -v grep|grep jackd > /dev/null";
+if(!spawnvp(_P_WAIT, "/bin/sh", argv_new))
+{
+driversFound[numFound] = "winejack.drv";
+name[numFound] = "jack";
+numFound++;
+}
+
+/* try to detect nas */
+/* TODO */
+
+/* try to detect audioIO (solaris) */
+/* TODO */
+
+/* try to detect alsa */
+if(!stat("/proc/asound", &buf))
+{
+driversFound[numFound] = "winealsa.drv";
+name[numFound] = "Alsa";
+numFound++;
+}
+
+/* try to detect oss */
+fd = open("/dev/dsp", O_WRONLY | O_NONBLOCK);
+if(fd)
+{
+close(fd);
+driversFound[numFound] = "wineoss.drv";
+name[numFound] = "OSS";
+numFound++;
+}
+
+
+if (numFound == 0)
+{
+TRACE("Could not detect any audio devices/servers");
+return FALSE;
+}
+
+/* TODO: possibly smarter handling of multiple drivers? */
+TRACE("Found driver %s\n", name[0]);
+
+return MMDRV_Install(driversFound[0], driversFound[0], FALSE);
+}
+
+/**
* MMDRV_InitFromRegistry [internal]
*/
static BOOL MMDRV_InitFromRegistry(void)
@@ -729,7 +805,9 @@
}
size = sizeof(buffer);
-if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) {
+BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type,
+(LPVOID)buffer, &size);
This is only available in C99. We try to make Wine compile with as many
C compilers as possible, including gcc 2.95, which doesn't allow this
sort of thing.
+if (keyQueried) {
p1 = buffer;
while (p1) {
p2 = strchr(p1, ';');
@@ -738,7 +816,11 @@
p1 = p2;
}
}
-
+
+/* if no driver specified in reg or driver fails to load then autodetect */
+if (!keyQueried || !ret)
+ret |= MMDRV_AutoDetectDriver();
+
/* finish with mappers */
size = sizeof(buffer);
if (!RegQueryValueExA(hKey, "WaveMapper", 0, &type, (LPVOID)buffer, &size))
Rob
Re: rsabase.dll
Michael Jung wrote: Rob, as far as I can tell from looking at your patch, our work is pretty much non overlapping. RSABase isn't that big. It is hard to do much without overlapping. I worked on the following aspects: - Implementation of "real handles", instead of "address-handles". This is useful. Address handles (pointers to objects in memory) have the disadvantage that they can leak memory if the application can't be bothered to free them, although this only really matters if the library is unloaded (as if the process terminates, all memory will be freed anyway) and can be just as easily accomplished with a separate heap. Hmm, maybe it isn't so useful. Why did you go down this route? - Separating OpenSSL dependend code from CSP code. I consider this beneficial, since there seem to be some license issues with OpenSSL (at least for the ReactOS project - there was a short discussion on this on the wine-devel list). If the OpenSSL code is cleanly separated, it will be easier to support GNUTLS or something later. I think this is just making the job harder. Yes, OpenSSL possible has licensing issues, but that is for the OS. Is there anything stopping you creating an OpenSSL layer on top of GNUTLS (or any other crypto library), rather than going down this messy compatibility route? - Basically, my code doesn't do any crypto stuff at all until now (Besides some first lines of code for MD5 hashing). I tried to get the MSDN CryptoAPI examples to compile and run, which only acquire contexts, hash data, derive keys, query CSP params and so on, but which never verify the results. So my code is mainly skin (but elephant skin), no guts. Yes, it is similar code to mine, except I used the EVP higher-level routines as they offer a similar framework to CryptoAPI and it is really no more work to add in new algorithms (except for a case statement in one or two switch blocks). I've attached the current version of my patch. Do you have a certain application, which you want to get running? Not really. I went down this route because I thought it would be needed for a certain application, but it turned out that it didn't need it. I'd still to finish the work and to get it incorporated into the Wine tree, however. I can still use this application to test with though (it calls ExitProcess if it doesn't verify correctly). Would it be ok for you if we proceed as follows: I will wait until you submit your patch (It would be nice if you could add some unit-tests that test for behaviour you depend on). After this you give me a week or two to incorporate my work. Sure, that sounds good. Is there any area in rsabase, which you definitely will not implement in the near future and which I could work on until you submit your patch? Well, pretty much everything that I was going to implement is in the patch I sent you. The only additional functions I was going to implement are RSA_CPSignHash and RSA_CPVerifySignature. However, if you want me to implement some more I would be only too happy to do so having gained a lot of familiarity with both CryptoAPI and the OpenSSL/Crypto library. Rob
Re: Support for Palm USB Hotsync
> "Harald" == Harald Milz <[EMAIL PROTECTED]> writes: Harald> Hi, I am new to this list (albeit not to Wine :-) my Wine usage Harald> dates back to 1993 when I interviewed Bob Amstadt in his Harald> home... ) Harald> Anyway - I have a problem with Palm USB hotsync which could Harald> perhaps be solved on the userspace level. As you all know, the Harald> Linux USB kernel code creates an in-kernel device (in this case, Harald> ttyUSB1) only when a connected device actually talks. With a Harald> Palm, this is only the case if one presses the hotsync Harald> button. This keeps me from running Hotsync permanently which I Harald> need to sync my Palm against Lotus Notes. As soon as I start Harald> Hotsync, it complains that the device is not there at all. Even Harald> if I press "hotsync" and start Hotsync immediately after that, Harald> no communication takes place. (pilot-xfer -p /dev/ttyUSB1 works Harald> just fine) Harald> Now, for Wine / Cxoffice, ttyUSB is merely a serial Harald> device. Wouldn't it be possible to modify the Wine code in a way Harald> to fake the open() call and return success to the caller, poll Harald> the actual device and open it as soon as it actually comes up? I Harald> would be willing to hack this in but I have no real idea where Harald> to look regarding the sheer size of the code. I suspect it's in Harald> server/serial.c but I am not sure. Any hint is welcome. Perhaps try a WINEDEBUG=+relay,+server,+file run, to see whats happening. Grepping through the source will help to find out whats happening. Keep us informed about your progress. Good luck -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Is bugzilla worth keeping?
Mike Hearn wrote: I talked to Dimi, Lionel and Alexandre on IRC about this. This is what they had to say: Lionel didn't think it should be scrapped however he proposed a system whereby bugs that didn't have any activity for two releases or more would be automatically closed. If you wanted to keep a bug open users would have to post reports of behaviour with current releases. http://bugs.winehq.org/show_bug.cgi?id=1236 Summary: Marcus was apparently of the same opinion. I, obviously, am not. I use bugzilla as a tool to keep track of my "todo" list. If there is a place where I suspect a certain behaviour is broken, I open a bug report (knowing it will only be me who will have to "confirm" it... :-), and leave it "unconfirmed". I think asking us (wine developers) to move at the same pace Alexandre is releasing is unrealistic. The idea is to make bugzilla more friendly to us, not less. I see why user-opened bugs could benefit from this policy, but developers opened bugs should probably not. Of all the BiDi related bugs, I think 1235 is the only place where a bug MAY have disappeared "by itself". Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: winecfg todo list
On Sun, 2004-07-25 at 23:51 +0300, Shachar Shemesh wrote: > You can't change to the TTY driver using just the registry. Saving the > value in the registry doesn't survive a Wine restart. Well no - currently the config branch of the registry is loaded from the config file. Once we switch that off changes you make to the config using regedit will be saved just like any other change ...
Re: winecfg todo list
Mike Hearn wrote: Oh, final thing, we need to double check that removing the config doesn't regress things. I've been running with no config file for a few months now and while there are a few minor things I don't think they are critical. I may well have missed things though. You can't change to the TTY driver using just the registry. Saving the value in the registry doesn't survive a Wine restart. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Invalid path L"c:\\WINDOWS" for L"windows" directory: does not exist
On Sun, 25 Jul 2004 19:13:11 +0200, Andreas Davour wrote: > I've tried that now, it looks like it now is searching for a "temp" > directory as well. I didn't get a "fake windows" when installing, but got > one from a friend. I'm beginning to suspect something is broken with the > FreeBSD port. I'll try to check with that maintainer. > > Thanks for your help, now I'm on track debugging the problem. Wine should generate ~/.wine and ~/.wine/drive_c when you first run it. Alternatively "wineprefixcreate" can be used to build it for you (does the same thing). If that isn't happening for you either you have an old version of Wine or your package is broken. thanks -mike
Re: Wine isn't GUI user friendly
Mike Hearn wrote: Christian Neumair <[EMAIL PROTECTED]> writes: That reminds me of asking for nicer, GUI-driven error handling: touch mustardandwiener.exe && wine mustardandwiener.exe returns wine: cannot determine executable type for L"H:\\Desktop\\test.exe" which is neither verbose enough nor user friendly, because it is simply printed at a terminal. Modern desktop environments usually launch wine from their file manager, i.e. without terminals. Well, as to the contents of the message itself, I don't know how it could be improved. You asked Wine to run an empty file and it said it can't figure out what kind of executable it is: why is this a problem? A user often doesn't understand what that means. A proper error message should be, at the very least, something like the following: Wine cannot run "H:\Desktop\test.exe". It is not in a format Wine understands. Also, maybe we need a new debug level for that (above ERR and FIXME), which is "Human readable messages". The message as it is is perfectly understandable to programmers, but not to users. Even if it was, these messages are usually surrounded by hundred of messages that the user have no use in seeing. We should be able to let the user see only the messages that are relevant to them. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Wine isn't GUI user friendly
On Sun, 2004-07-25 at 19:02 +0300, Shachar Shemesh wrote: > Also, maybe we need a new debug level for that (above ERR and FIXME), > which is "Human readable messages". The message as it is is perfectly > understandable to programmers, but not to users. Even if it was, these > messages are usually surrounded by hundred of messages that the user > have no use in seeing. We should be able to let the user see only the > messages that are relevant to them. Yeah, I like that idea. It could also be the first step towards moving certain classes of messages into a GUI form (of course it could still be sent to the console when you run wine like that, or be controlled by a config option). Alexandre, what is your opinion on such a channel? thanks -mike
Re: Marshalling tutorial
On Sun, 2004-07-25 at 11:27 +0200, Ove Kaaven wrote: > The answer is of course that COM doesn't assume that objects actually > are thread-safe. Most real-world objects aren't, in fact, for various > reasons. What these reasons are isn't too important here, though, it's > just important to realize that the problem of thread-unsafe objects is > what COM tries hard to solve with its apartment model. There are also > ways to tell COM that your object is truly thread-safe (namely the > free-threaded marshaller). In general, no object is truly thread-safe if > it could potentially use another not so thread-safe object, though, so > the free-threaded marshaller is less used than you'd think. Right. > Perhaps you should spell out "QueryInterface-d", instead of saying > "QId". Yeah, I suppose I should be as explicit as possible with this topic. Actually I found out later that I was wrong anyway. You can't just take a proxy and QueryInterface it to IRpcProxyBuffer as they have two physically separate vtables. If you want to control the proxy you have to use a separate vtable that is only ever returned by the CreateProxy function and cannot be accessed any other way. > It depends on the Windows version, I think. Windows 95 and Windows NT 4 > certainly had very different models when I looked. I'm pretty sure the > Windows 98 version of RPCRT4 was able to dispatch messages directly to > individual apartments. I'd be surprised if some similar functionality > was not added to Windows 2000. After all, if an object on machine A > wanted to use an object on machine B in an apartment C, wouldn't it be > most efficient if the RPC system knew about apartments and could > dispatch the message directly to it? And if RPC does know how to > efficiently dispatch to apartments, why should COM duplicate this > functionality? There were, however, no unified way to tell RPC about > them across Windows versions, so in that old patch of mine, I let the > COM/OLE dlls do the apartment dispatch, but even then, the RPC runtime > was always involved. After all, it could be quite tricky to tell whether > the call is merely interthread, without involving the RPC runtime... Currently OXIDs are just ((PID << 32) | TID) so you could see if it was inter-thread by examining that. In real DCOM though I don't know how they do it - presumably by walking the proesses apartment list looking for that OXID first. > Yes, it's right, but as you mentioned, typelibs cannot encode all the > information in the original IDL. InstallShield uses MIDL marshallers for > the interfaces which cannot be represented perfectly by a type library. > (You could of course ask why not use MIDL-generated marshallers all the > way. I believe part of the reason for that is that on appropriate > Windows versions, the marshallers generated from typelibs will be in a > form that Microsoft claims will run faster than a big MIDL-generated > marshaller, due to less RAM usage and CPU cache trashing.) Right. > And some related hacks in the typelib marshaller to cover up for the > fact that the typelibs don't actually represent the IDL perfectly, by > guessing at the extra information needed to successfully marshal the > interfaces used by InstallShield. To elaborate, the hack we're talking about is treating VT_VOID as an interface pointer. > All those hacks would no longer be needed after that old patch of mine, > of course... Yes but it's very large and none of us have been able to figure out how to chop it up and submit it in a way that won't cause regressions: really up until recently I didn't understand DCOM well enough to even attempt this, I would just have made a big mess of it. > I don't think you have covered the possibility of manually marshalling > an interface from one single-threaded apartment to another, either > (CoMarshalInterThreadInterfaceInStream). This is used to great effect in > InstallShield to separate the worker thread and the UI thread; DCOM does > all the hard work of letting the objects in the threads communicate > easily and conveniently, even while the worker threads work and the UI > thread remains responsive. Yes, I did not cover this as I thought the email was long enough as is, though the basic principles are still the same. Just the RPC transport differs. thanks for the review! -mike
Re: Invalid path L"c:\\WINDOWS" for L"windows" directory: does not exist
On Sat, 24 Jul 2004, Stefan Munz wrote: > Hi Andreas, > > first this question should better be posted to the wine users mailing list > ([EMAIL PROTECTED]). Thanks for mentioning it. I found this this via google and it seemed like the right place. Now I know. > Am Freitag, 23. Juli 2004 20:42 schrieb Andreas Davour: > > Hi! > > > > I try to use wine v.20040505 on FreeBSD5.2 and I just get the error in the > > subject line. > > > > I found another post about this and that OP was just told to check the > > "dosdevices" directly, since I have such a directory and I don't get any > > closer to a solution by staring uncomprehending at the files I thought > > maybe someone could give a wine newbie some more ideas on what to do? > > > > I didn't find any "C:" in that directory mentioned, and tried to make a > > c: synlink to a new directory without any more success. > > usually your fake windows drive is in /home/username/.wine/fake_windows this > is where your symlink C: in the dosdevices dir should point to. I've tried that now, it looks like it now is searching for a "temp" directory as well. I didn't get a "fake windows" when installing, but got one from a friend. I'm beginning to suspect something is broken with the FreeBSD port. I'll try to check with that maintainer. Thanks for your help, now I'm on track debugging the problem. /andreas
winecfg todo list
So, I talked with Chris and here are some tasks remaining on winecfg. All of these are *easy* and can be done by anybody who has basic coding ability. For a few of them you don't even really need to know C! So come on lurkers, I know you're out there, step on up. Things that need to be done before we should switch to winecfg IMHO are: * Windows Look has no associated edit control. Who modifies this setting these days anyway? I vote for killing the label rather than adding the edit. * UseTakeFocus (FIXME) - why is this a setting in the UI? I don't even know what the UseTakeFocus protocol does, I've certainly never tweaked it. Does it need to be there? At the very least it needs to be rephrased into terms people can understand and the FIXME needs to be removed. * In the Drives tab, the top half is full of widgetry we probably don't want anymore. In particular "Use real windows drive" etc doesn't make much sense, you can just change the c: mapping to get that effect and it's not something we want to encourage anyway. Especially as most people these days seem to use XP rather than Win98 using a real windows drive is fast way to get an inoperable Wine as well as (possibly) a torched Windows install if it's on FAT32 and you can even pick up viruses from them. I kid you not, the other day I ran a program that had been sitting on my Windows XP partition for a few months and my virtual windows drive (I think the term virtual rather than fake sounds better) ended up infected with some W32.Bagle variant. Anyway the top half of this tab doesn't do anything, never did, doesn't make any sense and should just be removed. * We should probably merge the X11 Driver and Audio tabs together as they both have lots of empty space, and rename it to "Audio and Video" or something. I think the term "X11 Driver" doesn't make much sense to many people anyway. Minor cosmetic fix: remove the groupbox on the "about" tab, it doesn't provide any information at all. We also may want to stick the authors list in there, as it's a bit more visible than in the shell32 about box which is hardly ever shown. But obviously these things should not block us switching to it. Once those things are done we can apply the patch to switch Wine to using the registry entirely. Is it worth writing a migration tool? I'm not really sure, I guess some people would like their settings preserved but most of the settings people tweak are just check boxes in the new UI anyway and would take like 5 seconds to restore. AppDefaults are a bigger issue but do many people have lots of these? Oh, final thing, we need to double check that removing the config doesn't regress things. I've been running with no config file for a few months now and while there are a few minor things I don't think they are critical. I may well have missed things though. thanks -mike
Re: Marshalling tutorial
On Sun, 2004-07-25 at 11:27 +0200, Ove Kaaven wrote: > The answer is of course that COM doesn't assume that objects actually > are thread-safe. Most real-world objects aren't, in fact, for various > reasons. What these reasons are isn't too important here, though, it's > just important to realize that the problem of thread-unsafe objects is > what COM tries hard to solve with its apartment model. There are also > ways to tell COM that your object is truly thread-safe (namely the > free-threaded marshaller). In general, no object is truly thread-safe if > it could potentially use another not so thread-safe object, though, so > the free-threaded marshaller is less used than you'd think. Right. > Perhaps you should spell out "QueryInterface-d", instead of saying > "QId". Yeah, I suppose I should be as explicit as possible with this topic. Actually I found out later that I was wrong anyway. You can't just take a proxy and QueryInterface it to IRpcProxyBuffer as they have two physically separate vtables. If you want to control the proxy you have to use a separate vtable that is only ever returned by the CreateProxy function and cannot be accessed any other way. > It depends on the Windows version, I think. Windows 95 and Windows NT 4 > certainly had very different models when I looked. I'm pretty sure the > Windows 98 version of RPCRT4 was able to dispatch messages directly to > individual apartments. I'd be surprised if some similar functionality > was not added to Windows 2000. After all, if an object on machine A > wanted to use an object on machine B in an apartment C, wouldn't it be > most efficient if the RPC system knew about apartments and could > dispatch the message directly to it? And if RPC does know how to > efficiently dispatch to apartments, why should COM duplicate this > functionality? There were, however, no unified way to tell RPC about > them across Windows versions, so in that old patch of mine, I let the > COM/OLE dlls do the apartment dispatch, but even then, the RPC runtime > was always involved. After all, it could be quite tricky to tell whether > the call is merely interthread, without involving the RPC runtime... Currently OXIDs are just ((PID << 32) | TID) so you could see if it was inter-thread by examining that. In real DCOM though I don't know how they do it - presumably by walking the proesses apartment list looking for that OXID first. > Yes, it's right, but as you mentioned, typelibs cannot encode all the > information in the original IDL. InstallShield uses MIDL marshallers for > the interfaces which cannot be represented perfectly by a type library. > (You could of course ask why not use MIDL-generated marshallers all the > way. I believe part of the reason for that is that on appropriate > Windows versions, the marshallers generated from typelibs will be in a > form that Microsoft claims will run faster than a big MIDL-generated > marshaller, due to less RAM usage and CPU cache trashing.) Right. > And some related hacks in the typelib marshaller to cover up for the > fact that the typelibs don't actually represent the IDL perfectly, by > guessing at the extra information needed to successfully marshal the > interfaces used by InstallShield. To elaborate, the hack we're talking about is treating VT_VOID as an interface pointer. > All those hacks would no longer be needed after that old patch of mine, > of course... Yes but it's very large and none of us have been able to figure out how to chop it up and submit it in a way that won't cause regressions: really up until recently I didn't understand DCOM well enough to even attempt this, I would just have made a big mess of it. > I don't think you have covered the possibility of manually marshalling > an interface from one single-threaded apartment to another, either > (CoMarshalInterThreadInterfaceInStream). This is used to great effect in > InstallShield to separate the worker thread and the UI thread; DCOM does > all the hard work of letting the objects in the threads communicate > easily and conveniently, even while the worker threads work and the UI > thread remains responsive. Yes, I did not cover this as I thought the email was long enough as is, though the basic principles are still the same. Just the RPC transport differs. thanks for the review! -mike
Re: dinput.dll: mouse didn't work
On Sun, Jul 25, 2004 at 04:10:04PM +0200, Michael Schlüter wrote: > Are keyboard and mouse handled within the same thread? Well, depends of the game... I think that it could well use a Keyboard device in one thread and a mouse device in another (for that, a +tid trace is nice because it prefixes all non-relay traces with the thread id). > Yes, KeyboardCallback is called with every key stroke. So, if both are in the same thread (see up there how to check it), we must have a problem somewhere. I once spent a lot of time looking at this code to hunt for the bug in the 'no waitforevent' game, and from what I remembered, I used the '+server,+hook' debug channels to see exactly how the 'hook' event was propagated via the server. I would need to re-follow the code path to refresh on this though :-) > The games are called "Robin Hood The Legend of Sherwood" and > "Desperados - Wanted Death or Alive". Demos are available but I don't > have the links handy. No need, I have both Demos installed (and even have the actual Desperados game itself). I will see if I can reproduce the bug here. By the way, how did you manage to actually play Desperados ? On my version of Wine, when I start either the demo or the game installer, it creates a zero-size window on the screen ... which prevents me to actually start the game or the installation. It works fine in Windows (it's one of those funky non-square windows). Lionel -- Lionel Ulmer - http://www.bbrox.org/
rsabase.dll
Rob,
as far as I can tell from looking at your patch, our work is pretty much non
overlapping.
I worked on the following aspects:
- Implementation of "real handles", instead of "address-handles".
- Separating OpenSSL dependend code from CSP code. I consider
this beneficial, since there seem to be some license issues
with OpenSSL (at least for the ReactOS project - there was a short
discussion on this on the wine-devel list). If the OpenSSL code is
cleanly separated, it will be easier to support GNUTLS or something
later.
- Basically, my code doesn't do any crypto stuff at all until now
(Besides some first lines of code for MD5 hashing). I tried to
get the MSDN CryptoAPI examples to compile and run, which only
acquire contexts, hash data, derive keys, query CSP params and so
on, but which never verify the results. So my code is mainly skin
(but elephant skin), no guts.
I've attached the current version of my patch.
Do you have a certain application, which you want to get running? Would it be
ok for you if we proceed as follows: I will wait until you submit your patch
(It would be nice if you could add some unit-tests that test for behaviour
you depend on). After this you give me a week or two to incorporate my work.
Is there any area in rsabase, which you definitely will not implement in the
near future and which I could work on until you submit your patch?
Greetings,
Michael
Index: dlls/rsabase/Makefile.in
===
RCS file: /home/wine/wine/dlls/rsabase/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- dlls/rsabase/Makefile.in 1 Mar 2004 21:20:33 - 1.2
+++ dlls/rsabase/Makefile.in 25 Jul 2004 08:25:50 -
@@ -7,7 +7,11 @@
IMPORTS = advapi32 kernel32
C_SRCS = \
- main.c
+ main.c \
+ handle.c \
+ implossl.c
+
+SUBDIRS = tests
@MAKE_DLL_RULES@
Index: dlls/rsabase/main.c
===
RCS file: /home/wine/wine/dlls/rsabase/main.c,v
retrieving revision 1.7
diff -u -r1.7 main.c
--- dlls/rsabase/main.c 25 Jun 2004 01:17:37 - 1.7
+++ dlls/rsabase/main.c 25 Jul 2004 08:25:52 -
@@ -21,27 +21,24 @@
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
*/
-
#include "config.h"
#include "wine/port.h"
#include
+#include
#include "windef.h"
#include "winbase.h"
#include "winreg.h"
#include "wincrypt.h"
+#include "lmcons.h"
+#include "handle.h"
+#include "rsabase.h"
#ifdef HAVE_OPENSSL_SSL_H
-#define DSA __ssl_DSA /* avoid conflict with commctrl.h */
-#undef FAR
-# include
-#undef FAR
-#define FAR do_not_use_this_in_wine
-#undef DSA
+#include "implossl.h"
#endif
#include "wine/library.h"
@@ -51,84 +48,316 @@
#define RSABASE_MAGIC 0x52534100
-#ifdef HAVE_OPENSSL_SSL_H
-
-#ifndef SONAME_LIBCRYPTO
-#define SONAME_LIBCRYPTO "libcrypto.so"
-#endif
-
-static void *libcrypto;
-
-#define MAKE_FUNCPTR(f) static typeof(f) * p##f
-
-/* OpenSSL funtions that we use */
-MAKE_FUNCPTR(RAND_bytes);
-
-static BOOL load_libcrypto( void )
+#define RSASTRONG_NUM_ALGS 14
+PROV_ENUMALGS_EX aProvEnumAlgsEx[RSASTRONG_NUM_ALGS] = {
+ {CALG_RC2,128, 40, 128,0, 4,"RC2", 24,"RSA Data Security's RC2"},
+ {CALG_RC4,128, 40, 128,0, 4,"RC4", 24,"RSA Data Security's RC4"},
+ {CALG_DES, 56, 56, 56,0, 4,"DES", 31,"Data Encryption Standard (DES)"},
+ {CALG_3DES_112, 112,112, 112,0, 13,"3DES TWO KEY",19,"Two Key Triple DES"},
+ {CALG_3DES, 168,168, 168,0, 5,"3DES",21,"Three Key Triple DES"},
+ {CALG_SHA,160,160, 160,CRYPT_FLAG_SIGNING, 6,"SHA-1", 30,"Secure Hash Algorithm (SHA-1)"},
+ {CALG_MD2,128,128, 128,CRYPT_FLAG_SIGNING, 4,"MD2", 27,"MD2 Message Digest 2 (MD2)"},
+ {CALG_MD4,128,128, 128,CRYPT_FLAG_SIGNING, 4,"MD4", 27,"MD4 Message Digest 4 (MD4)"},
+ {CALG_MD5,128,128, 128,CRYPT_FLAG_SIGNING, 4,"MD5", 27,"MD5 Message Digest 5 (MD5)"},
+ {CALG_SSL3_SHAMD5,288,288, 288,0, 12,"SSL3 SHAMD5", 12,"SSL3 SHAMD5"},
+ {CALG_MAC, 0, 0,0,0, 4,"MAC", 27,"Message Authentication Code"},
+ {CALG_RSA_SIGN, 1024,384,16384,CRYPT_FLAG_SIGNING|CRYPT_FLAG_IPSEC,9,"RSA_SIGN",14,"RSA Signature"},
+ {CALG_RSA_KEYX, 1024,384,16384,CRYPT_FLAG_SIGNING|CRYPT_FLAG_IPSEC,9,"RSA_KEYX",18,"RSA Key Exchange"},
+ {CALG_HMAC, 0, 0,0,0, 5,"HMAC",23,"HMAC Hugo's MAC (HMAC)"}
+};
+
+unsigned int iEnumAl
Re: Wine isn't GUI user friendly
Christian Neumair <[EMAIL PROTECTED]> writes: > That reminds me of asking for nicer, GUI-driven error handling: > touch mustardandwiener.exe && > wine mustardandwiener.exe > returns > wine: cannot determine executable type for L"H:\\Desktop\\test.exe" > which is neither verbose enough nor user friendly, because it is simply > printed at a terminal. Modern desktop environments usually launch wine > from their file manager, i.e. without terminals. Well, as to the contents of the message itself, I don't know how it could be improved. You asked Wine to run an empty file and it said it can't figure out what kind of executable it is: why is this a problem? As to using message boxes for errors, well I have submitted patches to do this before and some were accepted, and some were not. The reasoning was that having all errors appear in message boxes would be annoying. Perhaps if there was a generic mechanism such that when a terminal was available the message was printed, and when it was not (like in a GUI) a message box was used, that would be more acceptable. I don't know how to tell if a console is available or not though. Plus to be convenient it'd need to be a new Wine API and we're trying to remove them rather than add to them :) > Can't we have popup dialogs for that kind of errors? As far as I know, > debian guys have build a shell/wrapper around wine that pops up if weird > things like these occur. Can't we have such a wrapper in stock wine? For > now, it would be enough to just catch the most common problems (binary > not found, binary can't be loaded, etc.). To be frank I still think displaying the output of stderr when a program launched from the GUI fails is the desktops job. All kinds of messages can be printed by Wine before we even have a chance to initialize the GUI subsystem - in fact the "cannot run exe" message may well be an example of that. Writing a patch to Gnome to make it do that wouldn't be hard and would solve a broad class of problems. thanks -mike
Re: Is bugzilla worth keeping?
> 2. The people entering bugs aren't always developers and don't always > have the skills to provide a good bug report. We have a tools for writing bug report, tools/bug_report.pl We should encourage people to use it to write bug reports. Also closing unmaintained bugs would be a good idea. Ivan.
Re: Support PBS_MARQUE for progress bars
Sorry, this patch should compile.
Index: dlls/comctl32/progress.c
===
RCS file: /home/wine/wine/dlls/comctl32/progress.c,v
retrieving revision 1.36
diff -u -r1.36 progress.c
--- dlls/comctl32/progress.c11 Mar 2004 00:39:53 - 1.36
+++ dlls/comctl32/progress.c25 Jul 2004 12:26:33 -
@@ -26,9 +26,6 @@
* Unless otherwise noted, we believe this code to be complete, as per
* the specification mentioned above.
* If you discover missing features, or bugs, please note them below.
- *
- * TODO
- * --support PBS_MARQUE
*
*/
@@ -59,7 +56,9 @@
/* Control configuration constants */
-#define LED_GAP2
+#define LED_GAP 2
+#define MARQUEE_LEDS 5
+#define ID_MARQUEE_TIMER 1
/***
* PROGRESS_Invalidate
@@ -156,51 +155,215 @@
{
if (dwStyle & PBS_VERTICAL)
{
-INT old_top = rect.top;
-rect.top = rightBar;
-FillRect(hdc, &rect, hbrBar);
-rect.bottom = rect.top;
-rect.top = old_top;
-FillRect(hdc, &rect, hbrBk);
+if (dwStyle & PBS_MARQUEE)
+{
+INT old_top, old_bottom;
+old_top = rect.top;
+old_bottom = rect.bottom;
+
+leds = rect.bottom - rect.top;
+ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds;
+
+if(ledMStart > 0)
+{
+rect.top = max(rect.bottom - ledMStart, old_top);
+FillRect(hdc, &rect, hbrBar);
+rect.bottom = rect.top;
+}
+if(infoPtr->MarqueePos > 0)
+{
+rect.top = max(old_bottom - infoPtr->MarqueePos, old_top);
+FillRect(hdc, &rect, hbrBk);
+rect.bottom = rect.top;
+}
+if(rect.top >= old_top)
+{
+rect.top = max(rect.bottom - MARQUEE_LEDS, old_top);
+FillRect(hdc, &rect, hbrBar);
+rect.bottom = rect.top;
+}
+if(rect.top >= old_top)
+{
+rect.top = old_top;
+FillRect(hdc, &rect, hbrBk);
+}
+}
+else
+{
+INT old_top = rect.top;
+rect.top = rightBar;
+FillRect(hdc, &rect, hbrBar);
+rect.bottom = rect.top;
+rect.top = old_top;
+FillRect(hdc, &rect, hbrBk);
+}
}
else
{
-INT old_right = rect.right;
-rect.right = rightBar;
-FillRect(hdc, &rect, hbrBar);
-rect.left = rect.right;
-rect.right = old_right;
-FillRect(hdc, &rect, hbrBk);
+if (dwStyle & PBS_MARQUEE)
+{
+INT old_left, old_right;
+old_left = rect.left;
+old_right = rect.right;
+
+leds = rect.right - rect.left;
+ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds;
+rect.right = rect.left;
+
+if(ledMStart > 0)
+{
+rect.right = min(rect.left + ledMStart, old_right);
+FillRect(hdc, &rect, hbrBar);
+rect.left = rect.right;
+}
+if(infoPtr->MarqueePos > 0)
+{
+rect.right = min(old_left + infoPtr->MarqueePos, old_right);
+FillRect(hdc, &rect, hbrBk);
+rect.left = rect.right;
+}
+if(rect.right < old_right)
+{
+rect.right = min(rect.left + MARQUEE_LEDS, old_right);
+FillRect(hdc, &rect, hbrBar);
+rect.left = rect.right;
+}
+if(rect.right < old_right)
+{
+rect.right = old_right;
+FillRect(hdc, &rect, hbrBk);
+}
+}
+else
+{
+INT old_right = rect.right;
+rect.right = rightBar;
+FillRect(hdc, &rect, hbrBar);
+rect.left = rect.right;
+rect.right = old_right;
+FillRect(hdc, &rect, hbrBk);
+}
}
} else {
if (dwStyle & PBS_VERTICAL) {
-while(rect.bottom > rightBar) {
-rect.top = rect.bottom - ledWidth;
-if (rect.top < rightMost)
-rect.top = rightMost;
-FillRect(hdc, &rect, hbrBar);
-rect.bottom = rect.top;
-rect.top -= LED_GA
(Quite) Slow Starcraft
It is now really *slow*, but a quite old 2d game such as starcraft that runs perfectly in a PII 300 under windows should also run perfectly on linux with an AMD64 3200 :-) It happens that using the nasty DGA hack on sourceforge.net/projects/starcraft-wine applied by hand to current cvs it does run (as root) perfectly. but even if X11 is a sucky architecture for games it should run perfectly too with accelerated X11+XShm. Instead it happens that *sometimes* it runs fast (as with DGA), and sometimes it becomes unacceptably slow (for little time, though). I started to give a look at wine source to understand why this strange thing happens, but i fould no place where DGA and X11 code paths could differ in this way... maybe with x11 there are such things as an additionl wine thread or boh... maybe you wine hackers are already aware of similar problems, or may help me to understand what's up (and i would like possibly to help fix it). Thanx Please CC monge(at)sns(dot)it as i'm not subscribed. -- Best Regards Maurizio Monge "..the triumph of evil is for good men to do nothing." (Edmond Burke)
Re: dinput.dll: mouse didn't work
Am Samstag, den 24.07.2004, 22:50 +0200 schrieb Lionel Ulmer: > > And later when pressing a mouse button: > > > > trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 > > wp 200 lp 4071d074 > > > > But then there is no other dinput message. Shouldn't there be a call of > > the mouse callback function? > > There should, yeah But the way this works is that the event code is > sending a message (via the server) to the thread which registered the hook > via the DInput code. Now if that thread does not do any wait on any message, > the message will time-out and the event will be lost (I had this issue with > a game). Are keyboard and mouse handled within the same thread? > You could check by pressing a key to see if the keyboard low level hook is > actually called or not. Yes, KeyboardCallback is called with every key stroke. > By the way, could I know which game exhibits this problem and if I could > download it to be able to debug on my box ? The games are called "Robin Hood – The Legend of Sherwood" and "Desperados - Wanted Death or Alive". Demos are available but I don't have the links handy. Bye, Michael
Re: Is bugzilla worth keeping?
I talked to Dimi, Lionel and Alexandre on IRC about this. This is what they had to say: Lionel didn't think it should be scrapped however he proposed a system whereby bugs that didn't have any activity for two releases or more would be automatically closed. If you wanted to keep a bug open users would have to post reports of behaviour with current releases. Dimi thought it should be kept as well, but thought the UI could be improved a lot: for instance a mail based interface would be good. He also thought a dedicated triage guy would be great. Realistically though that's not likely to happen anytime soon. Alexandre basically agreed with this view, I think. I don't have a strong opinion either which way ... I used to read wine-bugs back when I worked only as a volunteer but usually people come into IRC with apps they'd like to get working and I tended to do that instead. I still do IRC "app on demand" type bugfixing occasionally :) thanks -mike
Re: rsabase unit tests
Am Sonntag, 25. Juli 2004 13:56 schrieben Sie: > Michael Jung wrote: > >Greetings, > >Michael > > > >Changelog: > > Added unit tests for CPGenRandom API function of rsabase.dll > > You seem to be working on Crypto stuff, so I thought I'd better tell you > that I've got a patch pending that implements half of the functionality > in rsabase. > > Rob Thanks for the information. Indeed I've been working on rsabase.dll. When do you plan to submit your patch? I would like to see if at least some of my code can be incorporated, or if the work was in vain. Michael
Re: location of mouse, scroll wheel handling
Hi, On Sat, Jul 24, 2004 at 04:36:18PM -0500, James Hawkins wrote: > Does anyone know where most of the mouse and scroll wheel actions are > being handled in the code? For example, say I am surfing the internet > with Internet Explorere and WINE and I use my scroll wheel to move the > page up and down. Where is the code that handles that? If anyone has > any ideas whatsoever (or even if you can just say you don't know) I > would really appreciate it. Grep the Wine tree for the *WHEEL* defines in include/winuser.h (WM_MOUSEWHEEL etc.) Andreas Mohr
Re: how can I find what functions a dll file provides?
Hi, On Sat, Jul 24, 2004 at 05:11:18PM -0500, James Hawkins wrote: > In what way can I list the API functions provided from a certain dll > file? I seem to remember seeing somewhere that you could use a > debugger, but I'm not sure. wine/tools/winedump/ (now even with 16bit NE file support) Greetings, Andreas Mohr
Re: Marshalling tutorial
ons, 14.07.2004 kl. 18.07 skrev Mike Hearn: > You might be wondering about putting threads next to processes and > machines in that last paragraph. You can access thread safe objects from > multiple threads without DCOM normally, right? Why would you need RPC > magic to do that? The answer is of course that COM doesn't assume that objects actually are thread-safe. Most real-world objects aren't, in fact, for various reasons. What these reasons are isn't too important here, though, it's just important to realize that the problem of thread-unsafe objects is what COM tries hard to solve with its apartment model. There are also ways to tell COM that your object is truly thread-safe (namely the free-threaded marshaller). In general, no object is truly thread-safe if it could potentially use another not so thread-safe object, though, so the free-threaded marshaller is less used than you'd think. > The backbone of DCOM is this RPC runtime, which is an implementation of > DCE RPC [1]. DCE RPC is not naturally object oriented, so this protocol > is extended with some new constructs and by assigning new meanings to > some of the packet fields, to produce ORPC or Object RPC. You might see > it called MS-RPC as well. I think MS-RPC refers to MS's implementation of DCE RPC (i.e. RPCRT4.dll), and possibly their API and extended IDL syntax. This is not the same concept as ORPC. You can have MS-RPC without ORPC, and, with some effort and wizardry, vice versa. It's just that the two work best together, as that's what they're designed to do. > COM PROXY/STUB SYSTEM > > COM proxies are objects that implement both the interfaces needing to be > proxied and also IRpcProxyBuffer. Likewise, COM stubs implement > IRpcStubBuffer and understand how to invoke the methods of the requested > interface. > > You may be wondering what the word "buffer" is doing in those interface > names. I'm not sure either, except that a running theme in DCOM is that > interfaces which have nothing to do with buffers have the word Buffer > appended to them, seemingly at random. Ignore it and *don't let it > confuse you* :) This stuff is convoluted enough ... The primary functionality of objects exposing IRpcProxyBuffer and IRpcStubBuffer does involve marshalling into and unmarshalling from a RPC buffer, if that helps. Their primary methods also get passed IRpcChannelBuffer instances, which allows them to transmit and receive RPC buffers. So they have *something* to do with buffers, at least, even though it's not in the way the interface names suggest. > Once CreateProxy has been called, the resultant object is QId to > IRpcProxyBuffer, which only has 1 method, IRpcProxyBuffer::Connect [4] > This method only takes one parameter, the IRpcChannelBuffer object which > encapsulates the "RPC Channel" between the client and server. Perhaps you should spell out "QueryInterface-d", instead of saying "QId". > RPC CHANNELS > > Remember the RPC runtime? Well, that's not just responsible for > marshalling stuff, it also controls the connection and protocols between > the client and server. We can ignore the details of this for now, > suffice it to say that an RPC Channel is a COM object that implements > IRpcChannelBuffer, and it's basically an abstraction of different RPC > methods. For instance, in the case of inter-thread marshalling (not > covered here) the RPC connection code isn't used, only the NDR > marshallers are, so IRpcChannelBuffer in that case isn't actually > implemented by RPCRT4 but rather just by the COM/OLE DLLS (fixme: is > this actually correct?). It depends on the Windows version, I think. Windows 95 and Windows NT 4 certainly had very different models when I looked. I'm pretty sure the Windows 98 version of RPCRT4 was able to dispatch messages directly to individual apartments. I'd be surprised if some similar functionality was not added to Windows 2000. After all, if an object on machine A wanted to use an object on machine B in an apartment C, wouldn't it be most efficient if the RPC system knew about apartments and could dispatch the message directly to it? And if RPC does know how to efficiently dispatch to apartments, why should COM duplicate this functionality? There were, however, no unified way to tell RPC about them across Windows versions, so in that old patch of mine, I let the COM/OLE dlls do the apartment dispatch, but even then, the RPC runtime was always involved. After all, it could be quite tricky to tell whether the call is merely interthread, without involving the RPC runtime... > In the case of InstallShield, it actually comes with typelibs for all > the interfaces it needs to marshal (fixme: is this right?), but they > actually use a mix of MIDL and typelib marshalling. Yes, it's right, but as you mentioned, typelibs cannot encode all the information in the original IDL. InstallShield uses MIDL marshallers for the interfaces which cannot be represented perfectly by a type library. (You could of course ask wh
