Re: VB6 and wine_get_unix_file_name

[Marcelo Duarte]

UnixPath = GetUnixPath() needs a parameter...

Escuder Nicolas escreveu:
>
> Hello,
>
> I’m trying to make a function for using wine_get_unix_file_name in VB6 
> programs.
>
> Private Declare Function lstrcpyA Lib "kernel32.dll" (ByVal lpString1 
> As String, ByVal lpString2 As Long) As Long
>
> Public Declare Function GetProcessHeap Lib "kernel32" () As Long
>
> Public Declare Function HeapFree Lib "kernel32" (ByVal hHeap As Long, 
> ByVal dwFlags As Long, IpMem As Any) As Long
>
> Public Declare Function wine_get_unix_file_name Lib "kernel32" (ByVal 
> lpszSrc As String) As Long
>
> Public Function GetUnixPath(ByVal sPath As String) As String
>
> Dim ptr As Long
>
> Dim sBuffer As String * 255
>
> ptr = wine_get_unix_file_name(StrConv(sPath, vbUnicode))
>
> lstrcpyA sBuffer, ptr
>
> HeapFree GetProcessHeap(), 0, ByVal ptr
>
> GetUnixPath = sBuffer
>
> End Function
>
> Sub Main()
>
> UnixPath = GetUnixPath()
>
> MsgBox UnixPath
>
> End usb
>
> When running this code I got a blank msgbox can anyone help me please.
>
> See you.
>
> *Escuder Nicolas*
>
> 
>
>
>   

Re: Poll: where do you have certs installed?

[Marcelo Duarte]

Juan Lang escreveu:

Could some of you check where you have, say, OpenSSL's CA certificates
installed, and email me what distro you're running, and the path?

E.g., I'm running Goobuntu, and I have them installed in
/etc/ssl/certs/ca-certificates.crt.

Thanks,
--Juan



  

Fedora 4 (2.6.17-1.2142_FC4)
/etc/pki/tls/certs/ca-bundle.crt

Re: comctl32: treeview: Message sequencing tests

[Marcelo Duarte]

Chris Peterson escreveu:
This is another patch for my CS130 assignment. It adds message 
sequencing tests. Other changes include: I updated one of my previous 
tests which was not testing the implied message; I changed a 
SendMessageW to SendMessageA call in DoFocusTest to fix a problem on 
Windows 98 due to a lack of default unicode support. Any 
comments/suggestions are welcome.

Thanks!
-Chris
  

Hi!
 
@@ -166,7 +315,8 @@ static void DoFocusTest(void)

 assert(hChild2);
 
 ShowWindow(hMainWnd,SW_SHOW);

-SendMessageW(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild);
+/* Using SendMessageA since Win98 doesn't have default unicode support */
+SendMessageA(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild);
  

