Re: Wine HQ server.
I don't know; that strikes me as overkill. We do have rack space for more servers, so we certainly could drop more in; if someone wants to buy 1U servers, we can put those in. Looking at the traffic reports, it seems like the WineHQ server is serving A LOT more than it ever has. We're at 300GB a month compared to 200GB a year ago at this time. And I seem to recall a year before that we were a lot lower. The only thing that looks simple to offload is the Changelog, which accounts for 16GB of traffic a month. I dunno, I know Newman does a lot of that work in his free time and it's not exactly the most glamorous job. I'm sure he could have advanced a few extra levels in WoW by now. What would be nice in a world of infinite time, money and resources would be to have 2 webservers that mirror each other set up as a DNS round robin with a separate MySQL backend box. (Or, have the MySQL box on the front end also doing the DNS.) But I do have to agree with Jeremy - there's a bug that needs to be fixed first. -Brian
Re: kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X by correctly setting LC_MESSAGES.
On Dec 11, 2006, at 5:49 PM, Pierre d'Herbemont wrote: On 12 déc. 06, at 00:20, Pierre d'Herbemont wrote: +} +closedir(dir); I think the above code to scan /usr/share/locale is unnecessary. Doesn't CFLocaleCopyAvailableLocaleIdentifiers provide the equivalent? You're quite right. I though setlocale didn't handle 'en' properly expecting full 'en_US' or 'en_GB', I can't understand why now. Probably didn't have enough sleep last night. I do remember now :) setlocale don't handle properly two letters language code like 'es' it expect a full locale name like 'es_ES' . And using the CFLocale API to obtain the full local from 'es' does not seem possible. And even with CFLocaleCopyAvailableLocaleIdentifiers() the returned array will contain 'es' among 'es_ES' and 'en_GB' so, when intersecting with the preferred languages [1] threw CFBundleCopyLocalizationsForPreferences() 'es' will be returned. setlocale(LC_MESSAGES, NULL) will return "C", and thus fallback the standard english language (LC_CTYPE is not set on Mac OS X), whereas setlocale should have returned es. The fix for this is to provide to setlocale a full locale name like 'es_ES', that's why I did it that way. Do you see any better way to do this rather than probably filling a bug report to Apple? [1] #defaults read -g AppleLanguages ( es, fr, en, de, ja, it, nl, sv, nb, da, fi, pt, "zh-Hans", "zh- Hant", ko) Hmm. Well, it probably results in more cumbersome code, but you could filter the array returned by CFLocaleCopyAvailableLocaleIdentifiers by testing which elements have a country code. For each, call CFLocaleCreateComponentsFromLocaleIdentifier and check if the resulting dictionary has an object for the kCFLocaleCountryCode key. You'd accumulate the locale IDs which pass the test in the mutable array. However, this whole strategy (however it's implemented, by scanning / usr/share/locale or the above method) seems to produce bad results. When I test here, CFBundleCopyLocalizationsForPreferences() spits out "en_ZW" (English, Zimbabwe). Some testing reveals that it is *not* just picking the last entry in the locale array whose language matches. It's not entirely predictable. I suspect it's doing a binary search. In System Preferences, I have my language preference set to English. If I edit the list and add U.S. English and put it at the top, then the above method does produce U.S. English. However, that's not how most people have things set up. I suppose we could use a multi-step approach. If the first element of the AppleLanguages array has a country code, use it directly. Otherwise, combine the language code from that element with the country code from the current locale. If that combination is present in the array of available locales, use that. Otherwise, fall back to CFBundleCopyLocalizationsForPreferences. -Ken
Re: kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X by correctly setting LC_MESSAGES.
On 12 déc. 06, at 00:20, Pierre d'Herbemont wrote: +} +closedir(dir); I think the above code to scan /usr/share/locale is unnecessary. Doesn't CFLocaleCopyAvailableLocaleIdentifiers provide the equivalent? You're quite right. I though setlocale didn't handle 'en' properly expecting full 'en_US' or 'en_GB', I can't understand why now. Probably didn't have enough sleep last night. I do remember now :) setlocale don't handle properly two letters language code like 'es' it expect a full locale name like 'es_ES' . And using the CFLocale API to obtain the full local from 'es' does not seem possible. And even with CFLocaleCopyAvailableLocaleIdentifiers() the returned array will contain 'es' among 'es_ES' and 'en_GB' so, when intersecting with the preferred languages [1] threw CFBundleCopyLocalizationsForPreferences() 'es' will be returned. setlocale(LC_MESSAGES, NULL) will return "C", and thus fallback the standard english language (LC_CTYPE is not set on Mac OS X), whereas setlocale should have returned es. The fix for this is to provide to setlocale a full locale name like 'es_ES', that's why I did it that way. Do you see any better way to do this rather than probably filling a bug report to Apple? [1] #defaults read -g AppleLanguages ( es, fr, en, de, ja, it, nl, sv, nb, da, fi, pt, "zh-Hans", "zh- Hant", ko) Pierre. PS: I'll resend the patch with your fixes.
Re: kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X by correctly setting LC_MESSAGES.
On 11 déc. 06, at 22:42, Ken Thomases wrote:
On Dec 11, 2006, at 1:46 PM, Pierre d'Herbemont wrote:
+/* This filters the 'right' locales (xx_xx.UTF-8) */
+if (strstr(file->d_name, ".UTF-8"))
+CFArrayAppendValue(available_locales, (void*)
CFStringCreateWithCString(kCFAllocatorDefault,
+file-
>d_name, kCFStringEncodingUTF8));
The above should use CFStringCreateWithFileSystemRepresentation
instead of CFStringCreateWithCString. Also, you need to CFRelease
the created string after adding it to the array. (The array
manages its references, but that doesn't relieve you of the
responsibility to manage your own.)
My bad.
+}
+closedir(dir);
I think the above code to scan /usr/share/locale is unnecessary.
Doesn't CFLocaleCopyAvailableLocaleIdentifiers provide the equivalent?
You're quite right. I though setlocale didn't handle 'en' properly
expecting full 'en_US' or 'en_GB', I can't understand why now.
Probably didn't have enough sleep last night.
+prefered_languages = CFPreferencesCopyValue( CFSTR
("AppleLanguages"), kCFPreferencesAnyApplication,
+
kCFPreferencesCurrentUser, kCFPreferencesAnyHost);
+if(prefered_languages)
+{
+CFArrayRef intersected_locales =
CFBundleCopyLocalizationsForPreferences(available_locales,
prefered_languages);
Do you need prefered_languages? The docs say that if you pass NULL
for the second parameter of
CFBundleCopyLocalizationsForPreferences, it uses the user's
preferences. That would avoid you having to look them up, above.
My bad.
Also, "preferred" is spelled with three R's.
My bad too.
A lot of mistakes here... Thanks for pointing them so fast,
Pierre.
Re: kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X by correctly setting LC_MESSAGES.
On Dec 11, 2006, at 1:46 PM, Pierre d'Herbemont wrote:
This patch allows Mac OS X Users that set in System Preferences.app
a language (say English) and that don't use the default number and
text formatting currently associated with this language (for
instance if they use French number and text formatting), to have
Wine displaying text in their choosen language. And thus it allows
Wine to behave like 'regular' Mac OS X Applications.
The only problem is that we have to translate the language id to a
locale id.
Pierre.
---
dlls/kernel32/locale.c | 54 +
++-
1 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c
index 8792623..345780f 100644
--- a/dlls/kernel32/locale.c
+++ b/dlls/kernel32/locale.c
@@ -2832,7 +2841,50 @@ void LOCALE_Init(void)
unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a
valid locale */
setenv( "LANG", user_locale, 0 );
TRACE( "setting locale to '%s'\n", user_locale );
-#endif
+
+/* We still want to set the LC_MESSAGES env to what is the
prefered language in
+ System Preferences.app, because it can differ from
CFLocaleCopyCurrent().
+
+ However this prefered language is stored using the general
language denotation
+ that may not include the country code (en,fr,en-GB,...)
which is not accepted
+ by setlocale (setlocale would expect en_US,fr_FR,en_GB,...).
+
+ So we retrieve possible locales from /usr/share/locale and
intersect them
+ with the prefered languages using
CFBundleCopyLocalizationsForPreferences. */
+dir = opendir("/usr/share/locale");
+available_locales = CFArrayCreateMutable(kCFAllocatorDefault,
0, NULL);
+while ((file = readdir(dir)))
+{
+/* This filters the 'right' locales (xx_xx.UTF-8) */
+if (strstr(file->d_name, ".UTF-8"))
+CFArrayAppendValue(available_locales, (void*)
CFStringCreateWithCString(kCFAllocatorDefault,
+file-
>d_name, kCFStringEncodingUTF8));
The above should use CFStringCreateWithFileSystemRepresentation
instead of CFStringCreateWithCString. Also, you need to CFRelease
the created string after adding it to the array. (The array manages
its references, but that doesn't relieve you of the responsibility to
manage your own.)
+}
+closedir(dir);
I think the above code to scan /usr/share/locale is unnecessary.
Doesn't CFLocaleCopyAvailableLocaleIdentifiers provide the equivalent?
+
+CFPreferencesAppSynchronize(kCFPreferencesAnyApplication);
+prefered_languages = CFPreferencesCopyValue( CFSTR
("AppleLanguages"), kCFPreferencesAnyApplication,
+
kCFPreferencesCurrentUser, kCFPreferencesAnyHost);
+if(prefered_languages)
+{
+CFArrayRef intersected_locales =
CFBundleCopyLocalizationsForPreferences(available_locales,
prefered_languages);
Do you need prefered_languages? The docs say that if you pass NULL
for the second parameter of CFBundleCopyLocalizationsForPreferences,
it uses the user's preferences. That would avoid you having to look
them up, above.
Also, "preferred" is spelled with three R's.
+CFStringRef user_language = NULL;
+
+if(CFArrayGetCount(intersected_locales))
+user_language = CFArrayGetValueAtIndex
(intersected_locales, 0);
+if(user_language)
+{
+CFStringGetCString( user_language, user_locale, sizeof
(user_locale), kCFStringEncodingUTF8 );
+CFRelease( user_language );
+TRACE( "setting LC_MESSAGES to '%s'\n", user_locale );
+setenv( "LC_MESSAGES", user_locale, 0 );
+}
+CFRelease(prefered_languages);
+CFRelease(intersected_locales);
+}
+CFRelease(available_locales);
+#endif /* __APPLE__ */
+
setlocale( LC_ALL, "" );
unix_cp = setup_unix_locales();
Re: fonts:add
On 12/11/06, Louis Lenders <[EMAIL PROTECTED]> wrote: So what now? How to proceed? Is that font freely available? Should we ask Reactos developers to "donate" the font to wine? Would be nice if this font could finally be added in near future, applications are failing because of this Talk to the ReactOS guys and ask them if they still have it. I don't remeber if I ever committed it to ReactOS svn but if its there it would have been in reactos/media/fonts. Email them or ask on IRC if they can get you in touch with the author. I think his irc handle was WiredW but I don't recall his real name. The author had offered to license it LGPL or X11/BSD and was going to try to import the source or whatever in to fontforge but was frustrated because it lost his hinting or something. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winemenubuilder: Write truecolor icons as PNGs
On 06.12.2006 20:01, Francois Gouget wrote: > I'm pretty sure my memory mangled some of this. Hopefully Alexandre will > clarify things. Yeah, I'm also wondering how an acceptable PNG icon support would look like. -f.r.
Re: comctl32: fix imagelist regression from "comctl32: Remove Nx1 assumptions in ImageList_Read"
On Sunday 10 December 2006 16:57, Peter Oberndorfer wrote: > The patch comctl32: Remove Nx1 assumptions in ImageList_Read > (e74b0ee9102470d1b866e94c54527b34806cf876) > would produce black images on the toolbar of IDA Pro Demo after clicking one > of the listviews on the right > > > Changelog: > comctl32: fix imagelist regression from "comctl32: Remove Nx1 assumptions in > ImageList_Read" > remove unused HBITMAP hbmColor > It still leaks memory, when it fails to read the bitmap or the mask. I'll try to write a testcase to see what happens if one of them is missing. Greetings Peter
Re: Wine HQ server.
Hi Tony, I don't know; that strikes me as overkill. We do have rack space for more servers, so we certainly could drop more in; if someone wants to buy 1U servers, we can put those in. But it seems like adding additional admin work in response to a single software glitch is a mistake. I think we should focus on finding and fixing this bug. It's got to be simple; something is making Apache run crazy, and we should stop it. I suppose we could start running separate Apache images on the one server - one for bugs, one for the appdb, and so on; that might help us figure out which one is going crazy faster. But I think Jer has a few other angles of attack on this as well... Cheers, Jeremy Tony Lambregts wrote: > What would it take (how much would it cost us) to move the > www.winehq.org site to another server? > > We have had this problem for a while now (over a week) that our main > site has been sporaticly unavailable. I appreciate all the work Jeremy > Newman has put into trying to find the problem but I think that having > all of websites (excepting the wiki) on one box is a bad idea in the > long run. I think that we should dedicate a box to www.winehq.org > since having a uninterupted presence on the web is critical to Wine's > image. > > Right now we host quite a number of different services on the one box. > Ideally we could have a redundant/mirrored solution but that is not > esential at this point. > > This is my list in order of importance (wiki is not on this list > because it is already on a separate box) > > Git - Essential service (easy to miror) > www.winehq.org - critical to our image (easy to mirror ???) > mysql - critical to appdb and bugzilla (cannot mirror effectively) > bugs.winehq.org - important to fixing bugs ;^) (hard to mirror) > appdb.winehq.org - userland mostly. ( yes it's important but not > critical) (hard to miror) > mailing lists archives - we already have redundancy here. > cvs - needed for web site development and people not converted to git > (easy to mirror) > > Buying an used box for $500-1000(us) and dedicating it to > www.winehq.org is one option I see (and am willing to help pay for). I > am sure there are other options but I wanted to at least open the > dicussion. > > -- > > Tony Lambregts > >
Re: fonts:add
>Greenville's face is substantially is different from Tahoma, the only >thing which is similar to Tahoma is character widths, which makes >Greenville a compatible replacement of Tahoma. Since I worked for >a publishing company for 10 years, and I know how the font faces are .>being created, I should say that although Greenville has been developed >(formally) for ReactOS I don't think that that fact should make it less >useable outside of it. So what now? How to proceed? Is that font freely available? Should we ask Reactos developers to "donate" the font to wine? Would be nice if this font could finally be added in near future, applications are failing because of this
Wine HQ server.
What would it take (how much would it cost us) to move the www.winehq.org site to another server? We have had this problem for a while now (over a week) that our main site has been sporaticly unavailable. I appreciate all the work Jeremy Newman has put into trying to find the problem but I think that having all of websites (excepting the wiki) on one box is a bad idea in the long run. I think that we should dedicate a box to www.winehq.org since having a uninterupted presence on the web is critical to Wine's image. Right now we host quite a number of different services on the one box. Ideally we could have a redundant/mirrored solution but that is not esential at this point. This is my list in order of importance (wiki is not on this list because it is already on a separate box) Git - Essential service (easy to miror) www.winehq.org - critical to our image (easy to mirror ???) mysql - critical to appdb and bugzilla (cannot mirror effectively) bugs.winehq.org - important to fixing bugs ;^) (hard to mirror) appdb.winehq.org - userland mostly. ( yes it's important but not critical) (hard to miror) mailing lists archives - we already have redundancy here. cvs - needed for web site development and people not converted to git (easy to mirror) Buying an used box for $500-1000(us) and dedicating it to www.winehq.org is one option I see (and am willing to help pay for). I am sure there are other options but I wanted to at least open the dicussion. -- Tony Lambregts
wine-rpm on mandriva2007_x86-64
For installing the latest *wine-rpms* and working with it, on mandriva-2007.0_x86-64, we need to install libxxf86vm1-1.0.1-2mdv2007.0.i586.rpm downloadable on a mandriva2007_x86_32 repository, like this for example: ftp://mirror.pacific.net.au/MandrivaLinux/official/2007.0/i586/media/main/release Regards -- Daniele Bagaglini
Re: fonts:add "framework" for tahoma font
On 12/10/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: "Steven Edwards" <[EMAIL PROTECTED]> wrote: > Greenville is virtually abandonware and while its not really possible > to claim the font was ripped of it still was being developed under the > umbrella of the ReactOS project. Even if work on it is revised and > completed, until the situation with ReactOS changes I doubt it would > make it in to winehq. Greenville's face is substantially is different from Tahoma, the only thing which is similar to Tahoma is character widths, which makes Greenville a compatible replacement of Tahoma. Since I worked for a publishing company for 10 years, and I know how the font faces are being created, I should say that although Greenville has been developed (formally) for ReactOS I don't think that that fact should make it less useable outside of it. Is there an official policy on whether or not Greenville would be accepted into Wine? Way back in September 2004 (and quoted in WWN 241 [1]) it was said that Greenville was written in some expensive program other that fontforge - is that hindering its inclusion? --Murph [1] http://www.kernel-traffic.org/wine/wn20040924_241.txt
oleaut32:
Alexandre Julliard escribió:
Alex Villacís Lasso <[EMAIL PROTECTED]> writes:
This patch added the setlocale(LC_ALL, "") line to
dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been
failing since that time on non-English locales. I see now that setting
the locale around calls of sprintfW() is not thread-safe. However, I
think there is no big problem on going through a string in order to
convert a floating-point number into a DECIMAL, since otherwise, we
would need to implement our own bit-splicer for floating-point
numbers. As long as the starting locale for sprintfW() is known to be
the LC_NUMERIC="C", all other parsing should work as before the MacOS
patch. Therefore I propose the attached patch. This patch simply sets
setlocale(LC_NUMERIC, "C") at the end of LOCALE_Init() in
dlls/kernel32/locale.c in order to guarantee that sprintfW will always
use periods as decimal separators.
I put this in for now, but oleaut32 should really be fixed, we can't
force the whole process to format number in English just because
oleaut32 is broken. It doesn't matter too much for Wine itself, but
any Unix library that we load should be able to behave properly
according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that
ties it to LC_NUMERIC being "C". This patch decomposes floats and
doubles into the component bitfields, then copies the values into
DECIMAL structures and manipulates them to get the corresponding DECIMAL
value. This removes the step of converting the floating-point number
into a string and therefore eliminates two uses of sprintfW on floats.
This particular patch passes all tests, but I am not really sure about
the rounding - I might be overdoing it. Please comment.
Changelog:
* Remove uses of sprintfW to convert floats into DECIMAL by directly
parsing the floating-point representation.
Alex Villacís Lasso
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
--- wine-0.9.27-cvs/dlls/oleaut32/vartype.c 2006-12-07 13:38:15.0 -0500
+++ wine-0.9.27-cvs-patch/dlls/oleaut32/vartype.c 2006-12-10 16:30:02.0 -0500
@@ -4143,6 +4143,21 @@
#define LOCALE_EN_US (MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT))
+/* internal representation of the value stored in a DECIMAL. The bytes are
+ stored from LSB at index 0 to MSB at index 11
+ */
+typedef struct DECIMAL_internal
+{
+DWORD bitsnum[3]; /* 96 significant bits, unsigned */
+unsigned char scale; /* number scaled * 10 ^ -(scale) */
+unsigned int sign : 1; /* 0 - positive, 1 - negative */
+} VARIANT_DI;
+
+static HRESULT VARIANT_DI_FromR4(float source, VARIANT_DI * dest);
+static HRESULT VARIANT_DI_FromR8(double source, VARIANT_DI * dest);
+static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to);
+static void VARIANT_DecFromDI(VARIANT_DI * from, DECIMAL * to);
+
/
* VarDecFromR4 (OLEAUT32.193)
*
@@ -4157,10 +4172,12 @@
*/
HRESULT WINAPI VarDecFromR4(FLOAT fltIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szFloatFormatW, fltIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR4(fltIn, &di);
+ if (hres == S_OK) VARIANT_DecFromDI(&di, pDecOut);
+ return hres;
}
/
@@ -4177,10 +4194,12 @@
*/
HRESULT WINAPI VarDecFromR8(double dblIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szDoubleFormatW, dblIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR8(dblIn, &di);
+ if (hres == S_OK) VARIANT_DecFromDI(&di, pDecOut);
+ return hres;
}
/
@@ -4596,16 +4615,6 @@
return hRet;
}
-/* internal representation of the value stored in a DECIMAL. The bytes are
- stored from LSB at index 0 to MSB at index 11
- */
-typedef struct DECIMAL_internal
-{
-DWORD bitsnum[3]; /* 96 significant bits, unsigned */
-unsigned char scale; /* number scaled * 10 ^ -(scale) */
-unsigned int sign : 1; /* 0 - positive, 1 - negative */
-} VARIANT_DI;
-
/* translate from external DECIMAL format into an internal representation */
static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to)
{
@@ -5190,6 +5199,284 @@
return r_o
Re: mscoree: Take advantage of an installed Mono for Windows to run .NET applications.
Hans Leidekker <[EMAIL PROTECTED]> writes:
> +memset(&si, 0, sizeof(si));
> +si.cb = sizeof(si);
> +if (!CreateProcessW(NULL, cmd_line, NULL, NULL, FALSE, 0, NULL, NULL,
> &si, &pi))
> +{
> +HeapFree(GetProcessHeap(), 0, cmd_line);
> +return -1;
> +}
> +
> +if (WAIT_OBJECT_0 != WaitForSingleObject(pi.hProcess, 1))
> +WARN("Timed out waiting for command to start\n");
This waits for the process to end. If you really want to wait for it
to start you have to use something like WaitForInputIdle.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: DDraw: Protect IDirectDrawImpl against race conditions
Am Montag 11 Dezember 2006 15:39 schrieb Alexandre Julliard: > Stefan Dösinger <[EMAIL PROTECTED]> writes: > > Am Donnerstag 07 Dezember 2006 21:17 schrieben Sie: > >> This seems dangerous, changing the window size will potentially send > >> messages to other threads, so doing it inside the lock can cause > >> deadlocks. > > > > So I should unlock before I change the window size? > > Probably, though I guess that depends on what the Windows behavior is > with windows and multiple threads. I have to read up the msdn and propably write tests for it, but there are some methods which must be called from the thread that created the device. SetDisplayMode and RestoreDisplayMode are 2 examples, I *think* it applies SetCooperativeLevel too. It would make sense because SetCooperativeLevel is the method used to turn on multithreading protection. pgpnqC9fEkzOt.pgp Description: PGP signature
Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch
Eric Pouech <[EMAIL PROTECTED]> writes: > Alexandre Julliard a écrit : >> Exactly, we already have 8 sound drivers, and not a single one >> actually works properly, so I'm pretty reluctant to add yet another >> copy of the same broken code. >> > which code are you referring to ? > the dsound driver stuff or the winmm driver stuff ? > to my knowledge mostly the first one is to blame Probably both, I don't know where the specific bugs are, and that's exactly the problem. When sound doesn't work, instead of chasing down the bug and fixing it, people just go out and write a new driver, which of course only makes the problem worse. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DDraw: Protect IDirectDrawImpl against race conditions
Stefan Dösinger <[EMAIL PROTECTED]> writes: > Am Donnerstag 07 Dezember 2006 21:17 schrieben Sie: >> This seems dangerous, changing the window size will potentially send >> messages to other threads, so doing it inside the lock can cause >> deadlocks. > So I should unlock before I change the window size? Probably, though I guess that depends on what the Windows behavior is with windows and multiple threads. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Hoiga salaray software
On Monday December 11 2006 11:39, Mattias Eriksson wrote: > So if you just mail me some contact information and I'll forward them to > the Hogia developers. If doing regression analysis is difficult for you then I can help you. I need software and brief description of introduced in wine-0.9.12 problem then I will do regression analysis for you. Please note that I cannot recieve by e-mail files bigger than ~12 MiB. If your software is bigger I can only download it by link (this is preffered method for me it saves me a lot of my money because I can download it during night) or recieve piece by piece via e-mail but no more than 1 big piece per hour. And I havn't enough traffic to recieve something bigger than 80 MiB via e-mail or 300 MiB via download link. If you decide to use my help then please contact me directly (via my e-mail) and don't post to the list.
Re: Hoiga salaray software
Am Montag 11 Dezember 2006 12:39 schrieb Mattias Eriksson: > Hi, I'm a user of Hogia salary software under wine. It works fine with > wine 0.9.11 but something broke in 0.9.12. It has gotten better with the > latest versions but it still has a bug that makes it not work. > I have been in contact with the Hogia developers and they are willing to > provide a demo version of the software for you to look at but they need > some information about who they should contact? > > So if you just mail me some contact information and I'll forward them to > the Hogia developers. The best thing you could do is to make a regression test between wine 0.9.11 and 0.9.12 to find the patch that broke the app. This is described here: http://wiki.winehq.com/GitWine , 6.1 "Regression testing" pgpE7RfMOeoZ3.pgp Description: PGP signature
Hoiga salaray software
Hi, I'm a user of Hogia salary software under wine. It works fine with wine 0.9.11 but something broke in 0.9.12. It has gotten better with the latest versions but it still has a bug that makes it not work. I have been in contact with the Hogia developers and they are willing to provide a demo version of the software for you to look at but they need some information about who they should contact? So if you just mail me some contact information and I'll forward them to the Hogia developers. //Mattias
