wine-devel August 2011

wine-devel@winehq.org

86 participants
258 discussions

winelib an fpc
by Reinier Napoles Martinez 29 Aug '11

29 Aug '11

best regards I would like to know if it is possible to use the wine libraries with freepascal compiler. kylix had a modified version of the wine libraries and I believe that it was possible to invoke them from pascal. I've tried several ways but all I get is "segment fault". sorry for my English. Thanks. program test01; {$MODE Delphi} uses types; Type BOOL = LongBool; function GetCursorPos(var lpPoint: TPoint): BOOL; stdcall; external 'libuser32.so' name 'GetCursorPos'; var a:Tpoint; begin WriteLn('Calling wine function'); GetCursorPos(a); WriteLn('End Calling wine function'); WriteLn(a.x); end. program test02; {$Mode Delphi} uses sysutils,types; Type BOOL = LongBool; TGetCursorPos=Function(var lpPoint: TPoint): BOOL;cdecl; Function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl'; Function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl'; Function dlclose(lib: pointer):longint;cdecl;external 'dl'; var lib : pointer; GetCursorPos:TGetCursorPos; a:Tpoint; begin lib:=dlopen('/usr/lib/wine/user32.dll.so',1); if lib <> nil then @GetCursorPos:=dlsym(lib,'GetCursorPos') else begin WriteLn('library not loaded'); exit; end; if Assigned(GetCursorPos) then begin WriteLn('Calling GetCursorPos'); Try GetCursorPos(a); Except on E : Exception do WriteLn(E.Message); end; WriteLn('X:',a.x,' Y:',a.Y); end else begin WriteLn('function not loaded'); exit; end; dlclose(lib); end. -- ********************************************************************* En la tierra hace falta personas que trabajen más y critiquen menos, que construyan más y destruyan menos, que prometan menos y resuelvan más que esperen recibir menos y dar más que digan mejor ahora que mañana. Che ********************************************************************* -- ********************************************************************* En la tierra hace falta personas que trabajen más y critiquen menos, que construyan más y destruyan menos, que prometan menos y resuelvan más que esperen recibir menos y dar más que digan mejor ahora que mañana. Che *********************************************************************

2 1

Re: [5/5] ddraw: Add a test for DDSD_ZBUFFERBITDEPTH and DDSD_PIXELFORMAT
by Marvin 29 Aug '11

29 Aug '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13811 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.

1 0

Re: [4/5] ddraw: Set dwZBufferBitDepth in old z buffers
by Marvin 29 Aug '11

29 Aug '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13810 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.

1 0

Re: winspool.drv/tests: Fix tracing a NULL string
by Marvin 29 Aug '11

29 Aug '11

1 0

Re: [3/5] ddraw: Convert dwZBufferBitDepth into a DDPIXELFORMAT
by Marvin 29 Aug '11

29 Aug '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13809 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.

1 0

Re: [2/2] net: Add support for enumerating the running services with 'net start'.
by Frédéric Delanoy 29 Aug '11

29 Aug '11

On Fri, Aug 26, 2011 at 17:41, Francois Gouget <fgouget(a)codeweavers.com> wrote: > --- > > Quite useful to see what services are actually running. > > programs/net/net.c | 55 ++++++++++++++++++++++++++++++++++++++++++++- > programs/net/net.rc | 4 ++- > programs/net/resources.h | 2 + > 3 files changed, 58 insertions(+), 3 deletions(-) > > diff --git a/programs/net/net.c b/programs/net/net.c > index 249c14d..ed26b43 100644 > + STRING_RUNNING, " %s\n" This one is not particularly translatable.

2 1

Re: Hebrew: update
by Yaron Shahrabani 29 Aug '11

29 Aug '11