Use SendMessage() instead.


 static void TestGetSetInsertMarkColor(void)
 {
 COLORREF crColor = RGB(0,0,0);
-SendMessage( hTree, TVM_SETBKCOLOR, 0, crColor );
-crColor = (COLORREF)SendMessage( hTree, TVM_GETBKCOLOR, 0, 0 );
+SendMessage( hTree, TVM_SETINSERTMARKCOLOR, 0, crColor );
+crColor = (COLORREF)SendMessage( hTree, TVM_GETINSERTMARKCOLOR, 0, 0 );
 ok(crColor == RGB(0,0,0), "Insert mark color reported as 0x%.8x, expected 
0x\n", crColor);
  

Re: Stub fro GetRawInputDeviceList

[Marcelo Duarte]

Michał Majchrowicz escreveu:

Hi.
I hope this time it is correct patch and will be accepted.
Regards Michael.

I think the spec file is incorrect.

diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec
index f857105..0517ebc 100644
--- a/dlls/user32/user32.spec
+++ b/dlls/user32/user32.spec
@@ -345,7 +345,7 @@
 # @ stub GetRawInputData
 # @ stub GetRawInputDeviceInfoA
 # @ stub GetRawInputDeviceInfoW
-# @ stub GetRawInputDeviceList
+@ stub GetRawInputDeviceList
  

maybe:
@ stdcall GetRawInputDeviceList(ptr ptr long)

 # @ stub GetReasonTitleFromReasonCode
 # @ stub GetRegisteredRawInputDevices
 @ stdcall GetScrollBarInfo(long long ptr)
diff --git a/include/winuser.h b/include/winuser.

Re: pt_BR

[Marcelo Duarte]

Hi, I´ll write the comments in portuguese, it is for us only (maybe):

grandao escreveu:

patch for README.pt_BR
some minor corrections  ;D


--
[grandão]



  

Grandão, que bom ter alguém na atividade.
Logo no começo tem grafado 2 palavras erradas:

--- README.pt_br2006-05-01 08:55:36.0 -0300
+++ copia2006-05-01 08:55:36.0 -0300
@@ -8,40 +8,42 @@
ou do X11. A biblioteca também pode ser usada para portar código
Win32 em executáveis nativos Unix.

-Wine é software livre, liberado segundo a GNU LGPL; veja o arquivo
-LICENÇA para detalhes.
+Wine é software livre, distrído sob a licensa GNU LGPL; veja o arquivo
+LICENCE para detalhes.
AQUI: distrído e licensa, o correto é licença.

[]
-Como o Wine requer suporte a tarefas a nível de kernel para executar,
+Como o Wine requer suporte à tarefas à nível de kernel para que seja 
executado,

somente os sistemas operacionais acima mencionados são suportados.
-Outros sistemas operacionais que suportarem tarefas do kernel poderão
+Outros sistemas operacionais que suportarem tarefas à nível de kernel 
poderão

ter suporte no futuro.
AQUI: Segundo já vi em programas do professor Pasquale, a expressão "à 
nivel de" é desnecessária, em qq frase.


@@ -173,11 +175,11 @@
7. OBTENDO MAIS INFORMAÇÃO

WWW:Uma grande quantidade de informação sobre o Wine está disponivel
-pelo WineHQ em http://www.winehq.org/ : vários guias do Wine,
-base de dados de aplicações, rastreamento de erros. Este é
+no sítio do Wine(http://www.winehq.org): vários guias do Wine,
+base de dados de aplicações, rastreamento de erros, etc... Este é
provavelmente o melhor ponto para começar.
AQUI: Eu particularmente não gosto dessa tradução "sítio", mas acho q já 
está sendo bem usado né?

 --
Tradução para Português do Brasil: Marcelo Duarte
+Revisão (01/05/2006): Daniel Oliveira

Re: localtime should accept any positive time value

[Marcelo Duarte]

Dmitry Timoshkov escreveu:

Hello,
  

Hello,


--- cvs/hq/wine/dlls/msvcrt/time.c  2006-01-23 20:50:58.0 -0600
+++ wine/dlls/msvcrt/time.c 2006-02-10 12:51:30.0 -0600
@@ -152,8 +152,12 @@ struct MSVCRT_tm* MSVCRT_localtime(const
   SYSTEMTIME st;
   DWORD tzid;
   TIME_ZONE_INFORMATION tzinfo;
+  ULONGLONG time;
 
-  ULONGLONG time = *secs * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970;

+  /* time < 0 means a date before midnight of January 1, 1970 */
+  if (time < 0) return NULL;
+
+  time = *secs * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970;
  

You compared the "time" before it has a assigned value...
 
   ft.dwHighDateTime = (UINT)(time >> 32);

   ft.dwLowDateTime  = (UINT)time;
@@ -161,7 +165,12 @@ struct MSVCRT_tm* MSVCRT_localtime(const
   FileTimeToLocalFileTime(&ft, &lft);
   FileTimeToSystemTime(&lft, &st);
 
-  if (st.wYear < 1970) return NULL;

+  if (st.wYear < 1970)
+  {
+/* if this happens it means that the sequence above does something wrong */
+FIXME("seconds since 1970 %ld => %d/%d/%d %02d:%02d:%02d\n", *secs,
+   st.wDay, st.wMonth, st.wYear, st.wHour, st.wMinute, st.wSecond);
+  }
 
   data->time_buffer.tm_sec  = st.wSecond;

   data->time_buffer.tm_min  = st.wMinute;
  




  

Re: advpack: Implement RunSetupCommand on top of DoInfInstall.

[Marcelo Duarte]

Markus Amsler escreveu:

ChangeLog:
Implement RunSetupCommand on top of DoInfInstall.

You forgot to remove "stub":

+TRACE("(%p, %s, %s, %s, %s, %p, 0x%08lx, %p): stub\n",
hWnd, debugstr_a(szCmdName), debugstr_a(szInfSection),
debugstr_a(szDir), debugstr_a(lpszTitle),
phEXE, dwFlags, pvReserved);
  

Re: [WINECFG] show sound card drivers and devices

[Marcelo Duarte]

Vitaliy Margolen escreveu:

Please update each resource file. We had this discussion before. Please
keep these changes in synch among all the languages. Otherwise we render
sound config useless for other languages.

  
No. If Reif update the others languages, the Beron' script to detect 
what need to translate will fail!

See
http://www.winehq.org/pipermail/wine-devel/2005-November/042209.html



So what you saying is that having it none functional is better then
having it in English?
  

For me, to translate: yes! For users, maybe no!

Re: [WINECFG] show sound card drivers and devices

[Marcelo Duarte]

Vitaliy Margolen escreveu:

Monday, December 5, 2005, 8:53:10 PM, Robert Reif wrote:
  

Show all sound card drivers and their devices.
--- programs/winecfg/En.rc  27 Oct 2005 11:24:02 -  1.54
+++ programs/winecfg/En.rc  6 Dec 2005 03:39:36 -
@@ -155,15 +155,17 @@ FONT 8, "MS Shell Dlg"
 BEGIN



Please update each resource file. We had this discussion before. Please
keep these changes in synch among all the languages. Otherwise we render
sound config useless for other languages.


  
No. If Reif update the others languages, the Beron' script to detect 
what need to translate will fail!

See http://www.winehq.org/pipermail/wine-devel/2005-November/042209.html

Re: CreateFile problem ?

[Marcelo Duarte]

Raphael escreveu:


Hi,

I'm working on advpack API LaunchINFSectionEx (trying to get mdac 2.7 
installer working)


And i have a strage problem:

In attached subset of my "+file,+advpack,+setupapi,+cabinet" log
you can see at line 30 that CopyFile failed to copy 
"C:\\windows\\temp\\IXP010.TMP\\odbc32.dll" 
to "c:\\windows\\system32\\odbc32.dll"


Reason why my install failed.

But: 
# ls -la ~/.wine/dosdevices/c:/windows/temp/IXP010.TMP | grep -i odbc32.dll

-rw-r--r--   1 fenix users  200704 nov 16 23:23 ODBC32.dll

Why it failed to check case insensitive existence ?
 

What file system you are using? I have some problems with FAT. If I 
remenber, the problem arises when the installer is on FAT fs.



Regards,
Raphael
 

Re: Add CMD_FONT for all notepad resource files

[Marcelo Duarte]

Vincent Béron escreveu:


Le jeu 10/11/2005 à 00:56, Pavel Roskin a écrit :
 


ChangeLog:

* programs/notepad/*.rc:
Add CMD_FONT for all notepad resource files where it was
missing.  Ru.rc gets translated version, others get English
version for now.
   



Please don't do that (copying the English part in all resource files).
 

I agree. Please, do not make this, therefore it only increases the 
translation work!

Re: Downloading Mozilla ActiveX

[Marcelo Duarte]

Brian Vincent escreveu:


Or maybe we could just ask the guy who wrote that software if he has a
better place?  In fact, let me do that right now.

-Brian
 

Note: Put a newest version, maybe 
http://www.iol.ie/~locka/mozilla/MozillaControl177.exe

Re: Downloading Mozilla ActiveX

[Marcelo Duarte]

Vitaliy Margolen escreveu:


Tuesday, October 18, 2005, 10:23:02 AM, Marcelo Duarte wrote:
 


If you edit the registry and add:
[Software\\Wine\\shdocvw] 1089668326
"MozillaUrl"="http://www.iol.ie/~locka/mozilla/MozillaControl16.exe";
   


Does that server has enough capacity to handle all Wine users? Will it be there
for a long time?

Vitaliy
 


No. The reason because the registry isn´t created by wine.inf

Re: Downloading Mozilla ActiveX

[Marcelo Duarte]

Vitaliy Margolen escreveu:


At present Wine asks the use it he/she wants to download and install Mozilla
ActiveX. But it doesn't work and doesn't tell the user that it didn't work. This
is not right. We either should say that download/install failed, or don't show
this message in the first place, unless we fix it.
 


If you edit the registry and add:
[Software\\Wine\\shdocvw] 1089668326
"MozillaUrl"="http://www.iol.ie/~locka/mozilla/MozillaControl16.exe";

The download functions normally.

Re: build errors

[Marcelo Duarte]

Oliver Stieber escreveu:


--- Phil Krylov <[EMAIL PROTECTED]> wrote:

 


Hi,

I can't build current CVS version of Wine:

   


I had exactly the same problem, I found that cleaning out my local tree and 
fetching everything
from CVS fixed the problem.

 

To fix the problem for me, instead of clean, I´d do the folowing command 
in wine tree:

rm */*/*.spec.*

Re: DINPUT: protect FF_STATUS usage

[Marcelo Duarte]

Now it compiles...
Thank you!
Daniel Remenak escreveu:


Changelog:
Protect FF_STATUS usage to avoid compile errors on machines with old
linux/input.h

This patch should fix Marcelo Duarte's reported compile error on FC2.

This patch was made against a copy of joystick_linuxinput.c that
already had "linuxinput axis enumeration fixes" and "allow the
creation of an effect while unacquired" applied to it, but it should
apply to an earlier revision.

--Daniel Remenak
 




--- ../wine2/dlls/dinput/joystick_linuxinput.c  2005-09-03 14:29:30.0 
-0700
+++ dlls/dinput/joystick_linuxinput.c   2005-09-03 23:00:35.0 -0700
@@ -302,7 +302,9 @@
  newDevice->ref = 1;
  newDevice->joyfd = -1;
  newDevice->dinput = dinput;
+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION
  newDevice->ff_state = FF_STATUS_STOPPED;
+#endif
  memcpy(&(newDevice->guid),rguid,sizeof(*rguid));
  for (i=0;iwantmin[i] = -32768;
@@ -723,9 +725,11 @@
break;
}
break;
+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION
case EV_FF_STATUS:
This->ff_state = ie.value;
break;
+#endif
default:
FIXME("joystick cannot handle type %d event (code 
%d)\n",ie.type,ie.code);
break;
 





 

Re: wine/dlls/dinput joystick_linuxinput.c

[Marcelo Duarte]

Alexandre Julliard escreveu:


ChangeSet ID:   19966
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED]   2005/09/03 10:02:38

Modified files:
	dlls/dinput: joystick_linuxinput.c 


Log message:
Daniel Remenak <[EMAIL PROTECTED]>
Implement EnumEffects, CreateEffect, EnumCreatedEffects,
SendForceFeedbackCommand, and GetForceFeedbackStatus for linux input
joysticks.

Patch: http://cvs.winehq.org/patch.py?id=19966

Old revision  New revision  Changes Path
1.25  1.26  +377 -12wine/dlls/dinput/joystick_linuxinput.c
 

I think that this patch is the cause of a compiler error in my box 
(Fedora core 2):


make[2]: Entering directory `/home/mduarte/wine/dlls/dinput'
gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__   
-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 
-fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2  -o 
joystick_linuxinput.o joystick_linuxinput.c

joystick_linuxinput.c: In function `alloc_device':
joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first 
use in this function)
joystick_linuxinput.c:305: error: (Each undeclared identifier is 
reported only once

joystick_linuxinput.c:305: error: for each function it appears in.)
joystick_linuxinput.c: In function `joy_polldev':
joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use 
in this function)

joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects':
joystick_linuxinput.c:1182: warning: unused variable `dei'
joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects':
joystick_linuxinput.c:1266: warning: unused variable `dei'
make[2]: ** [joystick_linuxinput.o] Erro 1
make[2]: Leaving directory `/home/mduarte/wine/dlls/dinput'
make[1]: ** [dinput/__install-lib__] Erro 2
make[1]: Leaving directory `/home/mduarte/wine/dlls'
make: ** [dlls/__install-lib__] Erro 2

Re: wine/ tools/winegcc/winegcc.c tools/winegcc/Ma ...

[Marcelo Duarte]

Hum I do make and the error occurs compile ntdll. I do make again 
and it builds. Is this behavior correct?


OS Fedora Core 2
gcc --version
gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)


Marcelo Duarte escreveu:


This patch cause a error: winegcc: prelink failed.
OS: Fedora Core 2 with last updates from Lecacy Fedora.

...
Alexandre Julliard escreveu:





Log message:
Added support for the --image-base linker option in winegcc using 
the

prelink tool.

Re: wine/ tools/winegcc/winegcc.c tools/winegcc/Ma ...

[Marcelo Duarte]

This patch cause a error: winegcc: prelink failed.
OS: Fedora Core 2 with last updates from Lecacy Fedora.

Output:
../../tools/winegcc/winegcc -B../../tools/winebuild -shared 
./kernel32.spec comm.drv.spec.o krnl386.exe.spec.o stress.spec.o 
system.drv.spec.o toolhelp.spec.o win87em.spec.o windebug.spec.o 
atom16.o error16.o registry16.o toolhelp16.o win87em.o  actctx.o atom.o 
change.o comm.o computername.o console.o cpu.o debugger.o dosmem.o 
editline.o environ.o except.o fiber.o file.o file16.o format_msg.o 
global16.o heap.o instr.o kernel_main.o lcformat.o local16.o locale.o 
lzexpand.o module.o ne_module.o ne_segment.o oldconfig.o path.o 
powermgnt.o process.o profile.o pthread.o relay16.o resource.o 
resource16.o selector.o snoop16.o stress.o string.o sync.o syslevel.o 
system.o tape.o task.o thread.o thunk.o time.o toolhelp.o utthunk.o 
version.o virtual.o volume.o vxd.o windebug.o wowthunk.o relay16asm.o 
kernel32.dll.dbg.o kernel.res  -Wl,--image-base,0x7b80 -o 
kernel32.dll.so -L../../dlls -L../../dlls/ntdll -lntdll  
-L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode  
-L../../libs/port -lwine_port

winegcc: prelink failed.
make[2]: ** [kernel32.dll.so] Erro 2
make[2]: Leaving directory `/home/mduarte/wine/dlls/kernel'
make[1]: ** [kernel] Erro 2
make[1]: Leaving directory `/home/mduarte/wine/dlls'
make: ** [dlls] Erro 2

Alexandre Julliard escreveu:


ChangeSet ID:   19399
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED]   2005/08/09 06:12:30

Modified files:
	tools/winegcc  : winegcc.c Makefile.in 
	.  : configure.ac configure Make.rules.in 


Log message:
Added support for the --image-base linker option in winegcc using the
prelink tool.

Patch: http://cvs.winehq.org/patch.py?id=19399

Old revision  New revision  Changes Path
1.39  1.40  +32 -3  wine/tools/winegcc/winegcc.c
1.14  1.15  +2 -1   wine/tools/winegcc/Makefile.in
1.391 1.392 +6 -0   wine/configure.ac
1.690 1.691 +48 -1  wine/configure
1.187 1.188 +1 -0   wine/Make.rules.in



 

Re: Add ShellExecute() conformance tests

[Marcelo Duarte]

Saulius Krasuckas escreveu:


* On Fri, 22 Jul 2005, Francois Gouget wrote:
 

So the goal of this conformance test is to at least get things started 
and to test a few sticking points like putting quotes around the
   



One test fails on my box:
 


In my box it pass(1).


| $ make -C dlls/shell32/tests/ test
| make: Entering directory 
`/mnt/antras/usr/src/wine-cvs/wine/dlls/shell32/tests'
| ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so 
shlexec.c && touch shlexec.ok
| shlexec.c:275: Test failed: ShellExecute(null, 
"C:\windows\temp\\test_shortcut_shlexec.lnk", null, null) failed: rc=31 err=0
| make: *** [shlexec.ok] Error 1

Any ideas?
 


Do you have the dir "C:\windows\temp" (2)?



 


(1) output of test:
make -C dlls/shell32/tests/ test
make: Entering directory `/home/mduarte/wine/dlls/shell32/tests'
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so shelllink.c && touch shelllink.ok
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so shellpath.c && touch shellpath.ok
fixme:shell:_SHGetUserProfilePath unsupported for user other than 
current or default
fixme:shell:_SHGetUserProfilePath unsupported for user other than 
current or default
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so shlexec.c && touch shlexec.ok
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so shlfileop.c && touch shlfileop.ok
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so shlfolder.c && touch shlfolder.ok
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p 
shell32_test.exe.so string.c && touch string.ok

make: Leaving directory `/home/mduarte/wine/dlls/shell32/tests'

(2) existence of the directory:
ll ~/c/windows/temp/
total 0

Re: Get FireFox button ?

[Marcelo Duarte]

Wine uses an Mozilla ActiveX in shdocvw, and Jacek is using Gecko in 
another part, forcing the user to have Firefox, no?
In another side, the user of Wine, is using Linux and Firefox or another 
Open Source Browser, not IE.


[EMAIL PROTECTED] escreveu:

Yes but anyone looking a wine knows about Linux and knows about the  
ammount crap to expect for IE be it on wine or windows


I find it hard to imagine that anyone coming to wine needs to be made  
aware of FF or any other non-IE browser.


The Open-standards link suggested would be a good idea for a link page 
but  I agree with Marcus that it is not needed on the front page.


Why not some worthy appeal buttons as well , Tsunami victims are less  
important than FireFox?


m2c ;)

On Wed, 06 Jul 2005 14:27:12 +0200, Andreas Mohr  
<[EMAIL PROTECTED]> wrote:



Hi,

On Wed, Jul 06, 2005 at 01:46:06PM +0200, Holly Bostick wrote:


By the way, did you guys know that Mozilla.org links to CX on the
plugins page?

http://plugindoc.mozdev.org/linux.html

Check the bottom of the page.

They even bring Wine into it, and compliment Codeweavers for their
support of the Wine project.

Damn decent of them, really.

But, whatever.

Holly


Do I sense some slight disagreement in this mail? ;-)

Well, I for one am slightly astonished about that FireFox button  
reaction.


The whole world is talking about the lack of interoperability or  
community

efforts within the OSS community, and here we are blindly rejecting
any attempt to go into such a direction.

So, while it can very easily be considered not very "PC" to place a  
specific

Mozilla button on the main page, a non-specific "you may get a
standards-compliant browser here" button surely cannot hurt?
(provided a decent web site exists for such an effort, and provided we
really want to do that)

I mean, *did* we have a huge amount of pain from all the non-standard
web pages caused by the "less than perfectly" interoperable 
Intrusion  Engine,

or didn't we?
And *did* we have huge pains from the continually reoccurring security
issues of IE or didn't we?

Next time you tell us we should remove the donation button from the
web page since it distracts users...

Andreas Mohr

Re: Get FireFox button ?

[Marcelo Duarte]

Wine uses an Mozilla ActiveX in shdocvw, and Jacek is using Gecko in 
another part, forcing the user to have Firefox, no?
In another side, the user of Wine, is using Linux and Firefox or another 
Open Source Browser, not IE.


[EMAIL PROTECTED] escreveu:

Yes but anyone looking a wine knows about Linux and knows about the  
ammount crap to expect for IE be it on wine or windows


I find it hard to imagine that anyone coming to wine needs to be made  
aware of FF or any other non-IE browser.


The Open-standards link suggested would be a good idea for a link page 
but  I agree with Marcus that it is not needed on the front page.


Why not some worthy appeal buttons as well , Tsunami victims are less  
important than FireFox?


m2c ;)

On Wed, 06 Jul 2005 14:27:12 +0200, Andreas Mohr  
<[EMAIL PROTECTED]> wrote:



Hi,

On Wed, Jul 06, 2005 at 01:46:06PM +0200, Holly Bostick wrote:


By the way, did you guys know that Mozilla.org links to CX on the
plugins page?

http://plugindoc.mozdev.org/linux.html

Check the bottom of the page.

They even bring Wine into it, and compliment Codeweavers for their
support of the Wine project.

Damn decent of them, really.

But, whatever.

Holly


Do I sense some slight disagreement in this mail? ;-)

Well, I for one am slightly astonished about that FireFox button  
reaction.


The whole world is talking about the lack of interoperability or  
community

efforts within the OSS community, and here we are blindly rejecting
any attempt to go into such a direction.

So, while it can very easily be considered not very "PC" to place a  
specific

Mozilla button on the main page, a non-specific "you may get a
standards-compliant browser here" button surely cannot hurt?
(provided a decent web site exists for such an effort, and provided we
really want to do that)

I mean, *did* we have a huge amount of pain from all the non-standard
web pages caused by the "less than perfectly" interoperable 
Intrusion  Engine,

or didn't we?
And *did* we have huge pains from the continually reoccurring security
issues of IE or didn't we?

Next time you tell us we should remove the donation button from the
web page since it distracts users...

Andreas Mohr

Re: [WINECFG] Japanese translation

[Marcelo Duarte]

Frank Richter escreveu:


On 05.07.2005 09:28, Hajime Segawa wrote:
 


+FONT 9, "MS UI Gothic"
   



Isn't it on Windows the case that dialogs generally use "MS Shell Dlg[
2]", which is at runtime mapped to a font appropriate for the language
(e.g. "MS UI Gothic" for Japanese)?

 


Read this:
http://www.winehq.org/hypermail/wine-devel/2005/02/0410.html

Because of that, I make a patch:
http://cvs.winehq.org/patch.py?id=16218



This link, while not 100% on that topic, contains some links:
http://blogs.msdn.com/michkap/archive/2005/03/20/399322.aspx

-f.r.



 

Re: winefile: switch to UNICODE mode

[Marcelo Duarte]

Martin Fuchs escreveu:


Changelog:
switch winefile to UNICODE mode
 

I don´t understand something or winefile can use Michael Jung´s unixfs 
namespace extension?



+
+/* functions in unixcalls.c */
+
+extern void call_getcwd(char* buffer, size_t len);
+extern void* call_opendir(const char* path);
+extern int call_readdir(void* pdir, char* name, unsigned* pinode);
+extern void call_closedir(void* pdir);
+
+extern int call_stat(
+   const char* path, int* pis_dir,
+   unsigned long* psize_low, unsigned long* psize_high,
+   time_t* patime, time_t* pmtime,
+   unsigned long* plinks
+);
+
#endif
 

Re: Wine and raw printing

[Marcelo Duarte]

Hiji escreveu:


I'll join, and add this.  I'm on Suse 9.2 Pro,
wine-20041203, and the only printers I have are on the
network.  I can print fine through any native linux
apps, but if I try to print through Wine, it says
there are no printers.

Maybe the problems are related somehow?

Hiji

 

I think that you need CUPS instaled, and if you build wine from sources, 
you need cups-devel.

Re: wcmd: Remove user32 dependencies

[Marcelo Duarte]

James Hawkins escreveu:


Hi,

This patch is in responese to Bug #1982 'Can't SSH into a computer and
use "wine cmd" or wineconsole'

http://bugs.winehq.org/show_bug.cgi?id=1982

The problem as identified by Marcus is that wcmd is importing user32
which brings in the x11 driver causing the ssh'ed wcmd to fail:

(~)> wine cmd
x11drv: Can't open display:
 

The command "wine wcmd" or "wcmd" produces to me the same results and I 
do not see the errors described in bug1892. Only the keyboard input is 
bad, but the message above is not displayed to me.
The command "wineconsole wcmd" functions. My terminal is 80x50 and it 
display on top 40x50.



I couldn't figure out any other way to get rid of LoadString.  It's
pretty essential since we're loading multilingual help strings from
resource files.

Changelog
* Dynamically call LoadString from user32.
* Remove all direct user32 dependencies.
* Don't import user32.

 

I dont think that this is necessary. This is not the cause of bug 1892. 
Maybe export DISPLAY

Re: Change of email addr?

[Marcelo Duarte]

Dimi Paun escreveu:


On Mon, 2005-05-23 at 20:39 +0100, Ann and Jason Edmeades wrote:
 


Hiya, Is there any way to change the email address I am registered
with for the wine mailing lists, bug tracking, Changelog etc, or is
the best way just to reregister for them all with a different id?
   



That's the way you do it AFAIK. At least that's what I did.

 


Only for bugzilla you can change the email address...

Re: Another debugging tutorial

[Marcelo Duarte]

Stefan Dösinger escreveu:
Am Mittwoch, 18. Mai 2005 22:00 schrieb Mike Hearn:
 

This time, it's how to debug PE Explorer hanging when you double click on
a DLL in the file open dialog (fixed in CVS).
 http://wiki.winehq.com/Debugging_the_PE_Explorer_file_open_dialog
Newbie developers, I crave your feedback. Are these actually useful or am
I wasting my time?
   

To me they are quit useful. Thanks ;-)
 

Good.

Re: No rule to make target distclean ??

[Marcelo Duarte]

Dustin Navea escreveu:
Im troubleshooting bug 2962 
http://bigs.winehq.com/show_bug.cgi?id=2962 and I had the reporter 
revert to the october release.  But when trying to compile it, it 
failed, so I told him to do make distclean.. Now he's getting the no 
rule to make target distclean... Im stumped as to what to do... Can 
someone help me out?

Dustin

If is a clean install, like you instructed him, a
cd wine
./configure
make depend && make
su -c "make install"
should be ok.
configure generates the make rules.

Re: [wine] Re: A better Beep

[Marcelo Duarte]

David Lee Lambert escreveu:
On Tue, May 17, 2005 at 10:43:25AM -0300, Marcelo Duarte wrote:
 

Whats happens if a program calls bepp with invalid values for dwFreq and 
dwDur on a linux console?
   

The bell becomes inaudible until reset by another terminal-control 
sequence.  However,  the special value (duration=-1) does not have the 
same semantics;  it's simply ignored.

On my box that has a PC speaker,  the bell is silent when any of the 
following are true:

freq < 21
dur == 0
dur > 1999
I can't hear any tones above 12000 Hz or so,  but I'm not sure whether 
that's my hearing, the speaker-hardware, or the kernel's decision.

Should I add range-checks on frequency and duration?
 

(the programmer thinks that dwFreq and dwDur are ignored by Win95).
   

That's what the API documentation says.  Are they used on WinXP or Win2k?
 

If you have programs to test, send me.

Re: A better Beep

[Marcelo Duarte]

Whats happens if a program calls bepp with invalid values for dwFreq and 
dwDur on a linux console?
(the programmer thinks that dwFreq and dwDur are ignored by Win95).

David Lee Lambert escreveu:
Changelog:
 Support beeping with the PC speaker when running from the Linux console
 


--- dlls/kernel/console.c.v1_39 Fri May 13 15:38:16 2005
+++ dlls/kernel/console.c   Fri May 13 21:02:19 2005
@@ -193,9 +193,19 @@
 */
BOOL WINAPI Beep( DWORD dwFreq, DWORD dwDur )
{
-static const char beep = '\a';
-/* dwFreq and dwDur are ignored by Win95 */
-if (isatty(2)) write( 2, &beep, 1 );
+   if (strcmp(getenv("TERM"),"linux")==0 && isatty(2)) {
+  /* the Linux console supports setting frequency and duration */
+  char szBeep[50];
+  snprintf(szBeep,50,"\x1B[10;%d]\x1B[11;%d]\a",(int)dwFreq,(int)dwDur);
+  write( 2, szBeep, strlen(szBeep) );
+  usleep(dwDur*1000);
+   } else if (isatty(2)) {
+  /* dwFreq and dwDur are ignored by Win95 */
+  static const char beep = '\a';
+  write( 2, &beep, 1 );
+   } else {
+  /* TODO: we could play a .wav file instead... */
+   }
return TRUE;
}
 

Re: README translations

[Marcelo Duarte]

Dimi, there are little typos in README.pt_br, see below:
Dimitrie O. Paun escreveu:
ChangeLog
   Dimitrie O. Paun <[EMAIL PROTECTED]>
   Update README translations to match the latest
   changes to the English README.
 

...
Index: documentation/README.pt_br
===
RCS file: /var/cvs/wine/documentation/README.pt_br,v
retrieving revision 1.8
diff -u -p -r1.8 README.pt_br
--- documentation/README.pt_br	14 Feb 2005 11:51:05 -	1.8
+++ documentation/README.pt_br	10 May 2005 15:12:04 -
@@ -21,9 +21,8 @@ nível do fonte do Wine (que contém este 

Execute programas conforme "wine [opções] programa". Para maiores 
informações e resolução de problemas, leia o restante deste arquivo, 
-a página "man" do Wine (man wine), os arquivos incluídos no diretório 
-de documentação do fonte do Wine (veja "DOCUMENTATION"), e especialmente 
-a abundância de informação encontrada em http://www.winehq.org.
+a página "man" do Wine (man wine), o especialmente  a abundância de i
+nformação encontrada em http://www.winehq.org.
 

here the correct is: "..e especialmente a abundância de informação..."
3.REQUERIMENTOS
@@ -91,9 +90,6 @@ Bibliotecas de suporte opcionais:
Se desejar o suporte de impressão do CUPS, por favor instale os pacotes
cups e cups-devel.
-Para os requesitos no caso de ter a intenção de contruir a documentação, veja 
-a seção "DOCUMENTAÇÃO".
-
4.COMPILAÇÃO

No caso de escolher não usar o wineinstall, execute os comandos a seguir
@@ -131,17 +127,7 @@ Não esqueça de desinstalar primeiramente
Wine que possa confitante. Tente qualquer um dos comandos "dpkg -r wine" ou "rpm -e wine" ou "make uninstall" antes de 
instalar.

-Se você quiser ler a documentação fornecida com a fonte do Wine, 
-veja a seção "DOCUMENTAÇÃO".
-
-O Wine requer um arquivo de configuração chamado "config" no diretório 
-~/.wine. O formato deste arquivo é explicado em "man wine.conf"
-(documentation/wine.conf.man).
-O arquivo documentation/samples/config contém um exemplo de arquivo de 
-configuração para ser adaptado e copiado para a localização anteriormente
-mencionada.
-
-Veja a área de suporte em http://www.winehq.org/ para mais sugestões 
+Veja a área de suporte em http://www.winehq.org/ para msugestões 
sobre a configuraçao.
 

here "msugestões" should be "sugestões"
Thanks.

Re: OLEPICTURE: Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case

[Marcelo Duarte]

Alex Villaci­s Lasso escreveu:
Alexandre Julliard wrote:
 
This seems a bit overkill just to retrieve the bitmap size. Couldn't
you simply do a GetObject on the bitmap?

 

You are right. I did a copy&paste from the SerializeIcon code. What do 
you think about this patch?

Changelog:
* Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case
...
+if(GetObjectA(infoIcon.hbmColor, sizeof(bm), &bm) != sizeof(bm)) {
 

Maybe GetObjectW is more consistent (get rid w->A calls)?

Re: OLEAUT32: fix detection of GIF palette index >= 128 for transparency

[Marcelo Duarte]

Hi,
Andreas Mohr escreveu:
Hi,
On Tue, Mar 29, 2005 at 12:43:38PM -0500, Alex Villaci­s Lasso wrote:
 

I traced this problem to a one-line bug in the GIF loading code. The 
code is supposed to initialize a transparency flag to -1 when no 
transparency is used, or else the palette index of the transparency 
color. The sample image I was using indicates that the transparency 
index is 255. Due to an unintended sign extension, the transparency 
index (held in a Byte array of basic type "signed char") is 
sign-extended to the variable "transparency" of basic type "signed int". 
This causes the flag to be assigned the value -1, which happens to be 
the same value used as a no-transparency indicator. So transparency was 
   



Heh, 3 times "the transparency" in exactly the same line position, 4 times
"transparency" in exactly the same position - what did you smoke?? ;-)
(or worse, what did *I* smoke to recognize this?? :-)
 

You is funny I am thinking what you smoked.
What I see is that Alex didn't cut the text, but your email client: yes!
OK, I promise I'll stop that useless fun email here.
Anyway, thanks for all those nice patches,
Andreas Mohr
 

;)

Re: How to install Mozilla ActiveX on demand

[Marcelo Duarte]

Mike Hearn escreveu:
On Wed, 2005-02-16 at 11:26 -0600, Robert Shearman wrote:
 

How about hosting it on SourceForge?
   

Yep, we could, though we'd need to either add extra code to fetch a
mirror list, or hard code it (the latter is much easier :).
There's also the issue of checksumming but I think we can duck that for
now, if a SourceForge mirror is cracked we all have much bigger
problems ...
 

Someone that has access to sourceforge (packagers?) can upload the file:
http://www.iol.ie/~locka/mozilla/MozillaControl16.exe
And email me the url that I´ll try to do a patch.
Thanks.

Re: wine/ programs/winefile/Pt.rc programs/winecfg ...

[Marcelo Duarte]

Francois Gouget escreveu:
On Wed, 16 Feb 2005, Marcelo Duarte wrote:
[...]
+FONT 8, "Helv"

Is this correct?
I copied the English file and only translated the strings.
I thought that we were using "MS Shell Dlg" everywhere except for 
Japanese where we use "MS UI Gothic" instead.
If this is the correct one, can leave that later I make a patch.
There does seem to be some inconsistencies. Two Japanese resource 
files use "Ms Shell Dlg" instead of "MS UI Gothic" (all the others do 
as expected):

$ egrep "^FONT" `find . -name "*.rc"` | grep "Ja.rc" | grep -v "MS UI 
Gothic"
./dlls/shell32/shell32_Ja.rc:FONT 10, "MS Shell Dlg"
./dlls/shell32/shell32_Ja.rc:FONT 8, "MS Shell Dlg"

And the following resource files don't use "MS Shell Dlg":
$ egrep "^FONT" `find . -name "*.rc"` | egrep -v "MS (Shell Dlg|UI 
Gothic)"
./dlls/mpr/mpr_De.rc:FONT 8, "Helv"
./dlls/mpr/mpr_En.rc:FONT 8, "Helv"
./dlls/mpr/mpr_Pt.rc:FONT 8, "Helv"
./dlls/mpr/mpr_Fr.rc:FONT 8, "Helv"
./dlls/shdocvw/En.rc:FONT 8, "Helv"
./dlls/shdocvw/Pt.rc:FONT 8, "Helv"
./dlls/shdocvw/De.rc:FONT 8, "Helv"
./dlls/user/resources/user32_Si.rc:FONT 8, "MS Sabs Serif"
./dlls/user/tests/resource.rc:FONT 8, "System"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/taskmgr/taskmgr.rc:FONT 8, "Tahoma"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/En.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"
./programs/winecfg/Nl.rc:FONT 8, "MS Sans Serif"


+ LTEXT "Por favor, entre como o nome de usuário e a senha:", 
IDC_EXPLAIN,

This is the same thing as "usuário" but encoded as UTF-8. I'm not sure 
we're supposed to use UTF-8 in Wine's resources so that may be a 
problem. Something must have changed the encoding on the way.

Re: wine/ programs/winefile/Pt.rc programs/winecfg ...

[Marcelo Duarte]

Hi,
Alexandre Julliard escreveu:
ChangeSet ID:	16090
CVSROOT:	/opt/cvs-commit
Module name:	wine
Changes by:	[EMAIL PROTECTED]	2005/02/14 05:12:30
 

In this file below, the correct is "usuário", but in cvs is incorrect 
"usuário" and I dont know how to correct...
In my tree it is correct.

Index: wine/dlls/mpr/mpr_Pt.rc
diff -u -p wine/dlls/mpr/mpr_Pt.rc:1.1 wine/dlls/mpr/mpr_Pt.rc:1.2
--- wine/dlls/mpr/mpr_Pt.rc:1.1 Wed Feb 16 09:36:32 2005
+++ wine/dlls/mpr/mpr_Pt.rc Wed Feb 16 09:36:32 2005
@@ -24,3 +24,23 @@ STRINGTABLE DISCARDABLE
{
IDS_ENTIRENETWORK "Toda a rede"
}
+
+IDD_PROXYDLG DIALOG LOADONCALL MOVEABLE DISCARDABLE 36, 24, 250, 154
+STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
+CAPTION "Entre a senha da rede"
+FONT 8, "Helv"
+{
+ LTEXT "Por favor, entre como o nome de usuário e a senha:", IDC_EXPLAIN, 40, 
6, 150, 15
+

Re: wine/ programs/winhelp/Pt.rc programs/winemine ...

[Marcelo Duarte]

Hi,
Sorry for the sincerity, but I am finding bad idea this to mix the 
translations.
My suggestion is to create a new archive for the variation (Ptg.rc or 
Pt_pt.rc, etc).
Thanks for attention.

Alexandre Julliard escreveu:
ChangeSet ID:   16040
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED]   2005/02/10 11:14:16
Modified files:
	programs/winhelp: Pt.rc 
	programs/winemine: Pt.rc 
	programs/winefile: Pt.rc 
	programs/winecfg: Pt.rc 
	programs/wcmd  : Pt.rc 
	programs/view  : Pt.rc 
	programs/start : Pt.rc 
	programs/regedit: Pt.rc 
	programs/progman: Pt.rc 
	programs/notepad: Pt.rc 
	programs/cmdlgtst: Pt.rc 
	programs/clock : Pt.rc 
	dlls/setupapi  : Pt.rc 
	dlls/serialui  : Pt.rc 

Log message:
Américo José Melo <[EMAIL PROTECTED]>
Francois Gouget <[EMAIL PROTECTED]>
Translate the Wine resources to Portuguese.
Patch: http://cvs.winehq.org/patch.py?id=16040
Old revision  New revision  Changes Path
1.8   1.9   +56 -2  wine/programs/winhelp/Pt.rc
1.6   1.7   +29 -1  wine/programs/winemine/Pt.rc
1.2   1.3   +132 -2 wine/programs/winefile/Pt.rc
1.16  1.17  +44 -2  wine/programs/winecfg/Pt.rc
1.3   1.4   +210 -1 wine/programs/wcmd/Pt.rc
1.2   1.3   +39 -2  wine/programs/view/Pt.rc
1.2   1.3   +45 -1  wine/programs/start/Pt.rc
1.7   1.8   +203 -2 wine/programs/regedit/Pt.rc
1.6   1.7   +130 -1 wine/programs/progman/Pt.rc
1.12  1.13  +88 -1  wine/programs/notepad/Pt.rc
1.3   1.4   +139 -1 wine/programs/cmdlgtst/Pt.rc
1.9   1.10  +29 -1  wine/programs/clock/Pt.rc
1.2   1.3   +17 -1  wine/dlls/setupapi/Pt.rc
1.2   1.3   +26 -1  wine/dlls/serialui/Pt.rc

 


--
Marcelo Duarte
DTM Informática
31-3551-3864
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: ntdll/time.c - TZ_INFO

[Marcelo Duarte]

Thank you Tom.
Changelog:
-Correct time zone for BRT and BRST.
-Better explained fixme.
Tom escreveu:
Marcelo Duarte wrote:
Uwe Bonnes escreveu:
"Marcelo" == Marcelo Duarte <[EMAIL PROTECTED]> writes:
  

   Marcelo> Hi, In my system/language I see some messages:
   Marcelo> fixme:ntdll:TIME_GetTZAsStr Can't match system time zone 
name
   Marcelo> "BRST" to an entry in TZ_INFO fixme:ntdll:TIME_GetTZAsStr
   Marcelo> Please add appropriate entry to TZ_INFO and submit as 
patch to
   Marcelo> wine-patches

   Marcelo> And before to update TZ_INFO I modifyied the FIXME and I 
think
   Marcelo> that it explain better the problem: 
fixme:ntdll:TIME_GetTZAsStr
   Marcelo> Can't match system time zone name "BRST", bias=120 and 
dst=1 to
   Marcelo> an entry in TZ_INFO. Please add appropriate entry to 
TZ_INFO
   Marcelo> and submit as patch to wine-patches

   Marcelo> And I see the real problem. In TZ_INFO bias=180 and 
dst=0. I
   Marcelo> added another BRST information. Is this correct?

I don't live in the Brasilian Timezone, so I cant tell. Maybe the 
old entry
was wrong,  or there is a mixup with standard and summer time...

Bye
 

There is a mixup. Standart use bias=180, dst=0 ans summer use 
bias=120, dst=1, but de same entry BRST. I dont know where to find 
information to do the correct behavior.


Hello,
BRT = Brasilia Time  -03:00 Offset from UTC
BRST= Brasilia Summer Time -02:00 Offset from UTC
Tom

Index: time.c
===
RCS file: /home/wine/wine/dlls/ntdll/time.c,v
retrieving revision 1.62
diff -u -p -r1.62 time.c
--- time.c	8 Feb 2005 12:13:36 -	1.62
+++ time.c	14 Feb 2005 05:25:09 -
@@ -145,11 +145,11 @@ static const struct tagTZ_INFO TZ_INFO[]
 {'N','e','w','f','o','u','n','d','l','a','n','d',' ','S','t','a','n','d',
  'a','r','d',' ','T','i','m','e','\0'}, 150, 1},
{"BRT",
-{'E','.',' ','S','o','u','t','h',' ','A','m','e','r','i','c','a',' ','S',
- 't','a','n','d','a','r','d',' ','T','i','m','e','\0'}, 180, 0},
+{'B','r','a','z','i','l','i','a','n',' ','S','t','a','n','d','a','r','d',
+ ' ','T','i','m','e','\0'}, 180, 0},
{"BRST",
-{'E','.',' ','B','r','a','z','i','l','i','a','n',' ','S','t','a','n','d',
- 'a','r','d',' ','T','i','m','e','\0'}, 180, 0},
+{'B','r','a','z','i','l','i','a','n',' ','S','u','m','m','e','r',
+ ' ','T','i','m','e','\0'}, 120, 1},
{"ART",
 {'S','A',' ','E','a','s','t','e','r','n',' ','S','t','a','n','d','a','r',
  'd',' ','T','i','m','e','\0'}, 180, 0},
