Ros-dev

ros-dev@reactos.org

3 participants
5789 discussions

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

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.

16 years, 2 months

Re: [ros-dev] [ros-diffs] [cgutman] 37247: - Close the connection before freeing it

by Aleksey Bragin

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 ); > } > >

16 years, 2 months

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

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

16 years, 2 months

by gedmurphy

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 - {

16 years, 2 months

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

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. >

16 years, 2 months

by Aleksey Bragin

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.

16 years, 2 months

rewrite NtGdiPolyPolyDraw,

by James Tabor

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

16 years, 2 months

Small update on my activities

by Maya Posch

Hi guys, After a lot of requests from people in ReactOS, I have decided to continue my work on USB support, the new bootloader and eventually Firewire and audio support. Making use of the freedom within the project I'll use my own, fully spec'ed and documented working methods, attract devs to work for me when I deem necessary and rally for donations for a speedy completion of those tasks. Since there's no roadmap or central goals I'll also set those for myself and my team(s). I'll provide regular updates on all activities inside those projects on an as of yet unknown location (ReactOS wiki?) and use a central repository for all documentation and specification produced by these projects. Maya

16 years, 2 months

Share Memory Issue

by James Tabor

Hi all, Fixing GetDeviceCaps exposed a thread process shared memory issue with WinLogon and Gimp.... Gimp bug, been around and the crash does not make sense until you see where the fault was located. Where? In client thread share memory. So, we need help and soon I will revert the hack in GetDeviceCaps. Maybe we are not passing everything to User32 that is needed. Thanks, James

16 years, 2 months

Regarding documentation and attracting new developers

by Maya Posch

Gentlemen, If you don't mind me intruding, I'd like to propose some things I think may ease life for us poor ROS devs, existing and new ones :) First of all, I'd like to suggest 'apprenticeship programming', also known by other names, but which commonly involves having one seasoned programmer in charge of a particular (sub-)project and one or more programmers following his lead. These latter programmers would be less experienced but could work on relatively advanced stuff due to the lead of the seasoned programmer. This model is commonly used in companies already and if adapted for ROS it should make it much easier for 'newbie' devs to get started, pick up experience and become seasoned devs themselves. My own experience with picking up the USB subproject reflect this as well. It's hard to get started without much of a lead, especially when one's experience with the NT subsystems is limited. This is also where documentation would have helped, bringing me to my second point: Whenever I start a new project or implementation I first write a technical specification detailing the exact layout, APIs and implementation. I've heard that this is common practice in professional programming as well as other areas. Benefits include having a good overview of the project before one starts on it, being able to pick out obvious oversights before writing a single line of code, having a central place of reference (code does _not_ work for this), allows one to quickly pick up on things during maintenance sessions (many months later...). It'd also enable the apprentice programming system and make it easy for the central project leader(s) to get an overview of the progress being made. Documentation and specifications are often ignored by programmers because they're not deemed 'time-efficient', preferring to start programming right away instead. In my experience and those of everyone in high-level jobs involving anything from programming to hardware design (like my housemate who is a senior engineer in a Dutch company which designs chips for the telecom industry), specifications and documentation are the lifeblood of any project. I have elected to use both the apprentice method as well as the documentation approach in my work on the new installer, bootloader and USB stack for ReactOS, attracting two relatively inexperienced but highly motivated devs for the installer (RI2, or ROSE) project already. They have expressed interest in helping me with further projects in ROS as well, even more low-level things. I think that this is a good example of the future ROS should be heading towards. So yeah, that's my rant I guess :) *ducks and runs for cover* Maya Posch

16 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev