Re: I need help, please
Hi David, On 28.09.2007 17:28, David Outteridge wrote: Thank you for the reply, Dan, a reply is appreciated. I must write that I am surprised by this response - your website seems to be asking for help at all levels. I am not quite convinced that Yes, any help is appreciated and you can help as well. months of work is needed (mainly because corelDRAW version 11 works); but maybe you know something I do not - the main point of my posting, Dan knows more, but AFAIK the X3 version uses some interfaces which are not implemented yet. That's the problem with quite a few new applications, but in due time they will be supported. Besides that, having past versions of an application working fine under Wine unfortunately has nothing to say about newer versions of that app. Sometimes, application internals change so much that it takes literally a year or more to support a newer version. Look at MS Office for example. One more thing: It may or may not be easier to get CorelDRAW 12 to install and run first, perhaps some of the issues you have to fix there also help for the X3 version. of course. Largely, I was asking for policy information; i.e., *what* to do, not *how* to do it, which I feel I can handle. Looking at your first mail, I see you indeed dived into the code and accomplished something. My suggestion would be to post a separate mail (if possible, with a proposed hack/patch) with a descriptive subject for every issue you run into. Such mails are generally replied to more often (because of the descriptive subject) than mails with the subject line of this thread. Another hint: You wrote that you used comp.emulators.ms-windows.wine for questions, however that newsgroup is AFAIK a one-way gateway from mail to news, i.e. 98% of the members of that mailing list did NOT see your message. Good Luck with the project. Thanks! Regards, Carl-Daniel
Re: Small Direct3D milestone
On 19.05.2007 21:55, Stefan Dösinger wrote: Did you change something affecting D3D multithreaded apps? I am currently working on this. Some fundamental work went into wine somewhen between .33 and .35, but its not active yet. It was just some data structure modifications to handle multiple contexts for one swapchain. Before that the state management rework enabled us to keep track of states for multiple contexts. But right now I am working on making things really thread safe, and after that I can debug some gl crashes with the context selection patches I posted on this list a few months ago so they can go in finally. Cool. Star Trek: Bridge Commander doesn't start for me (only blank screen) since 0.9.37. http://appdb.winehq.org/appview.php?iVersionId=4207 (AppDB) http://www.bridgecommander.com/indepth/bcdemo.htm (downloadable demo) I'm using the opensource r300 ATI drivers if that matters. No idea about that. If it worked before a regression test will help Will do a regression test and report back. Regards, Carl-Daniel
Re: Small Direct3D milestone
Hi! On 11.05.2007 21:16, Stefan Dösinger wrote: With Wine 0.9.37 we've archieved something that I allow myself to call a small milestone - All Direct3D7 Immediate mode SDK demos successfully perform their intended rendering. Congratulations! Two major problems are left though, namely windowed opengl rendering(see the junk where a menu bar should be) and GetDC(there should be a little bit of text rendered, I disabled render target locking to get proper performance). Where to go from here? I am currently fixing the DirectDraw rewrite regressions I can get hold of, and I am trying to make D3D thread safe finally. From the application point of view my focus will stay on fixing older apps first, which somewhat includes getting thread safety, render target locking and GetDC working properly. Did you change something affecting D3D multithreaded apps? Star Trek: Bridge Commander doesn't start for me (only blank screen) since 0.9.37. http://appdb.winehq.org/appview.php?iVersionId=4207 (AppDB) http://www.bridgecommander.com/indepth/bcdemo.htm (downloadable demo) I'm using the opensource r300 ATI drivers if that matters. Regards, Carl-Daniel
Re: [programs/regedit] Fix command line processing for /? patch
On 27.04.2007 21:58, Tom Spear wrote:
On 4/27/07, Tom Spear [EMAIL PROTECTED] wrote:
On 4/27/07, Tom Spear [EMAIL PROTECTED] wrote:
On 4/27/07, Tom Spear [EMAIL PROTECTED] wrote:
On 4/27/07, Alexandre Julliard [EMAIL PROTECTED] wrote:
You don't want to do that, even if you print usage, an invalid
switch
needs to cause an error.
So should we fprintf the usage statement and exit(1); or should we
print both the usage, and the error for the invalid switch.
Unfortunately I don't have a copy of win98's regedit, and winxp's
regedit does not accept command line switches (I have tried), so I
can't check (easily) how the native regedit that ours is supposed to
be command-line compatible with, does it.
Neither. I just figured out why /? is not working. I can't believe
that I did not think of this before. The shell processes an unescaped
?. In order for it to work, I have to use /\? .. If I just do /?
then s ends up being /c /d and so ch ends up being c, which makes chu
C (which is missing from the ignored switches if statement)..
With the old code:
regedit /c returns regedit: Undefined switch /C!
regedit /? returns regedit: Undefined switch /C!
regedit /C returns regedit: Undefined switch /C!
The usage shows /c and /C as being valid switches.
So.. I changed the line
if (chu == 'S' || chu == 'V') {
to
if (chu == 'S' || chu == 'V' || chu == 'C') {
and so now:
regedit /c opens regedit
regedit /? shows the usage statement !
regedit /C opens regedit
Is this a proper fix? Can I submit it? The diff is attached..
Further testing shows apparently not, because s is being shifted to
the /d now.
Any ideas on how to properly capture /? vs having to escape it like
/\? ??
And even more further testing shows that my distro is wonky. echo /?
for me echos /c /d to my terminal Guess it's time to email Pat
Volkerding to find out if he can fix it for the next slack release.
That is expected if you have one-letter directories in your root folder.
Try echo /?
Regards,
Carl-Daniel
Re: Excluding a Windows version from the tests
On 30.03.2007 09:14, Alexandre Julliard wrote: Stefan Dösinger [EMAIL PROTECTED] writes: Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98? Only if there is an app that does the same version check and depends on both behaviors. It's very unlikely that an app would want to crash when the version is win98, so we don't need to replicate that behavior. Wasn't there some weird installshield behaviour where we had to crash like windows to make installshield happy? Regards, Carl-Daniel
ExtTextOut with rotation and MM_ANISOTROPIC inverted coordinates
Hi,
I have a problem with rotated Text displayed by ExtTextOut after
SetMapMode(hdc, MM_ANISOTROPIC);
SetWindowExtEx(hdc, 1000, -1000, NULL);
Basically, giving one negative parameter to SetWindowExtEx should
reverse the direction (clockwise/counterclockwise) in which
rotation is done. It works in Windows, but has no effect in wine.
The patch I created uses a side effect of the WMF file I had as
test case, basically it sets lfClipPrecision = CLIP_LH_ANGLES
and triggers direction inversion based on that instead of checking
the WindowExtEx settings. That is of course wrong, but it is
available almost everywhere in the text output paths and served
me nicely as inverse rotation flag.
Instead of abusing lfClipPrecision, what should we use? The
SetWindowExtEx call sets some_matrix.eM11 to a negative value
if its first argument is negative and eM22 to a negative value
if its second argument is negative.
So checking (eM11 * eM22 0) (mapmode == MM_ANISOTROPIC)
should be the correct solution. Problem: You can't always check
these things because the dc is not available everywhere.
In case you have a GdiFont, you can check
(font-font_desc.matrix.eM11 * font-font_desc.matrix.eM22 0)
or in case you have a LOGFONT
(dc-xformWorld2Vport.eM11 * dc-xformWorld2Vport.eM22 0)
I have not tested whether the parameters of the current dc,
the parameters at the time CreateFontIndirect was run or the
parameters at the time SelectObject(hdc, hfont) was run are
responsible for the rotation inversion.
What works?
With the patch, lfClipPrecision = CLIP_LH_ANGLES has the effect
SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) should
have. Exception: The text is clipped at the border, while Windows
auto-extends the borders to avoid clipping.
What doesn't work?
SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) still
has no effect on the rotation angle.
Attached are:
create_mf.c: Testcase in C (thanks to Dmitry Timoshkov, who
created the C code from a reduced WMF testcase I sent him)
create_mf_generated.wmf: WMF file output by ./create_mf file.wmf
wine-fontdirection-24.diff: Preliminary patch described above
If somebody can take a look at the patch and mangle it so
that it does the right thing, I'd be very grateful.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
#include windows.h
#include stdio.h
static void print_LPtoDP_map(HDC hdc, int x, int y)
{
POINT pt = { x, y };
LPtoDP(hdc, pt, 1);
printf(%d,%d - %d,%d\n, x, y, pt.x, pt.y);
}
static int create_wmf(const char *fname)
{
static const char txt_string[] = Should be top-down if not MM_ISOTROPIC mode;
HMETAFILE hmf;
HDC hdc;
LOGFONT lf;
HFONT hfont;
hdc = fname ? CreateMetaFile(fname) : GetDC(0);
if (!hdc)
{
printf(CreateMetaFile(%s) failed\n, fname);
}
//if (!fname)
{
//SetMapMode(hdc, MM_ISOTROPIC);
SetMapMode(hdc, MM_ANISOTROPIC);
}
print_LPtoDP_map(hdc, 100, 100);
SetWindowExtEx(hdc, 1000, -1000, NULL);
SetWindowOrgEx(hdc, 0, 0, NULL);
print_LPtoDP_map(hdc, 100, 100);
if (!fname)
{
SetViewportExtEx(hdc, 1000, 1000, NULL);
SetViewportOrgEx(hdc, 0, 200, NULL);
}
print_LPtoDP_map(hdc, 100, 100);
memset(lf, 0, sizeof(lf));
lf.lfHeight = -20;
//lf.lfEscapement = 2700;
//lf.lfOrientation = 2700;
lf.lfEscapement = 900;
lf.lfOrientation = 900;
lf.lfClipPrecision = CLIP_LH_ANGLES;
strcpy(lf.lfFaceName, Arial);
hfont = CreateFontIndirect(lf);
SelectObject(hdc, hfont);
ExtTextOut(hdc, 100, 100, 0, NULL, txt_string, strlen(txt_string), NULL);
MoveToEx(hdc, 100, 100, NULL);
LineTo(hdc, 200, 200);
LineTo(hdc, 200, -100);
LineTo(hdc, 0, 100);
DeleteObject(hfont);
if (fname)
{
hmf = CloseMetaFile(hdc);
DeleteMetaFile(hmf);
}
else
ReleaseDC(0, hdc);
return 0;
}
int main(int argc, char *argv[])
{
create_wmf(argc 2 ? NULL : argv[1]);
return 0;
}
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c
index ea2e66c..40d76c4 100644
--- a/dlls/gdi32/font.c
+++ b/dlls/gdi32/font.c
@@ -1944,6 +1944,10 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x,
{
cosEsc = cos(lf.lfEscapement * M_PI / 1800);
sinEsc = sin(lf.lfEscapement * M_PI / 1800);
+if (lf.lfClipPrecision CLIP_LH_ANGLES)
+{
+sinEsc = - sinEsc;
+}
}
else
{
diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
index f7b1220..730725a 100644
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
@@ -2675,10 +2675,10 @@ GdiFont *WineEngCreateFontInstance(DC *d
if (!GetObjectW( hfont, sizeof(lf), lf )) return NULL;
can_use_bitmap = GetDeviceCaps(dc-hSelf, TEXTCAPS) TC_RA_ABLE;
-TRACE(%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d
escapement %d\n,
+TRACE(%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d
escapement %d clipprecision %d\n,
Re: Accessing File 4gb problem (was: Debugging Supreme Commander)
On 20.03.2007 15:08, Stephan Rose wrote: So apparently the issue comes down the lseek failing with 4 gig files only on cd-rom drives and ends up not being a wine bug after all as far as I can tell. I will try to install it from the hard drive in a little bit and see if it succeeds then. I didn't have enough time during lunch to actually let the install run from the HD. AFAIK Linux didn't support files with multiple extents on ISO9660 filesystems in the past, at least when Joliet is used. I'm not sure about the current status. http://en.wikipedia.org/wiki/ISO_9660#The_4_GB_file_size_limit Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: Resend: Add d3drmdef.h header file - try 3
On 20.03.2007 09:37, Dmitry Timoshkov wrote: Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: I know its very tough to get patches done by newbies to get in, esp wine. It's absolutely not hard to get patches accepted, be it Wine or any other project. But it's absolutely required to listen for the comments and fix your work accordingly. Sorry, listen for the comments is not entirely correct. Often there are no comments at all and the patches simply don't get applied. If soemone is a newbie and really wants to get his/her patches accepted, mail patches repeatedly once every day until the patches get applied or someone comments. At the same time, ask on IRC why the patches didn't get applied. Regards, Carl-Daniel
Re: Submitting winetricks to winehq tree?
Hi, On 14.03.2007 20:01, Dan Kegel wrote: I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. Sorry if this has been answered before, but is winetricks a newer version of winetools? Regards, Carl-Daniel
Code audit (was: Re: Working on DIBEngine for SOC)
On 05.03.2007 22:57, Rolf Kalbermatter wrote: ReactOS you better don't mention here in Wine. As long as ReactOS has not been fully audited from an independent organization to not contain any copied code not under a compatible open source license, Wine will not accept any code that looks or even has the slightest suspicion that it might be from ReactOS. BTW, has the Wine code audit ever been finished or was it just aborted when media attention faded? The last statement I found was from Alexandre in March 2006 where he stated that 50% of the code were covered. Regards, Carl-Daniel
Re: Forum proposal
On 01.03.2007 20:09, Luis C. Busquets Pérez wrote: Why not having both? Running a forum does not exclude continuing with the mailing lists and could add users and developpers who find more easy coordinate through a forum. Configuring phpBB (www.phpbb.com) does not take more than 1 hour . I have made a try in 30 minutes starting from not knowing anything about this package: http://ns2.ilidium.com:8011/ Why not trying both systems? Simple. phpBB has had dozens of security holes in the past. Most other forum solutions have had the same share of problems. Now imagine a breakin on a site hosted on winehq. The consequences would be far worse than for the average toy project. Wine depends on people trusting us that the code is legally clean (especially due to various FUD campaigns claiming otherwise). A breakin will always result in claims that the codebase has been polluted with MS code. Such a PR disaster is not something we need. You're of course free to import all mails to this mailing list into your own private forum and make that somehow accessible. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: Forum proposal
On 01.03.2007 23:25, Alexandre Julliard wrote: Carl-Daniel Hailfinger [EMAIL PROTECTED] writes: Now imagine a breakin on a site hosted on winehq. The consequences would be far worse than for the average toy project. Wine depends on people trusting us that the code is legally clean (especially due to various FUD campaigns claiming otherwise). A breakin will always result in claims that the codebase has been polluted with MS code. You cannot modify the codebase even if you break into the server. Everything in the git repository is authenticated by its SHA-1, so any change would be immediately noticed. I know about this special feature of git (basically not only every file is identified by its SHA-1 hash, but also the complete timeline and with that the complete repository are secured with SHA-1). There was a post on the linux-kernel list some time ago about this topic. However, in case of a breakin there will always be somebody without this knowledge writing about the breakin. And nobody will read what we have to say about the security of git because the first article has always more readers than any followup or response. Regards, Carl-Daniel -- http://www.hailfinger.org/
rotated text in ExtTextOut
Hi,
I have a problem displaying rotated text in Wine where the
rotation under Windows is counterclockwise, but the rotation
in Wine is clockwise.
The patch I came up with rotates the text in the right direction,
but the individual characters are still rotated in the wrong
direction.
The attached WMF file shows the bug.
Any help/criticism would be appreciated.
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c
index 24f16dd..24dac20 100644
--- a/dlls/gdi32/font.c
+++ b/dlls/gdi32/font.c
@@ -1820,6 +1820,11 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x,
{
cosEsc = cos(lf.lfEscapement * M_PI / 1800);
sinEsc = sin(lf.lfEscapement * M_PI / 1800);
+if (lf.lfClipPrecision CLIP_LH_ANGLES)
+{
+FIXME(rotated text flag with flag CLIP_LH_ANGLES unimplemented,
trying to fix it up\n);
+sinEsc = - sinEsc;
+}
}
else
{
diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
index 1fe30f6..21eaad6 100644
--- a/dlls/winex11.drv/xrender.c
+++ b/dlls/winex11.drv/xrender.c
@@ -1135,6 +1135,11 @@ BOOL X11DRV_XRender_ExtTextOut( X11DRV_P
if(lf.lfEscapement != 0) {
cosEsc = cos(lf.lfEscapement * M_PI / 1800);
sinEsc = sin(lf.lfEscapement * M_PI / 1800);
+if (lf.lfClipPrecision CLIP_LH_ANGLES)
+{
+FIXME(rotated text flag with flag CLIP_LH_ANGLES unimplemented,
trying to fix it up\n);
+sinEsc = - sinEsc;
+}
} else {
cosEsc = 1;
sinEsc = 0;
Regards,
Carl-Daniel