@@ -815,8 +815,9 @@ static const WCHAR* TIME_GetTZAsStr (tim
  )
 return TZ_INFO[i].psTZWindows;
}
-   FIXME("Can't match system time zone name \"%s\" to an entry in TZ_INFO\n",psTZName);
-   FIXME(" Please add appropriate entry to TZ_INFO and submit as patch to wine-patches\n");
+   FIXME("Can't match system time zone name \"%s\", bias=%d and dst=%d "
+ "to an entry in TZ_INFO. Please add appropriate entry to "
+ "TZ_INFO and submit as patch to wine-patches\n",psTZName,bias,dst);
return NULL;
 }
 

Re: ntdll/time.c - TZ_INFO

[Marcelo Duarte]

Uwe Bonnes escreveu:
"Marcelo" == Marcelo Duarte <[EMAIL PROTECTED]> writes:
   

   Marcelo> Hi, In my system/language I see some messages:
   Marcelo> fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name
   Marcelo> "BRST" to an entry in TZ_INFO fixme:ntdll:TIME_GetTZAsStr
   Marcelo> Please add appropriate entry to TZ_INFO and submit as patch to
   Marcelo> wine-patches
   Marcelo> And before to update TZ_INFO I modifyied the FIXME and I think
   Marcelo> that it explain better the problem: fixme:ntdll:TIME_GetTZAsStr
   Marcelo> Can't match system time zone name "BRST", bias=120 and dst=1 to
   Marcelo> an entry in TZ_INFO. Please add appropriate entry to TZ_INFO
   Marcelo> and submit as patch to wine-patches
   Marcelo> And I see the real problem. In TZ_INFO bias=180 and dst=0. I
   Marcelo> added another BRST information. Is this correct?
