Re: idea: display drivers

[Charles Davis]

C.W. Betts wrote:
> Is is just because of the Objective-C code? Would it be safe to make C 
> functions that would call Objective-C?  Such as:
> cheader.h:
> typedef struct struct1 struct1;
> cfuncCreate(struct1 *s);
> cfunc1();
> cfunc2();
> cfuncDestroy (struct1 *s);
> 
> cfile.m:
> @interface WHQFunc
> {
> 
> }
> -(id)init;
> -(void)dealloc;
> @end
> struct 
> {
>   WHQFunc *ObjC;
>   int ids;
> }struct1;
> @implementation WHQFunc
> 
> -(id)init
> {
>   return [super init];
> }
> -(void)dealloc
> {
>   [super dealloc];
> }
> @end
> 
> cfunc1()
> {
> 
> }
> cfunc2()
> {
> 
> }
> cfuncCreate(struct1 *s)
> {
>   s = malloc(sizeof(struct1));
>   [[s->ObjC alloc] init];
> }
> cfuncDestroy (struct1 *s)
> {
>   [s->ObjC release];
>   free(s);
> }
> 
Working on it.

The problem is that there can't be any Objective-C code in Wine. At all.
Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any
language other than pure, procedural C.

I wanted to wait until it was finished, but I may as well announce it
now. I'm working on a new tool to create pure C bindings to Objective-C
frameworks. That way, you can use an Objective-C framework (like the
Cocoa Foundation and AppKit frameworks) from C. There is a even a
companion framework that lets you define your own classes and create
instances of them--without writing a single line of Objective-C.

