Ros-dev November 2008

ros-dev@reactos.org

27 participants
42 discussions

Re: [ros-dev] [ros-diffs] [gschneider] 37281: Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code.
by Steven Edwards 10 Nov '08

10 Nov '08

On Mon, Nov 10, 2008 at 9:25 AM, <gschneider(a)svn.reactos.org> wrote: > Author: gschneider > Date: Mon Nov 10 08:25:24 2008 > New Revision: 37281 > > URL: http://svn.reactos.org/svn/reactos?rev=37281&view=rev > Log: > Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code. Please add the appropriate copyright headers to the source file stating the original author when implementing code based on third party sources. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

seh 64
by Timo Kreuzer 10 Nov '08

10 Nov '08

Hi, I have recently been working on getting SEH into the x64 port. This covers several parts. One of them is compiler support. On x64 SEH is table based rather than code based, that means it needs tables of unwind data. These can be generated from DWARF unwind info - which gcc generates - and that's what I'm working on. The x64 version of rsym shall parse the DWARF unwind data and convert it into Windows compatible unwind data. Now there is a problem. While older versions of mingw64 used the ".debug_frame" section, the newer versions use the ".eh_frame" section. That is good and bad at the same time. What does that mean? What's the difference? The .eh_frame section isn't part of the DWARF 2 or 3 specification, it's a GNU extension / part of the LSB-Core specification. Documentation was hard to find, but google is your friend and it seems there's only one major difference to the debug_frame section and that is relative addressing rather than absolute. This is actually very good and saves the day for all modules that live in kernel space, because the addresses are only 32 bits. There is still a problem left. While the .debug_frame section is by default put into the output executable as a seperate section, the .eh_frame section isn't. The default linker script puts it into the ".rdata" section. But there it's kinda lost and I don't want to keep it anyway. With ntoskrnl there's no problem as it uses it's own linker script anyway. I can change it, so the .eh_frame section is put at the end of the executable. But how do I do this for the other modules? Do i need to provide a new default linkerscript for all other modules? Can I "fix" this behavior in RosBE64 (the files in lib/ldscripts seem to be unused)? Or does anyone know a command line option to change this default behavior? Regards, Timo

2 6

seh 64
by Dmitry Gorbachev 08 Nov '08

08 Nov '08

> Or does anyone know a command line option to change this default behavior? --unique=.eh_frame ?

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 37248: - Check the status of IPSendDatagram - Validate the protocol - Use the hash value of the NCE address to get the lock - Simplify TCPAbortListenForSocket - Hardcode the length of the array
by Aleksey Bragin 08 Nov '08

08 Nov '08

On Nov 7, 2008, at 11:31 PM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Nov 7 14:31:34 2008 > New Revision: 37248 > > URL: http://svn.reactos.org/svn/reactos?rev=37248&view=rev > Log: > - Check the status of IPSendDatagram > - Validate the protocol > - Use the hash value of the NCE address to get the lock > - Simplify TCPAbortListenForSocket > - Hardcode the length of the array > > + HashValue = *(PULONG)(&NCE->Address.Address); > + HashValue ^= HashValue >> 16; > + HashValue ^= HashValue >> 8; > + HashValue ^= HashValue >> 4; > + HashValue &= NB_HASHMASK; It's used at least three times in the source code, I would do an inline hash-calculating function for that.

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 37247: - Close the connection before freeing it
by Aleksey Bragin 08 Nov '08

08 Nov '08

Does TCPClose do what was written in comments (cancelling all pending requests)? I wonder if it was that simple, why it wasn't implemented this way before? ;) On Nov 7, 2008, at 10:12 PM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Nov 7 13:12:26 2008 > New Revision: 37247 > > URL: http://svn.reactos.org/svn/reactos?rev=37247&view=rev > Log: > - Close the connection before freeing it > > Modified: > branches/aicom-network-fixes/lib/drivers/ip/transport/tcp/tcp.c > > Modified: branches/aicom-network-fixes/lib/drivers/ip/transport/tcp/ > tcp.c > URL: http://svn.reactos.org/svn/reactos/branches/aicom-network- > fixes/lib/drivers/ip/transport/tcp/tcp.c? > rev=37247&r1=37246&r2=37247&view=diff > ====================================================================== > ======== > --- branches/aicom-network-fixes/lib/drivers/ip/transport/tcp/tcp.c > [iso-8859-1] (original) > +++ branches/aicom-network-fixes/lib/drivers/ip/transport/tcp/tcp.c > [iso-8859-1] Fri Nov 7 13:12:26 2008 > @@ -283,8 +283,7 @@ > } > > VOID TCPFreeConnectionEndpoint( PCONNECTION_ENDPOINT Connection ) { > - TI_DbgPrint(MAX_TRACE,("FIXME: Cancel all pending requests\n")); > - /* XXX Cancel all pending requests */ > + TCPClose( Connection ); > ExFreePool( Connection ); > } > >