I don't live in the Brasilian Timezone, so I cant tell. Maybe the old entry
was wrong,  or there is a mixup with standard and summer time...
Bye
 

There is a mixup. Standart use bias=180, dst=0 ans summer use bias=120, 
dst=1, but de same entry BRST. I dont know where to find information to 
do the correct behavior.

Re: Added path settings to winecfg

[Marcelo Duarte]

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

Re: Added path settings to winecfg

[Marcelo Duarte]

Hi,
I think that you do not need to modify the .rc files from languages
other than En.rc and your native language. If you do not translate, it
will more easy to us to known that it is wrong and needs to be
translated. This is my position in relation to Pt.rc.
Thank you.
Jacek Caban wrote:
Changelog:
Added path settings to winecfg.

Re: Removed slovenian translation

[Marcelo Duarte]

Use diff -u Si.rc /dev/null
Jacek Caban wrote:
I found that slovenian translation is incomplete and not translated,
so I removed this from winecfg.rc. Si.rc should be remove too, but
I don't know how to do this in patch.
Changelog:
Removed slovenian translation
Index: programs/winecfg/winecfg.rc
===
RCS file: /home/wine/wine/programs/winecfg/winecfg.rc,v
retrieving revision 1.10
diff -u -r1.10 winecfg.rc
--- programs/winecfg/winecfg.rc	22 Jul 2004 19:45:00 -	1.10
+++ programs/winecfg/winecfg.rc	16 Aug 2004 19:23:12 -
@@ -32,7 +32,6 @@
 #include "It.rc"
 #include "Pt.rc"
 #include "Ru.rc"