If you'll be patient, I'll be finishing it soon, and I'll post the
source and binaries somewhere so you can use it. My intent is precisely,
among other things, to use this to create a Quartz driver that will work
in 64-bit (because the Carbon UI stuff doesn't work in 64-bit).

Chip

Re: idea: display drivers

[C.W. Betts]

Is is just because of the Objective-C code? Would it be safe to make C 
functions that would call Objective-C?  Such as:
cheader.h:
typedef struct struct1 struct1;
cfuncCreate(struct1 *s);
cfunc1();
cfunc2();
cfuncDestroy (struct1 *s);

cfile.m:
@interface WHQFunc
{

}
-(id)init;
-(void)dealloc;
@end
struct 
{
WHQFunc *ObjC;
int ids;
}struct1;
@implementation WHQFunc

-(id)init
{
return [super init];
}
-(void)dealloc
{
[super dealloc];
}
@end

cfunc1()
{

}
cfunc2()
{

}
cfuncCreate(struct1 *s)
{
s = malloc(sizeof(struct1));
[[s->ObjC alloc] init];
}
cfuncDestroy (struct1 *s)
{
[s->ObjC release];
free(s);
}

On Feb 6, 2010, at 7:45 AM, James McKenzie wrote:

> C.W. Betts wrote:
>> An idea that popped into my head when I was thinking about a Quartz (OS X) 
>> driver that perhaps there could be separate drivers for Quartz (OS X) and 
>> X11.  Such drivers would include OpenGL and DirectX "Drivers".
>> 
>> 
>> 
> This has been shot down time and time again by Alexandre.  However,
> picking up the old Winequartz.dll code and looking at it has been a
> project that I am interested in.   The code is available from
> Sourceforge.net.
> 
> James McKenzie
> 
> 

Re: [ mshtml missing function ]

[lementec fabien]

2010/2/6 lementec fabien :
> hi,
>
> thanks for the patch but it doesnot make
> solidwork works actually, even if it solves
> the previous issue. The error is now:
> fixme:mshtml:HTMLBodyElement_put_leftMargin
>
> I will file a bug,
>
> Regards,
>
> Fabien.
>
> 2010/2/6 Jacek Caban :
>> On 2/6/10 10:11 PM, lementec fabien wrote:
>>>
>>> Hi,
>>>
>>> I have mostly managed to make solidworks2010 work
>>> under the latest version of wine. The following function
>>> has a missing feature when called with the variant set to
>>> 3:
>>> dlls/mshtml.c::HTMLStyle_put_width
>>>
>>
>> You may try the attached patch (compile tested only).
>>
>>> I dont know anything related to mshtml,
>>
>> Then please file a bug instead of writing to wine-devel.
>>
>>>  so it would be
>>> great if anyone is interested in implementing it... would
>>> make this great software works with wine.
>>>
>>
>> I'd be skeptical about this, it's probably more work.
>>
>>
>> Jacek
>>
>>
>>
>>
>
>
>
> --
> the number of UNIX installations has grown to 10, with more expected.
> The unix programmer's manual, June, 1972
>



-- 
the number of UNIX installations has grown to 10, with more expected.
The unix programmer's manual, June, 1972

Re: [ mshtml missing function ]

[Jacek Caban]

On 2/6/10 10:11 PM, lementec fabien wrote:

Hi,

I have mostly managed to make solidworks2010 work
under the latest version of wine. The following function
has a missing feature when called with the variant set to
3:
dlls/mshtml.c::HTMLStyle_put_width
   


You may try the attached patch (compile tested only).


I dont know anything related to mshtml,


Then please file a bug instead of writing to wine-devel.


  so it would be
great if anyone is interested in implementing it... would
make this great software works with wine.
   


I'd be skeptical about this, it's probably more work.


Jacek
diff --git a/dlls/mshtml/htmlstyle.c b/dlls/mshtml/htmlstyle.c
index 04ba1d6..3022e2b 100644
--- a/dlls/mshtml/htmlstyle.c
+++ b/dlls/mshtml/htmlstyle.c
@@ -345,10 +345,12 @@ HRESULT set_nsstyle_attr_var(nsIDOMCSSStyleDeclaration 
*nsstyle, styleid_t sid,
 
 case VT_I4: {
 WCHAR str[14];
+
 static const WCHAR format[] = {'%','d',0};
+static const WCHAR px_format[] = {'%','d','p','x',0};
 
-wsprintfW(str, format, V_I4(value));
-return set_nsstyle_attr(nsstyle, sid, str, flags);
+wsprintfW(str, flags&ATTR_FIX_PX ? px_format : format, V_I4(value));
+return set_nsstyle_attr(nsstyle, sid, str, flags & ~ATTR_FIX_PX);
 }
 default:
 FIXME("not implemented vt %d\n", V_VT(value));
@@ -1779,15 +1781,7 @@ static HRESULT WINAPI HTMLStyle_put_width(IHTMLStyle 
*iface, VARIANT v)
 
 TRACE("(%p)->(v%d)\n", This, V_VT(&v));
 
-switch(V_VT(&v)) {
-case VT_BSTR:
-TRACE("%s\n", debugstr_w(V_BSTR(&v)));
-return set_style_attr(This, STYLEID_WIDTH, V_BSTR(&v), 0);
-default:
-FIXME("unsupported vt %d\n", V_VT(&v));
-}
-
-return E_NOTIMPL;
+return set_nsstyle_attr_var(This->nsstyle, STYLEID_WIDTH, &v, ATTR_FIX_PX);
 }
 
 static HRESULT WINAPI HTMLStyle_get_width(IHTMLStyle *iface, VARIANT *p)

Re: idea: display drivers

[Ben Klein]

On 7 February 2010 01:45, James McKenzie  wrote:
> C.W. Betts wrote:
>> An idea that popped into my head when I was thinking about a Quartz (OS X) 
>> driver that perhaps there could be separate drivers for Quartz (OS X) and 
>> X11.  Such drivers would include OpenGL and DirectX "Drivers".
>>
>>
>>
> This has been shot down time and time again by Alexandre.  However,
> picking up the old Winequartz.dll code and looking at it has been a
> project that I am interested in.   The code is available from
> Sourceforge.net.

Isn't there a LOT of code that's intertwined with winex11, or did that
get separated out?

Re: [ mshtml missing function ]

[Nikolay Sivov]

On 2/7/2010 00:11, lementec fabien wrote:

Hi,

I have mostly managed to make solidworks2010 work
under the latest version of wine. The following function
has a missing feature when called with the variant set to
3:
dlls/mshtml.c::HTMLStyle_put_width

   

You mean integer typed variant?

I dont know anything related to mshtml, so it would be
great if anyone is interested in implementing it... would
make this great software works with wine.

   
According to this - 
http://msdn.microsoft.com/en-us/library/aa768824%28VS.85%29.aspx

string is the only valid type for that.

Regards,

Fabien.

   

[ mshtml missing function ]

[lementec fabien]

Hi,

I have mostly managed to make solidworks2010 work
under the latest version of wine. The following function
has a missing feature when called with the variant set to
3:
dlls/mshtml.c::HTMLStyle_put_width

I dont know anything related to mshtml, so it would be
great if anyone is interested in implementing it... would
make this great software works with wine.

Regards,

Fabien.

-- 
the number of UNIX installations has grown to 10, with more expected.
The unix programmer's manual, June, 1972

Re: winedbg: output of the bt command misses sometimes a frame

[Eric Pouech]

Bernhard Übelacker a écrit :

Hello,
as I was debugging in wine I wondered if following behaviour is intended or
could be considered a bug (and should be filed in bugtracker?).

When the debugger's current position is on the opening curly bracket of a
function a "bt" command writes a different stack as if the current position
is on the next instruction in this function.

What me makes wonder is the frame 0 is always correct but the calling
function is not in the stack at all in the first bt:

  

this is likely because the prolog of IsWindow hasn't been run yet
try next (while on first {
and you should get a decent backtrace

actually, on i386, at the point you're considering
eip : is already in new function
but stack (ebp, esp) hasn't been initialized yet to new function => the 
prolog does it


actually, this is mainly due to the fact that winedbg doesn't do lots of 
magic about guessing prolog size, except when debug information is PDB 
(in that case, this very information is in the debug format)
we used to do some weird heuristics... like setting break address for 
function foo at second line number for this function, which is wrong of 
course
real fix would be (as gdb does in some cases) to disassembly the first 
bytes of the functions to guess the prolog size


A+

--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot." (Douglas Adams)

Re: idea: display drivers

[James McKenzie]

C.W. Betts wrote:
> An idea that popped into my head when I was thinking about a Quartz (OS X) 
> driver that perhaps there could be separate drivers for Quartz (OS X) and 
> X11.  Such drivers would include OpenGL and DirectX "Drivers".
>
>
>   
This has been shot down time and time again by Alexandre.  However,
picking up the old Winequartz.dll code and looking at it has been a
project that I am interested in.   The code is available from
Sourceforge.net.

James McKenzie

Re: msxml3: implement-domtext_replaceData

[Nikolay Sivov]

On 2/6/2010 04:36, jose rostagno wrote:
implement domtext_replaceData function 


+if(offset == 0){
+IXMLDOMText_substringData(iface, count, len - count,&str);
+hr = IXMLDOMText_put_data(iface, str);
+   if(hr == S_OK)
+hr = IXMLDOMText_put_data(iface, p);
   

This is obviously wrong. As a result just p will be stored as new data.
Let's deal with previous patch first, next patch should most likely just 
duplicate it.

Re: libpng dependency issue

[Luca Bennati]

2010/2/5 Vincent Povirk

>

> It's supported 32bpp with transparency from the start. The full list
> of supported writing formats is here:
> http://source.winehq.org/source/dlls/windowscodecs/pngformat.c#L680
>
> GUID_WICPixelFormat32bppBGRA is the format you want, I think.
>
> You probably tried to use a format not on that list, which defaults to
> 24-bit. I'm not sure what the behavior should be in that case.
>
> That's odd. Both WIC and winemenubuilder appear to be using BGR for
> 32-bit pixel formats and informing libpng of this . I don't know where
> you could be getting RGB pixels.
>
I didn't notice earlier, but you sent in a fix for winemenubuilder.
I tested compilation with it and it works fine.
Thank you for your attention on this problem.

Re: Winehq donation and DATA COMPRESSION

[Gert van den Berg]

On Sat, Jan 30, 2010 at 15:58, Gerold Jens Wucherpfennig
 wrote:
> BTW I've done some cabinet.dll stuff some years ago.
> Can anybody give me a hint to some easy-to-understand data compression
> documentation?
> I want to complete the cabinet.dll archive creation compression,
> if I get the required knowledge. It's so difficult... :-(

7-zip might have some usable code under a LGPL license (many files are
public domain as well)? (But is is mostly C++, but some codecs seem to
have C implementations...) (p7zip might be easier..)

http://www.7-zip.org/

Gert

idea: display drivers

[C.W. Betts]

An idea that popped into my head when I was thinking about a Quartz (OS X) 
driver that perhaps there could be separate drivers for Quartz (OS X) and X11.  
Such drivers would include OpenGL and DirectX "Drivers".

Re: msxml3-implement-domcomment_replaceData

[Nikolay Sivov]

On 2/5/2010 20:18, jose rostagno wrote:

implement missing domcomment_replaceData
+if((offset == 0) || ((count + offset)>= len))
+{
+if(offset == 0){
+IXMLDOMComment_substringData(iface, count, len - count,&str);
+hr = IXMLDOMComment_put_data(iface, str);
+   if(hr == S_OK)
+hr = IXMLDOMComment_appendData(iface, p);
   
This doesn't look right. You're appending replacement string to the rest 
of initial string data,
and offset == 0 means to replace from the start (if I didn't miss 
something).


Also we really need some tests here, and it's trivial to test here (look 
at existing test I recently added
for deleteData() for example). Especially test for a case count != (p 
string length) is interesting.


Minor things:
- watch for indentation and please avoid tabs - most lines are indented 
with spaces,
- don't use 'if () {' style. The rest of this file uses '{' on the next 
line,

- correct your name in author filed to start with uppercase.

Re: MDI client repaint issues (client and children) and conformance tests for this

[Reece Dunn]

On 6 February 2010 10:29, Reece Dunn  wrote:
> On 6 February 2010 04:15, Dmitry Timoshkov  wrote:
>> Reece Dunn  wrote:
>> Before
>> fixing the problem we need to understand what exactly is the sequence
>> of events that leads to it, how Windows and Wine behaviours differ.
>
> I understand this.

Looking a bit deeper into the MDI tests, the MDI client window used in
the tests has a size (0,0 - 0,0), whereas an MDI client in a
real-world application has it covering the frame's client area.

That is...

- 8< -
diff --git a/dlls/user32/tests/msg.c b/dlls/user32/tests/msg.c
index 76fef3b..7c707e7 100644
--- a/dlls/user32/tests/msg.c
+++ b/dlls/user32/tests/msg.c
@@ -3359,6 +3359,7 @@ static void test_mdi_messages(void)
 CLIENTCREATESTRUCT client_cs;
 HWND mdi_frame, mdi_child, mdi_child2, active_child;
 BOOL zoomed;
+RECT rc;
 HMENU hMenu = CreateMenu();

 assert(mdi_RegisterWindowClasses());
@@ -3389,6 +3390,11 @@ static void test_mdi_messages(void)
 assert(mdi_client);
 ok_sequence(WmCreateMDIclientSeq, "Create visible MDI client
window", FALSE);

+GetClientRect(mdi_frame, &rc);
+MoveWindow(mdi_client, rc.left, rc.top, rc.right - rc.left,
rc.bottom - rc.top, TRUE);
+/*MessageBoxA(NULL, "test", "test", MB_OK);*/
+flush_sequence();
+
 ok(GetActiveWindow() == mdi_frame, "wrong active window %p\n",
GetActiveWindow());
 ok(GetFocus() == mdi_frame, "input focus should be on MDI frame
not on %p\n", GetFocus());
- >8 --

which then fails some of the tests in Wine...

$ make msg.ok
msg.c:3510: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child:
19: in msg 0x0047 expecting wParam 0x9863 got 0x9062
msg.c:3532: Test failed: ShowWindow(SW_RESTORE):invisible MDI child:
5: in msg 0x0047 expecting wParam 0x9863 got 0x9062
msg.c:3556: Test failed: ShowWindow(SW_MAXIMIZE):MDI child: 5: in msg
0x0047 expecting wParam 0x9823 got 0x9022
msg.c:3562: Test failed: ShowWindow(SW_RESTORE):maximized MDI child:
4: in msg 0x0047 expecting wParam 0x9823 got 0x9022
msg.c:3719: Test failed: Create maximized invisible MDI child window:
17: in msg 0x0047 expecting wParam 0x8839 got 0x8038

... I am going to run this on the winetestbot to see how Windows behaves.

- Reece

winedbg: output of the bt command misses sometimes a frame

[Bernhard Übelacker]

Hello,
as I was debugging in wine I wondered if following behaviour is intended or
could be considered a bug (and should be filed in bugtracker?).

When the debugger's current position is on the opening curly bracket of a
function a "bt" command writes a different stack as if the current position
is on the next instruction in this function.

What me makes wonder is the frame 0 is always correct but the calling
function is not in the stack at all in the first bt:


Wine-dbg>bt
Backtrace:
=>0 0x7ebe3622 IsWindow(hwnd=0x20060) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2503] in 
user32 (0x0033b500)
  1 0x7e25429d create_window16+0x5c(cs=0x33b53c, className="QWidget", 
instance=0x40, unicode=1) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670]
 in user.exe16 (0x0033b520)
  2 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, className="QWidget", 
windowName="pica", style=114032640, x=-2147483648, y=-2147483648, 
width=-2147483648, height=-2147483648, parent=(nil), menu=(nil), 
instance=0x40, data=0x0(nil)) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] in 
user32 (0x0033b570)
  3 0x650778f3 in qtgui4 (+0x778f3) (0x8000)


Wine-dbg>next
2507if (!(ptr = WIN_GetPtr( hwnd ))) return FALSE;


Wine-dbg>bt
Backtrace:
=>0 0x7ebe3637 IsWindow+0x15(hwnd=0x20060) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2507] in 
user32 (0x0033b2b0)
  1 0x7ebe0bda WIN_CreateWindowEx+0x1201(cs=0x33b53c, className="QWidget", 
module=0x40, unicode=1) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1406] in 
user32 (0x0033b500)
  2 0x7e25429d create_window16+0x5c(cs=0x33b53c, className="QWidget", 
instance=0x40, unicode=1) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670]
 in user.exe16 (0x0033b520)
  3 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, className="QWidget", 
windowName="pica", style=114032640, x=-2147483648, y=-2147483648, 
width=-2147483648, height=-2147483648, parent=(nil), menu=(nil), 
instance=0x40, data=0x0(nil)) 
[/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] in 
user32 (0x0033b570)
  4 0x650778f3 in qtgui4 (+0x778f3) (0x8000)


Wine-dbg>


Kind regards
Bernhard

Re: MDI client repaint issues (client and children) and conformance tests for this

[Reece Dunn]

On 6 February 2010 04:15, Dmitry Timoshkov  wrote:
> Reece Dunn  wrote:
>
>> And in terms of a fix, what is the best approach for fixing the issue?
>> That is, Alexandre does not like an explicit call to InvalidateRect in
>> the WM_MDICREATE handler, so I assume that the repaint logic should be
>> done in a more specific place or figure out why it is not being called
>> for the MDI client.
>
> Probably WM_SETREDRAW has something to do with redrawing bug.

WM_SETREDRAW is used in two places in mdi.c, both of which don't do an
InvalidateRect/UpdateWindow call after the WM_SETREDRAW guard.

However, these don't have an effect. It might be a redraw bug deeper
into the windowing logic that mdi.c is making use of.

> Before
> fixing the problem we need to understand what exactly is the sequence
> of events that leads to it, how Windows and Wine behaviours differ.

I understand this.

- Reece

Re: Status of USB patches?

[Damjan Jovanovic]

On Sat, Feb 6, 2010 at 2:11 AM, Scott Ritchie  wrote:
> I wanted to experiment with these, but I'm not sure of their current
> state.  Do they still apply cleanly?  Are they on track for eventual
> inclusion?  I'm willing to help provide community testing by putting
> them in a special package repository.

A while back I sent some of the header files patches in, and now the
rest doesn't apply cleanly :-(. Sorry.

> Thanks,
> Scott Ritchie
>
>
>

Good luck
Damjan