1 0

Re: [ros-dev] [ros-diffs] [fireball] 37229: - Update the _ros.diff. Usual changes are there (unfortunately incompatibilites in Wine still exist, RpcMgmtWaitForServerListen is still not implemented there, and their dependency on unix sockets is totall
by Steven Edwards 07 Nov '08

07 Nov '08

On Fri, Nov 7, 2008 at 4:54 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > I highly doubt they work, in fact I'm sure they won't work at all. > But their only duty is to allow building unmodified rpcrt4 from Wine. > I still have a hope, somewhere very very deep in my soul, that Wine > will stop using linux-specific APIs in DLLs. You can hope and dream. One of the problems we saw, such as in the case of wininet, using unix sockets instead of winsock gave something like a 20% speedup in performance. Another issue was that select on linux (thanks to glibc) fixes FD_SETSIZE at 1024 so the solution was to move to using poll(). The poll/select thing is not that big of a deal as it can be wrapped but fixing the winsock performance issues may require someone to dedicate a lot of time profiling. If you can fix all of the issues so that performance will be the same with pure win32, then I am sure Alexandre will accept it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1

07 Nov '08

Do the apis in unix_func actually work? I wrote that file a long time ago, but I never actually tested it. I wasn't sure if that code was ever called. It was written mainly to allow me to build rpcrt4_new (which is what we now use) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org Sent: 06 November 2008 19:10 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [fireball] 37229: - Update the _ros.diff. Usual changes are there (unfortunately incompatibilites in Wine still exist, RpcMgmtWaitForServerListen is still not implemented there, and their dependency on unix sockets is totally out of place). On Author: fireball Date: Thu Nov 6 13:10:03 2008 New Revision: 37229 URL: http://svn.reactos.org/svn/reactos?rev=37229&view=rev Log: - Update the _ros.diff. Usual changes are there (unfortunately incompatibilites in Wine still exist, RpcMgmtWaitForServerListen is still not implemented there, and their dependency on unix sockets is totally out of place). On the good side I could get rid of disabling unix-sockets stuff in source code by slightly improving unix_func. Modified: trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff Modified: trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/rpcrt4_ro… ============================================================================== --- trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff [iso-8859-1] (original) +++ trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff [iso-8859-1] Thu Nov 6 13:10:03 2008 @@ -1,8 +1,42 @@ +Index: epm_towers.h +=================================================================== +--- epm_towers.h (working copy) ++++ epm_towers.h (working copy) +@@ -17,11 +17,11 @@ + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + * + */ + +-#include "epm.h" ++#include "epm_c.h" + + #define EPM_PROTOCOL_DNET_NSP 0x04 + #define EPM_PROTOCOL_OSI_TP4 0x05 + #define EPM_PROTOCOL_OSI_CLNS 0x06 + #define EPM_PROTOCOL_TCP 0x07 +Index: rpc_epmap.c +=================================================================== +--- rpc_epmap.c (working copy) ++++ rpc_epmap.c (working copy) +@@ -30,11 +30,11 @@ + + #include "wine/debug.h" + #include "wine/exception.h" + + #include "rpc_binding.h" +-#include "epm.h" ++#include "epm_c.h" + #include "epm_towers.h" + + WINE_DEFAULT_DEBUG_CHANNEL(ole); + + /* The "real" RPC portmapper endpoints that I know of are: Index: rpc_server.c =================================================================== --- rpc_server.c (working copy) +++ rpc_server.c (working copy) -@@ -1017,22 +1017,30 @@ +@@ -1040,22 +1040,28 @@ /*********************************************************************** * RpcMgmtServerWaitListen (RPCRT4.@) */ @@ -18,14 +52,12 @@ return RPC_S_NOT_LISTENING; } -+ do -+ { ++ do { LeaveCriticalSection(&listen_cs); ++ LIST_FOR_EACH_ENTRY(cps, &protseqs, RpcServerProtseq, entry) ++ WaitForSingleObject(cps->server_ready_event, INFINITE); - FIXME("not waiting for server calls to finish\n"); -+ LIST_FOR_EACH_ENTRY(cps, &protseqs, RpcServerProtseq, entry) -+ WaitForSingleObject(cps->server_ready_event, INFINITE); -+ + EnterCriticalSection(&listen_cs); + } while (!std_listen); + @@ -39,11 +71,11 @@ =================================================================== --- rpc_transport.c (working copy) +++ rpc_transport.c (working copy) -@@ -54,10 +54,13 @@ - #endif - #ifdef HAVE_SYS_POLL_H - #include <sys/poll.h> - #endif +@@ -65,10 +65,13 @@ + # include <sys/poll.h> + # endif + # define closesocket close + #endif /* defined(__MINGW32__) || defined (_MSC_VER) */ +#include <winsock2.h> +#include <ws2tcpip.h> @@ -53,7 +85,7 @@ #include "winnls.h" #include "winerror.h" #include "winternl.h" -@@ -71,10 +74,12 @@ +@@ -82,10 +85,12 @@ #include "rpc_binding.h" #include "rpc_message.h" #include "rpc_server.h" @@ -66,7 +98,7 @@ #endif WINE_DEFAULT_DEBUG_CHANNEL(rpc); -@@ -83,11 +88,11 @@ +@@ -94,11 +99,11 @@ typedef struct _RpcConnection_np { @@ -79,25 +111,27 @@ static RpcConnection *rpcrt4_conn_np_alloc(void) { -@@ -105,15 +110,15 @@ - { - if (npc->listening) +@@ -118,17 +123,17 @@ return RPC_S_OK; npc->listening = TRUE; -- if (ConnectNamedPipe(npc->pipe, &npc->ovl)) -+ if (ConnectNamedPipe(npc->pipe, &npc->ovl[0])) - return RPC_S_OK; - - if (GetLastError() == ERROR_PIPE_CONNECTED) { -- SetEvent(npc->ovl.hEvent); -+ SetEvent(npc->ovl[0].hEvent); - return RPC_S_OK; - } - if (GetLastError() == ERROR_IO_PENDING) { - /* will be completed in rpcrt4_protseq_np_wait_for_new_connection */ - return RPC_S_OK; -@@ -126,11 +131,11 @@ + for (;;) + { +- if (ConnectNamedPipe(npc->pipe, &npc->ovl)) ++ if (ConnectNamedPipe(npc->pipe, &npc->ovl[0])) + return RPC_S_OK; + + switch(GetLastError()) + { + case ERROR_PIPE_CONNECTED: +- SetEvent(npc->ovl.hEvent); ++ SetEvent(npc->ovl[0].hEvent); + return RPC_S_OK; + case ERROR_IO_PENDING: + /* will be completed in rpcrt4_protseq_np_wait_for_new_connection */ + return RPC_S_OK; + case ERROR_NO_DATA_DETECTED: +@@ -146,11 +151,11 @@ static RPC_STATUS rpcrt4_conn_create_pipe(RpcConnection *Connection, LPCSTR pname) { RpcConnection_np *npc = (RpcConnection_np *) Connection; @@ -110,7 +144,7 @@ RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); if (npc->pipe == INVALID_HANDLE_VALUE) { WARN("CreateNamedPipe failed with error %d\n", GetLastError()); -@@ -139,11 +144,12 @@ +@@ -159,11 +164,12 @@ else return RPC_S_CANT_CREATE_ENDPOINT; } @@ -124,7 +158,7 @@ * server thread as the thread must be alertable */ return RPC_S_OK; } -@@ -202,11 +208,13 @@ +@@ -220,11 +226,12 @@ /* success */ memset(&npc->ovl, 0, sizeof(npc->ovl)); /* pipe is connected; change to message-read mode. */ @@ -133,13 +167,12 @@ - npc->ovl.hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); + npc->ovl[0].hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); + npc->ovl[1].hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); -+ npc->pipe = pipe; return RPC_S_OK; } -@@ -308,11 +316,12 @@ +@@ -326,11 +333,12 @@ { /* because of the way named pipes work, we'll transfer the connected pipe * to the child, then reopen the server binding to continue listening */ @@ -153,7 +186,7 @@ old_npc->listening = FALSE; } -@@ -359,13 +368,18 @@ +@@ -377,13 +385,18 @@ unsigned int bytes_left = count; while (bytes_left) @@ -163,39 +196,39 @@ - if (!ret || !bytes_read) + ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, &npc->ovl[0]); + if ((!ret || !bytes_read) && (GetLastError() != ERROR_IO_PENDING)) ++ break; ++ ++ ret = GetOverlappedResult(npc->pipe, &npc->ovl[0], &bytes_read, TRUE); ++ if (!ret && (GetLastError() != ERROR_MORE_DATA)) break; -+ -+ ret = GetOverlappedResult(npc->pipe, &npc->ovl[0], &bytes_read, TRUE); -+ if (!ret && GetLastError() != ERROR_MORE_DATA) -+ break; + bytes_left -= bytes_read; buf += bytes_read; } return ret ? count : -1; } -@@ -379,13 +393,18 @@ +@@ -397,13 +410,18 @@ unsigned int bytes_left = count; while (bytes_left) { DWORD bytes_written; -- ret = WriteFile(npc->pipe, buf, count, &bytes_written, NULL); +- ret = WriteFile(npc->pipe, buf, bytes_left, &bytes_written, NULL); - if (!ret || !bytes_written) -+ ret = WriteFile(npc->pipe, buf, count, &bytes_written, &npc->ovl[1]); ++ ret = WriteFile(npc->pipe, buf, bytes_left, &bytes_written, &npc->ovl[1]); + if ((!ret || !bytes_written) && (GetLastError() != ERROR_IO_PENDING)) ++ break; ++ ++ ret = GetOverlappedResult(npc->pipe, &npc->ovl[1], &bytes_written, TRUE); ++ if (!ret && (GetLastError() != ERROR_MORE_DATA)) break; -+ -+ ret = GetOverlappedResult(npc->pipe, &npc->ovl[1], &bytes_written, TRUE); -+ if (!ret && GetLastError() != ERROR_MORE_DATA) -+ break; + bytes_left -= bytes_written; buf += bytes_written; } return ret ? count : -1; } -@@ -396,14 +415,19 @@ +@@ -414,13 +432,17 @@ if (npc->pipe) { FlushFileBuffers(npc->pipe); CloseHandle(npc->pipe); @@ -212,13 +245,11 @@ + CloseHandle(npc->ovl[1].hEvent); + npc->ovl[1].hEvent = 0; } -+ return 0; } static void rpcrt4_conn_np_cancel_call(RpcConnection *Connection) - { -@@ -547,11 +571,11 @@ +@@ -579,11 +601,11 @@ /* open and count connections */ *count = 1; conn = CONTAINING_RECORD(protseq->conn, RpcConnection_np, common); @@ -231,7 +262,7 @@ } /* make array of connections */ -@@ -568,11 +592,11 @@ +@@ -600,11 +622,11 @@ objs[0] = npps->mgr_event; *count = 1; @@ -244,7 +275,7 @@ } LeaveCriticalSection(&protseq->cs); return objs; -@@ -615,11 +639,11 @@ +@@ -647,11 +669,11 @@ b_handle = objs[res - WAIT_OBJECT_0]; /* find which connection got a RPC */ EnterCriticalSection(&protseq->cs); @@ -257,120 +288,3 @@ cconn = NULL; if (conn) RPCRT4_SpawnConnection(&cconn, &conn->common); -@@ -713,16 +737,18 @@ - RpcConnection_tcp *tcpc; - tcpc = HeapAlloc(GetProcessHeap(), 0, sizeof(RpcConnection_tcp)); - if (tcpc == NULL) - return NULL; - tcpc->sock = -1; -+#ifndef __REACTOS__ - if (socketpair(PF_UNIX, SOCK_STREAM, 0, tcpc->cancel_fds) < 0) - { - ERR("socketpair() failed: %s\n", strerror(errno)); - HeapFree(GetProcessHeap(), 0, tcpc); - return NULL; - } -+#endif - return &tcpc->common; - } - - static RPC_STATUS rpcrt4_ncacn_ip_tcp_open(RpcConnection* Connection) - { -@@ -783,12 +809,11 @@ - continue; - } - - /* RPC depends on having minimal latency so disable the Nagle algorithm */ - val = 1; -- setsockopt(sock, SOL_TCP, TCP_NODELAY, &val, sizeof(val)); -- fcntl(sock, F_SETFL, O_NONBLOCK); /* make socket nonblocking */ -+ setsockopt(sock, SOL_TCP, TCP_NODELAY, (char *)&val, sizeof(val)); - - tcpc->sock = sock; - - freeaddrinfo(ai); - TRACE("connected\n"); -@@ -806,10 +831,11 @@ - int sock; - int ret; - struct addrinfo *ai; - struct addrinfo *ai_cur; - struct addrinfo hints; -+ u_long blocking; - RpcConnection *first_connection = NULL; - - TRACE("(%p, %s)\n", protseq, endpoint); - - hints.ai_flags = AI_PASSIVE /* for non-localhost addresses */; -@@ -857,11 +883,11 @@ - ret = bind(sock, ai_cur->ai_addr, ai_cur->ai_addrlen); - if (ret < 0) - { - WARN("bind failed: %s\n", strerror(errno)); - close(sock); -- if (errno == EADDRINUSE) -+ if (errno == WSAEADDRINUSE) - status = RPC_S_DUPLICATE_ENDPOINT; - else - status = RPC_S_CANT_CREATE_ENDPOINT; - continue; - } -@@ -886,11 +912,12 @@ - } - /* need a non-blocking socket, otherwise accept() has a potential - * race-condition (poll() says it is readable, connection drops, - * and accept() blocks until the next connection comes...) - */ -- ret = fcntl(sock, F_SETFL, O_NONBLOCK); -+ blocking = 1; -+ ret = ioctlsocket(sock, FIONBIO, &blocking); - if (ret < 0) - { - WARN("couldn't make socket non-blocking, error %d\n", ret); - RPCRT4_DestroyConnection(&tcpc->common); - status = RPC_S_OUT_OF_RESOURCES; -@@ -929,10 +956,11 @@ - static RPC_STATUS rpcrt4_conn_tcp_handoff(RpcConnection *old_conn, RpcConnection *new_conn) - { - int ret; - struct sockaddr_in address; - socklen_t addrsize; -+ u_long blocking; - RpcConnection_tcp *server = (RpcConnection_tcp*) old_conn; - RpcConnection_tcp *client = (RpcConnection_tcp*) new_conn; - - addrsize = sizeof(address); - ret = accept(server->sock, (struct sockaddr*) &address, &addrsize); -@@ -940,11 +968,12 @@ - { - ERR("Failed to accept a TCP connection: error %d\n", ret); - return RPC_S_OUT_OF_RESOURCES; - } - /* reset to blocking behaviour */ -- fcntl(ret, F_SETFL, 0); -+ blocking = 0; -+ ret = ioctlsocket(ret, FIONBIO, &blocking); - client->sock = ret; - TRACE("Accepted a new TCP connection\n"); - return RPC_S_OK; - } - -@@ -1187,14 +1216,16 @@ - { - RpcServerProtseq_sock *ps = HeapAlloc(GetProcessHeap(), 0, sizeof(*ps)); - if (ps) - { - int fds[2]; -+ u_long blocking; - if (!socketpair(PF_UNIX, SOCK_DGRAM, 0, fds)) - { -- fcntl(fds[0], F_SETFL, O_NONBLOCK); -- fcntl(fds[1], F_SETFL, O_NONBLOCK); -+ blocking = 1; -+ ioctlsocket(fds[0], FIONBIO, &blocking); -+ ioctlsocket(fds[1], FIONBIO, &blocking); - ps->mgr_event_rcv = fds[0]; - ps->mgr_event_snd = fds[1]; - } - else - {