-#include "Si.rc"
 
 LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
 

Re: Localization of devenum and minor corrections

[Marcelo Duarte]

Resend.
Changelog:
Marcelo Duarte <[EMAIL PROTECTED]>
Localization to Portuguese (devenum) and minor corrections (winmm, 
progman, winmine).


Index: dlls/devenum/devenum.rc
===
RCS file: /home/wine/wine/dlls/devenum/devenum.rc,v
retrieving revision 1.7
diff -u -u -r1.7 devenum.rc
--- dlls/devenum/devenum.rc 23 Jul 2004 19:08:44 -  1.7
+++ dlls/devenum/devenum.rc 26 Jul 2004 21:36:02 -
@@ -51,3 +51,12 @@
9  "Dispositivo WaveOut di Default"
10 "Dispositivo MidiOut di Default"
 }
+
+STRINGTABLE DISCARDABLE
+LANGUAGE LANG_PORTUGUESE, SUBLANG_DEFAULT
+{
+   7  "DirectSound padrão"
+   8  "DirectSound: %s"
+   9  "Dispositivo padrão WaveOut"
+   10 "Dispositivo padrão MidiOut"
+}
Index: dlls/winmm/winmm_res.rc
===
RCS file: /home/wine/wine/dlls/winmm/winmm_res.rc,v
retrieving revision 1.15
diff -u -u -r1.15 winmm_res.rc
--- dlls/winmm/winmm_res.rc 13 Jul 2004 23:36:37 -  1.15
+++ dlls/winmm/winmm_res.rc 26 Jul 2004 21:36:10 -
@@ -1,4 +1,4 @@
-/* Multimedia resources (MMSYSTEM.DLL & WINMM.DLL
+/* Multimedia resources (MMSYSTEM.DLL & WINMM.DLL)
  *
  * Copyright (c) 1999, Eric Pouech
  *
Index: programs/progman/Pt.rc
===
RCS file: /home/wine/wine/programs/progman/Pt.rc,v
retrieving revision 1.5
diff -u -u -r1.5 Pt.rc
--- programs/progman/Pt.rc  4 Oct 2003 04:21:19 -   1.5
+++ programs/progman/Pt.rc  26 Jul 2004 21:36:14 -
@@ -38,7 +38,7 @@
MENUITEM "Sai&r do Windows...", PM_EXIT
  }
  POPUP "&Opções" {
-   MENUITEM "&Autoorganizar",  PM_AUTO_ARRANGE
+   MENUITEM "&Auto organizar",  PM_AUTO_ARRANGE
MENUITEM "&Minimizar na execução",PM_MIN_ON_RUN
MENUITEM "&Salvar alterações ao sair", PM_SAVE_SETTINGS
  }
Index: programs/winemine/rsrc.rc
===
RCS file: /home/wine/wine/programs/winemine/rsrc.rc,v
retrieving revision 1.15
diff -u -u -r1.15 rsrc.rc
--- programs/winemine/rsrc.rc   19 Jul 2004 19:34:26 -  1.15
+++ programs/winemine/rsrc.rc   26 Jul 2004 21:36:18 -
@@ -32,14 +32,13 @@
 #include "Ru.rc"
 #include "Si.rc"
+LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL
 IDA_WINEMINE ACCELERATORS DISCARDABLE
 {
 VK_F2, IDM_NEW, VIRTKEY, NOINVERT
 "X", IDM_EXIT, VIRTKEY, ALT, NOINVERT
 }
-
-LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL
 /* BINRES winemine.ico */
 WINEMINE ICON MOVEABLE winemine.ico

Re: devenum

[Marcelo Duarte]

Ivan Leo Puoti wrote:
English resources moved  to En.rc, language neutral resources moved to Xx.rc, 
and italian resources added in It.rc
Licence: LGPL

Ivan.
Ivan,
Why you do not leave the neutral resources in the main archive?
Greetings,
Marcelo

Localization status

[Marcelo Duarte]

Hi,
I modified a tool that Vincent Béron made and thus we can have the 
status of the translation of some languages. Case somebody wants that I 
add others I inform me.
We can see that some languages are well complete, as the Portuguese ;)

file:///home/mduarte/wine/tools/trans_html/index.html 




  

  dlls/oleaut32/oleaut32.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  stringtable
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/comctl32/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  complete
  complete
  complete


  stringtable
  incomplete
  complete
  complete
  complete
  complete
  complete


  dlls/shlwapi/shlwapi.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  nothing
  complete
  complete


  dlls/wineps/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/oledlg/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  nothing
  complete
  complete


  stringtable
  complete
  complete
  complete
  nothing
  complete
  complete


  dlls/avifil32/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  complete
  complete
  complete


  stringtable
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/devenum/devenum.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  stringtable
  nothing
  complete
  nothing
  nothing
  nothing
  nothing


  dlls/user/resources/user32.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  menu
  complete
  complete
  complete
  complete
  complete
  complete


  dialog
  incomplete
  complete
  complete
  complete
  complete
  complete


  stringtable
  nothing
  complete
  complete
  complete
  complete
  complete


  dlls/wininet/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/shell32/shres.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  menu
  nothing
  complete
  complete
  complete
  complete
  complete


  dialog
  incomplete
  complete
  complete
  complete
  complete
  complete


  stringtable
  incomplete
  complete
  complete
  mismatch
  mismatch
  complete


  dlls/msrle32/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  stringtable
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/commdlg/rsrc.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  dialog
  complete
  complete
  complete
  complete
  complete
  complete


  stringtable
  incomplete
  complete
  complete
  complete
  complete
  complete


  dlls/mpr/mpr.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  stringtable
  complete
  complete
  complete
  nothing
  complete
  complete


  dlls/winmm/winmm_res.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  stringtable
  complete
  complete
  complete
  complete
  complete
  complete


  dlls/kernel/kernel.rc



  
  GERMAN
  ENGLISH
  SPANISH
  FRENCH
  ITALIAN
  PORTUGUESE


  string

Re: dlls/shell32 W->A cleanup of systray.c

[Marcelo Duarte]

Danny Hawkins wrote:
Hi,
Converted all wide-char->ansi calls to ansi->wide-char in systray.c
 

The TTM_UPDATETIPTEXTA should be converted to TTM_UPDATETIPTEXTW and 
TTM_ADDTOOLA -> TTM_ADDTOOLW

@@ -272,13 +272,13 @@
  ti.rect.bottom = ICON_SIZE+2*ICON_BORDER;
  if(modify)
-SendMessageA(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti);
+SendMessageW(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti);
  else
-SendMessageA(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti);
+SendMessageW(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti);
}
 

Here, you should'nt cast (WCHAR *)"". Please define:
static const WCHAR emptyW[] = {0};
Or modify the function to accept NULL.
@@ -297,15 +297,15 @@
  (*ptrayItem)->notifyIcon.hWnd = pnid->hWnd; /* only needed for callback message */
  SYSTRAY_ItemSetIcon   (*ptrayItem, (pnid->uFlags&NIF_ICON)   ?pnid->hIcon   
:0);
  SYSTRAY_ItemSetMessage(*ptrayItem, 
(pnid->uFlags&NIF_MESSAGE)?pnid->uCallbackMessage:0);
-  SYSTRAY_ItemSetTip(*ptrayItem, (pnid->uFlags&NIF_TIP)?pnid->szTip   
:"", FALSE);
+  SYSTRAY_ItemSetTip(*ptrayItem, (pnid->uFlags&NIF_TIP)?pnid->szTip   :(WCHAR 
*)"", FALSE);

The old code should be eliminated, not commented:
+/*{
  BOOL flag=FALSE;
  TRACE("enter %p %d %ld\n", pnid->hWnd, pnid->uID, dwMessage);
  switch(dwMessage) {
@@ -377,13 +390,30 @@
  }
  TRACE("leave %p %d %ld=%d\n", pnid->hWnd, pnid->uID, dwMessage, flag);
  return flag;
-}
+}*/
 


+/*{
BOOL ret;
PNOTIFYICONDATAA p = HeapAlloc(GetProcessHeap(),0,sizeof(NOTIFYICONDATAA));
@@ -395,4 +425,4 @@
	HeapFree(GetProcessHeap(),0,p);
	return ret;
-}
+}*/
 

Re: Cleaning up W->A calls

[Marcelo Duarte]

James Hawkins wrote:
First I suggest you to subscribe in the list, you are welcome, thus you 
will receive all the answers from the other users.
http://www.winehq.org/mailman/listinfo/wine-devel

I recently decided to help with the development of Wine, and seeing as
how I am new to the process, I have chosen menial tasks to take on. 
This way I can learn more about Wine while contributing.

