More Darwine news (was Re: New Darwine Binary Released)
Sanjay Connare wrote: Hey All, I am proud and happy to announce the release of a new binary labeled Darwine 20040820 DP. This binary is based upon the 20040813 wine release. ... Thought I would post a follow-up as Sanjay neglected to include a link to the new binary: http://darwine.opendarwin.org/ http://sourceforge.net/projects/darwine/ Other Darwine news is that there was an interview with moi on osViews: the article(s) are posted Text: http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=2046 Broadcast: http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=2047 Thank you for your help and support. It is greatly appreciated. I hope this helps bring about increased awareness for the Darwine project. -- Kelly McNeill OSV And perhaps the most interesting news is that Darwine's lead developer Pierre d'Herbemont has sucessfully ported QEMU (fast X86 emulator) to Mac OS X: QEMU on Mac OS X by Pierre d'Herbemont 2004-07-04 at 11:07:13 I am proud to announce that QEMU is now working on Mac OS X. • Original announcement on the qemu-devel list • Download the installer for Mac OS X • Screenshots of QEMU running on Mac OS X • The FreeOSZoo, to download ready-to-run images of QEMU virtual computers, pre-installed with a Free Operating System and a set of popular free software. I would like to thanks Matt Reda for its collaboration. http://www.freeoszoo.org/download.php Jim White
Re: Wrong call convention for SHAllocShared & co?
>Hence my confusion and my call for help. The solution that comes in mind is write a test program and find out. Ivan.
Re: Wrong call convention for SHAllocShared & co?
On Sun, 22 Aug 2004, Ivan Leo Puoti wrote: > > So who's right? The platform SDK that says this is a cdecl function or > > Wine's headers? > If the SDK is wrong and is diffrent from the windows implementation, then > programs calling that function will have > problems bacause of imcompatible headers between the ones used to build windows > and the SDK ones used to build the program, no? Yes and that would seem to indicate that the Platform SDK is correct. However if Wine's implementation is wrong then Windows applications that call this API should crash and we should have noticed, no? So that seems to indicate that Wine's implementation must be correct. Hence my confusion and my call for help. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Re: Wrong call convention for SHAllocShared & co?
> So who's right? The platform SDK that says this is a cdecl function or > Wine's headers? If the SDK is wrong and is diffrent from the windows implementation, then programs calling that function will have problems bacause of imcompatible headers between the ones used to build windows and the SDK ones used to build the program, no? Ivan.
Re: Wrong call convention for SHAllocShared & co?
Still looking in undocshell.h, I see we have: BOOL WINAPI GetFileNameFromBrowse( HWND hwndOwner, LPSTR lpstrFile, DWORD nMaxFile, LPCSTR lpstrInitialDir, LPCSTR lpstrDefExt, LPCSTR lpstrFilter, LPCSTR lpstrTitle); But in the Platform SDK's the prototype is: SHSTDAPI_(BOOL) GetFileNameFromBrowse(HWND hwnd, LPWSTR pszFilePath, UINT cbFilePath,LPCWSTR pszWorkingDir, LPCWSTR pszDefExt, LPCWSTR pszFilters, LPCWSTR pszTitle); So is this an Ansi or a Unicode function? Or maybe it's one of these AW Ansi/Unicode functions? In that case the implementation is wrong because it definitely expects to receive Ansi strings. Same question for PickIconDlg(). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Wrong call convention for SHAllocShared & co?
In the platform SDK's shlobj.h I find: HANDLE _SHAllocShared(LPCVOID pvData, DWORD dwSize, DWORD dwDestinationProcessId); Notice the lack of a WINAPI and the leading underscore. So this would indicate a cdecl API. But in dlls/shell32/undocshell.h I see: HANDLE WINAPI SHAllocShared(LPVOID pv, ULONG cb, DWORD pid); This really looks like the same function, just without the underscore. Furthermore shell32.spec says: 520 stdcall SHAllocShared (long long long) So who's right? The platform SDK that says this is a cdecl function or Wine's headers? There's the same issue for SHFreeShared, SHLockShared and SHUnlockShared. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Re: Re: make CryptSetProviderEx update the provider Name and TypeName to registry
I just ran a test programming in windows to see how the registry is changed by called CryptSetProviderEx with the CRYPT_DELETE_DEFAULT flag. When the CRYPT_DELETE_DEFAULT flag is used, the Name value of the Type XXX key is removed, but not the TypeName, which solves the problem of not being able to get to the TypeName. I will rewrite this patch with the new behavior and send it shortly. On Fri, 20 Aug 2004 13:11:12 -0700, James Hawkins <[EMAIL PROTECTED]> wrote: > I'm working on a test app that I hope wil shine some light on how > windows gets the Name and TypeName values back in the registry after > they've been deleted. The problem is that the only instance of the > Name and TypeName data is in the DllRegisterServer function of the > provider dll. I couldn't think of any other way to get to that data > to get it in the registry, but I will be testing this in windows. > What im thinking is that windows might not even delete the key at all. > If you have any suggestions it would help a lot. > > > > On Fri, 20 Aug 2004 12:48:07 -0700, Alexandre Julliard > <[EMAIL PROTECTED]> wrote: > > James Hawkins <[EMAIL PROTECTED]> writes: > > > > >> Changelog > > >>* Call provider.dll's DllRegisterServer from CryptSetProviderEx to > > >> update the Name and TypeName values in the registry properly when > > >> setting the default provider > > > > It doesn't seem right to call DllRegisterServer from there, IMO it > > should only be called when the dll is installed. Do you have evidence > > that Windows does it this way? > > > > -- > > Alexandre Julliard > > [EMAIL PROTECTED] > > > > > -- > James Hawkins > -- James Hawkins
Re: Optimize Critical Section Functions
Robert Shearman <[EMAIL PROTECTED]> writes: > Yes, I agree. In fact the patch actually decreases performance. > Test: 10,000,000 calls to EnterCriticalSection & LeaveCriticalSection, > simulating fast path on critical sections. > Results: > Win2k - 1000ms > Wine w/ patch - 1346ms > Wine w/o patch - 1294ms > > I think the best way to improve performance of the critical section > functions is to rewrite them in assembly and I will submit a patch > doing so when I have a spare moment. I don't think that's necessary either, unless you have good evidence that the critical section non-contention path represents a significant amount of the total time spent by an application. IMO we have much bigger performance issues to solve first, before we make the critical section code unreadable just to save a couple of cycles. -- Alexandre Julliard [EMAIL PROTECTED]
Re: MS Project 2000 not working in wine.
James Courtier-Dutton wrote: Has anyone got MS Project 2000 working in wine? James I tried it a couple times and get about 80% into the install. It stops at the same spot each time. fixme:powermgnt:SetThreadExecutionState (0x0): stub, harmless. fixme:ntdll:NtAdjustPrivilegesToken (0x4c,0x,0x4055e0e8,0x,(nil),(nil)),stub! I/O operation aborted Tom
Re: Optimize Critical Section Functions
Alexandre Julliard wrote: Michael Stefaniuc <[EMAIL PROTECTED]> writes: Andreas Mohr wrote: Umm, this should go into a global header file, right? The theory being that it would be useful at many more performance critical Wine places... But I have to admit that I don't know which header file this should be... Like in the Linux kernel (where this seems to come from) in compiler.h or something like that. No, I don't think we want to do that, it would only encourage people to sprinkle this stuff all over the place believing they are "optimizing" the code. This should only be added in places where it makes a significant difference, demonstrated with benchmark results. Yes, I agree. In fact the patch actually decreases performance. Test: 10,000,000 calls to EnterCriticalSection & LeaveCriticalSection, simulating fast path on critical sections. Results: Win2k - 1000ms Wine w/ patch - 1346ms Wine w/o patch - 1294ms I think the best way to improve performance of the critical section functions is to rewrite them in assembly and I will submit a patch doing so when I have a spare moment. Rob
Re: MS Visio 2000 not working with wine.
James Courtier-Dutton wrote: Has anyone got MS Visio 2000 working with wine? James Yes. Tom
MS Project 2000 not working in wine.
Has anyone got MS Project 2000 working in wine? James
MS Visio 2000 not working with wine.
Has anyone got MS Visio 2000 working with wine? James
Re: Added path settings to winecfg
Jacek Caban escreveu:
But what about other languages, which nobody updates as you do?
I have one more question: where can I find this script? I see that
polish translation is far from complete and I thought I could work
aroun dit.
Thanks,
Jacek
Sorry for the delay. Atached is the patch to create a trans.sh in in
wine/tools.
To run in wine directory run tools/trans.sh and it creates
tools/trans_html/index.html
This is a modified version of the original patch that Vincent Beron send
in January.
Index: .cvsignore
===
RCS file: /home/wine/wine/tools/.cvsignore,v
retrieving revision 1.11
diff -u -r1.11 .cvsignore
--- .cvsignore 17 Aug 2004 22:33:14 - 1.11
+++ .cvsignore 21 Aug 2004 14:32:10 -
@@ -4,4 +4,6 @@
fnt2fon
makedep
sfnt2fnt
+trans
+trans_html
wineprefixcreate
Index: Makefile.in
===
RCS file: /home/wine/wine/tools/Makefile.in,v
retrieving revision 1.41
diff -u -r1.41 Makefile.in
--- Makefile.in 17 Aug 2004 22:33:14 - 1.41
+++ Makefile.in 21 Aug 2004 14:32:10 -
@@ -13,6 +13,7 @@
fnt2fon \
makedep \
sfnt2fnt \
+ trans \
wineprefixcreate
C_SRCS = \
@@ -21,6 +22,7 @@
fnt2fon.c \
makedep.c \
sfnt2fnt.c \
+ trans.c
SUBDIRS = \
widl \
@@ -54,6 +56,9 @@
bin2res: bin2res.o
$(CC) $(CFLAGS) -o bin2res bin2res.o $(LIBPORT)
+
+trans: trans.o
+ $(CC) $(CFLAGS) -o trans trans.o $(LIBPORT)
wineprefixcreate: wineprefixcreate.in
sed -e 's,@dlldir\@,$(dlldir),g' -e 's,@datadir\@,$(datadir),g' $(SRCDIR)/wineprefixcreate.in >$@ || ($(RM) $@ && false)
--- /dev/null 2004-02-23 18:02:56.0 -0300
+++ trans.c 2004-08-21 00:55:19.0 -0300
@@ -0,0 +1,327 @@
+/*
+ * Copyright 2003-2004 Vincent Béron
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * 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
+#include
+#include
+#include "windef.h"
+
+#define NB_RES_TYPE 21
+#define NB_LANG 0x94
+
+static const char *res_types[] = {
+"cursor",
+"bitmap",
+"icon",
+"menu",
+"dialog",
+"stringtable",
+"fontdir",
+"font",
+"accelerator",
+"rcdata",
+"messagetable",
+"cursor_group",
+"icon_group",
+"versioninfo",
+"ani_cursor",
+"ani_icon",
+"dlginit",
+"toolbar",
+"menuex",
+"dialogex",
+"user"
+};
+
+#define PRETTYPRINTLANG(langid) \
+ if(LANG_##langid == lid) { \
+ return #langid; \
+ }
+
+static const char *get_language_name(int lid) {
+ PRETTYPRINTLANG(NEUTRAL)
+ PRETTYPRINTLANG(AFRIKAANS)
+ PRETTYPRINTLANG(ALBANIAN)
+ PRETTYPRINTLANG(ARABIC)
+ PRETTYPRINTLANG(ARMENIAN)
+ PRETTYPRINTLANG(ASSAMESE)
+ PRETTYPRINTLANG(AZERI)
+ PRETTYPRINTLANG(BASQUE)
+ PRETTYPRINTLANG(BELARUSIAN)
+ PRETTYPRINTLANG(BENGALI)
+ PRETTYPRINTLANG(BULGARIAN)
+ PRETTYPRINTLANG(CATALAN)
+ PRETTYPRINTLANG(CHINESE)
+ PRETTYPRINTLANG(CROATIAN)
+ PRETTYPRINTLANG(CZECH)
+ PRETTYPRINTLANG(DANISH)
+ PRETTYPRINTLANG(DIVEHI)
+ PRETTYPRINTLANG(DUTCH)
+ PRETTYPRINTLANG(ENGLISH)
+ PRETTYPRINTLANG(ESTONIAN)
+ PRETTYPRINTLANG(FAEROESE)
+ PRETTYPRINTLANG(FARSI)
+ PRETTYPRINTLANG(FINNISH)
+ PRETTYPRINTLANG(FRENCH)
+ PRETTYPRINTLANG(GALICIAN)
+ PRETTYPRINTLANG(GEORGIAN)
+ PRETTYPRINTLANG(GERMAN)
+ PRETTYPRINTLANG(GREEK)
+ PRETTYPRINTLANG(GUJARATI)
+ PRETTYPRINTLANG(HEBREW)
+ PRETTYPRINTLANG(HINDI)
+ PRETTYPRINTLANG(HUNGARIAN)
+ PRETTYPRINTLANG(ICELANDIC)
+ PRETTYPRINTLANG(INDONESIAN)
+ PRETTYPRINTLANG(ITALIAN)
+ PRETTYPRINTLANG(JAPANESE)
+ PRETTYPRINTLANG(KANNADA)
+ PRETTYPRINTLANG(KASHMIRI)
+ PRETTYPRINTLANG(KAZAK)
+ PRETTYPRINTLANG(KONKANI)
+ PRETTYPRINTLANG(KOREAN)
+ PRETTYPRINTLANG(KYRGYZ)
+ PRETTYPRINTLANG(LATVIAN)
+ PRETTYPRINTLANG(LITHUANIAN)
+ PRETTYPRINTLANG(MACEDONIAN)
+ PRETTYPRINTLANG(MALAY)
+ PRETTYPRINTLANG(MALAYALAM)
+ PRETTYPRINTLANG(MANIPURI)
+ PRETTYPRINTLANG(MARATHI)
+ PRETTYPRINTLANG(MONGOLIAN)
+ PRETTYPRINTLANG(NEPALI)
+ PRETTYPRINTLANG(NORWEGIAN)
+ PRETTYPRINTLANG(ORIYA)
+ PRETTYPRINTLANG(POLISH)
+ PRETTYPRINTLANG(PORTUGUESE)
+ PRETTYPRINTLANG(PUNJABI)
+ PRETTYPRINTLANG(ROMANIAN)
+ PRETTYPRINTLANG(RUSSIAN)
+ PRETTYPRINTLANG(SANSKRIT)
+ PRETTYPRINTLANG(SERBIAN)
+ PRETTYPRINTLANG(SINDHI)
+ PRETTYPRINTLANG(SLOVAK)
+ PRETTYPRINTLANG(SLOVENIAN)
+ PRETTYPRINTLANG(SPANISH)
+ PRETTYPRINTLANG(SWAHILI)
+ PRETTYPRINTLANG(SWEDISH)
+ PRETTYPRINTLANG(SYRIAC)
+ PRETTYPRINTLANG(TAMIL)
+ PRETTYPRINTLANG(TATAR)
+ PRETTYPRI
[Fwd: Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]]
Forwarded Message From: Con Kolivas <[EMAIL PROTECTED]> To: Mike Hearn <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [ck] Re: Threading issues? [EMAIL PROTECTED]: ck Digest, Vol 3, Issue 16] Date: Sat, 21 Aug 2004 10:39:21 +1000 Mailer: Mozilla Thunderbird 0.7.1 (X11/20040626) Mike Hearn wrote: > On Tue, 17 Aug 2004 10:06:46 +0200, Andreas Mohr wrote: > >>Are we doing some big no-nos in the threading area here? >>(or maybe it's just done the way it is because we cannot do it a >>different, better way?) >> >>For the whole discussion, please see >>http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html > > > 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. The other (useful?) bit of information is that one person solved his issue with this: >I had a similar problem with Cedega. I fixed it by editing the >Cedega/WineX config file and specifying that I wanted to use ALSA >instead of WineOSS, then disable mmap for ALSA. I'm not sure if that fixes all the problems but perhaps that helps. I'm interested in getting this resolved so please keep me informed. Cheers, Con P.S. Sorry I had trouble posting to your newsgroup.
Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
> the program starts, but the difference between this and a regular
> non-static variable is that this static variable holds whatever value
> it contains
That wasnt very clear so I'll try to explain better. The bottom line
is that the value of the static variable is retained between repeated
function calls to the same function.
See http://www-ee.eng.hawaii.edu/Courses/EE150/Book/chap14/subsection2.1.1.6.html
for more information.
On Sat, 21 Aug 2004 02:52:31 -0700, James Hawkins <[EMAIL PROTECTED]> wrote:
> Tobias wrote:
> > > +if (warned++ < 10 && lprgn != NULL)
>
> Stefan wrote:
> > for me this looks like
> >
> > if (0 < 10 && lprgn != NULL)
>
> The variable 'warned' doesn't actually turn out to be zero all of the
> time. It is a static variable, so it is initialized once to zero when
> the program starts, but the difference between this and a regular
> non-static variable is that this static variable holds whatever value
> it contains. If this code snippet runs then warned will increase by
> one each time and this new value will not be set back to zero the next
> time the block runs.
>
>
>
> On Sat, 21 Aug 2004 11:08:09 +0200, Stefan Leichter
> <[EMAIL PROTECTED]> wrote:
> > Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus:
> > > +
> > > HRESULT WINAPI Main_DirectDrawClipper_SetClipList(
> > > -LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize
> > > +LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag
> > > ) {
> > > ICOM_THIS(IDirectDrawClipperImpl,iface);
> > > -FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize);
> > > +static int warned = 0;
> > > +if (warned++ < 10 && lprgn != NULL)
> > Hello,
> >
> > for me this looks like
> >
> > if (0 < 10 && lprgn != NULL)
> >
> > what is the same like
> >
> > if (lprgn != NULL)
> >
> > I thing you meant something different
> >
> > Bye Stefan
> >
> >
>
>
> --
> James Hawkins
>
--
James Hawkins
Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
Tobias wrote:
> > +if (warned++ < 10 && lprgn != NULL)
Stefan wrote:
> for me this looks like
>
> if (0 < 10 && lprgn != NULL)
The variable 'warned' doesn't actually turn out to be zero all of the
time. It is a static variable, so it is initialized once to zero when
the program starts, but the difference between this and a regular
non-static variable is that this static variable holds whatever value
it contains. If this code snippet runs then warned will increase by
one each time and this new value will not be set back to zero the next
time the block runs.
On Sat, 21 Aug 2004 11:08:09 +0200, Stefan Leichter
<[EMAIL PROTECTED]> wrote:
> Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus:
> > +
> > HRESULT WINAPI Main_DirectDrawClipper_SetClipList(
> > -LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize
> > +LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag
> > ) {
> > ICOM_THIS(IDirectDrawClipperImpl,iface);
> > -FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize);
> > +static int warned = 0;
> > +if (warned++ < 10 && lprgn != NULL)
> Hello,
>
> for me this looks like
>
> if (0 < 10 && lprgn != NULL)
>
> what is the same like
>
> if (lprgn != NULL)
>
> I thing you meant something different
>
> Bye Stefan
>
>
--
James Hawkins
Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
Hi,
On Sat, Aug 21, 2004 at 11:08:09AM +0200, Stefan Leichter wrote:
> Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus:
> > +
> > HRESULT WINAPI Main_DirectDrawClipper_SetClipList(
> > -LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize
> > +LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag
> > ) {
> > ICOM_THIS(IDirectDrawClipperImpl,iface);
> > -FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize);
> > +static int warned = 0;
> > +if (warned++ < 10 && lprgn != NULL)
> Hello,
>
> for me this looks like
>
> if (0 < 10 && lprgn != NULL)
>
> what is the same like
>
> if (lprgn != NULL)
>
> I thing you meant something different
Note that warned is defined to be static.
Maybe go back in your corner and find out what that means? :-)
(or it might just be that you missed the static part)
Andreas Mohr
Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus:
> +
> HRESULT WINAPI Main_DirectDrawClipper_SetClipList(
> -LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize
> +LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag
> ) {
> ICOM_THIS(IDirectDrawClipperImpl,iface);
> -FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize);
> +static int warned = 0;
> +if (warned++ < 10 && lprgn != NULL)
Hello,
for me this looks like
if (0 < 10 && lprgn != NULL)
what is the same like
if (lprgn != NULL)
I thing you meant something different
Bye Stefan
