Re: Re[4]: Fix tab size (3)

On October 21, 2003 12:43 am, Vitaliy Margolen wrote: > I'm not exactly sure how such a test will work. It involves graphical > components. Unless there are some way to make test see what's on the screen > I can't think of a way how to do this. Right, graphical tests are tricky, and it's not clear

Re[4]: Fix tab size (3)

Monday, October 20, 2003, 10:13:12 PM, you wrote: > On October 20, 2003 01:49 am, Vitaliy Margolen wrote: >> Do you mean I need to write some test program? I do have one, written in >> Delphi. I can send it in, or put on the web site and post a link here. >> Only it's not exactly nice program.

Re: Re[2]: Fix tab size (3)

On October 20, 2003 01:49 am, Vitaliy Margolen wrote: > Do you mean I need to write some test program? I do have one, written in > Delphi. I can send it in, or put on the web site and post a link here. > Only it's not exactly nice program. Just something to test few things > about tab control. Her

Re: EDIT_WM_Create fix.

On October 20, 2003 02:55 am, Rein Klazes wrote: > I cannot imagine the conformance here to be accidentally "lost". I am > not against conformance tests in general, but to protect such simple > one-line functionality seems to me a waste of the effort. Right, but the test would also tell us if all

Re: MDI windows, MDIClient and mdiclient

"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > In case anyone is interested - http://shemesh.biz/winetrace.bz2 Again unicows.dll (Microsoft Layer for Unicode) plays bad games with Wine. Could you regenerate the log with additional +snoop? -- Dmitry.

Xlib and wine and XGrabButton