I am currently working on the janitorial task of getting rid of W->A
calls and I have a few questions about how I should implement these
changes.
Initially CryptAcquireContextW converts all of its arguments to ansi
then calls CryptAcquireContextA (which is intuitively not what we're
wanting and thus the cleanup.)  

The question is, what exactly is the best way to clean this up?
It seems to me that there are two main options as to what can be done: 

A) convert the W->A calls in the wide-char functions to A->W calls in
the asci functions and implement the wide-char functions instead, or 
 

The best is option A.
If we are to choose plan A, I have seen several different methods of
converting asci to wide-char, and I am wondering which method is best. 
for example:

dlls/advapi32/crypt.c lines 133-141
wcount = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0);
wcount = wcount < wstrsize/sizeof(WCHAR) ? wcount :
wstrsize/sizeof(WCHAR);
if (wstrsize == -1)
*wstr = CRYPT_Alloc(wcount * sizeof(WCHAR));
if (*wstr)
{
MultiByteToWideChar(CP_ACP, 0, str, -1, *wstr, wcount);
return TRUE;
}
and,
dlls/advapi32/registry.c lines 1626-1636
LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, 
LPSECURITY_ATTRIBUTES sa )
{
UNICODE_STRING *fileW = &NtCurrentTeb()->StaticUnicodeString;
NTSTATUS status;
STRING fileA;

RtlInitAnsiString(&fileA, file);
if ((status = RtlAnsiStringToUnicodeString(fileW, &fileA, FALSE)))
return RtlNtStatusToDosError( status );
return RegSaveKeyW(hkey, fileW->Buffer, sa);
}
Which method is better/more efficient?
 

I do not cheched your code, but each situation has its reason and you 
decide which you will be better.
I suggest you to start converting something simple, like:
dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to 
Shell_NotifyIconA
dlls/version/install.c: version: VerInstallFileW: illegal call to 
VerInstallFileA
When I made one of these conversions, I chose "dlls/shell32/shlexec.c: 
shell32: ShellExecuteExW: illegal call to ShellExecuteExAand" very 
laborious and was complicated. You can give one looked at as I made: 
http://cvs.winehq.com/patch.py?id=10692

I would have to argue that implementing both the asci functions and
wide-char functions separately would be the most efficient way to solve
the W->A problem.  Throughout all the wine libs, many conversion calls
are being made from W->A and A->W, when most of these calls could be
left out.  I think performance would improve without all of the
conversion calls.  Granted the size of the code would increase, but
speed would also increase.
 

Yes, but the bugs duplicates, the code increases and the future I 
believe that the majority of the programs is in unicode.

There are a couple snags when it comes to implementing asci and
wide-char functions independently, but that can be discussed later.
If I'm totally off the mark, let me know, and if there are other jobs I
could be doing, let me know as well because I would like to contribute,
but I'm not exactly sure what to do yet.  Thankyou for your time.
James Hawkins
 

 

I wait to have helped.
---
Marcelo Duarte

Re: readme update

[Marcelo Duarte]

Ivan, Dimi had much work in officializing the domain winehq.org and you
modified text placing .com again.

- Original Message - 
From: "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]>
To: "wine-patches" <[EMAIL PROTECTED]>
Sent: Sunday, January 18, 2004 5:44 PM
Subject: readme update


This patch improves the italian version fo the README file, and uniforms it
layout to the one of the English README. It also updates the links to the
faq,
the forums and the cvs to the urls currently used at winehq in all versions
of
README. Alexandre, I think it would be a good idea to move these files to
the root
source directory, so that non-English speakers can spot them immediately. It
may
also be a good idea to rename them something more obvious, for example from
README.it to LEGGIMI.italiano (README.italian), shall I send in a patch that
does this?
License: LGPL

Ivan.

Re: Shell32 patch from ROS 2

[Marcelo Duarte]

OK. Relatively to files shlexec.c (ShellExecute, etc) I will do it. Others
with you  ;)
- Original Message - 
From: "Steven Edwards" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, January 16, 2004 2:15 PM
Subject: Re: Shell32 patch from ROS 2


> Hello Marcelo,
> --- Marcelo Duarte <[EMAIL PROTECTED]> wrote:
> > Changelog:
> > "Martin Fuchs" <[EMAIL PROTECTED]>
> > - fixed HCR_GetExecuteCommandExA/W() to correct ShellExecuteEx()
> > behaviour
> > with flag SEE_MASK_CLASSNAME set
>
> Thanks for your help merging this patch.
> Steven
>
>
> __
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: Janitorial: Get rid of W->A calls for shlexec [RESEND]

[Marcelo Duarte]

Why my patch was not applied? If it will be because it conflicts with the 
patches of the ROS, can leave that in the next weekend I intend to make this, 
thus diminishes the work of them. But necessary to know if my patch it goes 
to be accepted, if I do not go to be losing my time.
Thank you. 
 
Em Sáb 10 Jan 2004 04:51, Marcelo Duarte escreveu:
> Updated with the lastest cvs.
>
> Changelog:
> Marcelo Duarte <[EMAIL PROTECTED]>
> -Janitorial: Get rid of W->A calls for shlexec
> -Implementation of FindExecutableW

-- 
Marcelo Duarte

Re: newbie wine developer question

[Marcelo Duarte]

I think that a good way to contribute is run a program of your interest and
try to make run perfectly. Can I suggest: Winzip (see bug 792), Winamp 5 and
we have a control that is not implemented (richedit).
Gook luck.

- Original Message - 
From: "Mike Hearn" <[EMAIL PROTECTED]>
To: "Zimler Attila" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, December 24, 2003 10:38 AM
Subject: Re: newbie wine developer question


> On Wed, 2003-12-24 at 11:16, Zimler Attila wrote:
> > Am I understanding it correctly: If the application work we can ignore
> > fixmes? (With other words - to do some real work I need an application
> > which does not work? - I have plenty of them if this is the case :)
>
> Yes, that's definately the best way.
>
>
>

Re: wine/windows painting.c

[Marcelo Duarte]

Em Dom 07 Dez 2003 07:01, Andreas Mohr escreveu:
> Hi,
>
> On Sun, Dec 07, 2003 at 03:51:01AM -0300, Marcelo Duarte wrote:
> > This patch caused a regression in Winamp 2.91, and the top window is not
> > repainted.
>
> Maybe (just *maybe*) the patch is actually very correct,
> but Winamp for some reason collects some more "dirty" data that just
> happens to be committed to screen by this random unrelated WM_PAINT
> message...

Yes, you are correct. I made more some tests, also removing all and part of 
the code, and finished discovering that this patch is not the cause. This 
patch only made me to see that the problem existed.


> In other words: the dirty graphics area in Winamp should have been painted
> by some other Windows function already which is responsible for these
> graphics changes in Winamp. Since this seems to not get done, it appears
> that the superfluous WM_PAINT is necessary to clean their act up after the
> fact.
>
> Thus the actual challenge would probably be to find the place where we
> should have issued the REAL WM_PAINT by one way or another, in order to
> make Winamp happy again...

Yes, but nor I know for where to start and still has the problem of the 
heading not to appear if he will not be in desktop mode
-- 
Marcelo Duarte

Re: wine/windows painting.c

[Marcelo Duarte]

This patch caused a regression in Winamp 2.91, and the top window is not 
repainted.
I use with the folowing modifications in the ~/.wine/config:

; Winamp 2.91 runs good, but the title is eated. In desktop is better.
[AppDefaults\\winamp.exe\\x11drv]
"Desktop" = "560x700"

Em Sex 05 Dez 2003 01:42, Alexandre Julliard escreveu:
> ChangeSet ID: 10338
> CVSROOT:  /opt/cvs-commit
> Module name:  wine
> Changes by:   [EMAIL PROTECTED]   2003/12/04 22:42:43
>
> Modified files:
>   windows: painting.c
>
> Log message:
>   In RDW_ValidateParent, get rid of the parent update region if it is
>   empty after the validation, to avoid a useless WM_PAINT.
>
> Patch: http://cvs.winehq.com/patch.py?id=10338
>
> Old revision  New revision  Changes Path
>  1.88  1.89  +9 -1   wine/windows/painting.c
Index: wine/windows/painting.c
diff -u wine/windows/painting.c:1.88 wine/windows/painting.c:1.89
--- wine/windows/painting.c:1.88Sun Dec  7 05:54:18 2003
+++ wine/windows/painting.c Sun Dec  7 05:54:18 2003
@@ -379,7 +379,15 @@
 ptOffset.x = rect.left - rectParent.left;
 ptOffset.y = rect.top - rectParent.top;
 OffsetRgn( hrg, ptOffset.x, ptOffset.y );
-CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, 
hrg, RGN_DIFF );
+if (CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, 
hrg, RGN_DIFF ) == NULLREGION)
+{
+/* the update region has become empty */
+DeleteObject( wndParent->hrgnUpdate );
+wndParent->hrgnUpdate = 0;
+wndParent->flags &= ~WIN_NEEDS_ERASEBKGND;
+if( !(wndParent->flags & WIN_INTERNAL_PAINT) )
+add_paint_count( wndParent->hwndSelf, -1 );
+    }
 OffsetRgn( hrg, -ptOffset.x, -ptOffset.y );
 }
 }



-- 
Marcelo Duarte

Re: wine/dlls/kernel process.c

[Marcelo Duarte]

0
warn:file:CreateFileW Unable to get full filename from L"f:\\kernel32.dll" 
(GLE 2)
trace:file:CreateFileW L"C:\\windows\\system\\ntdll.dll" QUERY_ACCESS 
FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING  attributes 0x0
warn:file:CreateFileW Unable to get full filename from 
L"C:\\windows\\system\\ntdll.dll" (GLE 2)
trace:file:CreateFileW L".\\ntdll.dll" QUERY_ACCESS FILE_SHARE_READ 
FILE_SHARE_WRITE OPEN_EXISTING  attributes 0x0
warn:file:CreateFileW Unable to get full filename from L".\\ntdll.dll" (GLE 2)

-- 
Marcelo Duarte

Re: Compiler problems

[Marcelo Duarte]

Em Sex 21 Nov 2003 10:28, Ivan Leo Murray-Smith escreveu:
> Current code builds on my system.

I get it building after a forced compilation, a make uninstall, updated 
cvs and buid and install now runs
-- 
Marcelo Duarte

Re: Regressions....

[Marcelo Duarte]

One regression that I found:
err:seh:setup_exception stack overflow 304 bytes in thread 000c eip 
Was resolved by the patch:
Log message:
Force minimum stack size to 1Mb for Xlib.

Patch: http://cvs.winehq.com/patch.py?id=10104

Thanks.
Another persists yet.

