PATCH: define __user (was: Re: ./configure message)
On Wed, Feb 22, 2006 at 05:48:44PM -0700, Jesse Allen wrote: > On 2/21/06, dmitry serpokryl <[EMAIL PROTECTED]> wrote: > > configure: WARNING: linux/capi.h: present but cannot be compiled > > configure: WARNING: linux/capi.h: check for missing prerequisite > > headers? > > configure: WARNING: linux/capi.h: see the Autoconf documentation > > configure: WARNING: linux/capi.h: section "Present But Cannot Be > > Compiled" > > configure: WARNING: linux/capi.h: proceeding with the preprocessor's result > > configure: WARNING: linux/capi.h: in the future, the compiler will take > > precedence > > configure: WARNING: ## ## > > configure: WARNING: ## Report this to wine-devel@winehq.org ## > > configure: WARNING: ## ## > > > > > > SuSE 10 x86-64, gcc-4.0.2 (release) > You are compiling with linux 2.6 header files... And there is nothing bad with that. We need __user defined (to nothing) during configure checking as a workaround. What about this patch? Ciao, Marcus Changelog: Explicitly define __user to "empty" to allow kernel header inclusion. Index: configure.ac === RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.445 diff -u -r1.445 configure.ac --- configure.ac20 Feb 2006 20:19:39 - 1.445 +++ configure.ac23 Feb 2006 07:11:07 - @@ -169,6 +169,7 @@ AC_SUBST(GLU32FILES,"") AC_SUBST(OPENGL_LIBS,"") +AC_DEFINE(__user,[],[To allow configure checking of kernel headers.]) dnl Check for header files AC_CHECK_HEADERS(\
Re: comm & Win98
Wednesday, February 22, 2006, 1:51:45 PM, Eric Pouech wrote: > could someone with a Win98 box test the attached test > (it's a diff to dlls/kernel/tests/comm.c) ? > the test passes on XP, I want to be sure it does as well on Win9x before > I remove the offending code > TIA Ran on win98 in vmware: L:\wine\crosstests>kernel32_crosstest.exe comm comm.c:677:Found Com port COM1. Connected devices may disturbe results comm.c:695:GetCommModemStatus returned 0x00b0->MS_RLSD_ON MS_DSR_ON MS_CTS_ON comm.c:745:test_waittxempty comm.c:770:WriteFile succeeded, took 0 ms to write 17 Bytes at 150 Baud comm.c:784:WaitCommEvent for EV_TXEMPTY took 0 ms comm.c:677:Found Com port COM1. Connected devices may disturbe results comm.c:804:test_ClearCommErrors done comm.c:677:Found Com port COM1. Connected devices may disturbe results comm.c:677:Found Com port COM1. Connected devices may disturbe results comm.c:1295:test_AbortWaitCts timeout 500 handle 0x0014 comm.c:1265: Changing CommMask on the fly for handle 0014 after timeout 500 comm.c:1303:Thread created comm.c:1313:Success 0x err 0x03e5 evtmask 0x comm.c:1315:overlapped WriteCommEvent returned. comm.c:1322:Success 0x0001 err 0x03e5 evtmask 0x diff1 0, diff2502 comm.c:1269:comm: 5510 tests executed, 0 marked as todo, 0 failures.
Re: ./configure message
On 2/21/06, dmitry serpokryl <[EMAIL PROTECTED]> wrote: > configure: WARNING: linux/capi.h: present but cannot be compiled > configure: WARNING: linux/capi.h: check for missing prerequisite > headers? > configure: WARNING: linux/capi.h: see the Autoconf documentation > configure: WARNING: linux/capi.h: section "Present But Cannot Be > Compiled" > configure: WARNING: linux/capi.h: proceeding with the preprocessor's result > configure: WARNING: linux/capi.h: in the future, the compiler will take > precedence > configure: WARNING: ## ## > configure: WARNING: ## Report this to wine-devel@winehq.org ## > configure: WARNING: ## ## > > > SuSE 10 x86-64, gcc-4.0.2 (release) > > > You are compiling with linux 2.6 header files...
Re: [MSI 5/5] Fix Stack Buffer Overflow in MSI_ProcessMessage
Robert Shearman <[EMAIL PROTECTED]> writes: > ChangeLog: > Fix a theoretical stack buffer overflow if the number was greater than > one digit. Then the buffer should be larger, silently truncating the number is not that much better than a stack overflow. -- Alexandre Julliard [EMAIL PROTECTED]
Re: WineFile: [PATCH] Implement part of Save Settings to registry
Am Montag, den 20.02.2006, 12:57 -0500 schrieb Jason Green:
> > This patch adds the ability to save your window position to the
> > registry when using winefile.
> +static const WCHAR registry_key[] =
{ 'S','o','f','t','w','a','r','e','\\',
>+ 'W','i','n','e','\\','W','i','n','e','F','i','l','e','\0'};
Native winfile uses winfile.ini on win9x and this is mapped to the
registry in WinNT.
(IniFileMapping does not work in wine yet
http://www.microsoft.com/resources/documentation/windowsnt/4/workstation/reskit/en-us/26_ini.mspx
).
Can we make the settings compatible?
+static windowOptions load_registry_settings()
+{
+ windowOptions opts;
+
+ return opts;
+}
BANG.
You used a struct on the stack.
That Memory is not valid after the return.
Use a pointer to the your struct as Parameter: ...(windowOptions * opts)
--
By By ...
... Detlef
comm & Win98
could someone with a Win98 box test the attached test
(it's a diff to dlls/kernel/tests/comm.c) ?
the test passes on XP, I want to be sure it does as well on Win9x before
I remove the offending code
TIA
--
Eric Pouech
diff --git a/dlls/kernel/tests/comm.c b/dlls/kernel/tests/comm.c
index ed79b15..794ded2 100644
--- a/dlls/kernel/tests/comm.c
+++ b/dlls/kernel/tests/comm.c
@@ -804,6 +804,18 @@ static void test_ClearCommErrors(HANDLE
trace("test_ClearCommErrors done\n");
}
+static void test_non_pending_errors(HANDLE hcom)
+{
+DCB dcb;
+DWORD err;
+
+ok(GetCommState(hcom, &dcb), "GetCommState failed\n");
+dcb.ByteSize = 255; /* likely bogus */
+ok(!SetCommState(hcom, &dcb), "SetCommState should have failed\n");
+ok(ClearCommError(hcom, &err, NULL), "ClearCommError should succeed\n");
+ok(!(err & CE_MODE), "ClearCommError shouldn't set CE_MODE byte in this case (%lx)\n", err);
+}
+
/**/
static void test_LoopbackRead(HANDLE hcom)
{
@@ -1613,7 +1625,7 @@ static void test_WaitBreak(HANDLE hcom)
START_TEST(comm)
{
HANDLE hcom;
-/* use variabel and not #define to compile the code */
+/* use variables and not #define to compile the code */
BOOL loopback_txd_rxd = LOOPBACK_TXD_RXD;
BOOL loopback_rts_cts = LOOPBACK_CTS_RTS;
BOOL loopback_dtr_dsr = LOOPBACK_DTR_DSR;
@@ -1632,10 +1644,16 @@ START_TEST(comm)
hcom = test_OpenComm(FALSE);
if (hcom != INVALID_HANDLE_VALUE)
{
- Sleep(200); /* Give the laster cahacter of test_waittxempty to drop into the receiver*/
+ Sleep(200); /* Give the laster character of test_waittxempty to drop into the receiver */
test_ClearCommErrors(hcom);
CloseHandle(hcom);
}
+hcom = test_OpenComm(FALSE);
+if (hcom != INVALID_HANDLE_VALUE)
+{
+test_non_pending_errors(hcom);
+ CloseHandle(hcom);
+}
if((loopback_txd_rxd) && ((hcom = test_OpenComm(FALSE))!=INVALID_HANDLE_VALUE))
{
test_LoopbackRead(hcom);
Re: OLEAUT32: Fix regression in OLEFontImpl_Clone
Alex Villacís Lasso wrote:
Lately, all VB6 applications crash on exit. This weekend, I found the
cause. Apparently the VB6 runtime creates a standard OLEFont object,
and then calls IFont::clone() on it to get a second object. At exit,
the VB6 runtime disposes of both objects. However, the recent OLEFont
changes introduced a bug in which the cloning fails to clone the
connection points associated with the object. Therefore the dispose of
one of the objects frees the connection points, and the dispose of the
second object crashes on attempt to dispose an already-freed object.
Changelog:
* Create new empty connection points on clone of OLEFont
Alex Villacís Lasso
--- wine-0.9.8-cvs/dlls/oleaut32/olefont.c 2006-02-14 10:38:35.0
-0500
+++ wine-0.9.8-cvs-patch/dlls/oleaut32/olefont.c2006-02-18
18:40:01.0 -0500
@@ -1113,6 +1113,19 @@
/* The cloned object starts with a reference count of 1 */
newObject->ref = 1;
+ /* We need to clone the connection points too. */
+ /* FIXME: should we just add a reference to the (shared) connection points?
*/
+ newObject->pPropertyNotifyCP = NULL;
+ newObject->pFontEventsCP = NULL;
+ CreateConnectionPoint((IUnknown*)newObject, &IID_IPropertyNotifySink,
&newObject->pPropertyNotifyCP);
+ CreateConnectionPoint((IUnknown*)newObject, &IID_IFontEventsDisp,
&newObject->pFontEventsCP);
+
+ if (!newObject->pPropertyNotifyCP || !newObject->pFontEventsCP)
+ {
+OLEFontImpl_Destroy(newObject);
+return E_OUTOFMEMORY;
+ }
+
*ppfont = (IFont*)newObject;
return S_OK;
Is there anything wrong with this patch? Not applied, and nobody has
commented on it either.
Alex Villacís Lasso
Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - Corrected
Any thing wrong with this patch. Any Comments (expecting a lot) On 2/17/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote: > Hi, > I am sending the Correct Version. > ChangeLog > > Add More Tests for InternetQueryOption > Add Tests for InternetSetOption > > Thanks, > Vijay > On 2/17/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote: > > please ignore this > > will send a correct version soon > > > > On 2/17/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote: > > > ChangeLog > > > > > > Add More Tests for InternetQueryOption > > > Add Tests for InternetSetOption > > > > > > > > > > > > > >
Re: Cross-Machine COM-Calls under Wine... (RePost from wine.user)
Olaf Schmidt wrote: are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. I assume you mean cross-process COM calls? The D-part of DCOM is not currently supported. No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). Great! So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. This is expected and it is on my todo list to fix this. However, I want to get more applications working first before I make the ones that do work faster! But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Brilliant! Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) No. It doesn't really make sense at the moment. We don't recommend that Wine be run as root and we don't support impersonating other Unix users that would be necessary to maintain security in this environment. 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) The probably both do nothing. Since you shouldn't be running as root, then this isn't a problem. 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding Not supported yet. During a recent rewrite of the ROT implementation I made it easier to do this, but our midl replacement "widl" isn't quite at the point where this can be implemented yet. I can provide more details about the architecture of the ROT if you are interested. 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). I'm not sure what you mean here by "RPCServer-internal singletons". Please elaborate. Both of the APIs you mention should be fully functional. Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. The best debugging source would be to run with the environment variable "WINEDEBUG=+ole" and dump the output to a file. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. I don't have time to download and install your applications, but I am willing to look at debug logs if you generate them. -- Rob Shearman
Cross-Machine COM-Calls under Wine... (RePost from wine.user)
are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. If you want to test a Server/Client-Pair - here's our free Download: www.datenhaus.de/Downloads/dh_RPC.zip For a successful test under Wine, you have to Install the Redistributables of an actual VB6-Runtime and some ADO-Distributable >=2.5 first. I've tested the whole thing under a Debian-Sid with a somewhat older Kernel (2.6.9), but with a new "apt-getted" Wine-Version (0.97). The Installation of the VB6-Runtime and the ADO-Redist was not possible, until I figured out, that a prior install of IE6 was helpful, to install the two above mentioned packages. After installing these prerequisites, I removed the IE6-ProgramFolder, unpacked our ZIP to c:\dh_RPC, started the Server and the Client - eh voilà - all was working fine (Linux->Linux and XP->Linux). The complete set of COM-DemoCalls was working "OutOfTheBox", even the "Disconnected ADO-Recordset"-Call was successful. (For the Linuxers, that are serialized DB-Resultsets, wich are often used in distributed COM-Scenarios). No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. Thanks. Olaf Schmidt
./configure message
configure: WARNING: linux/capi.h: present but cannot be compiled configure: WARNING: linux/capi.h: check for missing prerequisite headers? configure: WARNING: linux/capi.h: see the Autoconf documentation configure: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/capi.h: proceeding with the preprocessor's result configure: WARNING: linux/capi.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to wine-devel@winehq.org ## configure: WARNING: ## ## SuSE 10 x86-64, gcc-4.0.2 (release)
Re: WineD3D / D3D8 color format issues
Hi, > What shall I do, just change the behaviour back to GL_RGB which works? > Second the issue likely appears for some other formats which Oliver > changed. I've seen the same issues with 16 bit games. My current solution is to switch to GL_RGB, but I doubt that this is correct. There are a lot of strange RGB<->BGR conversions, depending on the color depth. I think we should check this against all D3D formats. I've not fully understood the texture loading code, but I think that Oliver might be right with GL_BGR, and the bug might be somwhere else. pgpWLeCc1yUId.pgp Description: PGP signature
Window discovering
Hello, Under Windows, there is a tool, that comes with Visual Studio - "Spy++". This tool allows to select window object, get its information (class, styles, etc.) and its messages. Unfortunately, I was unable to start this application (probably it requires some COM object to be register, or something else). I've tried to google for any similar tools, and found one, named WinSpector (http://www.windows-spy.com). But it doesn't allow to select any window from separate process. Is there any tool, that allows to do such things, that works with wine, or probably I need any special settings to run this application? -- Cyril Margorin
Cross-Machine COM-Calls under Wine... (RePost from wine.user)
are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. If you want to test a Server/Client-Pair - here's our free Download: www.datenhaus.de/Downloads/dh_RPC.zip For a successful test under Wine, you have to Install the Redistributables of an actual VB6-Runtime and some ADO-Distributable >=2.5 first. I've tested the whole thing under a Debian-Sid with a somewhat older Kernel (2.6.9), but with a new "apt-getted" Wine-Version (0.97). The Installation of the VB6-Runtime and the ADO-Redist was not possible, until I figured out, that a prior install of IE6 was helpful, to install the two above mentioned packages. After installing these prerequisites, I removed the IE6-ProgramFolder, unpacked our ZIP to c:\dh_RPC, started the Server and the Client - eh voilà - all was working fine (Linux->Linux and XP->Linux). The complete set of COM-DemoCalls was working "OutOfTheBox", even the "Disconnected ADO-Recordset"-Call was successful. (For the Linuxers, that are serialized DB-Resultsets, wich are often used in distributed COM-Scenarios). No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. Thanks. Olaf Schmidt P.S. As Dan Kegel has recommended in 'wine.user', I will try to isolate the Problems 3. und 4. in separate Binaries and post a link later.
Re: suse linux 9.3
On Tue, Feb 21, 2006 at 08:33:11AM -0800, melvin qiuntin wrote: > I tried to install your new .98 rpm and it is listing unsatisfied > dependancies. V3 DSA signature, Libwine so.1, no key Key ID0175623e. I am > not sure if that is a o or a 0. > Please explain. libwine.so.1 is within the WINE package itself. Can you cut & paste the error messages? Ciao, Marcus