On Tue, Aug 23, 2011 at 12:43 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > Did you really mean not to CC wine-devel? Right sorry... > > > On Tue, 23 Aug 2011, Yaron Shahrabani wrote: > > > On Mon, Aug 22, 2011 at 3:25 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > > > > > > #: crypt32.rc:182 > > > > msgid "KeyID=" > > > > -msgstr "" > > > > +msgstr "KeyID=" > > > > > > I think you should really translate 'KeyID' In French it was translated > > > to 'ID de clé'. So assuming there is a Hebrew word for 'key' then this > > > would not remain as is. > > This appears in a certificate, it is much more useful to the user than > > the Hebrew tern (מזהה מפתח)... > > It's in a resource file which usually means the author (Juan Lang in > this case) expects it to be translated. If it's not meant to be > translated then it should either be removed from the resource file or > marked as not needing translation (I have a patch for that, maybe I'll > send it tomorrow). I'm not translating so things will be translated, I also have to make sure that the user experience is somewhat natural and pleasing, translating this string is mostly confusing. > > > > > > > -"\t/i {package|productcode} [property]\n" > > > > -"\t/package {package|productcode} [property]\n" > > > > +"\t/i {package|product_code} [property]\n" > > > > +"\t/package {package|product_code} [property]\n" > > > > > > Ideally you should translate the user-replaceable strings like 'package' > > > and 'productcode'. But option names such as '/package' should remain as > > > is of course. > > Since we have certain RTL issues with the Linux kernel (Hebrew is > > displayed in reverse) we discourage the translators to translate > > strings that would probably appear there > > > > > > > > > > msgid "DirectX Diagnostic Tool" > > > > -msgstr "" > > > > +msgstr "DirectX Diagnostic Tool" > > > > > > This is sort of a product name os it's always a bit dicey. Still, > > > wouldn't it be better if 'Diagnostic Tool' was translated? At > > > non-English speakers would understand what the purpose of the tool it. > > Wasn't quite sure if it appears in a console or GUI, can you tell? > > It is displayed in a message box (so GUI). Great, I will fix this in my next commit, for now it is perfectly fine... > > > > Since we have certain RTL issues with the Linux kernel (Hebrew is > > displayed in reverse) we discourage the translators to translate > > strings that would probably appear there > > How does the Linux kernel get involved? Using Wine on the Linux console > would be quite unusual. Usually it is run in a Gnome terminal, and Xterm > or some other GUI equivalent. Don't these do their own handling of text > independently from the Linux kernel? Most terminal emulators doesn't support RTL besides MLTerm. Wineconsole does not support Hebrew or Arabic script out of the box, there are several fonts that should be installed in order to enable that, AFAIK Arabic displayed in the right order but the letters are not joined, I can check that and get back to you. > > > [...] > > > > -msgstr "%s : File Not Found\n" > > > > +msgstr "%s: File Not Found\n" > > > [...a lot more...] > > > > > > These are not translated and do not have their place in a PO file. They > > > will prevent future translators working on this file from knowing what > > > has been translated. > > > > They better not work on this... I need this to remain untranslated > > until the Hebrew bugs in the Linux kernel will be fixed. > > In that case you should add translator comments indicating that the > string should remain untranslated for the time being. A translator > comment is a '#' followed by a space, but adding a second space so it > lines up with the others makes it nicer. For instance: > > # DO NOT TRANSLATE: needs RTL fixes to the Linux kernel > #: cmd.rc:280 > msgid "%s: File Not Found\n" > msgstr "" > > > The translator comments will be preserved through the updates. I'm translating using Virtaal, meaning I can't add comments while translating and I guess other translators as well, I look at comments but sometimes when I have many strings to translate I don't have much time to stop and read each and every one of them, it takes a lot of my (precious) time so for the sake of efficiency I let myself ignore some of them, so do other Hebrew translators, But most of us do understand that if a string is copied as-is it shouldn't be translated (Sort of convention if you like). It may seem odd but Hebrew, although a private case of Arabic is still not handled the best way it should in computing, there are still many nasty bugs so we do our best to give the Hebrew user the best experience but its still not perfect as we want it to be and we value the efforts of the developers that do help us but we understand if they have no interest and it is fine by us besides I realize there are much more important things to develop so we just leave it aside and deal with what we can deal with our given tools. Kind regards, Yaron Shahrabani. > > > > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: Because rebooting is for adding new hardware

5 17

re: [3/3] (resend) usp10: draw selected glyphs in ScriptStringOut
by Dan Kegel 29 Aug '11

29 Aug '11

Hi Aric, did you forget to include Makefile.in changes with your patch? It failed to build here: http://buildbot.kegel.com/builders/runtests/builds/70 ccache gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O0 -o spy.o spy.c usp10.o: In function `SS_ItemOut': /home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10/usp10.c:1061: undefined reference to `GetSysColor' /home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10/usp10.c:1065: undefined reference to `GetSysColor' /usr/bin/ld: usp10.dll.so: hidden symbol `GetSysColor' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: ccache failed make[1]: Leaving directory `/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10' make[1]: *** [usp10.dll.so] Error 2

1 0

re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
by Dan Kegel 29 Aug '11

29 Aug '11

Fails to build here, since it depends on the patch "include/winnet.h: Add more GetVolumeInformation system flags", but you didn't mark them as being part of a series. See "Subject Line" in http://wiki.winehq.org/SubmittingPatches volume.c: In function ‘GetVolumeInformationW’: volume.c:672: error: ‘FILE_SUPPORTS_REPARSE_POINTS’ undeclared (first use in this function) volume.c:672: error: (Each undeclared identifier is reported only once volume.c:672: error: for each function it appears in.) volume.c:672: error: ‘FILE_SUPPORTS_SPARSE_FILES’ undeclared (first use in this function) volume.c:672: error: ‘FILE_VOLUME_QUOTAS’ undeclared (first use in this function) make[1]: *** [volume.o] Error 1 You probably also want to use shorter subject lines, and move more of the patch description into the body of your message.

3 4

Documenting WineTest best practices
by Francois Gouget 29 Aug '11

29 Aug '11

I have done a major refresh of the Wiki's conformance tests page. http://wiki.winehq.org/ConformanceTests One aspect I would like to document there is the best practices mostly for people running WineTest unattended on their computer. For instance I recently learned that one should really make sure that ntlm_auth works otherwise there will be failures. There are other things for which I don't have the answer however. In particular: * On Windows XP the firewall will ask whether to block network access to some tests. How should this be dealt with. Since WineTest is being run unattended clicking 'ok' does not work. * Similarly on Vista and Windows 7 UAC comes into play. I believe it mostly causes some tests to be skipped. So again, are there recommandations around this? * Are we interested in tests being run as an administrator or a regular user? Both? I also came across the MakeTestFailures page and it seems pretty out of date. Is maintaining a list of failing tests (still) really useful? http://wiki.winehq.org/MakeTestFailures -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

1 1

← Newer
1
2
3
4
5
6
7
8
9
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2011