Em Sáb 15 Nov 2003 14:00, Marcelo Duarte escreveu:
> Em Sáb 15 Nov 2003 13:28, você escreveu:
> Hi,
> Recently I found plus a regression when trying to install my application,
> using the installer of the M$, with updated cvs. See the error:
>
> [EMAIL PROTECTED] setup]$ wine config
> Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
> Could not stat /cdrom (No such file or directory), ignoring drive D:
> Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
> Could not stat /cdrom (No such file or directory), ignoring drive D:
> err:seh:setup_exception stack overflow 304 bytes in thread 000c eip
> 4045ec30 esp 405c0ed0 stack 0x405c-0x405c4000
> [EMAIL PROTECTED] setup]$
>
> Somebody can give tips to discover the problem to me? Running +relay is too
> slow in my machine, but I hava a 1.2MB log. I have little time that I can
> dedicate to the Wine, but go to try to make this today and tomorrow.
>
> Here is the part of +relay where the error occurs and system hangs:
> 000c:Call ntdll.RtlInitAnsiString(405c3c6c,406867c0
> "Software\\Wine\\Wine\\Config\\Tweak.Fonts") ret=405e32a4
> 000c:Ret  ntdll.RtlInitAnsiString() retval= ret=405e32a4
> 000c:Call ntdll.RtlAnsiStringToUnicodeString(40018bf8,405c3c6c,)
> ret=405e32ad
> 000c:Ret  ntdll.RtlAnsiStringToUnicodeString() retval= ret=405e32ad
> 000c:Call ntdll.NtOpenKey(405c3d78,000f003f,405c3c74) ret=405e32d3
> 000c:Ret  ntdll.NtOpenKey() retval=c034 ret=405e32d3
> 000c:Call ntdll.RtlNtStatusToDosError(c034) ret=405e32b7
> 000c:Ret  ntdll.RtlNtStatusToDosError() retval=0002 ret=405e32b7
> 000c:Ret  advapi32.RegOpenKeyA() retval=0002 ret=4066f28c
> 000c:Call kernel32.LoadLibrary16(40686903 "GDI.EXE") ret=4066f2a3
> err:seh:setup_exception stack overflow 460 bytes in thread 000c eip
> 4045ec30 esp 405c0e34 stack 0x405c-0x405c4000
>
> Thanks in advance.
>
> > Em Qua 05 Nov 2003 22:30, Marcelo Duarte escreveu:
> > > Hi all,
> > >
> > >   Some days ago, I have some problems with my application developed in
> > > Visual Foxpro 3, that before the end of separation of kernel, runs with
> > > some issues, but runs.  The problems resides in a call to dlls and
> > > library (in VFP, the comand SET LIBRARY calls a especial type of DLL)
> > > and the 3 forms is accepted: 1) SET LIBRARY TO FOXTOOLS
> > > 2) SET LIBRARY TO FOXTOOLS.FLL
> > > 3) SET LIBRARY TO "FOXTOOLS.FLL"
> > > In wine, after the end of separation fase, in the new wine-20031016,
> > > only the (3) is accepted, and accutually (the last CVS) the forms 1, 2
> > > and 3, appear to be running, and I will investigate
> > > But, the usage of external DLLs is broken.
> > > Exist the comand DECLARE, wich declares a function in a dll, and as
> > > example, I use this:
> > > DECLARE INTEGER GetLogicalDriveStrings IN WIN32API;
> > >   INTEGER nLen, STRING @sBuf
> > >
> > > and call:
> > > nLen = GetLogicalDriveStrings(MAX_DRIVES, @sBuf)
> > >
> > > When the calls fire, the programs terminates, a messagebox appear with
> > > text "Invalid indentifier" and some others erros and wine returns the
> > > following errors:
> > >
> > > [EMAIL PROTECTED] MODULLUS.300]$ wine modullus
> > > fixme:font:WineEngAddFontResourceEx :stub
> > > fixme:font:WineEngAddFontResourceEx :stub
> > > [EMAIL PROTECTED] MODULLUS.300]$ wine: Unhandled exception (thread
> > > 000b), starting debugger...
> > > WineDbg starting on pid a
> > > Loaded debug information from ELF 'wine' ((nil))
> > > Breakpoint 1 at 0x4000d484 (_end+0x400a660)
> > > Loaded debug information from ELF '/usr/local/lib/libwine.so.1'
> > > (0x40028000) No debug information in ELF '/lib/libc.so.6' (0x4003f000)
> > > No debug information in ELF '/lib/libdl.so.2' (0x40184000)
> > > No debug information in ELF '/lib/libm.so.6' (0x40187000)
> > > Loaded debug information from ELF '/lib/ld-linux.so.2' (0x4000)
> > > Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so'
> > > (0x401aa000)
> > > Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1'
> > > (0x40216000)
> > > N

Re: Compiler problems

[Marcelo Duarte]

I get an succes on compiling winearts after installing glibc-devel-static, 
but in the loader directory still error:

make[1]: Entering directory `/home/mduarte/wine-20031118/loader'
gcc -c -I. -I. -I../include -I../include-Wall -mpreferred-stack-boundary=2 
-fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -o glibc.o glibc.c
gcc -o wine-glibc -Wl,--section-start,.interp=0x3c000100 -Wl,--export-dynamic 
glibc.o -L../libs/wine -lwine -L../libs/port -lwine_port
glibc.o(.text+0x84): In function `get_threading':
/home/mduarte/wine-20031118/loader/glibc.c:61: undefined reference to 
`pthread_create'
glibc.o(.text+0x90):/home/mduarte/wine-20031118/loader/glibc.c:62: undefined 
reference to `pthread_join'
collect2: ld returned 1 exit status
make[1]: ** [wine-glibc] Erro 1
make[1]: Leaving directory `/home/mduarte/wine-20031118/loader'
make: ** [loader] Erro 2

Someone had an ideia?


Em Ter 18 Nov 2003 02:34, Marcelo Duarte escreveu:
> Updating wine to current cvs, I get an error, can someone help me:
>
> I run ./configure; make depend && make
> make[2]: Entering directory `/home/mduarte/wine-cvs/dlls/winmm/winearts'
> gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.oarts.o audio.o
> winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine
> -L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid
> -L../../../libs/port -lwine_port  -lm  -lc
> /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
> collect2: ld returned 1 exit status
> make[2]: ** [winearts.drv.so] Erro 1
> make[2]: Leaving directory `/home/mduarte/wine-cvs/dlls/winmm/winearts'
> make[1]: ** [winmm/winearts] Erro 2
> make[1]: Leaving directory `/home/mduarte/wine-cvs/dlls'
> make: ** [dlls] Erro 2
>
>
> Entering in directory loader and make:
> [EMAIL PROTECTED] loader]$ make clean
> rm -f *.o *.a *.so *.ln *.so \#*\# *~ *% .\#* *.bak *.orig *.rej *.flc
> *.spec.c *.spec.def *.dbg.c y.tab.c y.tab.h lex.yy.c core
> rm -f wine-glibc wine-kthread wine-pthread wine
> [EMAIL PROTECTED] loader]$ make
> gcc -c -I. -I. -I../include -I../include-Wall
> -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith 
> -g -O2 -o glibc.o glibc.c gcc -o wine-glibc
> -Wl,--section-start,.interp=0x3c000100 -Wl,--export-dynamic glibc.o
> -L../libs/wine -lwine -L../libs/port -lwine_port
> glibc.o(.text+0x84): In function `get_threading':
> /home/mduarte/wine-cvs/loader/glibc.c:61: undefined reference to
> `pthread_create'
> glibc.o(.text+0x90):/home/mduarte/wine-cvs/loader/glibc.c:62: undefined
> reference to `pthread_join'
> collect2: ld returned 1 exit status
> make: ** [wine-glibc] Erro 1

-- 
Marcelo Duarte

Compiling winearts - please replay!

[Marcelo Duarte]

I updated to new wine version and had errors, cvs update, and errors persists:

make[2]: Entering directory `/home/mduarte/wine-20031118/dlls/winmm/winearts'
gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.oarts.o audio.o  
winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine 
-L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid 
-L../../../libs/port -lwine_port  -lm  -lc
/usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
collect2: ld returned 1 exit status
make[2]: ** [winearts.drv.so] Erro 1
make[2]: Leaving directory `/home/mduarte/wine-20031118/dlls/winmm/winearts'
make[1]: ** [winmm/winearts] Erro 2
make[1]: Leaving directory `/home/mduarte/wine-20031118/dlls'
make: ** [dlls] Erro 2

Someone knows what is happen?

-- 
Marcelo Duarte

Compiler problems

[Marcelo Duarte]

Updating wine to current cvs, I get an error, can someone help me:

I run ./configure; make depend && make
make[2]: Entering directory `/home/mduarte/wine-cvs/dlls/winmm/winearts'
gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.oarts.o audio.o  
winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine 
-L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid 
-L../../../libs/port -lwine_port  -lm  -lc
/usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
collect2: ld returned 1 exit status
make[2]: ** [winearts.drv.so] Erro 1
make[2]: Leaving directory `/home/mduarte/wine-cvs/dlls/winmm/winearts'
make[1]: ** [winmm/winearts] Erro 2
make[1]: Leaving directory `/home/mduarte/wine-cvs/dlls'
make: ** [dlls] Erro 2


Entering in directory loader and make:
[EMAIL PROTECTED] loader]$ make clean
rm -f *.o *.a *.so *.ln *.so \#*\# *~ *% .\#* *.bak *.orig *.rej *.flc 
*.spec.c *.spec.def *.dbg.c y.tab.c y.tab.h lex.yy.c core
rm -f wine-glibc wine-kthread wine-pthread wine
[EMAIL PROTECTED] loader]$ make
gcc -c -I. -I. -I../include -I../include-Wall -mpreferred-stack-boundary=2 
-fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -o glibc.o glibc.c
gcc -o wine-glibc -Wl,--section-start,.interp=0x3c000100 -Wl,--export-dynamic 
glibc.o -L../libs/wine -lwine -L../libs/port -lwine_port
glibc.o(.text+0x84): In function `get_threading':
/home/mduarte/wine-cvs/loader/glibc.c:61: undefined reference to 
`pthread_create'
glibc.o(.text+0x90):/home/mduarte/wine-cvs/loader/glibc.c:62: undefined 
reference to `pthread_join'
collect2: ld returned 1 exit status
make: ** [wine-glibc] Erro 1

-- 
Marcelo Duarte

Re: Localization to portguese - winecfg (with patch)

[Marcelo Duarte]

No problem, I bring up to date again. I only wanted to see as it was being the 
WineCfg and as it would be in Portuguese. Who wants to see apply the patch. 

Em Dom 16 Nov 2003 08:55, Mike Hearn escreveu:
> Well, I don't have any real problem with it, but as I said before it's
> pretty pointless IMHO. The GUI is going to start changing again when I
> next get time to work on it (unfortunately not anytime soon in the
> foreseeable future), so you'll have to update it all over again.
>
> What winecfg needs now is code rather than strings
>
> On Sat, 15 Nov 2003 15:43:18 -0300, Sir Marcelo Duarte scribed thus:
> > I updated the resources of winecfg. If Mike Hearn don't disagree with
> > this.
> >
> > Changelog:
> > Marcelo Duarte <[EMAIL PROTECTED]>
> > - Localization to portguese - winecfg.

-- 
Marcelo Duarte

Re: Regressions....

[Marcelo Duarte]

Em Sáb 15 Nov 2003 13:28, você escreveu:
Hi,
Recently I found plus a regression when trying to install my application,
using the installer of the M$, with updated cvs. See the error:

[EMAIL PROTECTED] setup]$ wine config
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
Could not stat /cdrom (No such file or directory), ignoring drive D:
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
Could not stat /cdrom (No such file or directory), ignoring drive D:
err:seh:setup_exception stack overflow 304 bytes in thread 000c eip
4045ec30 esp 405c0ed0 stack 0x405c-0x405c4000
[EMAIL PROTECTED] setup]$

Somebody can give tips to discover the problem to me? Running +relay is too
slow in my machine, but I hava a 1.2MB log. I have little time that I can 
dedicate to the Wine, but go to try to make this today and tomorrow.

Here is the part of +relay where the error occurs and system hangs:
000c:Call ntdll.RtlInitAnsiString(405c3c6c,406867c0 
"Software\\Wine\\Wine\\Config\\Tweak.Fonts") ret=405e32a4
000c:Ret  ntdll.RtlInitAnsiString() retval= ret=405e32a4
000c:Call ntdll.RtlAnsiStringToUnicodeString(40018bf8,405c3c6c,) 
ret=405e32ad
000c:Ret  ntdll.RtlAnsiStringToUnicodeString() retval= ret=405e32ad
000c:Call ntdll.NtOpenKey(405c3d78,000f003f,405c3c74) ret=405e32d3
000c:Ret  ntdll.NtOpenKey() retval=c034 ret=405e32d3
000c:Call ntdll.RtlNtStatusToDosError(c034) ret=405e32b7
000c:Ret  ntdll.RtlNtStatusToDosError() retval=0002 ret=405e32b7
000c:Ret  advapi32.RegOpenKeyA() retval=0002 ret=4066f28c
000c:Call kernel32.LoadLibrary16(40686903 "GDI.EXE") ret=4066f2a3
err:seh:setup_exception stack overflow 460 bytes in thread 000c eip 4045ec30 
esp 405c0e34 stack 0x405c-0x405c4000

