Re: Translations/locale

[Paul Vriens]

Paul Vriens wrote:

Ken Sharp wrote:
Can someone tell me what's going on on this page 
http://source.winehq.org/transl/lang.php?lang=009%3A00 ?


If you click on the bottom links (locales) I see a message "Invalid 
resource file".  Does this mean the resource file doesn't exist, or is 
there a little oops in the links?


Thanks,
Ken.



I saw that as well yesterday (first time I actually clicked on that link).

I'm not sure if there should be a link at all. If yes, I suspect we 
should be seeing the resources from the dlls/kernel32/nls/*.nls files.


Likewise selecting the 'dlls/kernel32' link should probably show you the 
  resources belonging to the dlls/kernel32/nls/winerr_* files. Currently 
it shows you "resource MESSAGE #1: Resource translated" for some 
languages but with no links to the actual resources.


I'm not sure how difficult it would be to implement these though and if 
there is actually a need for it.


Just checked. The dlls/kernel32/kernel.res contains everything we need, 
both the resources related to nls-information and also the messages 
coming from the winerr_* files.


--
Cheers,

Paul.

Re: Translations/locale

[Paul Vriens]

Ken Sharp wrote:
Can someone tell me what's going on on this page 
http://source.winehq.org/transl/lang.php?lang=009%3A00 ?


If you click on the bottom links (locales) I see a message "Invalid 
resource file".  Does this mean the resource file doesn't exist, or is 
there a little oops in the links?


Thanks,
Ken.



I saw that as well yesterday (first time I actually clicked on that link).

I'm not sure if there should be a link at all. If yes, I suspect we 
should be seeing the resources from the dlls/kernel32/nls/*.nls files.


Likewise selecting the 'dlls/kernel32' link should probably show you the 
  resources belonging to the dlls/kernel32/nls/winerr_* files. 
Currently it shows you "resource MESSAGE #1: Resource translated" for 
some languages but with no links to the actual resources.


I'm not sure how difficult it would be to implement these though and if 
there is actually a need for it.


--
Cheers,

Paul.

Re: winex11.drv: Handle clipboard on an auxiliary thread for windowless apps (try 3)

[Dmitry Timoshkov]

"Yuri Khan"  wrote:


+void selection_acquire(void)


Should be 'static'.


+DWORD WINAPI selection_thread_proc(LPVOID lphwnd)


Should be 'static'. What's the purpose of such a parameter name?
'dummy', 'unused' or just 'param' would be better IMO.


+{
+HANDLE handles[1];
+
+selection_acquire();
+
+while (selectionAcquired)
+{
+MsgWaitForMultipleObjectsEx(0, handles, INFINITE, QS_SENDMESSAGE, 0);
+}


What's the purpose of 'handles'? 'handles' is not initialized, moreover
the number of passed handles is 0. MsgWaitForMultipleObjectsEx() works
just fine with '0, NULL' combination.


--
Dmitry.

Re: comctl32: Fix dialog ('Next' button was hidden)

[Aurimas Fišeras]

On 07/08/2009 10:31 PM, Frédéric Delanoy wrote:
> 
I think it should be under the button "Finish", so that
the "Finish" button can be shown in the same place
instead of "Next >" on the last wizard page.

Translations/locale

[Ken Sharp]

Can someone tell me what's going on on this page 
http://source.winehq.org/transl/lang.php?lang=009%3A00 ?


If you click on the bottom links (locales) I see a message "Invalid 
resource file".  Does this mean the resource file doesn't exist, or is 
there a little oops in the links?


Thanks,
Ken.

Re: Fwd: [Wine] Tmax Window(a propietary OS) using Wine?

[Scott Ritchie]

Austin English wrote:
> -- Forwarded message --
> From: nengad24 
> Date: Tue, Jul 7, 2009 at 5:54 AM
> Subject: [Wine]  Tmax Window(a propietary OS) using Wine?
> To: wine-us...@winehq.org
> 
> 
> Hi, Im posting here the next doubt:
> 
> Yesterday a korean company has released a new OS which is compatible
> with MS Windows Apps. As they state, they are a propietary OS, and i
> cant see any GPL code or SVN repository.Of course my lack of Korean
> can help to not find the open source code,but the little im able to
> read seems they arent going to release any source code.
> 
> I know that is quite difficult to replicate Windows APIs, so i´m
> asking myself if this OS is using Wine code to replicate the APIs.
> 
> If they are using, they could be violating GPL rules.
> http://www.tmaxwindow.co.kr/
> 

I don't know why we even have to discuss this, it's obviously either a
fraud or a GPL violation.


Thanks,
Scott Ritchie

Re: [Wine] Tmax Window(a propietary OS) using Wine?

[Ben Klein]

2009/7/8 Austin English :
> On Tue, Jul 7, 2009 at 9:43 PM, Ben Klein wrote:
>> 2009/7/8 Austin English :
>>> -- Forwarded message --
>>> From: nengad24 
>>> -- snip --
>>> Yesterday a korean company has released a new OS which is compatible
>>> with MS Windows Apps.
>>> -- snip --
>>> http://www.tmaxwindow.co.kr/
>>>
>>> If you want to have more Info, i point you to the ReactOS Forum,where
>>> a thread about this Company can be found.
>>
>> Someone posted a cnet blog article about tmax to #winehq, but without
>> any real details or investigation, or someone more reputable than cnet
>> commenting on it, I personally dismissed it as "yet another localised,
>> doomed OS".
>>
>> After reading the ReactOS thread linked in the original forwarded
>> mail, it looks like it's a blatant violation of GPL (and LGPL)
>> spanning many projects, and FSF's legal team should be alerted.
>>
>
> As was already pointed out, unless it's certain that Wine's copyright
> is being infringed, that's a harsh step.
>
> First, it needs to be verified that Wine's license is being violated.
> Then, someone holding a copyright in Wine's source code needs to
> complain, since they have standing.
> --
> -Austin
>

It does look very suspicious. Someone mentioned that the mail client
looks exactly like Thunderbird, that the office suite looks exactly
like OpenOffice.org, and based on a comment I read about acid3 test
support, the browser is almost certainly webkit-based ...

Re: transl and sublangs are not showing neutral

[Paul Vriens]

Ricardo Filipe wrote:



2009/7/8 Paul Vriens >


Ricardo Filipe wrote:



2009/7/8 Paul Vriens mailto:paul.vriens.w...@gmail.com>
>>


   Paul Vriens wrote:

   Ricardo Filipe wrote:

   hi mikolaj,

   in transl the Portuguese language (not Portugese :( )
is not
   showing most of the neutral strings for it's sublangs
   (portugal and brazil).
   i think this is not how it should be... in each
sublang it
   should show the Neutral derived strings and the
warning that
   neutral is being used and should not be used aside the
   language name in the main list, not put neutral
separate in
   another hidden page.

   as it is now it's hard for me to know what is
translated and
   what's not. what do you (and wine devel) think? could you
   please change this?

   regards,
   Ricardo


 
 



   Hi Ricardo,

   So you would be happy/happier if we show "Portuguese
(Neutral)"
   (with the warning) on the main page next to the "Portuguese
   (Portugal)" and "Portuguese (Brazilian)"?

   Just re-read your email. What you like is to have "Portuguese
   (Portugal)" show the combination of "Portuguese (Portugal)" and
   "Portuguese (Neutral)", correct? With a warning for the neutral
   resources.

   What does this mean for "English (Neutral)" should that be
treated
   the same or is Portuguese an exception?

   --Cheers,

   Paul.


yes that is what i would like and think is correct showing.
portuguese strings should defer to neutral if none is found in
the sublang, with a warning that they may be incorrect.

i would say english is the exception by having all translated in
SUBLANG_DEFAULT and not separating sublangs as is done with
portuguese resources and others.
as i stated in irc one of these days, i think the solution to
english is to have a SUBLANG_BRITISH or whatever and not assume
neutral is for british english, how it is right now contradicts
the use of wrc which is sublang -> neutral -> default (english).
i'd say english should have all resources in neutral and then
the different ones in sublang_british or sublang_australian or
other.

at least that is what makes sense to me for the process to be
consistent.


The attached patch makes transl behave more or less the way you want
I think.

The rest of the pages look fine to me as well (see attached
screenshots). The only thing not correct in those screenshots is
kernel32 being marked as partial where it should be "not translated".

It of course also doesn't have the warning in front of it but that
seems trivial. So see this as a proof of concept.

We of course need some kind of consensus here whether this is the
way forward.

-- 
Cheers,


Paul.

diff --git a/transl/scripts/ver.pl b/transl/scripts/ver.pl
index 9b7f289..dd898d6 100755
--- a/transl/scripts/ver.pl
+++ b/transl/scripts/ver.pl
@@ -83,9 +83,11 @@ $norm_fn = $filename;
 $norm_fn =~ s/[^a-zA-Z0-9]/-/g;
 #mkdir "$workdir/dumps/$norm_fn";

-...@file_langs = ("009:01");
+...@file_langs = ("009:01","016:01","016:02"); # See also comments below
 #$deflangs{"009:00"} = TRUE;
-$deflangs{"009:01"} = TRUE;
+$deflangs{"009:01"} = TRUE; # Make sure 'English (US)' always
inherits from 'English (Neutral)' if needed
+$deflangs{"016:01"} = TRUE; # Make sure 'Portuguese (Brazilian)'
always inherits from 'Portuguese (Neutral)' if needed
+$deflangs{"016:02"} = TRUE; # Make sure 'Portuguese (Portugal)'
always inherits from 'Portuguese (Neutral)' if needed

 while ()
 {


that looks almost right, there is a bug though: it's showing non 
translated pages as partially translated (e.g. see cryptui and winedbg).


and yeah it would be good to have other people's opinions to see if this 
is the right track. it sure helps to have all resources together to see 
what's missing.




The attached patch works fine for Portuguese.

--
Cheers,

Paul.
diff --git a/transl/scripts/ver.pl b/transl/scripts/ver.pl
index 9b7f289..9336f97 100755
--- a/transl/scripts/ver.pl
+++ b/transl/scripts/ver.pl
@@ -120,6 +120,20 @@ while ()
 $deflangs{$lang} = TRUE;
 push @file_langs, $lang;
 }
+# Cater for 'Portuguese (Portugal)' and 'Po

Re: winequartz.drv Mac OS X UI discontinued?

[Adam Strzelecki]

James,


Well actually you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html
Is this still true?  I would like to convert what work we do have  
into c
level code so that it will pass AJs 'c' scan and to avoid using ObjC  
code.


Those functions allow pure C code call and work on Objective-C  
(shortened to Obj-C later) object pointers. While it gives you  
possibility to write an Obj-C Cocoa based pure-C extension for Wine,  
IMHO this would be a nightmare. Because of few reasons: (1) You'd need  
to write lot more code than writing Obj-C, (2) This code would be  
suboptimal (Obj-C isn't translated to C, it is separate compiler), (3)  
You can expect lot of problems with memory allocation and freeing that  
is done more less automatically with Obj-C memory pools, etc.


In addition, if an exported Carbon/Cocoa library exists, this would  
help

move the project along.


As I previously mentioned Carbon is pure-C UI/graphics library for Mac  
OS X that is legacy and partial compatible with older versions such as  
Mac OS 8 & 9. Since it is legacy, all new features doesn't go into  
Carbon so Carbon doesn't expose all OSX functionality, also there's no  
64-bit Carbon.
So, Yes you can write Wine OSX support using pure-C Carbon library,  
but beware that it is LEGACY and Apple doesn't recommend you to use  
it. Moreover it can be discontinued at some 10.x release, so all your  
work will be wasted.


Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is NextStep  
based objective oriented GUI & OS. And Obj-C is a basement of both  
NextStep and OSX. So if you want to write OSX GUI application properly  
you have to use Obj-C, same as C++ & KDE and so on.


So forcing constraint that all Wine source files have to be C is  
simply unreasonable in this case. You can easily achieve that only OSX  
dependent source files will be Obj-C, while having OS independent code  
to be pure-C - as C is a subset of Obj-C, and Obj-C is backwards  
compatible with C. So from the other OSes point of view Wine will be  
still pure-C program.


Cheers,
--
Adam

Re: transl and sublangs are not showing neutral

[Paul Vriens]

Ricardo Filipe wrote:



2009/7/8 Paul Vriens >


Ricardo Filipe wrote:



2009/7/8 Paul Vriens mailto:paul.vriens.w...@gmail.com>
>>


   Paul Vriens wrote:

   Ricardo Filipe wrote:

   hi mikolaj,

   in transl the Portuguese language (not Portugese :( )
is not
   showing most of the neutral strings for it's sublangs
   (portugal and brazil).
   i think this is not how it should be... in each
sublang it
   should show the Neutral derived strings and the
warning that
   neutral is being used and should not be used aside the
   language name in the main list, not put neutral
separate in
   another hidden page.

   as it is now it's hard for me to know what is
translated and
   what's not. what do you (and wine devel) think? could you
   please change this?

   regards,
   Ricardo


 
 



   Hi Ricardo,

   So you would be happy/happier if we show "Portuguese
(Neutral)"
   (with the warning) on the main page next to the "Portuguese
   (Portugal)" and "Portuguese (Brazilian)"?

   Just re-read your email. What you like is to have "Portuguese
   (Portugal)" show the combination of "Portuguese (Portugal)" and
   "Portuguese (Neutral)", correct? With a warning for the neutral
   resources.

   What does this mean for "English (Neutral)" should that be
treated
   the same or is Portuguese an exception?

   --Cheers,

   Paul.


yes that is what i would like and think is correct showing.
portuguese strings should defer to neutral if none is found in
the sublang, with a warning that they may be incorrect.

i would say english is the exception by having all translated in
SUBLANG_DEFAULT and not separating sublangs as is done with
portuguese resources and others.
as i stated in irc one of these days, i think the solution to
english is to have a SUBLANG_BRITISH or whatever and not assume
neutral is for british english, how it is right now contradicts
the use of wrc which is sublang -> neutral -> default (english).
i'd say english should have all resources in neutral and then
the different ones in sublang_british or sublang_australian or
other.

at least that is what makes sense to me for the process to be
consistent.


The attached patch makes transl behave more or less the way you want
I think.

The rest of the pages look fine to me as well (see attached
screenshots). The only thing not correct in those screenshots is
kernel32 being marked as partial where it should be "not translated".

It of course also doesn't have the warning in front of it but that
seems trivial. So see this as a proof of concept.

We of course need some kind of consensus here whether this is the
way forward.

-- 
Cheers,


Paul.

diff --git a/transl/scripts/ver.pl b/transl/scripts/ver.pl
index 9b7f289..dd898d6 100755
--- a/transl/scripts/ver.pl
+++ b/transl/scripts/ver.pl
@@ -83,9 +83,11 @@ $norm_fn = $filename;
 $norm_fn =~ s/[^a-zA-Z0-9]/-/g;
 #mkdir "$workdir/dumps/$norm_fn";

-...@file_langs = ("009:01");
+...@file_langs = ("009:01","016:01","016:02"); # See also comments below
 #$deflangs{"009:00"} = TRUE;
-$deflangs{"009:01"} = TRUE;
+$deflangs{"009:01"} = TRUE; # Make sure 'English (US)' always
inherits from 'English (Neutral)' if needed
+$deflangs{"016:01"} = TRUE; # Make sure 'Portuguese (Brazilian)'
always inherits from 'Portuguese (Neutral)' if needed
+$deflangs{"016:02"} = TRUE; # Make sure 'Portuguese (Portugal)'
always inherits from 'Portuguese (Neutral)' if needed

 while ()
 {


that looks almost right, there is a bug though: it's showing non 
translated pages as partially translated (e.g. see cryptui and winedbg).


and yeah it would be good to have other people's opinions to see if this 
is the right track. it sure helps to have all resources together to see 
what's missing.


Yeah, that's why I mentioned kernel32 as that was the most obvious to me 
(I think there are only 4 translations for kernel32).


Will investigate further though.

--
Cheers,

Paul.

Font problem in Notepad -- regression today

[Susan Cragin]

Notepad is behaving very strangely today. It crashes every time I try to change 
the font. 
However, when I tried to trace the problem using winedbg, the font changed 
fine, after the following fixme showed up. 
Then when I closed the winedbg terminal window, notepad closed too. 

su...@ubuntu:~$ winedbg
Wine-dbg>info process
 pid  threads  parent   executable (all id:s are in hex)
 0008 1 'notepad.exe'
 000e 3000a 'services.exe'
 0011 4000e 'winedevice.exe'
 0018 10008 'explorer.exe'
Wine-dbg>attach 0x8
0x680007f0 GLIBC_2+0x7f0 in ld-linux.so.2: int  $0x80
Wine-dbg>set $BreakOnFirstChance=0
Wine-dbg>cont
fixme:winedbg:be_i386_is_func_call Unsupported yet call insn (0xcd) at 
0x680007f0

Re: transl and sublangs are not showing neutral

[Ricardo Filipe]

2009/7/8 Paul Vriens 

> Ricardo Filipe wrote:
>
>>
>>
>> 2009/7/8 Paul Vriens > paul.vriens.w...@gmail.com>>
>>
>>
>>Paul Vriens wrote:
>>
>>Ricardo Filipe wrote:
>>
>>hi mikolaj,
>>
>>in transl the Portuguese language (not Portugese :( ) is not
>>showing most of the neutral strings for it's sublangs
>>(portugal and brazil).
>>i think this is not how it should be... in each sublang it
>>should show the Neutral derived strings and the warning that
>>neutral is being used and should not be used aside the
>>language name in the main list, not put neutral separate in
>>another hidden page.
>>
>>as it is now it's hard for me to know what is translated and
>>what's not. what do you (and wine devel) think? could you
>>please change this?
>>
>>regards,
>>Ricardo
>>
>>
>>
>>  
>>
>>
>>Hi Ricardo,
>>
>>So you would be happy/happier if we show "Portuguese (Neutral)"
>>(with the warning) on the main page next to the "Portuguese
>>(Portugal)" and "Portuguese (Brazilian)"?
>>
>>Just re-read your email. What you like is to have "Portuguese
>>(Portugal)" show the combination of "Portuguese (Portugal)" and
>>"Portuguese (Neutral)", correct? With a warning for the neutral
>>resources.
>>
>>What does this mean for "English (Neutral)" should that be treated
>>the same or is Portuguese an exception?
>>
>>--Cheers,
>>
>>Paul.
>>
>>
>> yes that is what i would like and think is correct showing. portuguese
>> strings should defer to neutral if none is found in the sublang, with a
>> warning that they may be incorrect.
>>
>> i would say english is the exception by having all translated in
>> SUBLANG_DEFAULT and not separating sublangs as is done with portuguese
>> resources and others.
>> as i stated in irc one of these days, i think the solution to english is
>> to have a SUBLANG_BRITISH or whatever and not assume neutral is for british
>> english, how it is right now contradicts the use of wrc which is sublang ->
>> neutral -> default (english). i'd say english should have all resources in
>> neutral and then the different ones in sublang_british or sublang_australian
>> or other.
>>
>> at least that is what makes sense to me for the process to be consistent.
>>
>
> The attached patch makes transl behave more or less the way you want I
> think.
>
> The rest of the pages look fine to me as well (see attached screenshots).
> The only thing not correct in those screenshots is kernel32 being marked as
> partial where it should be "not translated".
>
> It of course also doesn't have the warning in front of it but that seems
> trivial. So see this as a proof of concept.
>
> We of course need some kind of consensus here whether this is the way
> forward.
>
> --
> Cheers,
>
> Paul.
>
> diff --git a/transl/scripts/ver.pl b/transl/scripts/ver.pl
> index 9b7f289..dd898d6 100755
> --- a/transl/scripts/ver.pl
> +++ b/transl/scripts/ver.pl
> @@ -83,9 +83,11 @@ $norm_fn = $filename;
>  $norm_fn =~ s/[^a-zA-Z0-9]/-/g;
>  #mkdir "$workdir/dumps/$norm_fn";
>
> -...@file_langs = ("009:01");
> +...@file_langs = ("009:01","016:01","016:02"); # See also comments below
>  #$deflangs{"009:00"} = TRUE;
> -$deflangs{"009:01"} = TRUE;
> +$deflangs{"009:01"} = TRUE; # Make sure 'English (US)' always inherits
> from 'English (Neutral)' if needed
> +$deflangs{"016:01"} = TRUE; # Make sure 'Portuguese (Brazilian)' always
> inherits from 'Portuguese (Neutral)' if needed
> +$deflangs{"016:02"} = TRUE; # Make sure 'Portuguese (Portugal)' always
> inherits from 'Portuguese (Neutral)' if needed
>
>  while ()
>  {
>

that looks almost right, there is a bug though: it's showing non translated
pages as partially translated (e.g. see cryptui and winedbg).

and yeah it would be good to have other people's opinions to see if this is
the right track. it sure helps to have all resources together to see what's
missing.

Re: Obsolete print dialogs in comdlg32?

[Austin English]

2009/7/8 Frédéric Delanoy :
> Hi,
>
> During update of translation of comdlg32 dialogs, I saw that some
> printing dialogs seem broken, namely PRINT and PRINT_SETUP,
> while PRINT32 and PRINT32_SETUP look OK.
>
> I checked some programs and the PRINT[_SETUP] dialogs don't seem to be
> used (a casual check in the code didn't find usages).
>
> Are they still needed? Or can they simply be deleted?

I haven't looked at the code, but perhaps they're used for 16-bit programs?

-- 
-Austin

Re: winhttp(2/5): Simplify netconn_resolve when using getaddrinfo

[Juan Lang]

> This causes test failures, you can't ignore the port.

Thanks Hans, I'll rework it.
--Juan

Re: [comctl32/tests] Fix test failures with comctl32 <= 5.80

[Nikolay Sivov]

Paul Vriens wrote:

Hi,

Most of them are with comctl32 <= 5.80 but there seem to be some 
different failures for 4.70. And not all failures for <= 5.80 are on 
4.70. I didn't think changing the comment for that is a big deal.


I don't have 4.70 on any of my boxes but I've tested with 4.72.

Changelog
  Fix test failures with comctl32 <= 5.80


You forgot a patch.

Re: transl and sublangs are not showing neutral

[Ricardo Filipe]

2009/7/8 Paul Vriens 

> Paul Vriens wrote:
>
>> Ricardo Filipe wrote:
>>
>>> hi mikolaj,
>>>
>>> in transl the Portuguese language (not Portugese :( ) is not showing most
>>> of the neutral strings for it's sublangs (portugal and brazil).
>>> i think this is not how it should be... in each sublang it should show
>>> the Neutral derived strings and the warning that neutral is being used and
>>> should not be used aside the language name in the main list, not put neutral
>>> separate in another hidden page.
>>>
>>> as it is now it's hard for me to know what is translated and what's not.
>>> what do you (and wine devel) think? could you please change this?
>>>
>>> regards,
>>> Ricardo
>>>
>>>
>>> 
>>>
>>>
>>>  Hi Ricardo,
>>
>> So you would be happy/happier if we show "Portuguese (Neutral)" (with the
>> warning) on the main page next to the "Portuguese (Portugal)" and
>> "Portuguese (Brazilian)"?
>>
>>  Just re-read your email. What you like is to have "Portuguese (Portugal)"
> show the combination of "Portuguese (Portugal)" and "Portuguese (Neutral)",
> correct? With a warning for the neutral resources.
>
> What does this mean for "English (Neutral)" should that be treated the same
> or is Portuguese an exception?
>
> --
> Cheers,
>
> Paul.
>

yes that is what i would like and think is correct showing. portuguese
strings should defer to neutral if none is found in the sublang, with a
warning that they may be incorrect.

i would say english is the exception by having all translated in
SUBLANG_DEFAULT and not separating sublangs as is done with portuguese
resources and others.
as i stated in irc one of these days, i think the solution to english is to
have a SUBLANG_BRITISH or whatever and not assume neutral is for british
english, how it is right now contradicts the use of wrc which is sublang ->
neutral -> default (english). i'd say english should have all resources in
neutral and then the different ones in sublang_british or sublang_australian
or other.

at least that is what makes sense to me for the process to be consistent.

Obsolete print dialogs in comdlg32?

[Frédéric Delanoy]

Hi,

During update of translation of comdlg32 dialogs, I saw that some
printing dialogs seem broken, namely PRINT and PRINT_SETUP,
while PRINT32 and PRINT32_SETUP look OK.

I checked some programs and the PRINT[_SETUP] dialogs don't seem to be
used (a casual check in the code didn't find usages).

Are they still needed? Or can they simply be deleted?

Frédéric

Re: winhttp(2/5): Simplify netconn_resolve when using getaddrinfo

[Hans Leidekker]

Hi Juan,

-*sa_len = sizeof(struct sockaddr_in);
-memset( sa, 0, sizeof(struct sockaddr_in) );
-memcpy( &((struct sockaddr_in *)sa)->sin_addr, &((struct sockaddr_in 
*)res->ai_addr)->sin_addr, sizeof(struct in_addr) );
-((struct sockaddr_in *)sa)->sin_family = res->ai_family;
-((struct sockaddr_in *)sa)->sin_port = htons( port );
+*sa_len = res->ai_addrlen;
+memcpy( sa, res->ai_addr, res->ai_addrlen );

This causes test failures, you can't ignore the port.

 -Hans

Re: [1/3] WineD3D: An indirect address op can adjust min and max at the same time

[Stefan Dösinger]

Am Wednesday 08 July 2009 08:46:02 schrieb Henri Verbeet:
> If you're going to fix it, you might as well fix it properly. There's
> no point in assigning min_rel_offset or max_rel_offset if they're
> already the same as reg->idx.
Hmm true. Its a minor detail, but I send a new patch

RE: [Wine] Tmax Window(a propietary OS) using Wine?

[Nicklas Börjesson]

> Surely the wine test suite would be a rough guide.

Some more information(a marketwire article):

http://www.marketwire.com/press-release/Tmax-1013937.html 

The company behind it:

http://us.tmaxsoft.com/jsp/main.jsp


//Nicklas