I currently write a small desktop app (in case you are curious http://sourceforge.net/projects/launchmenu) and for this I have to research on how to grab mouse events and eventually keyboard as well. Now I thought that this might be usefull for wine when playing games under the DirectX emulation, s

Re: Fix comctl32 conformance test

Hans Leidekker <[EMAIL PROTECTED]> writes: > It appears that the comctl32 conformance test calls functions by name > that are exported by ordinal only on Windows. Still the test runs (and > thus run-time links) on Wine. Is this wanted behavior? Yes it is, the functions are converted to ordinal i

Re: will it?

Wine can't load windows drivers. This may be possible in a very very far future, but it would probably be easier to write native drivers. Probably by the time wine can do such a thing, all hardware vendors will support linux anyway.

import and export tables

A .tar.gz containing HTML tables of imports and exports for windows dlls is now available here: http://24.229.94.2/import_export_tables.tar.gz It is about 1MB but it will decompress to 1000+ html files and 58MB! I have not included empty tables where a dll does not import or export any functions.

Re: [ros-kernel] about headers

Hi Steven We've (ReactOS) already gone beyond the header issue with the decision to do a vendor branch of WINE. With regards to doing the same for ZLib and FreeType: well spotted! We should definitely do the same there. As I understand it, with a vendor import of WINE it doesn't matter to us (Rea

Re: [ros-kernel] about headers

From: "Jason Filby" > The only thing that worries me is Danny saying that they're not > aiming for the Windows SDK/DDK! If this is true then we may have to > keep our own headers, public or otherwise? > Small correction. I don't know what "they" are aiming for. I only know what I am aiming for -

Re: [ros-kernel] about headers

Ok thanks for clearing that up. Since our priority is SDK/DDK we'll probably be the main submitters of such code then. Regards Jason --- Danny Smith <[EMAIL PROTECTED]> wrote: > From: "Jason Filby" > > The only thing that worries me is Danny saying that they're not > > aiming for the Windows SDK/

Re: [ros-kernel] about headers

Hey Danny, --- Danny Smith <[EMAIL PROTECTED]> wrote: > Small correction. I don't know what "they" are aiming for. I only > know > what I am aiming for -- and that is to provide a good, affordable > compiler toolset for the ordinary user. The SDK/DDK is a low > priority > for me personally. Rig

Re: MDI windows, MDIClient and mdiclient

Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail. No, it shouldn't. The conversi

Re: MDI windows, MDIClient and mdiclient

Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail. No, it shouldn't. The conversio

Re: ReactOS GPL vs. proprietary drivers - NTFS Driver under Linux + WINE

Hello Jan, Comments are inline. --- Jan Kratochvil <[EMAIL PROTECTED]> wrote: > Hi, > > As GPLed Linux-NTFS still has no NTFS r/w capability I completed the > project > for reliable r/w access in Wine way by using MS-Windows ntfs.sys > driver. > > Captive-NTFS > http://www.jankratochvil.ne

Re: MDI windows, MDIClient and mdiclient

"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > When you send things via the "SendMessageA", I would assume they need to > be ANSI. As such, the "obvious reasons" are that it appears, to my > understanding of things, that this SHOULD fail. No, it shouldn't. The conversion should take place in th

will it?

(B (B (Bnow that windows drivers will work in linux, can (Bwine run directx easy?  with wine on linux, and having windows drivers, the (Bwine shouldn't have any troubles whatsoever acting as (Bwindows

Re: MDI windows, MDIClient and mdiclient

>I'm trying to see why a propritery program misbehaves under wine, by comparing it to >Windows. When running it under Windows, I don't have the luxury of OutputDebugString. Maybe even better: http://www.codeproject.com/useritems/DLL_Injection_tutorial.asp Already with a sample about logging win

Re: MDI windows, MDIClient and mdiclient

>Doesn't help me much when I have sources for neither program nor APIs. > >I'm trying to see why a propritery program misbehaves under wine, by comparing it to >Windows. When running it under Windows, I don't have the luxury of OutputDebugString. What about Spy++ for messages? For system calls y

Re: MDI windows, MDIClient and mdiclient

Boaz Harrosh wrote: I always use OutputDebugString (Win32 API), or TRACE macros under msvc headers. Than it shows under the Debugger. And if on-site, Just download for free the DebugMon application from: www.sysinternals.com It will catch and display all your Trac

Re: named pipes problem?

On Sun, 2003-10-19 at 21:22, Alexandre Julliard wrote: > Daniel Marmier <[EMAIL PROTECTED]> writes: > > > Are you talking about support for TLS in wine? > > If so, is that already assigned? > > No, the problem is TLS support in glibc itself, since that bypasses > our pthread wrappers. We don't ne

Re: MDI windows, MDIClient and mdiclient

I always use OutputDebugString (Win32 API), or TRACE macros under msvc headers. Than it shows under the Debugger. And if on-site, Just download for free the DebugMon application from: www.sysinternals.com   It will catch and display all your Traces and let you save them to file and more.. Fr

Re: named pipes problem?

On Mon, 2003-10-20 at 00:19, Gregory M. Turner wrote: > cool trick. an ironic side-note (I have not tried this on my without-nptl > system yet, so the following is not relevant to my problem): on my nptl > system (the one that works now), I get: > > # /lib/libc-2.3.2.so > Inconsistency detected

Re: MDI windows, MDIClient and mdiclient

Hi I hope I'm not stating the obvious here, I'm just trying to help. >I'm trying to find my way around the MDI setting, and phrase a regression test. >However, I cannot seem to create the exact same circumstances. When looking at the >original app using Spy++, I see that the application has a w

Re: MDI windows, MDIClient and mdiclient

Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM

Re: S3 texture compression patent

On Mon, 20 Oct 2003 02:26:53 +0100 Keith Matthews <[EMAIL PROTECTED]> wrote: > On Sun, 19 Oct 2003 23:23:44 +0200 > "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]> wrote: > > > >Is it a patent for a hrdware solution, or for software? If software then in > > >Europe, at least in Germany and others, it

Re: EDIT_WM_Create fix.

On Sun, 19 Oct 2003 12:19:10 -0400, you wrote: > On October 19, 2003 11:10 am, Rein Klazes wrote: > > Now I spent some time creating EDIT windows, varying parameters (with or > > without text), varying styles including multilines even tested the edit > > part of a combobox. In all cases the WM_CRE

Asprotected programs crash with current wine-cvs

Hello Alexandre , current CVS version has regression. All Asprotected (probably) programs crash due to the fact that Asprotect assumes that executables are being loaded from kernel32.dll, so stack return address passed to executable entry (in the other words executable entry was called from kerne