Thanks in advance.

> Em Qua 05 Nov 2003 22:30, Marcelo Duarte escreveu:
> > Hi all,
> >
> > Some days ago, I have some problems with my application developed in
> > Visual Foxpro 3, that before the end of separation of kernel, runs with
> > some issues, but runs.  The problems resides in a call to dlls and
> > library (in VFP, the comand SET LIBRARY calls a especial type of DLL) and
> > the 3 forms is accepted: 1) SET LIBRARY TO FOXTOOLS
> > 2) SET LIBRARY TO FOXTOOLS.FLL
> > 3) SET LIBRARY TO "FOXTOOLS.FLL"
> > In wine, after the end of separation fase, in the new wine-20031016, only
> > the (3) is accepted, and accutually (the last CVS) the forms 1, 2 and 3,
> > appear to be running, and I will investigate
> > But, the usage of external DLLs is broken.
> > Exist the comand DECLARE, wich declares a function in a dll, and as
> > example, I use this:
> > DECLARE INTEGER GetLogicalDriveStrings IN WIN32API;
> > INTEGER nLen, STRING @sBuf
> >
> > and call:
> > nLen = GetLogicalDriveStrings(MAX_DRIVES, @sBuf)
> >
> > When the calls fire, the programs terminates, a messagebox appear with
> > text "Invalid indentifier" and some others erros and wine returns the
> > following errors:
> >
> > [EMAIL PROTECTED] MODULLUS.300]$ wine modullus
> > fixme:font:WineEngAddFontResourceEx :stub
> > fixme:font:WineEngAddFontResourceEx :stub
> > [EMAIL PROTECTED] MODULLUS.300]$ wine: Unhandled exception (thread 000b),
> > starting debugger...
> > WineDbg starting on pid a
> > Loaded debug information from ELF 'wine' ((nil))
> > Breakpoint 1 at 0x4000d484 (_end+0x400a660)
> > Loaded debug information from ELF '/usr/local/lib/libwine.so.1'
> > (0x40028000) No debug information in ELF '/lib/libc.so.6' (0x4003f000)
> > No debug information in ELF '/lib/libdl.so.2' (0x40184000)
> > No debug information in ELF '/lib/libm.so.6' (0x40187000)
> > Loaded debug information from ELF '/lib/ld-linux.so.2' (0x4000)
> > Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so'
> > (0x401aa000)
> > Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1'
> > (0x40216000)
> > No debug information in ELF '/lib/libnss_files.so.2' (0x4001a000)
> > Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so'
> > (0x4042)
> > Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so'
> > (0x4068)
> > Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so'
> > (0x407ab000)
> > Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so'
> > (0x4081b000)
> > Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so'
> > (0x40847000)
> > Loaded debug information from ELF '/usr/local/lib/wine/comdlg32

Re: Native Dll x Built-in Dll - why everything doesn't work with native dlls

[Marcelo Duarte]

I have notified a recent regression in loading native dlls from database
programs like VFP3. I believe that VB work the same way.
- Original Message - 
From: "Uwe Bonnes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2003 3:27 PM
Subject: Re: Native Dll x Built-in Dll - why everything doesn't work with
native dlls


> > "Leonardo" == Leonardo Luiz Padovani da Mata <[EMAIL PROTECTED]>
writes:
>
> Leonardo> Hello all!!  My name is Leonardo, and i'm working in a
project
> Leonardo> that will migrate thousands of windows NT4 machines to
Linux.
> Leonardo> In this project we will do some wine impplementations, if
> Leonardo> needed.
>
> Leonardo> The apps that we are testing is some VB6/5 apps and DataBase
> Leonardo> client apps.  None of the apps executed correctly. So we
will
> Leonardo> impplement wine.
>
> Leonardo> I need to know why when we use Native DLL these apps doesn't
> Leonardo> work.  How does wine open the native dll files?  Where are
the
> Leonardo> doc about that?
>
> High level DLLs (like the visual basic dlls) call into low level dlls,
like
> kernel32.dll. If there are bugs in the wine implementation of these dlls,
> errors will happen, even when a native high level dll is uses.
>
> With VB6/5, most errors happen around Ole/Com, as wine still needs a long
> way in that area. Running with the appropriate native DLLs may circumvent
> the problem. For migrating, using the native dlls is not a (legal) option
> however.
>
> Native dlls are opened by loading the dll, when the PE header request the
> dll, just like windows does. Learn the basics from reading low level
windows
> books, and then understand what wine does in what way by reading the wine
> source and asking good questions on the list. Asking "Where are the doc
> about that?" is normally not considered a good question, as you don't show
> what effort you did yourself to solve that problem.
>
> Bye
> -- 
> Uwe Bonnes[EMAIL PROTECTED]
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> - Tel. 06151 162516  Fax. 06151 164321 --
>

Regressions....

[Marcelo Duarte]

.dll.so' 
(0x41112000)
Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' 
(0x4125)
Loaded debug information from ELF '/usr/local/lib/wine/ctl3d32.dll.so' 
(0x41371000)
No debug information in 32bit DLL 'C:\windows\system\VFP300.ESL' (0x40)
No debug information in 32bit DLL 'NTDLL.DLL' (0x401c)
No debug information in 32bit DLL 'KERNEL32.DLL' (0x4045)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' 
(0x4083)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x407c)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406a)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' 
(0x4085)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x409e)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x4098)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a3)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' 
(0x40a7)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x4090)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' 
(0x4088)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' (0x40b2)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40b0)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MPR.DLL' (0x40b3)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b5)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40bc)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x410d)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x4112)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x4110)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x4126)
No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\CTL3D32.DLL' (0x4138)
Unhandled exception: page fault on write access to 0x55bd0565 in 32-bit code 
(0x00405732).
In 32-bit mode.
0x00405732 (VFP300.ESL..text+0x3732 in VFP300.ESL): movl%edx,0x0(%eax)
Wine-dbg>WineDbg terminated on pid a

The winedbg crahes

The wine-20030911 runs fine.
Can someone help me how to correct, or where to find the problem?

-- 
Marcelo Duarte

Re: DMUSIC: fix in dmloader's behavior

[Marcelo Duarte]

DWORD SearchPath(

LPCTSTR  lpszPath, // address of search path 
LPCTSTR  lpszFile, // address of filename 
LPCTSTR  lpszExtension, // address of extension 
DWORD  cchReturnBuffer, // size, in characters, of buffer 
LPTSTR  lpszReturnBuffer, // address of buffer for found filename 
LPTSTR  *plpszFilePart  // address of pointer to file component 
   );
- Original Message - 
From: "Jerry Jenkins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 27, 2003 11:30 PM
Subject: Re: DMUSIC: fix in dmloader's behavior


> Rok Mandeljc wrote:
> > + /* OK, MSDN says that search order is the following:
> > + - current directory (DONE)
> > + - windows search path (FIXME: how do I get that?)
> Try this :
> DWORD GetEnvironmentVariable(
>LPCTSTR lpName,  // environment variable name
>LPTSTR lpBuffer, // buffer for variable value
>DWORD nSize  // size of buffer
> );
> or
> NTSTATUS WINAPI RtlQueryEnvironmentVariable_U(
>PWSTR env,
>PUNICODE_STRING name,
>PUNICODE_STRING value
> );
> 
> > + - loader's search path (DONE)
> > + */
> 
>

Re: docs: wine-devel [11/16]

[Marcelo Duarte]

- Original Message - 
From: "Eric Pouech" <[EMAIL PROTECTED]>
To: "Dimitrie O. Paun" <[EMAIL PROTECTED]>
> Dimitrie O. Paun wrote:
> > Eric, a lot of stuff in here looks like it's in
> > need of some TLC, if you can take a look...
> TLC ? tender & loving care 
> is that what you're looking for ? (even if everything is not filled in
yet)
> A+
>
>
> -- 
> Eric Pouech
>
In this list, some times I see acronyms that I do not understand, some I try
to imagine. For the majority of the people who had not been born speaking
English this also must be complicated. I am imagining where to find a
description of these terms. Somebody could indicate a site?

TLC, IMO, BTW...

Re: Wine lecture slides

[Marcelo Duarte]

From: "Ove Kaaven" <[EMAIL PROTECTED]>
To: "Eric Pouech" <[EMAIL PROTECTED]>
Cc: "Shachar Shemesh" <[EMAIL PROTECTED]>; "Marcelo Duarte"
<[EMAIL PROTECTED]>; "Wine Devel" <[EMAIL PROTECTED]>
Sent: Sunday, September 21, 2003 2:25 PM
Subject: Re: Wine lecture slides


> søn, 21.09.2003 kl. 08.46 skrev Eric Pouech:
> > > MZ are the first two bytes of the file, identifying it as an
executable.
> > > I'm not aware that they mean anything at all.
> > IIRC, they were the initial of the author(s) of the file format
>
> Mark Zbikowski. But that's just a theory, I haven't heard about anybody
> really knowing for sure what it stands for, I think (many books mention
> this theory, but never like it was a fact).

I also read this theory in a book, and perhaps either exactly this name. I
find that he was in the book "The MSDOS Bible" of Ray Duncan.

Re: Wine lecture slides

[Marcelo Duarte]

- Original Message - 
From: "Mike Hearn" <[EMAIL PROTECTED]>
To: "Shachar Shemesh" <[EMAIL PROTECTED]>

> * I say Wine is an emulator. I don't know how to read the official
> definition, it could go both ways, but I've found the whole "Wine Is Not
> an Emulator" thing just confuses newbies :)

I taste to think that the "Wine is a simulator", because it simulates the
Windows environment. Poverty not?

> * Slide 17 - 3rd file type is NE (win16 binary). PE = Portable
> Executable. NE = ?, but the N is bound to stand for something
> stupid, like "new" or whatever

Yes, NE = New Executable, as the opposite to format MZ, that was the
predominant format until the new creation. Already MZ I do not remember what
it means.

M.

Re: Latest CVS doesnt compile

[Marcelo Duarte]

- Original Message - 
From: "Dustin Navea" <[EMAIL PROTECTED]>


> --- Jon Brandenburg <[EMAIL PROTECTED]> wrote:
> > On Sat, 2003-09-06 at 16:36, Ian Goldby wrote:
> >
> > > and occurs 2-3 hours into the build. Thanks for any further
suggestions.
> >
> Well on my old 1.2 ghz athlon (when i last had it) it took roughly 30-45
minutes
>

On my Athlon 650, 256MB, took a maximum 50 minutes to configure, make depend
&& make, etc.

Re: for Red Hat packager

[Marcelo Duarte]

I think that a clean installation decides the problem. A desenvolvedor
already had a similar problem.

http://www.winehq.org/hypermail/wine-devel/2003/07/0474.html

Obviously if in the installation of the package this cleanness could be
made, better.

- Original Message - 
From: "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]>
To: "wine-devel" <[EMAIL PROTECTED]>
Sent: Tuesday, September 09, 2003 12:35 AM
Subject: for Red Hat packager


> Could the Red Hat packager please take care of this
> http://www.winehq.org/hypermail/wine-users/2003/09/0081.html
> I don't know if it's a rpm packaging error or a problem with the users
system
> setup, but I suppose the creator of the rpm can solve the issue quite
easily.
>
>
>