RE: iostream and msvcrt?
Hi Boaz, Have been off the case for a few days. Is it possible for you to post a copy of your stl_wine.h, stlcomp.h and makefile? I seem to be missing something as I cant get it to work. thanks, Scott. > -Original Message- > From: Boaz Harrosh [SMTP:[EMAIL PROTECTED] > Sent: Sunday, 22 August 2004 22:18 > To: Scott Snell > Cc: Dimitrie O. Paun; Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > You need to have your stlport/config/stl_wine.h (I based mine on > stl_mycomp.h, not stl_gcc.h) and change /stlport/config/stlcomp.h to > include it (based on a WINE_GCC flag). You need to do that because of > the way STLPort works with headers. you must put a path that will > Definitely select wine/msvcrt as the source of stdc. I used ../msvcrt in > the header and than Just fixed up the -I list in makefiles (and the > WINE_GCC flag or is there a flag that is defined by wingcc). > > Free Life > Boaz >
CryptSetProviderExA fix
Hi,
I'll start off by explaining how the Cryptographic Service
Providers are stored in the registry. A lot of advapi32 CSP functions
can accept a provider name sent in to use that provider, or advapi32
can use the default provider which is located in the registry at:
HKLM\Software\Microsoft\Cryptography\Defaults\
Listed under the Provider\ key are the keys of the different providers
available on the computer. Each provider has a non-unique provider
type associated with it, and several providers may be of the same
provider type. These types are listed under the 'Provider Types' key
which is itself under 'Defaults\'. The keynames are of the form 'Type
XXX' where XXX is the numeric value of the type. These keys under
'Provider Types\' assign the default provider that is to be used for
each type. The 'Name' value associates each type with the
corresponding provider default that is used with this type. It is
essential that the 'TypeName' registry of each provider type remain in
the registry, because it is only inserted once when the dll is
registered. It is acceptable if the 'Name' value is removed, and this
should happen when CryptSetProviderEx is called with the
CRYPT_DELETEDEFAULT flag.
This is the code that handles the CRYPT_DELETEFLAG in the current
implementation of CryptSetProviderExA:
if (dwFlags & CRYPT_DELETE_DEFAULT)
{
if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags &
CRYPT_USER_DEFAULT)) )
CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY);
RegDeleteKeyA( (dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER :
HKEY_LOCAL_MACHINE, keyname);
CRYPT_Free(keyname);
return TRUE;
}
The important line to look as is the RegDeleteKeyA call. This call
removes the entire 'Type XXX' key from the registry. The next time a
call is made to CryptSetProviderEx to set the default provider and not
remove it, the call will fail because of the next line:
if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags &
CRYPT_USER_DEFAULT)) )
CRYPT_GetTypeKeyName uses the dwProvType parameter to search the
registry for the particular 'Type XXX' key that matches the provider
type, but this call fails because when we last called
CryptSetProviderExA with the CRYPT_DELETEDEFAULT flag, the entire
'Type XXX' key was removed.
The proper fix for this, and the way windows handles it, is to just
remove the 'Name' value from the 'Type XXX' key if the
CRYPT_DELETEDEFAULT flag is sent in. This way the required 'TypeName'
will never be removed, and the next call can set the default provider.
If you would like to look at the already patched version, I'll attach
it along with the patch. Thankyou for taking the time to look this
over. If there are problems with the patch, please let me know so we
can get this committed.
--
James Hawkins
patched_cspe
Description: Binary data
Index: dlls/advapi32/crypt.c
===
RCS file: /home/wine/wine/dlls/advapi32/crypt.c,v
retrieving revision 1.50
diff -u -r1.50 crypt.c
--- dlls/advapi32/crypt.c 20 Aug 2004 19:25:35 - 1.50
+++ dlls/advapi32/crypt.c 23 Aug 2004 06:50:01 -
@@ -1697,7 +1697,7 @@
*/
BOOL WINAPI CryptSetProviderExA (LPCSTR pszProvName, DWORD dwProvType, DWORD *pdwReserved, DWORD dwFlags)
{
- HKEY hKey;
+ HKEY hProvKey, hTypeKey;
PSTR keyname;
TRACE("(%s, %ld, %p, %08ld)\n", pszProvName, dwProvType, pdwReserved, dwFlags);
@@ -1709,31 +1709,35 @@
if (dwFlags & ~(CRYPT_MACHINE_DEFAULT | CRYPT_USER_DEFAULT | CRYPT_DELETE_DEFAULT)
|| dwFlags == CRYPT_DELETE_DEFAULT)
CRYPT_ReturnLastError(NTE_BAD_FLAGS);
-
- if (dwFlags & CRYPT_DELETE_DEFAULT)
- {
- if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & CRYPT_USER_DEFAULT)) )
- CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY);
- RegDeleteKeyA( (dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE, keyname);
- CRYPT_Free(keyname);
- return TRUE;
- }
-
- if ( !(keyname = CRYPT_GetProvKeyName(pszProvName)) )
+
+ if (!(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & CRYPT_USER_DEFAULT)))
CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY);
- if (RegOpenKeyA(HKEY_LOCAL_MACHINE, keyname, &hKey))
+ if (RegOpenKeyA((dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE,
+ keyname, &hTypeKey))
{
CRYPT_Free(keyname);
CRYPT_ReturnLastError(NTE_BAD_PROVIDER);
}
CRYPT_Free(keyname);
- RegCloseKey(hKey);
- if ( !(keyname = CRYPT_GetTypeKeyName(dwProvType, dwFlags & CRYPT_USER_DEFAULT)) )
- CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY);
- RegCreateKeyA( (dwFlags & CRYPT_USER_DEFAULT) ? HKEY_CURRENT_USER : HKEY_LOCAL_MACHINE, keyname, &hKey);
- CRYPT_Free(keyname);
- if (RegSetValueExA(hKey, "Name", 0, REG_SZ, pszProvName, strlen(pszProvName) +1))
- return FALSE;
+
+ if (dwFlags & CRYPT_DELETE_DEFAULT)
+ RegDeleteValueA(hTypeKey, "Name");
+ else
+ {
+ if (!(keyname = CRYPT_GetProvKeyName(pszProv
Re: poll vs. epoll
Shachar Shemesh wrote: Now don't go and do level-triggered stuff just because it's easier :-) That's not it at all, and edge vs. level is not part of my considerations. Libevent does support a wider variety of selection interfaces, and with wider platform support, than your library. Don't get me wrong. Libevent is good stuff. Niels is a very good guy. I don't think platform support is an issue (which platform do you need?) The one interface rn is missing, I think, is a timer. Buffered events would be a fine addition, too. But rn has the basic notification stuff; it was intended to focus on those. I don't think it's fair to say level-triggered is ideal for wineserver. In fact, wineserver is an example of the kind of program that is easier to convert to edge-triggering than most programs, since it's small and self-contained. Can you give benchmarks for performance differences between the two? The essential difference is that level-triggered means more notifications coming from kernel space, which always means higher overhead. The difference is going to be slight. I have also noticed that in some situations where the interest mask is hard to compute, using edge triggered is much easier, because you never have to compute it. The more I think about it, the more I'm getting the impression that going edge trigger means we need to maintain our own cache of not-yet-useful data The same cache is maintained in the kernel for you if you use level triggering. as well as risking starvation. There is no risk of starvation in a properly written program. Also, can you show me how to do edge trigger via poll? There is no need for that, since Linux and *BSD all support some form of edge-triggered notification. However, if we want to support ancient operating systems, it wouldn't be too hard to add poll() support to rn under the covers, and present the edge-triggered interface to the user. I'll qualify the starvation claim. Suppose we have five fds we are watching. Suppose one (let's call it "3") of them is really really intensive in it's request rate. Using the current interface (as used in the preliminary patch I sent), each time we call epoll we will see that 3 is active, but any time any other fd has anything to do, it will be handled. Suppose we go edge triggered now. We call epoll, and it's likely that 3 will be the only one active. We will call the 3 handling function, which will try to exhaust the requests arriving on 3 before returning. No it's a problem - requests potentially are never exhausted on 3. When do we exit the handler to do other stuff? We would need to write some mechanism to introduce this fairness ourselves. Yes, but that's easy. It's about four lines of code. In short, if you are going edge trigger, your relative scheduling priority is your responsibility, as well as keeping all partial memory buffered. With level trigger, the kernel does that for you. What's this about partial memory buffering? Sounds like you're inventing a difficulty here. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change
Re: poll vs. epoll
Dan Kegel wrote: Shachar Shemesh wrote: It doesn't compile (rn.c is not including ). When I fix that, it checks whether epoll_create works. If it does, it sets all handlers to use sigio. I don't think this library is quite stable enough :-) You're a tough customer :-) It's quite close; guess I should polish it up a bit. In any case, it seems that it's interface is not ideal for wineserver. Libevent, on the other hand.. Now don't go and do level-triggered stuff just because it's easier :-) That's not it at all, and edge vs. level is not part of my considerations. Libevent does support a wider variety of selection interfaces, and with wider platform support, than your library. I don't think it's fair to say level-triggered is ideal for wineserver. In fact, wineserver is an example of the kind of program that is easier to convert to edge-triggering than most programs, since it's small and self-contained. Can you give benchmarks for performance differences between the two? The more I think about it, the more I'm getting the impression that going edge trigger means we need to maintain our own cache of not-yet-useful data, as well as risking starvation. I'm sure there are cases where this is preferable, but can you explain why this is such a case? Also, can you show me how to do edge trigger via poll? Sigh. I wish my wrists were in better shape; I'd convert it myself. As it is, he who does the work gets to choose interfaces. - Dan I'll qualify the starvation claim. Suppose we have five fds we are watching. Suppose one (let's call it "3") of them is really really intensive in it's request rate. Using the current interface (as used in the preliminary patch I sent), each time we call epoll we will see that 3 is active, but any time any other fd has anything to do, it will be handled. Suppose we go edge triggered now. We call epoll, and it's likely that 3 will be the only one active. We will call the 3 handling function, which will try to exhaust the requests arriving on 3 before returning. No it's a problem - requests potentially are never exhausted on 3. When do we exit the handler to do other stuff? We would need to write some mechanism to introduce this fairness ourselves. In short, if you are going edge trigger, your relative scheduling priority is your responsibility, as well as keeping all partial memory buffered. With level trigger, the kernel does that for you. Is there any reason to assume that we can do that better than the kernel? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: poll vs. epoll
Shachar Shemesh wrote: It doesn't compile (rn.c is not including ). When I fix that, it checks whether epoll_create works. If it does, it sets all handlers to use sigio. I don't think this library is quite stable enough :-) You're a tough customer :-) It's quite close; guess I should polish it up a bit. In any case, it seems that it's interface is not ideal for wineserver. Libevent, on the other hand.. Now don't go and do level-triggered stuff just because it's easier :-) I don't think it's fair to say level-triggered is ideal for wineserver. In fact, wineserver is an example of the kind of program that is easier to convert to edge-triggering than most programs, since it's small and self-contained. Sigh. I wish my wrists were in better shape; I'd convert it myself. As it is, he who does the work gets to choose interfaces. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change
Re: Info on debugging requested: trying to run "Hearts of Iron"
On Fri, 2004-08-20 at 12:00, Simon Kitching wrote: > > > > Any suggestions on how to make progress on this issue are welcome. > > If a relay trace doesn't help, then the next thing would be to disas > > surrounding code at 0x004191fb and walk back the code flow to find out > > where the NULL %ecx was coming from. > > > I have some good news anyway. I still can't load the games I saved > earlier. But I tried starting a new game, and can load/save happily. So > the possibilities are: > (a) that the problem was caused by a corrupt save-file being *created* > when running with the debian wine release (Version: 0.0.20040615-1), and > that now I am running with wine CVS HEAD, games are being saved > properly. > (b) that there is a bug in HoI, and that the saved game wouldn't have > loaded on Windows anyway. I will test this theory soon by taking the > save-game to a friend with a Windows copy and see what happens. It would > be truly bad luck to strike an HoI bug the first time I try to run it > under Wine, but stranger things have happened. > (c) that the bug is wine-related, but only pops up sometimes. I can test > this by playing a lot more games, and seeing if it happens again. > > > So for now, I'm going to suspend the wine debugging, and do some more > playing instead :-) Just to end this thread, I have done some more "testing" :-) and the issue with being unable to load saved games has not reappeared. I still don't know which of the above theories was correct, but don't care now - it all "just works" (tm). Thanks for the cool software. Simon
Hearts of Iron on Wine
Hi All, I just wanted to let you all know that I have now given the game "Hearts of Iron" a good testing on Wine (no windows partition) and it works *extremely* well; only a few minor issues on startup, all with simple workarounds. I've submitted an entry to the app database for this. What is more interesting, though, is that the developer (Paradox Entertainment) and publisher (Strategy First) are releasing: (a) Hearts of Iron "Platinum Edition" in September 2004 (b) Hearts of Iron 2 in "Q4 2004/Q1 2005". As Wine runs HoI so very well, I thought it might be worth someone contacting Paradox to see if they would be willing to pay the Wine team for the final minor issues with HoI/wine to be resolved, and maybe to provide support for HoI 2 on Wine. Just a thought See: http://www.paradoxplaza.com/heartsofiron.asp http://www.paradoxplaza.com/heartsofiron2.asp http://www.gamespot.com/pc/strategy/heartsofiron/news_6103237.html Cheers, Simon
Re: check box in group box regression
Zach Gorman wrote: Does it matter whether the check box is before or after the group box in the Z-order? Does the group box obscure any other controls? If you move the check box so it is half-in and half-out of the group box, for example, does only half of it get cut off? Zach -Original Message- From: Robert Reif [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 7:01 PM To: Zach Gorman Cc: [EMAIL PROTECTED] Subject: Re: check box in group box regression Zach Gorman wrote: Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html It is a real problem that I was able to reproduce with a simple program. It's just a simple MFC program. I don't have the source with me now but all it does is set the wait cursor in the check box callback, sleep for 5 seconds, and then restore the cursor. The check box is inside a group box. I can get it tomorrow if needed. I just finished compiling cvs and the z order problem is fixed but the wait cursor doesn't change when you move it off the dialog.
Re: check box in group box regression
Zach Gorman wrote: Does it matter whether the check box is before or after the group box in the Z-order? Does the group box obscure any other controls? If you move the check box so it is half-in and half-out of the group box, for example, does only half of it get cut off? Zach -Original Message- From: Robert Reif [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 7:01 PM To: Zach Gorman Cc: [EMAIL PROTECTED] Subject: Re: check box in group box regression Zach Gorman wrote: Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html It is a real problem that I was able to reproduce with a simple program. It's just a simple MFC program. I don't have the source with me now but all it does is set the wait cursor in the check box callback, sleep for 5 seconds, and then restore the cursor. The check box is inside a group box. I can get it tomorrow if needed. The z order problem wasn't there 2 days ago.
RE: check box in group box regression
Does it matter whether the check box is before or after the group box in the Z-order? Does the group box obscure any other controls? If you move the check box so it is half-in and half-out of the group box, for example, does only half of it get cut off? Zach -Original Message- From: Robert Reif [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 7:01 PM To: Zach Gorman Cc: [EMAIL PROTECTED] Subject: Re: check box in group box regression Zach Gorman wrote: >Is this a general problem, or just in the hour.exe example? Is there source >for hour.exe? > >Zach > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Robert Reif >Sent: Tuesday, August 24, 2004 8:02 AM >To: Wine Develop >Subject: check box in group box regression > >With current cvs, check boxes in group boxes are no longer displayed. >See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html > > > > > It is a real problem that I was able to reproduce with a simple program. It's just a simple MFC program. I don't have the source with me now but all it does is set the wait cursor in the check box callback, sleep for 5 seconds, and then restore the cursor. The check box is inside a group box. I can get it tomorrow if needed.
Re: check box in group box regression
Zach Gorman wrote: Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html It is a real problem that I was able to reproduce with a simple program. It's just a simple MFC program. I don't have the source with me now but all it does is set the wait cursor in the check box callback, sleep for 5 seconds, and then restore the cursor. The check box is inside a group box. I can get it tomorrow if needed.
Re: Non-perfect epoll patch
Shachar Shemesh wrote: Hi all, Attached is a non-perfect patch for review. This is a migration of the wineserver to use epoll instead of poll (if it's available). current known issue with this patch: 1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile if epoll not available at compile time) 2. Segfaults on wine exit. 3. Lots of debug asserts. Comments welcome. Shachar One more thing. I don't think it matters much, but this patch is against 20040716. -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Non-perfect epoll patch
Hi all,
Attached is a non-perfect patch for review. This is a migration of the
wineserver to use epoll instead of poll (if it's available).
current known issue with this patch:
1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile
if epoll not available at compile time)
2. Segfaults on wine exit.
3. Lots of debug asserts.
Comments welcome.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
Index: configure
===
RCS file: /home/sun/sources/cvs/wine/configure,v
retrieving revision 1.573
diff -u -r1.573 configure
--- configure 17 Jul 2004 00:52:37 - 1.573
+++ configure 24 Aug 2004 12:03:32 -
@@ -6727,6 +6727,79 @@
fi
+echo "$as_me:$LINENO: checking for epoll_create in -lepoll" >&5
+echo $ECHO_N "checking for epoll_create in -lepoll... $ECHO_C" >&6
+if test "${ac_cv_lib_epoll_epoll_create+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ ac_check_lib_save_LIBS=$LIBS
+LIBS="-lepoll $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+/* Override any gcc2 internal prototype to avoid an error. */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char epoll_create ();
+int
+main ()
+{
+epoll_create ();
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+ (eval $ac_link) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+{ ac_try='test -z "$ac_c_werror_flag" || test ! -s
conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+{ ac_try='test -s conftest$ac_exeext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ac_cv_lib_epoll_epoll_create=yes
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_epoll_epoll_create=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+ conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_epoll_epoll_create" >&5
+echo "${ECHO_T}$ac_cv_lib_epoll_epoll_create" >&6
+if test $ac_cv_lib_epoll_epoll_create = yes; then
+ cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBEPOLL 1
+_ACEOF
+
+ LIBS="-lepoll $LIBS"
+
+fi
+
+
echo "$as_me:$LINENO: checking for res_9_init in -lresolv" >&5
echo $ECHO_N "checking for res_9_init in -lresolv... $ECHO_C" >&6
if test "${ac_cv_lib_resolv_res_9_init+set}" = set; then
@@ -16190,6 +16263,7 @@
+
for ac_func in \
_lwp_create \
_lwp_self \
@@ -16202,6 +16276,7 @@
_vsnprintf \
chsize \
clone \
+epoll_create \
finite \
fpclass \
fstatfs \
@@ -16435,6 +16510,7 @@
+
for ac_header in \
arpa/inet.h \
arpa/nameser.h \
@@ -16495,6 +16571,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: configure.ac
===
RCS file: /home/sun/sources/cvs/wine/configure.ac,v
retrieving revision 1.285
diff -u -r1.285 configure.ac
--- configure.ac6 Jul 2004 21:01:19 - 1.285
+++ configure.ac24 Aug 2004 12:01:22 -
@@ -140,6 +140,8 @@
AC_CHECK_LIB(xpg4,_xpg4_setrunelocale)
dnl Check for -lpoll for Mac OS X/Darwin
AC_CHECK_LIB(poll,poll)
+dnl Check for -lepoll
+AC_CHECK_LIB(epoll,epoll_create)
dnl Check for -lresolv for Mac OS X/Darwin
AC_CHECK_LIB(resolv,res_9_init)
dnl Check for -lpthread
@@ -1036,6 +1038,7 @@
_vsnprintf \
chsize \
clone \
+epoll_create \
finite \
fpclass \
fstatfs \
@@ -1146,6 +1149,7 @@
sys/msg.h \
sys/param.h \
sys/poll.h \
+ sys/epoll.h \
sys/ptrace.h \
sys/reg.h \
sys/scsiio.h \
Index: include/config.h.in
===
RCS file: /home/sun/sources/cvs/wine/include/config.h.in,v
retrieving revision 1.190
diff -u -r1.190 config.h.in
--- include/config.h.in 18 Jun 2004 19:36:26 - 1.190
+++ include/config.h.in 24 Aug 2004 12:05:42 -
@@ -80,6 +80,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_ELF_H
+/* Define to 1 if you have the `epoll_create' function. */
+#undef HAVE_EPOLL_CR
Re: Wine Emulation: Swapping functions
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes: > Hi Alexandre, > > This patch allows to load a PE exe to memory. You may notice that > there is no "mass" byte swapping. The technics used here is a bit > developer here: > http://stegefin.free.fr/wine/ > You might prefer a more conventional way of doing the byte swapping, > in this case tell me. We might still need this approach since it could > efficient for sharing data accross the LE exe and the BE winelib. It doesn't seem very efficient to trap on every memory access... Besides, I don't see how this can possibly work, there is no guarantee that the compiler is going to generate accesses that always match the size of the requested type, memcpy() being the obvious example. I think you are going in the wrong direction with this; the right way IMO is to compile Wine for x86 and run the whole Wine+app under the CPU emulator. Otherwise you'll have to write wrappers for each of the 15,000 APIs. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DbgHelp: Fix for Includes with Relative Paths
Eric Pouech wrote:
Robert Shearman a écrit :
How does the attached patch look?
better, but you should to nuke srcpath (and no longer currpath) in
N_SO case, when *ptr is '\0' (it's defensive code, so it shouldn't
harm on normally formed stabs file). As a side effect, you don't need
also to memset currpath to 0 at the beginning of func
Is the attached patch correct?
Rob
Index: wine/dlls/dbghelp/stabs.c
===
RCS file: /home/wine/wine/dlls/dbghelp/stabs.c,v
retrieving revision 1.8
diff -u -p -r1.8 stabs.c
--- wine/dlls/dbghelp/stabs.c 23 Aug 2004 17:56:07 - 1.8
+++ wine/dlls/dbghelp/stabs.c 24 Aug 2004 20:49:54 -
@@ -1085,8 +1085,8 @@ SYM_TYPE stabs_parse(struct module* modu
struct symt_function* curr_func = NULL;
struct symt_block* block = NULL;
struct symt_compiland* compiland = NULL;
-charcurrpath[PATH_MAX];
-charsrcpath[PATH_MAX];
+charcurrpath[PATH_MAX]; /* path to current file */
+charsrcpath[PATH_MAX]; /* path to directory source file
is in */
int i, j;
int nstab;
const char* ptr;
@@ -1108,7 +1108,6 @@ SYM_TYPE stabs_parse(struct module* modu
stab_ptr = (const struct stab_nlist*)(addr + staboff);
strs = (const char*)(addr + strtaboff);
-memset(currpath, 0, sizeof(currpath));
memset(srcpath, 0, sizeof(srcpath));
memset(stabs_basic, 0, sizeof(stabs_basic));
@@ -1377,7 +1376,7 @@ SYM_TYPE stabs_parse(struct module* modu
if (*ptr == '\0') /* end of N_SO file */
{
/* Nuke old path. */
-currpath[0] = '\0';
+srcpath[0] = '\0';
stabs_finalize_function(module, curr_func);
curr_func = NULL;
source_idx = -1;
@@ -1387,20 +1386,17 @@ SYM_TYPE stabs_parse(struct module* modu
}
else
{
-stabs_reset_includes();
-if (*ptr != '/')
+int len = strlen(ptr);
+if (ptr[len-1] != '/')
{
strcpy(currpath, srcpath);
strcat(currpath, ptr);
+stabs_reset_includes();
compiland = symt_new_compiland(module, currpath);
source_idx = source_new(module, currpath);
}
else
-{
strcpy(srcpath, ptr);
-compiland = symt_new_compiland(module, srcpath);
-source_idx = source_new(module, srcpath);
-}
}
break;
case N_SOL:
Re: poll vs. epoll
Shachar Shemesh wrote: Dan Kegel wrote: By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. That's fine, except that compiling your library on a machine that has epoll, and then trying to run it on a machine without will not work. It will not load if runtime glibc doesn't have epoll. I'm using "syscall" to work around that problem in wine. Compile time detection is insufficient. My code is at http://kegel.com/rn Sure will have a look. It doesn't compile (rn.c is not including ). When I fix that, it checks whether epoll_create works. If it does, it sets all handlers to use sigio. I don't think this library is quite stable enough :-) In any case, it seems that it's interface is not ideal for wineserver. Libevent, on the other hand.. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: DbgHelp: Fix for Includes with Relative Paths
Robert Shearman a écrit : How does the attached patch look? better, but you should to nuke srcpath (and no longer currpath) in N_SO case, when *ptr is '\0' (it's defensive code, so it shouldn't harm on normally formed stabs file). As a side effect, you don't need also to memset currpath to 0 at the beginning of func A+
Re: CreateRemoteThread and related stuff (patch)
Robert Shearman <[EMAIL PROTECTED]> writes: > Mike Hearn wrote: > >> Ick. That sounds really really complicated. I'd be tempted to go for >> bringing back the service thread but I wasn't around when it was >> busy causing pain so maybe I sound a bit blase about that :) > > Perhaps the old-timers can tell us a story around the camp fire about > this... The main problem with a service thread is that it basically turns all apps into multi-threaded apps whether they expect it or not, so it creates various synchronization issues (for instance apps suddenly start to receive DLL_THREAD_ATTACH notifications they don't expect, things like that). And of course it also uses more resources (stack space etc.); this is acceptable for apps that actually use the feature, but we don't want to penalize all apps to support such an uncommon case. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DbgHelp: Fix for Includes with Relative Paths
Eric Pouech wrote:
which means that:
- we create a new compilation unit (for example) on 2205 => this gives
the source directory
- we start the main compilation unit on 2206 =>
/home/dm/wine/dlls/dbghelp/elf_module.c
- in this CU, we start a new include file (on ), =>
/home/dm/wine/dlls/dbghelp/../../include/winbase.h
- ...
- we close the CU on 4978
Basically, as I wrote, you don't need two different beasts: currpath
and srcpath. They refer to the same object, but the code is wrong.
We should:
- store the current directory on first SO (or the SO ended by a '/',
which would be better)
- on a non NULL SO, not ended by a '/' create a new compilation unit
by concatening curr dir and the file name (or if file name is
absolute, use the filename)
- for each SOL, get the file name by concatening the curr dir with the
file name (this operation is the same as above).
- nuke the curr dir when getting a NULL SO
current code is wrong as it creates two compilands for each
compilation unit (one for each non NULL SO)
How does the attached patch look?
Rob
Index: wine/dlls/dbghelp/stabs.c
===
RCS file: /home/wine/wine/dlls/dbghelp/stabs.c,v
retrieving revision 1.8
diff -u -p -r1.8 stabs.c
--- wine/dlls/dbghelp/stabs.c 23 Aug 2004 17:56:07 - 1.8
+++ wine/dlls/dbghelp/stabs.c 24 Aug 2004 17:33:07 -
@@ -1085,8 +1085,8 @@ SYM_TYPE stabs_parse(struct module* modu
struct symt_function* curr_func = NULL;
struct symt_block* block = NULL;
struct symt_compiland* compiland = NULL;
-charcurrpath[PATH_MAX];
-charsrcpath[PATH_MAX];
+charcurrpath[PATH_MAX]; /* path to current file */
+charsrcpath[PATH_MAX]; /* path to directory source file
is in */
int i, j;
int nstab;
const char* ptr;
@@ -1387,20 +1387,17 @@ SYM_TYPE stabs_parse(struct module* modu
}
else
{
-stabs_reset_includes();
-if (*ptr != '/')
+int len = strlen(ptr);
+if (ptr[len-1] != '/')
{
strcpy(currpath, srcpath);
strcat(currpath, ptr);
+stabs_reset_includes();
compiland = symt_new_compiland(module, currpath);
source_idx = source_new(module, currpath);
}
else
-{
strcpy(srcpath, ptr);
-compiland = symt_new_compiland(module, srcpath);
-source_idx = source_new(module, srcpath);
-}
}
break;
case N_SOL:
Re: CreateRemoteThread and related stuff (patch)
Alexander Yaworsky wrote: Hello Well, not quite. You can open another handle to the process using DuplicateHandle or something else, so you need to go via the server. The simplest way to do this using Win32 is: if (GetProcessId(handle) == GetCurrentProcessId()) You miss. It seems we really need __wine_is_current_process. Sorry, GetProcessId is not available in Wine yet. I'll submit a patch to add it. Is it really necessary to perform the action required for remote invocation of some operation asynchronously? It seems to add a lot of unneeded complexity. What shall we do with csVirtual critical section in ntdll/virtual.c? Ah, I see now. We may need to make server calls while in the remote process and they will hang unless the "remote operation call" is done asynchronously. Rob
RE: check box in group box regression
Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Alexander Yaworsky wrote: I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Hi Alexandre, Your patch is very large. It's difficult to find regressions in large patches, and it's difficult to review as so much code is changed. It may be all perfectly correct, but it's not obviously perfectly correct :) I'd suggest that you resubmit the patch and break it up into smaller chunks, so that as much as possible, each one is easy to review and makes a small understandable, atomic and necessary change. Test cases also help, if you can write them. From the looks of things your patch is well researched, and you understand what you're doing. If you submit your work in smaller chunks, I'm pretty sure it will be accepted. Mike
check box in group box regression
With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
Well, apparently we don't use sched_yield, so the problem must lie somewhere else. Maybe Con can help us out here? Alexandre says he doesn't know what the issue is either and somebody needs to investigate. I guess we do need to concern ourselves over the details :) Interesting. Probably the most valuable information is that it seems to work fine if we artificially limit the threads to exactly the same timeslice _or_ we put them at such a low priority that they are forced to be guaranteed to round robin one task at a time. This is the way 2.4 used to work which is why with the new 2.6 schedulers which do far more out-of-order rescheduling some applications have a problem; particularly under load. I suspect it's actually the latter issue. Locking between threads should prevent that being a problem, though. You already mentioned that you dont use sched_yield() and I couldn't even begin to look at the wine code myself so perhaps you know something more. Hi Con, One thought that occurred to me, and this is just a random theory, is that maybe the issue is not with the Wine code but the Win32 code run on top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows (NT) scheduling? Could it be that some apps are written to expect Windows-style scheduling and fail to work if they don't get it? In case you hadn't noticed, I'm afraid I only have first-year CS knowledge of scheduling :/ thanks -mike
Re: A new regression
On Tue, Aug 24, 2004 at 09:37:58AM +0100, Mike Hearn wrote: > For those following along, translated that means: fix that works all the > time blocks on the window management 'rewrite' which means we use X > windows only for toplevels. Last I heard this rewrite was about 2-3 > months away from completion but obviously it's not a fixed thing and > could easily take longer. Note that this will break even more all the non-fullscreen OpenGL applications pending adaptation of the GL code to support GL rendering on non-top level windows. >From what I expect, this may not be trivial at all. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Hello > Dont take offence if your patch goes to the void. Just resubmit after a > a week to give it a chance to filter through Alexandre's tree. Its > possible either I merely meant that maybe something wrong with implementation. Well, I will resubmit it soon.
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Steven Edwards wrote: Hi Alexander, --- Alexander Yaworsky <[EMAIL PROTECTED]> wrote: I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Dont take offence if your patch goes to the void. Just resubmit after a a week to give it a chance to filter through Alexandre's tree. Its possible either 1. He is going to merge it and its just taken him a while 2. He rejected it and just forgot to send a note due to the constrants of time. 3. It went to the void in space where the lost patches go. Just resubmit and you should hear something back from someone. Thanks Steven Actually, during the last wineconf, "There's nothing obviously wrong with it, but it makes Alexandre uneasy" for the usual reason patches go to void Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Hi Alexander, --- Alexander Yaworsky <[EMAIL PROTECTED]> wrote: > I even tried to submit a patch but it was silently ignored. Let me > remind about this patch -- > http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe > it will be useful. If you have suggestions, I promise to > rewrite it as required ;)) Dont take offence if your patch goes to the void. Just resubmit after a a week to give it a chance to filter through Alexandre's tree. Its possible either 1. He is going to merge it and its just taken him a while 2. He rejected it and just forgot to send a note due to the constrants of time. 3. It went to the void in space where the lost patches go. Just resubmit and you should hear something back from someone. Thanks Steven __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Re: A new regression
The problem is that the app uses OpenGL for painting, and OpenGL doesn't support the IncludeInferiors clipping mode. Fixing that properly will require getting rid of X windows for child windows, but in the meantime I have added a workaround that should work in most cases. For those following along, translated that means: fix that works all the time blocks on the window management 'rewrite' which means we use X windows only for toplevels. Last I heard this rewrite was about 2-3 months away from completion but obviously it's not a fixed thing and could easily take longer. The reason it's being taken slowly is exactly so these sort of regressions can be shaken out. In the absence of branching it's the only way. thanks -mike
Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
Hello In fact, the existing implementation of service subsystem in advapi32 is very poor and is sufficient only for very simple services or test programs. I tried to launch oracle 7 database under wine and that trial has been failed. The main problem was inability of parameter passing. Not only oracle -- most services require that. I did some improvements. Although I still cannot start database, because its launcher, oradim, requires CreateRemoteThread, the listener service works well (although, it cannot be fully tested because no database instance exists, but there is nothing suspicious in trace logs). I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Also, maybe the diagram shown below will be useful. Thanks. This simplified diagram shows interaction between three main components of win32 service subsystem. Service Control | Service Control Manager | Service Program Program | | +-+- | | StartService-> LockServiceDatabase | | IF OWN_PROCES or | | (SHARE_PROCESS and Service | Program is not running)| | THEN | | | | CreateProcess===> ... | wait for call to | initialization | StartServiceCtrlDispatcher| must not be longer | timeout=30s | than 30 seconds | | ... | if wait timed out then| ... | TerminateProcess | ... failure < UnlockServiceDatabase | ... | | ... | wait satisfied <= StartServiceCtrlDispatcher | | | END IF| | | | CreateThread ***> ServiceMain | (or CreateRemoteThread| ... |for SHARE_PROCESS; |* |if SHARE_PROCESS then|* |find entry in service|** |table by service name; | * |if OWN_PROCESS then use | * |first entry) | * success < UnlockServiceDatabase | * | | * | accept control requests | * | | * ControlService---> request accepted ===> ServiceControlHandler * | | ... * status <- return status <== SetServiceStatus * | | * | | * | |** | |* | | ... | | SetServiceStatus | ExitThread <* (STOPPED) | if Service Program has| | now only one thread | | return control from | | StartServiceCtrlDispatcher==> ... | | ExitProcess legend: --- Service Control Program's thread === Service Program's main thread (control thread) *** Service Program's service thread OWN_PROCESS == SERVICE_WIN32_OWN_PROCESS SHARE_PROCESS == SERVICE_WIN32_SHARE_PROCESS Implementation. completely win32-based Two basic things: a) The only time the service control manager requests ownership of the lock is when it is starting a service. (C) M$DN; b) When StartService creates a new service process, it must pass arguments, or at least argv[0] - the service name - for ServiceMain across process boundary. So, use the existence of shared memory object as lock indicator and the content of object for passing service name. Also we need a wait object for monitoring process startup. The call to StartServiceCtrlDispatcher will satisfy wait condition. A dedicated shared memory object is used for each service thread. It holds other arguments, control requests and status. Also
