Re: remove redundant semicolons for ANSI compat.
On Sat, 2007-01-13 at 21:19 +0100, Michael Stefaniuc wrote:
> Joel Parker wrote:
> > Bug 4527
> >
> >
> >
> >
> >
> >
> >>From 205f7fdd9a63409014a322318aba3fd77ec90f47 Mon Sep 17 00:00:00 2001
> > From: Joel Parker <[EMAIL PROTECTED](none)>
> > Date: Fri, 12 Jan 2007 17:26:47 -0600
> > Subject: remove redundant semicolons for ANSI compat.
> > ---
>
> > @@ -636,17 +636,17 @@ #define DEFINE_SMapLS(n) \
> > "movl " #n "(%ebp),%eax\n\t" \
> > "call " __ASM_NAME("SMapLS") "\n\t" \
> > "movl %edx," #n "(%ebp)\n\t" \
> > - "ret" );
> > + "ret" )
> >
> > -DEFINE_SMapLS(8);
> > -DEFINE_SMapLS(12);
> > -DEFINE_SMapLS(16);
> > -DEFINE_SMapLS(20);
> > -DEFINE_SMapLS(24);
> > -DEFINE_SMapLS(28);
> > -DEFINE_SMapLS(32);
> > -DEFINE_SMapLS(36);
> > -DEFINE_SMapLS(40);
> > +DEFINE_SMapLS(8)
> > +DEFINE_SMapLS(12)
> > +DEFINE_SMapLS(16)
> > +DEFINE_SMapLS(20)
> > +DEFINE_SMapLS(24)
> > +DEFINE_SMapLS(28)
> > +DEFINE_SMapLS(32)
> > +DEFINE_SMapLS(36)
> > +DEFINE_SMapLS(40)
> Are you sure this compiles? You removed the semicolon in the macro
> definition and when it is used. And even if it compiles the code needs
> to look like C code.
>
Yes, it compiles. For some reason there's a missing line of context in
the diff. If you look at this link:
http://source.winehq.org/source/dlls/kernel32/selector.c#L634
you'll see that it actually goes like this:
#define DEFINE_SUnMapLS(n) \
__ASM_GLOBAL_FUNC( SUnMapLS_IP_EBP_ ## n, \
"pushl %eax\n\t" /* preserve eax */ \
"pushl " #n "(%ebp)\n\t" \
"call " __ASM_NAME("UnMapLS") "\n\t" \
"movl $0," #n "(%ebp)\n\t" \
"popl %eax\n\t" \
"ret" )
DEFINE_SUnMapLS(8);
DEFINE_SUnMapLS(12);
DEFINE_SUnMapLS(16);
etc.
I'm removing the semicolons from these last lines. The _ASM_GLOBAL_FUNC
needs different semicolon terminators depending on the version being
used, so they just carry through.
> bye
> michael
--
Joel Parker
Re: oleaut32: Remove unused items
Andrew Talbot wrote: > Changelog: > oleaut32: Remove unused items. > > diff -urN a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > --- a/dlls/oleaut32/vartype.c 2006-12-22 14:43:36.0 + > +++ b/dlls/oleaut32/vartype.c 2007-01-13 20:13:23.0 + > @@ -228,7 +228,6 @@ > SIMPLE(LONG64, SHORT, VarI8FromI2); > SIMPLE(LONG64, signed char, VarI8FromI1); > SIMPLE(LONG64, USHORT, VarI8FromUI2); > -SIMPLE(LONG64, LONG, VarI8FromI4); Are you removing a test here? > SIMPLE(LONG64, ULONG, VarI8FromUI4); > POSTST(LONG64, ULONG64, VarI8FromUI8, I8_MAX); bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: [15/20] WineD3D: Clean up drawprim a bit
On 12/01/07, Christoph Bumiller <[EMAIL PROTECTED]> wrote: Stefan Dösinger wrote: > We will need software shaders for a correct implementation of > IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I > don't really think OpenGL feedback mode is what we want here. > > Maybe we should remove it for now, but keep the code somewhere(in the > wiki maybe). If someone is extra-ambitious we can do something like > Softwire/SwiftShader does. But I think ProcessVertices is a good > oportunity to verify our vertex shader implementation. > Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing. How about something like R2VB?
Re: Dapper, git, and version-stamp pain again
Dan Kegel wrote: On one of my dapper boxes (an old laptop), I got the error main.o: In function `check_command_line':/home/dank/wine-git/loader/main.c:89: undefined reference to `wine_version' today. Turns out the version-stamp rule in loader/Makefile is misbehaving; I had to hack that rule to not invoke git at all. Hmm. I remember having to do that before. Oh, yeah, it's coming back to me now: Dapper's "git --version" reports 1.1.3, and http://wiki.winehq.org/GitWine#head-f90aa63f963ccd6f1b34f59e4fdaafaecc72ad18 says that's too old. Grr. I guess I should submit a patch that checks git's version and doesn't break the build if it's only 1.1.3... it'd save me fifteen minutes next time I forget about this... - Dan At least with git 1.1.4, I seem to need the attached patch to create a valid wine_version. Subject: [PATCH] Seems to be needed. --- loader/Makefile.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 70e18f05992192ef78dc6e2eb3a5002ba804ca6c diff --git a/loader/Makefile.in b/loader/Makefile.in index f3e365f..9b256ab 100644 --- a/loader/Makefile.in +++ b/loader/Makefile.in @@ -68,7 +68,7 @@ clean:: $(RM) version.c version-stamp version-stamp: dummy - (GIT_DIR=$(TOPSRCDIR)/.git git-describe 2>/dev/null || echo "[EMAIL PROTECTED]@") | sed -e 's/\(.*\)/const char wine_version[] = "\1";/' >$@ || ($(RM) $@ && exit 1) + (GIT_DIR=$(TOPSRCDIR)/.git git-describe master 2>/dev/null || echo "[EMAIL PROTECTED]@") | sed -e 's/\(.*\)/const char wine_version[] = "\1";/' >$@ || ($(RM) $@ && exit 1) version.c: version-stamp @cmp -s version-stamp $@ || cp version-stamp $@ -- 1.1.4
Re: remove redundant semicolons for ANSI compat.
Joel Parker wrote:
> Bug 4527
>
>
>
>
>
>
>>From 205f7fdd9a63409014a322318aba3fd77ec90f47 Mon Sep 17 00:00:00 2001
> From: Joel Parker <[EMAIL PROTECTED](none)>
> Date: Fri, 12 Jan 2007 17:26:47 -0600
> Subject: remove redundant semicolons for ANSI compat.
> ---
> @@ -636,17 +636,17 @@ #define DEFINE_SMapLS(n) \
> "movl " #n "(%ebp),%eax\n\t" \
> "call " __ASM_NAME("SMapLS") "\n\t" \
> "movl %edx," #n "(%ebp)\n\t" \
> - "ret" );
> + "ret" )
>
> -DEFINE_SMapLS(8);
> -DEFINE_SMapLS(12);
> -DEFINE_SMapLS(16);
> -DEFINE_SMapLS(20);
> -DEFINE_SMapLS(24);
> -DEFINE_SMapLS(28);
> -DEFINE_SMapLS(32);
> -DEFINE_SMapLS(36);
> -DEFINE_SMapLS(40);
> +DEFINE_SMapLS(8)
> +DEFINE_SMapLS(12)
> +DEFINE_SMapLS(16)
> +DEFINE_SMapLS(20)
> +DEFINE_SMapLS(24)
> +DEFINE_SMapLS(28)
> +DEFINE_SMapLS(32)
> +DEFINE_SMapLS(36)
> +DEFINE_SMapLS(40)
Are you sure this compiles? You removed the semicolon in the macro
definition and when it is used. And even if it compiles the code needs
to look like C code.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
dlls/mshtml/tests/htmldoc.c breakage
The following change to dlls/mshtml/tests/htmldoc.c date: 2007-01-12 19:56:11 +; author: julliard; state: Exp; lines: +2 -1 Paul Vriens <[EMAIL PROTECTED]> mshtml/tests: Cast-qual warning fix. breaks the build with GCC 3.4: /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o htmldoc.o htmldoc.c htmldoc.c: In function `test_Load': htmldoc.c:1806: error: invalid initializer Would you mind having a look? Gerald
python-to-c++ compiler under wine
hi there,
while trying to get an experimental python-to-c++ compiler
(http://mark.dufour.googlepages.com) to run under wine, I found a
not-so complicated test case that crashes. it is a simple C++ program,
converted from 57 lines of Python. it is quite self-contained, and
only uses the Boehm GC, but it crashes early and consistently. I
corresponded with mike hearn about this, but he is too busy atm to
look at it further. here is a mail of me to him, with a link to an
archive with an .exe that crashes (but works under windows), the .py
and .?pp source code, and a crash log with debugging symbols. it would
be great if any of you here would have a look at it.
---
I tried to minimize the test program so it still crashes. the
attachment (t37.py, 56 lines) very quickly and consistently crashes
when trying to print out a list of integers:
def propagate(lit, mods, failed_literal=0):
..
print 'prop', lit
print occurrence[3]
this happens after calling just a few functions (solve_rec, lookahead,
lookahead_variable, propagate) and no backtracking.
in C++ terms, occurrence is a list *> *> *.
occurrence[3] is then a list *> *. occurrence[3] is a list
of 6 'clauses'. it always goes wrong on printing the 3rd clause (or
list *), at the line 'r->unit += repr.. ' below, in the file
builtin.hpp:
template str *list::__repr__() {
str *r = new str("[");
for(int i = 0; i__len__();i++) {
r->unit += repr(units[i])->unit;
if (i__len__()-1)
r->unit += ", ";
}
r->unit += "]";
return r;
}
now what happens in repr(..) is a bit complicated because of templatry
and va_args stuff and all, but I would think that if the clause is not
corrupt it should just work..
btw. a list uses a vector in it called 'units', as can be seen above.
here's a bundle of files (crash log, t37.py, t37.?pp, t37.exe..):
http://mark.dufour.googlepages.com/shedskin_crash.tgz
---
thanks for any help!
mark dufour.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
New dlls/crypt32/tests/cert.c breakage
The following change to dlls/crypt32/cert.c
revision 1.36
date: 2007-01-12 20:56:12 +0100; author: julliard; state: Exp; lines: +56
-57
Paul Vriens <[EMAIL PROTECTED]>
crypt32/tests: Cast-qual warning fixes.
breaks the bootstrap on some of my systems. Specifically, it added a new
variable
static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W;
initialized with MS_DEF_PROV_W.
However, in include/wincrypt.h we have the following:
#if defined(__GNUC__)
# define MS_DEF_PROV_W (const WCHAR []){ ... }
#elif defined(_MSC_VER)
# define MS_DEF_PROV_W L"Microsoft Base Cryptographic Provider v1.0"
#else
static const WCHAR MS_DEF_PROV_W[] = {
'M','i','c','r','o','s','o','f','t',' ',
'B','a','s','e','
','C','r','y','p','t','o','g','r','a','p','h','i','c',' ',
'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 };
#endif
In my case this breaks for GCC 3.4:
/usr/bin/gcc -c -I. -I. -I../../../include -I../../../include
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith
-g -O2 -o cert.o cert.c
cert.c:312: error: invalid initializer
Gerald
PS: The patch below avoids this breakage on my test system, but is
obviously not the real fix.
Index: cert.c
===
RCS file: /home/wine/wine/dlls/crypt32/tests/cert.c,v
retrieving revision 1.36
diff -u -3 -p -r1.36 cert.c
--- cert.c 12 Jan 2007 19:56:12 - 1.36
+++ cert.c 13 Jan 2007 17:08:00 -
@@ -309,7 +309,10 @@ static void checkHash(const BYTE *data,
}
static WCHAR cspNameW[] = {
'W','i','n','e','C','r','y','p','t','T','e','m','p',0 };
-static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W;
+static WCHAR ms_def_prov_w[] = { 'M','i','c','r','o','s','o','f','t',' ' ,
+ 'B','a','s','e',' ','C','r','y','p','t','o','g','r','a','p','h','i','c', ' ',
+ 'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 };
+
static void testCertProperties(void)
{
Re: configure: add ncursesw detecting [try 2]
Dmitry Timoshkov wrote:
"Vitaly Lipatov" <[EMAIL PROTECTED]> wrote:
> Most likely the real fixes in your patch are changing CP_ACP to
CP_UNIXCP
> and getting rid of hardcoded vkkeyscan_table. Do you have an
evidence that
> ncurses is so much broken that it really can't handle UTF-8? Does
it work
> if you change the locale to a not UTF-8 one?
Dmitry, as I already post in this thread, we have test program which
does not print correctly ever in UTF-8 locale.
Usual ncurses works in 8-bit locales like koi8-r correctly, but we
can't output in utf8 locale.
Have you been able to see any cyrillic text in wineconsole with the
curses
backend at all? Even after changing CP_ACP to CP_UNIXCP I don't see
anything.
This is with a KOI8-R locale. We need to make this configuration work
first.
Hello!
With This patch you will be able to see cyrillic symbols in wineconsole.
Changelog:
Add convertig from multibyte to widechar for correctly assignment in
FillSimpleChar function.
Have Removed check in Refresh function : if(ch >127...), because
cyrillic symbols has code more that 127.
Index: programs/wineconsole/curses.c
===
RCS file: /home/wine/wine/programs/wineconsole/curses.c,v
retrieving revision 1.31
diff -u -p -u -r1.31 curses.c
--- programs/wineconsole/curses.c 10 Jan 2007 11:37:39 - 1.31
+++ programs/wineconsole/curses.c 12 Jan 2007 13:47:17 -
@@ -365,7 +365,7 @@ static void WCCURSES_Refresh(const struc
{
WideCharToMultiByte(CP_UNIXCP, 0, &cell[x].Char.UnicodeChar, 1,
&ch, 1, NULL, NULL);
-attr = ((BYTE)ch < 32 || (BYTE)ch > 127) ? 32 : (BYTE)ch;
+attr = ((BYTE)ch < 32) ? 32 : (BYTE)ch;
if (cell[x].Attributes & FOREGROUND_RED) attr |= COLOR_PAIR(COLOR_RED);
if (cell[x].Attributes & FOREGROUND_BLUE) attr |= COLOR_PAIR(COLOR_BLUE);
@@ -487,6 +487,7 @@ static unsigned WCCURSES_FillSimpleChar(
{
unsigned vk;
unsigned inchar;
+unsigned char ch;
unsigned numEvent = 0;
DWORDcks = 0;
@@ -538,8 +539,9 @@ static unsigned WCCURSES_FillSimpleChar(
ir[numEvent].Event.KeyEvent.dwControlKeyState |= LEFT_ALT_PRESSED;
ir[numEvent].Event.KeyEvent.wVirtualKeyCode = vk;
ir[numEvent].Event.KeyEvent.wVirtualScanCode = mapvkey_0[vk & 0x00ff]; /* VirtualKeyCodes to ScanCode */
-ir[numEvent].Event.KeyEvent.uChar.UnicodeChar = (unsigned char)inchar;
+ch = (unsigned char) inchar;
+MultiByteToWideChar(CP_UNIXCP, 0,(char*)&ch,1,&ir[numEvent].Event.KeyEvent.uChar.UnicodeChar, 1);
ir[numEvent + 1] = ir[numEvent];
ir[numEvent + 1].Event.KeyEvent.bKeyDown = 0;
[15/20] WineD3D: Clean up drawprim a bit
Stefan Dösinger wrote: We will need software shaders for a correct implementation of IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I don't really think OpenGL feedback mode is what we want here. Maybe we should remove it for now, but keep the code somewhere(in the wiki maybe). If someone is extra-ambitious we can do something like Softwire/SwiftShader does. But I think ProcessVertices is a good oportunity to verify our vertex shader implementation. Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
Re: Paul Vriens : mshtml/tests: Cast-qual warning fix.
Paul Vriens wrote:
> Michael Stefaniuc wrote:
>> Alexandre Julliard wrote:
>>> Module: wine
>>> Branch: master
>>> Commit: 6338caa9eda8eda98dad9a89a8e71c6ea37bd168
>>> URL:
>>> http://source.winehq.org/git/wine.git/?a=commit;h=6338caa9eda8eda98dad9a89a8e71c6ea37bd168
>>>
>>>
>>> Author: Paul Vriens <[EMAIL PROTECTED]>
>>> Date: Fri Jan 12 14:26:05 2007 +0100
>>>
>>> mshtml/tests: Cast-qual warning fix.
>>
>> This breaks compilation with older gcc versions. At least with gcc-3.1.1
>> used by Smatch.
>>
>> dlls/mshtml/tests/htmldoc.c: In function `test_Load':
>> dlls/mshtml/tests/htmldoc.c:1806: invalid initializer
>> make[2]: *** [htmldoc.o] Error 1
>>
> Hi,
>
> does the attached patch fix this? If yes, I'll produce patches for
Sure, that works as well.
bye
michael
> mshtml, crypt32 and secur32 which all suffer the same issue.
>
> Cheers,
>
> Paul.
>
>
>
>
> diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c
> index 0815c01..99a15cc 100644
> --- a/dlls/mshtml/tests/htmldoc.c
> +++ b/dlls/mshtml/tests/htmldoc.c
> @@ -1803,7 +1803,9 @@ static void test_Load(IPersistMoniker *persist)
> {
> IBindCtx *bind;
> HRESULT hres;
> -static WCHAR sz_html_clientsite_objectparam[] =
> SZ_HTML_CLIENTSITE_OBJECTPARAM;
> +static WCHAR sz_html_clientsite_objectparam[MAX_PATH];
> +
> +lstrcpyW(sz_html_clientsite_objectparam, SZ_HTML_CLIENTSITE_OBJECTPARAM);
>
> test_readyState((IUnknown*)persist);
>
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: New list subscriber - Question about gdi:widenpath
On 1/13/07, Laurent Vromman <[EMAIL PROTECTED]> wrote: > Can you provide a URL to a page describing the software you're trying > to port? http://francois.fouchet.free.fr/ Thanks. I just tried installing it following your instructions (I can read French, but you also have english instructions) and ran into the following problems: 1) I had to install the VB6 runtimes before running your app. 2) Even after installing Libraries.exe, your app claimed that dao350.exe was not installed. Running $ WINEDEBUG=+file ~/wine-git/wine NavigationMAJ.exe > log 2>&1 $ grep FindFirst.*DAO350 log trace:file:FindFirstFileExW L"C:\\Program Files\\FouFou\\Navigation\\DAO350.DLL" 0 0x33f060 0 (nil) 0 trace:file:FindFirstFileExW L"c:\\windows\\DAO350.DLL" 0 0x33f060 0 (nil) 0 trace:file:FindFirstFileExW L"c:\\windows\\system32\\DAO350.DLL" 0 0x33f060 0 (nil) 0 shows that your app doesn't search the directory where Librarie.exe installed DAO350.exe, namely Program Files/Common Files/DAO350.dll Could you update your app to fix at least the latter part? >> The point is this software needs gdi:widenpath to work. > It's not planned, as far as I know. Is there a web page where anyone could follow a planning, so that i won't disturb you to much ? wine-devel is it. I'll try to produce a patch if my skills allow me too and if I find enough time to do it. Great! - Dan
Re: Paul Vriens : crypt32/tests: Cast-qual warning fixes.
Michael Stefaniuc wrote: Alexandre Julliard wrote: Module: wine Branch: master Commit: 259c06ffc93d690fa5105b1451e519aa1c92b72e URL: http://source.winehq.org/git/wine.git/?a=commit;h=259c06ffc93d690fa5105b1451e519aa1c92b72e Author: Paul Vriens <[EMAIL PROTECTED]> Date: Fri Jan 12 15:51:02 2007 +0100 crypt32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/crypt32/tests/cert.c:312: invalid initializer make[2]: *** [cert.o] Error 1 Hi, I've sent 3 patches for this (crypt32/mshtml/secur32). I mentioned the compilation issues reported by Marcus this of course should have been Michael. Cheers, Paul.
Re: Paul Vriens : mshtml/tests: Cast-qual warning fix.
Michael Stefaniuc wrote:
Alexandre Julliard wrote:
Module: wine
Branch: master
Commit: 6338caa9eda8eda98dad9a89a8e71c6ea37bd168
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=6338caa9eda8eda98dad9a89a8e71c6ea37bd168
Author: Paul Vriens <[EMAIL PROTECTED]>
Date: Fri Jan 12 14:26:05 2007 +0100
mshtml/tests: Cast-qual warning fix.
This breaks compilation with older gcc versions. At least with gcc-3.1.1
used by Smatch.
dlls/mshtml/tests/htmldoc.c: In function `test_Load':
dlls/mshtml/tests/htmldoc.c:1806: invalid initializer
make[2]: *** [htmldoc.o] Error 1
Hi,
does the attached patch fix this? If
yes, I'll produce patches for mshtml,
crypt32 and secur32 which all suffer the
same issue.
Cheers,
Paul.
diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c
index 0815c01..99a15cc 100644
--- a/dlls/mshtml/tests/htmldoc.c
+++ b/dlls/mshtml/tests/htmldoc.c
@@ -1803,7 +1803,9 @@ static void test_Load(IPersistMoniker *persist)
{
IBindCtx *bind;
HRESULT hres;
-static WCHAR sz_html_clientsite_objectparam[] =
SZ_HTML_CLIENTSITE_OBJECTPARAM;
+static WCHAR sz_html_clientsite_objectparam[MAX_PATH];
+
+lstrcpyW(sz_html_clientsite_objectparam, SZ_HTML_CLIENTSITE_OBJECTPARAM);
test_readyState((IUnknown*)persist);
Re: New list subscriber - Question about gdi:widenpath
Hi, I took a look this morning to gdi32 source code. I think i'll be able to make a priliminary working version, partially implemented. I have already created a account to add the application in AppDB, I will do it as soon as possible. Laurent Tho a écrit : Hi Laurent, if you can`t implement the functionality yourself, then you might want to file a Bug in Bugzilla stating that your application depends on WidenPath() and add a simple Testcase for it. This will (at least) increase the chance, that the functionality gets added someday :) Maybe it would be useful too, if you would add an entry in our AppDB that decribes your App in more detail. Thorsten Thanks for answering me. Dan Kegel a écrit : Hi Laurent! You wrote: I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? http://francois.fouchet.free.fr/ The page doesn't exist in english. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. It's not planned, as far as I know. Is there a web page where anyone could follow a planning, so that i won't disturb you to much ? If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan In fact, I don't need this software professionaly. I wrote what job I'm doing only to present myself. I'll try to produce a patch if my skills allow me too and if I find enough time to do it. Otherwise I'll wait and keep a look on your mailing-list. Thank you for your help. I hope I'll come again with something to give you. Laurent
Re: New list subscriber - Question about gdi:widenpath
Hi Laurent, if you can`t implement the functionality yourself, then you might want to file a Bug in Bugzilla stating that your application depends on WidenPath() and add a simple Testcase for it. This will (at least) increase the chance, that the functionality gets added someday :) Maybe it would be useful too, if you would add an entry in our AppDB that decribes your App in more detail. Thorsten Thanks for answering me. Dan Kegel a écrit : Hi Laurent! You wrote: I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? http://francois.fouchet.free.fr/ The page doesn't exist in english. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. It's not planned, as far as I know. Is there a web page where anyone could follow a planning, so that i won't disturb you to much ? If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan In fact, I don't need this software professionaly. I wrote what job I'm doing only to present myself. I'll try to produce a patch if my skills allow me too and if I find enough time to do it. Otherwise I'll wait and keep a look on your mailing-list. Thank you for your help. I hope I'll come again with something to give you. Laurent
Re: New list subscriber - Question about gdi:widenpath
Thanks for answering me. Dan Kegel a écrit : Hi Laurent! You wrote: I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? http://francois.fouchet.free.fr/ The page doesn't exist in english. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. It's not planned, as far as I know. Is there a web page where anyone could follow a planning, so that i won't disturb you to much ? If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan In fact, I don't need this software professionaly. I wrote what job I'm doing only to present myself. I'll try to produce a patch if my skills allow me too and if I find enough time to do it. Otherwise I'll wait and keep a look on your mailing-list. Thank you for your help. I hope I'll come again with something to give you. Laurent
Re: GreenVille font, is it still available? I have a question about it.
Wierd_w wrote: Markus Amsler wrote: Adding hinting is IMO a second step. This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.) I would say, that's THE reason why to put TTF files into wines source. Have you done the "width hinting"? Depending on how far you want to go, you have 3 options as I see them: 1) (Best,but unlikely, due to the intense effort required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely." 2) Use the Type-1 font that is correct at sizes 15 and up, and use a bitmapped font for sizes below that and have WINE perform the substitution. 3) Adapt FontForge to inject SBIT record data (Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes. 4) Drop SFD->TTF conversion and add a "width hinted" TTF font.
