LogonUser(), netapi work
Hi, after having been busy with other stuff for a while, I'd like to inquire the status of my LogonUser() patch (http://www.winehq.com/hypermail/wine-devel/2002/09/0448.html) I have had almost no feedback, positive or negative, on this, and it wasn't applied either. I still think it could be useful, although it is clear that wine won't (shouldn't) be able to change personality in the foreseeable future. Andriy, what is the status of your netapi work? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Marshalling code for me to use?
and I don't know about anyone else working on it (Juergen Schmied is probably busy with other stuff). Yes, I'm not able to do much of work for some month. (Bussy changing nappies...). I was only merging the RPC stuff because I was interested in getting ove's COM stuff into wine. I might start to work there (COM) again sometimes later [or more early if I could pay my bills from it ... - thats life ;-) ] I still have some not-yet-ready-for-submitting LPC stuff in my queue. (If sbd interested...) PS: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? juergen --- [EMAIL PROTECTED]
Re: Third listview status update
On Mon, 21 Oct 2002 23:57:52 -0400, you wrote: I would like to thank everybody that helped me with testing, patches, or reporting bugs. I couldn't have done the half of it without that support. This sounds like this is a done deal. It's not. There's a lot of stuff that remains to be done, but I needed some closure. :) Yes that seems the right way to proceed. Here is an update of newsbin status (current cvs == V18 ). On the positive side background colouring for new messages works now. Current show-stoppers: - only first column displays text; this problem existed from the beginning; - when downloading headers, the messages listview doesn't get filled; this problem was introduced in rev. 1.200; I can get the list to display after the download is finished by toggling the show only new headers option; I have uploaded a cut of a +listview trace on www.xs4all.nl/~rklazes/nb.log.bz2 ; - crashes :(( see below. Nit-picking: - the green background extends as far as the text; with native comctl32 is extends the whole column; - A line that has both a green background and is marked slected will display as white text on green backgound; With native comctl32 is shows as white text on dark blue background (same as selected); - updates are from bottom to top; this gets some getting used to; Till sofar I had two different (looking at the backtrace) crashes. I did not found a way to reproduce easily, just that it happens always shorly after a second download is requested. I will try to create debug logs when I find a way to reproduce. Crash 1: | err:ntdll:RtlpWaitForCriticalSection section 0x4fcf28 ? wait timed out, retrying |(60 sec) tid=087ee0b8 | Unhandled exception: page fault on write access to 0x00418082 in 32-bit code |(0x400a3e2d). | In 32-bit mode. | 0x400a3e2d (INSTR_EmulateInstruction+0xaf9 [instr.c:615] in libntdll.dll.so): movl | %eax,0x0(%esi) | Warning: L/usr/home/projects/wine/mywine/dlls/ntdll/../../memory/instr.c not |accessible from a configured DOS drive | Unable to open file /usr/home/projects/wine/mywine/dlls/ntdll/../../memory/instr.c | Backtrace: | =0 0x400a3e2d (INSTR_EmulateInstruction+0xaf9(context=0x40630a50, |context=0x40630a50, context=0x40630a50, context=0x40630a50, context=0x40630a50, |context=0x40630a50, context=0x40630a50, context=0x40630a50, context=0x40630a50, |context=0x40630a50, context=0x40630a50, context=0x40630a50, context=0x40630a50, |context=0x40630a50, context=0x40630a50, context=0x40630a50, context=0x40630a50, |context=0x40630a50, context=0x40630a50, context=0x40630a50) [instr.c:615] in |libntdll.dll.so) (ebp=406309c4) | 1 0x400dd289 (do_segv+0x109(context=0x40630a50, trap_code=0xd, cr2=0x0, |err_code=0x0) [signal_i386.c:761] in libntdll.dll.so) (ebp=40630a2c) | 2 0x400dd762 (segv_handler+0x3a(__signal=0xb, __context=0x1587) |[signal_i386.c:986] in libntdll.dll.so) (ebp=40630d1c) | 3 0x4025fb88 (NTDLL.DLL.toupper+0x59ae in libc.so.6) (ebp=414a0328) | 4 0x0cd6 (ebp=00010023) | 5 0x18171615 (LIBFILTER.DLL..reloc+0x812e615) (ebp=14131211) | *** Invalid address 0x14131211 (LIBFILTER.DLL..reloc+0x40ee211) | Crash 2: | err:ntdll:RtlpWaitForCriticalSection section 0x4fcf28 ? wait timed out, retrying |(60 sec) tid=087eedb8 | Unhandled exception: page fault on write access to 0x1784562e in 32-bit code |(0x4272392f). | In 32-bit mode. | 0x4272392f (_end+0xdbf6f): addb %bh,0x957c4272(%ebx,%edi,1) | Register dump: | CS:0023 SS:002b DS:002b ES:002b FS:008f GS:1587 | EIP:4272392f ESP:40741c5c EBP:40741cb4 EFLAGS:00210a86( R- 00O I S - -P1 ) | EAX:427d1354 EBX:40be1094 ECX:41a7ff3c EDX:0002 | ESI:41a7ff3c EDI:414a0328 | Backtrace: | =0 0x4272392f (_end+0xdbf6f) (ebp=40741cb4) | 1 0x40b7db77 (DPA_QuickSort+0xf3(lpPtrs=0x414bd320, l=0xd1, r=0xd2, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2077] in comctl32.dll.so) |(ebp=40741ce0) | 2 0x40b7db1c (DPA_QuickSort+0x98(lpPtrs=0x414bd320, l=0xd1, r=0xd4, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2072] in comctl32.dll.so) |(ebp=40741d14) | 3 0x40b7db35 (DPA_QuickSort+0xb1(lpPtrs=0x414bd320, l=0xcc, r=0xd4, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2075] in comctl32.dll.so) |(ebp=40741d5c) | 4 0x40b7db1c (DPA_QuickSort+0x98(lpPtrs=0x414bd320, l=0xcc, r=0xdd, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2072] in comctl32.dll.so) |(ebp=40741d90) | 5 0x40b7db35 (DPA_QuickSort+0xb1(lpPtrs=0x414bd320, l=0xb9, r=0xdd, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2075] in comctl32.dll.so) |(ebp=40741dd8) | 6 0x40b7db35 (DPA_QuickSort+0xb1(lpPtrs=0x414bd320, l=0x94, r=0xdd, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2075] in comctl32.dll.so) |(ebp=40741e20) | 7 0x40b7db1c (DPA_QuickSort+0x98(lpPtrs=0x414bd320, l=0x94, r=0x126, |pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2072] in comctl32.dll.so) |(ebp=40741e54) | 8 0x40b7db35 (DPA_QuickSort+0xb1(lpPtrs=0x414bd320,
Re: [RFC] Adding an include/wine/wine directory?
It would be nice but I dont expect/want a major overhaul of the header system for you and I with the Mingw and MS_VC work. If one day WINE is going to use some sort of common header/import system that it shares with Mingw/Borland* then I am all for it but atm ReactOS is not contributing much back and I have not had much time to focus on anything so take my vote with a gain of salt. Thanks Steven * I think that work is underway for borland or one of the other open compilers to use the win32api/ddk package that the mingw project uses. If this system works and becomes popular it would still be nice to see all of the Open-Win projects be able to work together. It seems that I'm not the only one having this problem as well. Steven Edwards also wants a way to use the Mingw/W32api package together with Wine in a sane way.
Re: Marshalling code for me to use?
Am Die, 2002-10-22 um 13.46 schrieb Ove Kaaven: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? I borrowed the UuidHash algorithm from freedce. I don't think we can borrow a lot since the way rpcrt4 does ndr internally is part of the exported API, but it can be used as a reference implementation (and maybe a source of .idl files?) What about Samba-TNG (www.dcerpc.org, www.samba-tng.org)and the sidlc compiler that is part of it? (Forgive me if that's a stupid suggestion) Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
here's a snapshot of my tree...
I'm holding back on submitting an official patch to give Alexandre
the chance to catch up so I can start a new F series and not
stay forever conceptually forked from CVS wine. But I thought he or
somebody else might like to see what's I'm up to so here goes (I'm also
having some HD troubles so, in case I have a meltdown, this will prevent
me from losing my work!)
I'm enclosing a diff relative to E_PL15 and also a bigger one of uncomitted
changes relative to CVS wine (the E_PLxx series are inclusive of this latter
diff, so there is nothing new there). I've indexed it as F_PL1 because
presumably F_PL0 will be yet another copy of the unmerged server
parts.
the E_PL15_unmerged patch does not include the F_PL1_pre0 patch,
so if you take CVS wine, apply E_PL15_unmerged.diff, and then
apply F_PL1_pre0.diff on top of that, you have my tree. As usual,
this is not a hint to apply.
LICENSE: X11
CHANGELOG (for rpc_F_PL1_pre0 only):
* dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h;
include: rpcndr.h, wine/rpcfc.h:
Greg Turner [EMAIL PROTECTED]
- make explicit some hidden include dependencies
- Implement NdrGetBuffer, NdrFreeBuffer, and
NdrConformantStringBufferSize
- define the RPC_FC_C_CSTRING constant
- perhaps I don't want those MIDL structs after all. removed.
--
gmt
Oh, and of course, the fastest way to dig
a tunnel is to dig at both sides.
-- The Linux Advanced Routing HOWTO
diff -urN -x unpatch -x CVS -x 'bigdif*' ../wine.vanilla/dlls/rpcrt4/Makefile.in ./dlls/rpcrt4/Makefile.in
--- ../wine.vanilla/dlls/rpcrt4/Makefile.in 2002-10-21 19:41:17.0 -0500
+++ ./dlls/rpcrt4/Makefile.in 2002-10-21 21:48:54.0 -0500
@@ -21,6 +21,7 @@
rpc_binding.c \
rpc_message.c \
rpc_server.c \
+ rpc_epmap.c \
rpcrt4_main.c
SUBDIRS = tests
diff -urN -x unpatch -x CVS -x 'bigdif*' ../wine.vanilla/dlls/rpcrt4/ndr_midl.c ./dlls/rpcrt4/ndr_midl.c
--- ../wine.vanilla/dlls/rpcrt4/ndr_midl.c 2002-10-21 19:41:17.0 -0500
+++ ./dlls/rpcrt4/ndr_midl.c 2002-10-22 02:43:40.0 -0500
@@ -172,9 +172,23 @@
* NdrClientInitializeNew [RPCRT4.@]
*/
void WINAPI NdrClientInitializeNew( PRPC_MESSAGE pRpcMessage, PMIDL_STUB_MESSAGE pStubMsg,
-PMIDL_STUB_DESC pStubDesc, int unknown )
+PMIDL_STUB_DESC pStubDesc, unsigned int ProcNum )
{
- FIXME(stub\n);
+ TRACE((pRpcMessage == ^%p, pStubMsg == ^%p, pStubDesc == ^%p, ProcNum == %d)\n,
+pRpcMessage, pStubMsg, pStubDesc, ProcNum);
+
+ memset(pRpcMessage, 0, sizeof(RPC_MESSAGE));
+ memset(pStubMsg, 0, sizeof(MIDL_STUB_MESSAGE));
+
+ pStubMsg-ReuseBuffer = TRUE;
+ pStubMsg-IsClient = TRUE;
+ pStubMsg-StubDesc = pStubDesc;
+ pStubMsg-pfnAllocate = pStubDesc-pfnAllocate;
+ pStubMsg-pfnFree = pStubDesc-pfnFree;
+ pStubMsg-RpcMsg = pRpcMessage;
+
+ pRpcMessage-ProcNum = ProcNum;
+ pRpcMessage-RpcInterfaceInformation = pStubDesc-RpcInterfaceInformation;
}
/***
diff -urN -x unpatch -x CVS -x 'bigdif*' ../wine.vanilla/dlls/rpcrt4/rpc_binding.c ./dlls/rpcrt4/rpc_binding.c
--- ../wine.vanilla/dlls/rpcrt4/rpc_binding.c 2002-10-21 19:40:01.0 -0500
+++ ./dlls/rpcrt4/rpc_binding.c 2002-10-21 21:48:54.0 -0500
@@ -241,7 +241,7 @@
LPSTR pname;
pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Binding-Endpoint) + 1);
strcat(strcpy(pname, prefix), Binding-Endpoint);
- TRACE(listening on %s\n, pname);
+TRACE(listening on %s\n, pname);
Binding-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
0, PIPE_UNLIMITED_INSTANCES, 0, 0, 5000, NULL);
HeapFree(GetProcessHeap(), 0, pname);
@@ -262,7 +262,7 @@
LPSTR pname;
pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Binding-Endpoint) + 1);
strcat(strcpy(pname, prefix), Binding-Endpoint);
- TRACE(listening on %s\n, pname);
+TRACE(listening on %s\n, pname);
Binding-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
0, PIPE_UNLIMITED_INSTANCES, 0, 0, 5000, NULL);
HeapFree(GetProcessHeap(), 0, pname);
@@ -278,8 +278,8 @@
}
}
else {
- ERR(protseq %s not supported\n, Binding-Protseq);
- return RPC_S_PROTSEQ_NOT_SUPPORTED;
+ERR(protseq %s not supported\n, Binding-Protseq);
+return RPC_S_PROTSEQ_NOT_SUPPORTED;
}
}
else { /* client */
@@ -288,67 +288,65 @@
if (strcmp(Binding-Protseq, ncalrpc) == 0) {
static LPSTR prefix = .\\pipe\\lrpc\\;
LPSTR pname;
- HANDLE conn;
- DWORD err;
+HANDLE conn;
+DWORD err;
pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Binding-Endpoint) + 1);
strcat(strcpy(pname, prefix),
Services
I have had a look at dlls/advapi/services.c and found that it is pretty incomplete. Can anybody tell what the current implementation is used for (are there any known programs starting services?) In particular I'd like to know what people generally think about the usefulness of Services in Wine. The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless. However it may be desirable to translate services into something useful on Unix, especially for winelib (it would be useful for the app I am trying to port). Has there been a discussion yet how to set this up without compromising system security? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Marshalling code for me to use?
On Tuesday 22 October 2002 04:40 am, Jürgen Schmied wrote: I was only merging the RPC stuff because I was interested in getting ove's COM stuff into wine. I might start to work there (COM) again sometimes later [or more early if I could pay my bills from it ... - thats life ;-) ] I still have some not-yet-ready-for-submitting LPC stuff in my queue. (If sbd interested...) I am interested, at least to see this. Throw me a diff and I'll definitely take a look at it; it may (or may not) be useful for me. PS: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? Ove is correct that Windows has its own quirky way of doing things and we are stuck with their structure to an extent. Then again, if something works, it works, so I'm not going to obsess about doing things like Windows; for now, I just want to support the API's used by MIDL-generated code. It is unfortunate, but we basically have to implement a documented wire protocol using an undocumented API. In places like NdrClientCall2, we technically have a lot of flexibility to do things however we want. But it would just create redundancy to go off on our own tangent when we have to implement it the Microsoft way sooner or later. Nevertheless, DCE RPC and freedce are potentially valuable resources in this effort. -- gmt Oh, and of course, the fastest way to dig a tunnel is to dig at both sides. -- The Linux Advanced Routing HOWTO
Re: Marshalling code for me to use?
On Tuesday 22 October 2002 06:46 am, Ove Kaaven wrote: I borrowed the UuidHash algorithm from freedce. When are you planning to give it back? ;) DISCLAIMER: Sorry. That is a terrible, and old, joke. But somehow I couldn't resist. I take no responsibility for any feelings of discomfort, disappointment, or hatred this comment may have engendered. -- gmt p.s.: could I borrow a cigarette? Oh, and of course, the fastest way to dig a tunnel is to dig at both sides. -- The Linux Advanced Routing HOWTO
An RPC progress report
On Tuesday 22 October 2002 12:47 pm, you wrote: Greg - I've been following the RPC merges lately, looks like a lot of stuff added. I browsed the code, but I couldn't really get a grasp on some of it. That's OK, I'm not sure /I've/ got a grasp on some of it !! ;) I was just wondering if you'd like to write an update (short, long, whatever) about what you've done, what's left to do, major stumbling blocks, etc. I'll include it in the next issue of Wine Weekly News. Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extentions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler). My target right now is to get a hello world API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement properly. I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near. Now, what remains to be done? Well, as Ove mentions in the TODO for his units, a whole lot. Here are several things in no particular order: - widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler does some really wierd stuff. Then again, we don't neccesarily have to make widl work like MIDL, so it could be worse. - RPC has a quite featureful error handling mechanism; none of it is implemented right now. - The server portions of the patch don't seem to be getting accepted by Alexandre. My guess is that once I have a working test he'll conceed to let this in. To implement this properly is tricky and possibly beyond my abilities; Ove seems to think the right way to do this is to use LPC (Local Procedure Call, another undocumented monster). LPC has no implementation in wine and is not going to be trivial to create. - there are several different memory allocation schemes for MSRPC. I don't even understand what they all are yet, much less have them properly implemented. - MSRPC provides impersonation capabilities which currently are not possible to implement in wine. - Some transports are not yet implemented. The existing transport implementations are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call, etc --- the various types of low-level plumbing that can be used to connect the client and the server). - Data marshalling is the means by which RPC represents data across process and machine boundaries. MSRPC extends NDR format for this. The wire protocol is mostly documented, but the MS API's to convert data-types in memory into NDR are not. This, alone, is a sizable chunk of work. - ORPC is RPC for OLE; once we have a working RPC framework, we can use it to implement out-of-process OLE client/server communications. This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE expert (hell, I'm no RPC expert :) - Surely there is much more stuff I am forgetting. Like Ove said, it's a whole lot of stuff, approximately as big a project as, say, DirectX. Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to solve this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the real work, and deserves way more credit than me for any success I may achieve in the near future). wish me luck, -- gmt Oh, and of course, the fastest way to dig a tunnel is to dig at both sides. -- The Linux Advanced Routing HOWTO
Re: An RPC progress report
On October 22, 2002 02:50 pm, Greg Turner wrote: Now, what remains to be done? Well, as Ove mentions in the TODO for his units, a whole lot. Here are several things in no particular order: And this nice summary should be placed in a file header somewhere in the RPC code, so that other developers can pick it up in the future. -- Dimi.
Re: using native regedit
On Tuesday 22 October 2002 01:01 pm, Jeff Smith wrote:
htmldiv style='background-color:'DIVnbsp; I know I must be missing
something very simple, but I cannot seem to/DIV
DIVgetnbsp;nativenbsp;regedit to run.nbsp; The builtin version always
runs instead.nbsp; The only/DIV DIVthing I could think of was an entry
in DllOverrides:/DIV
DIVregedit.exe = native, builtin.nbsp; That did not work./DIV
DIVnbsp;/DIV
DIVnbsp; I have debugged a littlenbsp;andnbsp;know MODULE_GetLoadOrder
is returning/DIV DIV{LOADORDER_BI, LOADORDER_DLL, LOADORDER_INVALID,
LOADORDER_INVALID}/DIV DIVeven when I add that DllOverride line.nbsp;
But I am just not in the mood at/DIV DIVthe moment for deep digging if
I can help it.nbsp; /DIV
DIVnbsp;/DIV
DIVnbsp; -- Jeff S./DIV/divbr clear=allhrProtect your PC - a
href=http://g.msn.com/8HMZEN/2024;Click here/a for McAfee.com VirusScan
Online /html
Well, if my wetware HTML parser is working today, I think I understand
your problem. Just rename regedit.exe to winregedit.exe (or whatever you like),
or create a symlink or copy of the native version. (some configs don't respect
symlinks).
--
gmt
Oh, and of course, the fastest way to dig
a tunnel is to dig at both sides.
-- The Linux Advanced Routing HOWTO
Re: using native regedit
Thanks for the advice, this should get me by for now.
Of course I would still like DllOverrides section to
work as advertised, but maybe I can hack on it some
more when I am more in the mood.
P.S. Sorry about the HTML message, the Hotmail admins
seem to be playing around with default settings.
-- Jeff S.
From: Greg Turner To: Jeff Smith , [EMAIL PROTECTED] On Tuesday 22
October 2002 01:01 pm, Jeff Smith wrote: I know I must be missing
something very simple, but I cannot seem to
get native regedit to run. The builtin version always runs instead.
The only thing I could think of was an entry in DllOverrides:
regedit.exe = native, builtin. That did not work.
I have debugged a little and know MODULE_GetLoadOrder is returning
{LOADORDER_BI, LOADORDER_DLL, LOADORDER_INVALID, LOADORDER_INVALID} even
when I add that DllOverride line. But I am just not in the mood at the
moment for deep digging if I can help it. -- Jeff S.
Well, if my wetware HTML parser is working today, I think I understand your
problem. Just rename regedit.exe to winregedit.exe (or whatever you
like), or create a symlink or copy of the native version. (some configs
don't respect symlinks).
--
gmt
_
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp
RE: [RFC] Adding an include/wine/wine directory?
Patrik Stridvall [EMAIL PROTECTED] writes: I suggest that we gradually move the files in include/wine to include/wine/wine or in some cases other places like the DLL directories. Eventually, far in the future, the include/wine directory will be empty (save for a wine directory). This provides a slow and steady migration path from the old to the new that doesn't have any of the problems you described. What more can you ask for? A clean solution? Seriously this is ugly as hell; It would have been nice if had been cleaner yes, but then you can't have everything can you? :-) Seriously, I think we can do a little better. See below. especially when you consider that after you install you will get Wine headers in /usr/include/wine, /usr/include/wine/wine and /usr/include/wine/wine/wine. Correct. [I think we understand each other at least this time] Tell me this isn't confusing... First of all you have /usr/include/wine and /usr/include/wine/wine even today. Which already is a little confusing. But hey it works for most thing so I'm not complaining that much. But yes, it is a little confusing. Hmm. Thinking We could do that following instead: (1) /usr/include/wine = /usr/include/wine/windows (2) /usr/include/wine/wine = /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine = /usr/include/wine Also note (2) will disappear eventually. This would be very nice since now normal Winelib applications ie ports from Windows can do -I/usr/include/wine/windows regardless of whether they use the Wine extensions or not since #include wine/test.h for example will work without a -I. Special Winelib application could do #include wine/windows/wincrypt.h without any -I if somebody for example wanted to use the Windows encryption API in a normal Unix application. Hmm. Perhaps /usr/include/wine/windows should be /usr/include/wine/win32 instead, with perhaps /usr/include/wine/windows as symbolic link to /usr/include/wine/win32. But that is just details, what do you think in principle. If you really want to make it possible to mix and match headers from different sources, you need a more serious redesign of the whole include layout, and you need to ensure that the normal case is at least as easy and clean as it is today. I think the suggestion above would do nicely. Internally in the wine tree I think we might have to choose the ugly include/wine/wine solution, but we could install to the solution above which is what's really important. PS. Of course we could move include/*.h to include/wine/windows or something like that but then it is no real use and beside it ruins the cvs patch log. Better stick to the ugly include/wine/wine solution interally IMHO.
Re: Marshalling code for me to use?
On 22 Oct 2002, Martin Wilck wrote: Am Die, 2002-10-22 um 13.46 schrieb Ove Kaaven: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? I borrowed the UuidHash algorithm from freedce. I don't think we can borrow a lot since the way rpcrt4 does ndr internally is part of the exported API, but it can be used as a reference implementation (and maybe a source of .idl files?) What about Samba-TNG (www.dcerpc.org, www.samba-tng.org)and the sidlc compiler that is part of it? Samba is GPL, is it not? Also, it has been my impression that Samba-TNG was moving towards using freedce anyway, though I haven't looked at any of their code (probably since the license would make it useless anyway).
Re: [RFC] Adding an include/wine/wine directory?
Patrik Stridvall [EMAIL PROTECTED] writes: We could do that following instead: (1) /usr/include/wine = /usr/include/wine/windows (2) /usr/include/wine/wine = /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine = /usr/include/wine Also note (2) will disappear eventually. Well, it's somewhat better, but it's still too complex IMO. Maybe what we should do is put the (3) headers directly in /usr/include, like /usr/include/wine_unicode.h. But this would work only if we don't have many of them, so we probably want to work on simplifying this first. Also note that this is not going to solve your problem, because wine/test.h is more a category (2) header (or maybe you need a new category for Wine internal headers that don't get installed). PS. Of course we could move include/*.h to include/wine/windows or something like that but then it is no real use and beside it ruins the cvs patch log. Better stick to the ugly include/wine/wine solution interally IMHO. Not an option. If we have to move the files we'll move them; it's better to avoid moving things around too much. but we shouldn't let CVS limitations impose a broken structure. Now if we can find a non broken structure that also doesn't involve moving files that's better. -- Alexandre Julliard [EMAIL PROTECTED]
Re: updated dlls/comctl32/commctrl.c comments
On October 22, 2002 03:02 pm, Christian Neumair wrote: Dimitrie started posting a header doc patch for listview.c, so I got motivated and wrote the same thing for commctrl.c. I hope it's complete. Thanks, Chris. In many respects, this is more important than code. For many reasons I will not go into here, I think it is vital that we have a header giving a _clear_ pictures of what remains to be done. I just hope others will do the same. -- Dimi.
RE: [RFC] Adding an include/wine/wine directory?
Patrik Stridvall [EMAIL PROTECTED] writes:
We could do that following instead:
(1) /usr/include/wine = /usr/include/wine/windows
(2) /usr/include/wine/wine = /usr/include/wine/windows/wine
(3) /usr/include/wine/wine/wine = /usr/include/wine
Also note (2) will disappear eventually.
Well, it's somewhat better, but it's still too complex IMO.
Where is the complexity?
If you want to port a Window application, you add
-I/usr/include/wine/windows and everything as much
as like under Windows as possible. If you in
addition wish to call some Wine extension no
problem just do #include wine/foo.h or similar.
If you just want to use the Windows API in an Unix
application you need anything at all. Just
do #include wine/windows/wincrypt.h and you're done.
[Linking is a separate problem, of course. But then,
this changes nothing as far as this is concerned]
Maybe what
we should do is put the (3) headers directly in /usr/include, like
/usr/include/wine_unicode.h. But this would work only if we don't have
many of them, so we probably want to work on simplifying this first.
I can't see any principal difference between
/usr/include/wine_foo.h or /usr/include/wine/foo.h
None of them requires any -I. It is more a convention that if you
have many .h you have a directory, if not, well then you can have a
directory anyway, it is up to you.
Also note that this is not going to solve your problem, because
wine/test.h is more a category (2) header
Well wine/test.h is really kind of a special case anyway it could
be moved to programs/winetest/include/wine or something under
whatever name it is not really a concern.
Perhaps we should move programs/winetest/wtmain.c to test/ and make
it a library similar to library/ and unicode/. This is what I did
with MSVC, eventhough I did it in programs/winetest instead.
(or maybe you need a new
category for Wine internal headers that don't get installed).
You mean for files like windef16.h?
Well, in the long run such files really belongs in the dlls/*
directories. In the extent that that can't they really are
Wine extension that might as well be used by any Winelib
application not just internally should IMHO be installed.
But yes, we certainly need some place to put them in the meantime,
since this isn't happing over night. However I think that they can
remain in include/wine/ until we move them one by one. See below.
PS. Of course we could move include/*.h to include/wine/windows or
something like that but then it is no real use and beside it ruins
the cvs patch log. Better stick to the ugly include/wine/wine
solution interally IMHO.
Not an option. If we have to move the files we'll move them; it's
better to avoid moving things around too much. but we shouldn't let
CVS limitations impose a broken structure.
OK.
Now if we can find a non
broken structure that also doesn't involve moving files that's better.
Perhaps this would work:
mkdir library/wine
mv include/wine/{library,port}.h library/wine
mkdir unicode/wine
mv include/wine/unicode.h unicode/wine
mkdir dlls/ntdll/wine
mv include/wine/exception.h dlls/ntdll/wine
Sure it would mean a few more -I internally but it
would not be that bad.
Then during install all these files as well as some files from
include/wine/ ends up in /usr/include/wine
and the include/ files end up in /usr/include/wine/windows
or /usr/include/wine/win32 not sure what is best.
That would require moving a minimum of files. As before eventually
far in the future include/wine/ would be empty. Transition done.
We needn't move everything right now either. As mentioned before
running the Wine test with the Microsoft headers currently AFAICS
only requires that we fix wine/{exception,test,unicode}.h.
Of course compiling every DLL with the Microsoft headers requires
fixing all of include/wine/ but then as long as we have a solution
when we get where eventually is good enough IMHO, doing that is no
particular rush. Having the Wine tests work properly sooner
rather than later is much more important though.
Re: using native regedit
Jeff Smith [EMAIL PROTECTED] writes: Found something: it works if I fully qualify the command name. I was trying this in the DllOverrides / command-line respectively: regedit.exe = native, builtin --dll regedit.exe=n,b What I have to do for it to work is this: C:\\Windows\\regedit.exe = native, builtin --dll C:\\Windows\\regedit.exe=n,b I still do not think this is *exactly* as it should be, but I'm finally on the track to figuring it out. It's the way it's supposed to work, because it mimics the way loadorder works for dlls: a simple regedit.exe matches only if regedit is in the system directory. Otherwise you need to specify the full path, or use a wildcard entry like *regedit.exe. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RFC] Adding an include/wine/wine directory?
Patrik Stridvall [EMAIL PROTECTED] writes: Patrik Stridvall [EMAIL PROTECTED] writes: We could do that following instead: (1) /usr/include/wine = /usr/include/wine/windows (2) /usr/include/wine/wine = /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine = /usr/include/wine Also note (2) will disappear eventually. Well, it's somewhat better, but it's still too complex IMO. Where is the complexity? The complexity is that you create up to 3 levels of directories under /usr/include, I don't think such a deep hierarchy is really necessary. I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h Well, the difference is that you can then use /usr/include/wine for the Windows includes. Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though. I agree getting the Wine tests to work soon is important, but you don't really need the final header organization for that; you can easily work around the current problem by copying files around or specifying an absolute -I option. I don't think we have found a fully satisfying solution yet, and IMO the situation will be clearer when the dll separation is finished and the loose ends are cleaned up, so I'd prefer to wait until then to decide on the final structure. (And my secret hope is that by then we will be able to switch to Subversion which should make renaming files a lot easier; but that's another topic...) -- Alexandre Julliard [EMAIL PROTECTED]
Re: using native regedit
I have the same problem here. It seems that something is going wrong in config file reading. The notepad.exe entry specified in documentation/samples/config doesn't work too. Well, if my wetware HTML parser is working today, I think I understand your problem. Just rename regedit.exe to winregedit.exe (or whatever you like), or create a symlink or copy of the native version. (some configs don't respect symlinks). ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: [RFC] Adding an include/wine/wine directory?
On October 22, 2002 07:12 pm, Alexandre Julliard wrote: decide on the final structure. (And my secret hope is that by then we will be able to switch to Subversion which should make renaming files a lot easier; but that's another topic...) Oh my, you think it's going to take us _that_ long?!? :P -- Dimi.
Re: Third listview status update
On October 22, 2002 06:16 am, Rein Klazes wrote: On the positive side background colouring for new messages works now. ;) [snip] - updates are from bottom to top; this gets some getting used to; Fixed in one of the W-patches. Crash 2: | err:ntdll:RtlpWaitForCriticalSection section 0x4fcf28 ? wait timed out, | retrying (60 sec) tid=087eedb8 Unhandled exception: page fault on write | access to 0x1784562e in 32-bit code (0x4272392f). In 32-bit mode. | 0x4272392f (_end+0xdbf6f): addb %bh,0x957c4272(%ebx,%edi,1) | Register dump: | CS:0023 SS:002b DS:002b ES:002b FS:008f GS:1587 | EIP:4272392f ESP:40741c5c EBP:40741cb4 EFLAGS:00210a86( R- 00O I S - | -P1 ) EAX:427d1354 EBX:40be1094 ECX:41a7ff3c EDX:0002 | ESI:41a7ff3c EDI:414a0328 | Backtrace: | =0 0x4272392f (_end+0xdbf6f) (ebp=40741cb4) | 1 0x40b7db77 (DPA_QuickSort+0xf3(lpPtrs=0x414bd320, l=0xd1, r=0xd2, | pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2077] in | comctl32.dll.so) (ebp=40741ce0) 2 0x40b7db1c | (DPA_QuickSort+0x98(lpPtrs=0x414bd320, l=0xd1, r=0xd4, | pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2072] in | comctl32.dll.so) (ebp=40741d14) 3 0x40b7db35 | (DPA_QuickSort+0xb1(lpPtrs=0x414bd320, l=0xcc, r=0xd4, | pfnCompare=0x40b9728c, lParam=0x10023) [comctl32undoc.c:2075] in | comctl32.dll.so) (ebp=40741d5c) 4 0x40b7db1c The line numbers look strage. What version of dlls/comctl32/comctl32undoc.c did you run it with? -- Dimi.
eTax status report
Hi, I have now completed using the eTax program from the Australian Taxation Office (http://etax.ato.gov.au) under wine, and have some concluding remarks. * Yellow Note Popups over buttons: these notes pop up almost immediately you put your mouse over a button, and if you click on them, the button does not respond. This causes great user frustration, as you point the mouse at a button, click the mouse, and nothing happens because the popup note appeared and stole the mouse click. Perhaps this could be solved by moving the popup note position so that it's not directly under the mouse pointer? I don't know if this is an etax problem or a wine problem. Workaround: move mouse over button and click again, or be very quick with your mouse click the first time. * ListView (tree): when hovering over items with long names, the same popup note appears, and also greedily steals mouse clicks, preventing you from selecting the item underneath. The note must pass the mouse click through for proper handling by the list item. Workaround: Wait for popup to disappear and then click on list item. * I had some refresh issues with the print preview section of the program. When it draws a page for the first time, all form fields appear to be filled in correctly, but when scrolling the form fields are often left blank when they should be filled in. This may be verified by going forward and then back a page, to force a complete re-draw of the original page, and verifying that fields which were previously blank are now drawn properly. * I didn't try to submit the tax return under wine, as I did not know about the wine integration of the web browser which would be used to perform the submission. (I failed to download the security codes under Mozilla, so I resorted to a Windows box for downloanding security codes and submission.) * Help problems, partly to do with launching winhelp from within etax, and also partly because WINE help can't yet read the etax help file properly. I used etax in the desktop windowing mode, as I had problems with both the managed and unmanaged modes. I set all dlls to builtin (except for *). This is the first year that I have been able to use eTax to do the tax return. I want to thank all of the wine contributors for making it possible! Last year I gave up and used a Windows box for the whole thing. Ben Stanley
Re: [RFC] Adding an include/wine/wine directory?
On Mon, 21 Oct 2002, Patrik Stridvall wrote: [...] However there are at least two intresting ways to compile and run the tests on Windows. 1. Compile using the Wine headers. 2. Compile using the Microsoft headers. Currently only (1) works in a portable way. To get (2) to work I had to add the directory of the Microsoft includes to the begining of the include path. This is not very portable since it differs from installation to installation. I have currently hardcoding my specific directory. Actually there is a portable solution. Here's what i did when I compiled the Wine tests on Windows: Run 'vcvars32.bat' first. When you install Microsoft Visual C++ you can either tell it to add environment variables with the useful stuff (either in autoexec.bat or the registry for NT), or just rely on 'vcvars32.bat'. This script is usually in the include directory: c:\Program Files\Microsoft Visual Studio\VC98\include\vcvars32.bat Well, so I run it on the command line and then in the makefile (a realy .mak file) I put: INCLUDE=$(TOTOP)\include;$(INCLUDE) Then I don't use -I at all and the compiler will automatically use the environment variable. If using the .mak file directly from the IDE you don't even need to run vcvars32.bat, However I still had include order problems: part of the headers were coming from MS and part from Wine but did not have time to look into it in detail. So I ended up extracting the tests from the Wine tree. But if you are able to avoid the header mixup then the above could work. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: using native regedit
I agree that the example should be changed to indicate a 'valid' entry if this is the way it is supposed to be. This would have saved me a lot of trouble and confusion. Now I can work on getting native regedit working again. -- Jeff S. Shouldn't we update the sample entry in documentation/sample/config ? ; you can specify applications too -*\\notepad.exe = native, builtin +notepad.exe = native, builtin ; default for all other dlls * = builtin, native It's the way it's supposed to work, because it mimics the way loadorder works for dlls: a simple regedit.exe matches only if regedit is in the system directory. Otherwise you need to specify the full path, or use a wildcard entry like *regedit.exe. -- Alexandre Julliard [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Impressive success
I just got an ATAPI Plextor PlexWriter 40/12/40A (which rocks), and Plextor's Win32-only firmware updater worked flawlessly in wine, a few months old CVS. Kudos to all involved in supporting that sort of access!
Re: Third listview status update
On October 22, 2002 11:45 pm, Rein Klazes wrote: On Tue, 22 Oct 2002 19:38:41 -0400, you wrote: The line numbers look strage. What version of dlls/comctl32/comctl32undoc.c did you run it with? rev 1.71, latest cvs. Interesting. Listen, can you please retry with _all_ my latest patches, there were 2 very serious bugs that might have caused those problems, in some strange ways. Thanks. -- Dimi.
Re: Third listview status update
On October 22, 2002 06:16 am, Rein Klazes wrote: - the green background extends as far as the text; with native comctl32 is extends the whole column; - A line that has both a green background and is marked slected will display as white text on green backgound; With native comctl32 is shows as white text on dark blue background (same as selected); I need good bad screenshots of these things to understand what is wrong, and what needs to get done. -- Dimi.
Treeview fix
Intro:
Once I got wine to finally execute the native regedit,
treeview was bringing it down.
Background:
I discovered treeview uses DSA's and Dimi recently
changed the max element number in DSA's to 0x7fff (SHRT_MAX).
Note this value has the special meaning in DSA_InsertPtr
functions of 'add new element to end of array'.
Problem:
INT_MAX (0x7fff) was being passed from treeview
to DSA_InsertPtr. This caused failure returns and
eventually a seg fault.
Conclusion:
This patch fixes the problem (according to the style of other
calls to DSA_InsertPtr), and native regedit now works.
Questions for further thought:
I wonder, should 0x7fff be used explicitly, or should
SHRT_MAX be used in places like this instead?
Changelog:
Treeview fix due to change in maximum DSA size.
-- Jeff S.
Index: dlls/comctl32/treeview.c
===
RCS file: /home/wine/wine/dlls/comctl32/treeview.c,v
retrieving revision 1.103
diff -u -r1.103 treeview.c
--- dlls/comctl32/treeview.c 6 Sep 2002 19:41:18 - 1.103
+++ dlls/comctl32/treeview.c 23 Oct 2002 04:12:53 -
-949,7 +949,7
if (!newItem)
return NULL;
-if (DPA_InsertPtr(infoPtr-items, INT_MAX, newItem) == -1)
+if (DPA_InsertPtr(infoPtr-items, 0x7fff, newItem) == -1)
{
COMCTL32_Free(newItem);
return NULL;
-2885,7 +2885,7
for (child = item-firstChild; child != NULL; child =
child-nextSibling)
{
- if (DPA_InsertPtr(list, INT_MAX, child) == -1)
+ if (DPA_InsertPtr(list, 0x7fff, child) == -1)
{
DPA_Destroy(list);
return NULL;
_
Get faster connections -- switch to MSN Internet Access!
http://resourcecenter.msn.com/access/plans/default.asp
Re: Treeview fix
On October 23, 2002 12:44 am, Jeff Smith wrote: I discovered treeview uses DSA's and Dimi recently changed the max element number in DSA's to 0x7fff (SHRT_MAX). Note this value has the special meaning in DSA_InsertPtr functions of 'add new element to end of array'. This was my initial reaction to this thing, as well. But I think my fix (sent earlier with Subject DPA_InsertPtr) is better. Please try it out -- it should fix your problem. BTW, I've also audited all other uses of DPA_InsertPtr, and they are fine. We should be back to normal now (well, after my patch is applied, of course). -- Dimi.
Re: Treeview fix
Oops, your previous message got lost in the shuffle... I'm sure anything is better than the little patch I wrote. I was just taking a minimalist approach to get treeview working. -- Jeff S Dimi wrote: On October 23, 2002 12:44 am, Jeff Smith wrote: I discovered treeview uses DSA's and Dimi recently changed the max element number in DSA's to 0x7fff (SHRT_MAX). Note this value has the special meaning in DSA_InsertPtr functions of 'add new element to end of array'. This was my initial reaction to this thing, as well. But I think my fix (sent earlier with Subject DPA_InsertPtr) is better. Please try it out -- it should fix your problem. BTW, I've also audited all other uses of DPA_InsertPtr, and they are fine. We should be back to normal now (well, after my patch is applied, of course). -- Dimi. _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
Re: fairly old wine regression: no$gmb no longer works
did you try with CVS ? I will try it in few hours. please report your current version. --- Jonathan Gevaryahu [EMAIL PROTECTED] a écrit : In wine builds from early? last year until January 29th, 2002, no$gmb (Nocash gameboy emulator) worked reasonably in wine (yes it would crash if you did 'animate trace' for too long, but that's a seperate issue). the commit which broke it was to wine/dlls/comctl32/status.c, on January 29th at 11:54 am. However, the fix that was done to status.c seems to be valid (later fixes to status.c do the same as what the fix did, I believe), so I suspect that the bug stems from some other issue which causes it to need the incorrect behavior in status.c in order to work. (personally I think it was something done during January that makes it need the incorrect status.c behavior, but I'm probably wrong) The nocash website is http://www.work.de/nocash/ or http://nocash.work.de/ Jonathan Gevaryahu ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