2 1

Re: [ros-dev] [ros-diffs] [jimtabor] 37223: - Fix WidenPath. Now Area.exe runs and crashes when using real hardware. That is a good thing. We now know our Xorg based region code has problems. It allocates all the memory building PolyPolygon region da
by James Tabor 07 Nov '08

07 Nov '08

Hi, LOL, Wine code does not work at all.... I tested Area.exe with the latest head and it dies and the application continues to work with out drawing the PATH figures. ReactOS: (subsystems/win32/win32k/objects/gdiobj.c:544) Object->cExclusiveLock = 1 (subsystems/win32/win32k/objects/path.c:1911) BeginPath 1 0xbc07024b (subsystems/win32/win32k/objects/path.c:1936) BeginPath 2 h 0xbd07024b p 0x8d9b4830 (subsystems/win32/win32k/objects/path.c:2022) EndPath 0xbd07024b (ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 8192 bytes from paged pool - nothing suitable found, returning NULL (subsystems/win32/win32k/objects/path.c:1609) Should never happen (subsystems/win32/win32k/objects/path.c:1609) Should never happen (subsystems/win32/win32k/objects/path.c:1609) Should never happen (subsystems/win32/win32k/objects/path.c:1609) Should never happen (subsystems/win32/win32k/objects/path.c:1609) Should never happen (subsystems/win32/win32k/objects/path.c:1612) Got path flag (ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 4096 bytes from paged pool - nothing suitable found, returning NULL <snip> (ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 11264 bytes from paged pool - nothing suitable found, returning NULL (subsystems/win32/win32k/objects/gdiobj.c:544) Object->cExclusiveLock = 1 (subsystems/win32/win32k/objects/path.c:1911) BeginPath 1 0xbd07024b (subsystems/win32/win32k/objects/path.c:1936) BeginPath 2 h 0xbe07024b p 0x8d9b4830 (subsystems/win32/win32k/objects/path.c:2022) EndPath 0xbe07024b (ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 2048 bytes from paged pool - nothing suitable found, returning NULL <snip> (ntoskrnl/mm/rpoolmgr.h:820) Trying to allocate 2400 bytes from paged pool - nothing suitable found, returning NULL Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x000004B0 could not be written: Page not present. kdb:> bt Eip: <win32k.sys:84c9c (subsystems/win32/win32k/objects/bezier.c:160 (GDI_InternalBezier@20))> Frames: <win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84deb (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:84dfd (subsystems/win32/win32k/objects/bezier.c:178 (GDI_InternalBezier@20))> <win32k.sys:85008 (subsystems/win32/win32k/objects/bezier.c:216 (@GDI_Bezier@12))> <win32k.sys:a1760 (subsystems/win32/win32k/objects/path.c:988 (@PATH_AddFlatBezier@12))> <win32k.sys:a286a (subsystems/win32/win32k/objects/path.c:1019 (@PATH_FlattenPath@4))> <win32k.sys:a295e (subsystems/win32/win32k/objects/path.c:1514 (NtGdiWidenPath@4))> <NTOSKRNL.EXE:a145a (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))> <ntdll.dll:5f1e> <Area.exe:35ad> <04ec8353> Couldn't access memory at 0x56E58959! kdb:> The problem is in IntCreatePolyPolygonRgn, it is based on Xorg mipolygen.c. The figure is some what complex and this old Xorg code seems to become over whelmed by it. IntCreatePolyPolygonRgn calles REGION_InsertionSort hundreds or even thousands of times. Using Qemu you will sit there all night and that is the reason for using hardware for this test. The first figure was 3 polygons with a total of 516 points. Question is, why is that so hard to map and sort? I assume the next three figures have the same or close to the same amount of points. Since they do look and draw about the same. The bug report has GDI_InternalBezier faulting out the kernel, well since there is no more PagedPool available so it returned a NULL without faulting. I'm looking into alternative methods that are much simpler than the Xorg code for mapping and filling regions. My best one is from Graphapp, it is a modified variation of the same Xorgs poly code. This means more time I do not have to work out a hypothesise and rewrite all of the region code. FYI: Our Xorg code is the same Xorg code that is in wine....... I assume wine code breaks and bombs out when the memory pool empties. Which is not avalid excuse not to draw. Thanks, James On Thu, Nov 6, 2008 at 7:05 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > How does this code work in Wine without this change? > > WBR, > Aleksey. >

1 0

06 Nov '08

How does this code work in Wine without this change? WBR, Aleksey. On Nov 6, 2008, at 2:55 PM, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Thu Nov 6 05:55:08 2008 > New Revision: 37223 > > URL: http://svn.reactos.org/svn/reactos?rev=37223&view=rev > Log: > - Fix WidenPath. Now Area.exe runs and crashes when using real > hardware. That is a good thing. We now know our Xorg based region > code has problems. It allocates all the memory building PolyPolygon > region data.

1 0

rewrite NtGdiPolyPolyDraw,
by James Tabor 06 Nov '08

06 Nov '08

Hi, This change broke GDI Path support..... http://svn.reactos.org/svn/reactos?view=rev&revision=36686

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev November 2008