- Ros-dev - ReactOS.org

by Olaf Siejka

Since revisions 37313-37314 i observe repetitive problems with WIDL. Every time WIDL is called by our BE, it throws an exception: Faulting application widl.exe, version 0.0.0.0, time stamp 0x491c610d, faulting module widl.exe, version 0.0.0.0, time stamp 0x491c610d, exception code 0xc0000005, fault offset 0x00005f0a, process id 0x17f8, application start time 0x01c945b3aefa8530. > [WIDL] obj-i386\include\reactos\idl\svcctl_s.c > [WIDL] obj-i386\include\reactos\idl\svcctl_s.h > mingw32-make: *** Waiting for unfinished jobs.... > mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.h] Error -1073741819 (0xC0000005) > mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.c] Error -1073741819 (0xC0000005) Reverting revisions 37313 and 37314 fixes this problem. Apart from me, this issue been noted by dreimer, encoded and Christoph_vW. Dunno about Christoph, but me, dreimer and encoded are using Vista/2008. I couldnt replicate this issue on XP/2003 though.

16 years, 10 months

3
2
0 0

1st stage GUI setup and file system managment

by Matthias Kupfer

Hi folks, during the development of the 1st-stage-GUI-setup I experienced some problems with physical drive detection with reactos api (because it's fairly incomplete - it works under windows). To continue the development and to bring more benefits I want to make following suggestion. Sooner or later we need a drive/volume/partition management tool, so i will continue with this basing on the usetup code and replaced later by working reactos api calls. So we can use this tool to determine the current harddisk(s) layout(s), create/delete partitions, format with different file systems and show/install/configure the current boot loader. Later I can use this functions to handle the drives during installation process in a similiar way. What do you think about this plan? Matt -- Matthias Kupfer Telefon +49 (0) 371 236 46 52 Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54 09122 Chemnitz

16 years, 10 months

2
1
0 0

Add a linkerflag to make sure we get an .eh_frame section

by Dmitry Gorbachev

Hi, > Todo: Get it at the end of the executable, so we can safely remove it. I think it can be safely removed from inside of the executable — just wasting some address space.

16 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gschneider] 37281: Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code.

by Steven Edwards

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

16 years, 10 months

1
0
0 0

seh 64

by Timo Kreuzer

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

16 years, 10 months

2
6
0 0

seh 64

by Dmitry Gorbachev

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

16 years, 10 months

2
1
0 0

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, 10 months

1
0
0 0

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, 10 months

1
0
0 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

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, 10 months

2
1
0 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 totally out of place)

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, 10 months

2
1
0 0

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, 10 months

1
0
0 0

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

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, 10 months

1
0
0 0

rewrite NtGdiPolyPolyDraw,

by James Tabor

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

16 years, 10 months

2
2
0 0

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, 10 months

2
1
0 0

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, 10 months

2
3
0 0

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, 10 months

12
28
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 37110: - Add Documentation for netshell

by Aleksey Bragin

You're obliged to keep it up-to-date now :-), so it doesn't become like VFAT "documentation". On Oct 31, 2008, at 2:26 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Fri Oct 31 06:26:23 2008 > New Revision: 37110 > > URL: http://svn.reactos.org/svn/reactos?rev=37110&view=rev > Log: > - Add Documentation for netshell > > Added: > trunk/reactos/dll/win32/netshell/README (with props)

16 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cfinck] 37104: Hack: Copy the toolbar image on our own instead of using CopyImage to hackfix the messed up toolbar graphics as it was done for previous releases.

by Aleksey Bragin

I thought this one was fixed? WBR, Aleksey. On Oct 30, 2008, at 9:15 PM, cfinck(a)svn.reactos.org wrote: > Author: cfinck > Date: Thu Oct 30 13:15:00 2008 > New Revision: 37104 > > URL: http://svn.reactos.org/svn/reactos?rev=37104&view=rev > Log: > Hack: Copy the toolbar image on our own instead of using CopyImage > to hackfix the messed up toolbar graphics as it was done for > previous releases. > > Modified: > branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > > Modified: branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/ > toolbar.c > URL: http://svn.reactos.org/svn/reactos/branches/ros-branch-0_3_7/ > reactos/dll/win32/comctl32/toolbar.c? > rev=37104&r1=37103&r2=37104&view=diff > ====================================================================== > ======== > --- branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > [iso-8859-1] (original) > +++ branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > [iso-8859-1] Thu Oct 30 13:15:00 2008 > @@ -2665,7 +2665,33 @@ > TRACE("adding hInst=%p nID=%d nButtons=%d\n", bitmap->hInst, > bitmap->nID, bitmap->nButtons); > /* Add bitmaps to the default image list */ > if (bitmap->hInst == NULL) /* a handle was passed */ > - hbmLoad = (HBITMAP)CopyImage(ULongToHandle(bitmap->nID), > IMAGE_BITMAP, 0, 0, 0); > + { > + BITMAP bmp; > + HBITMAP hOldBitmapBitmap, hOldBitmapLoad; > + HDC hdcImage, hdcBitmap; > + > + /* copy the bitmap before adding it so that the user's bitmap > + * doesn't get modified. > + */ > + GetObjectW ((HBITMAP)bitmap->nID, sizeof(BITMAP), (LPVOID) > &bmp); > + > + hdcImage = CreateCompatibleDC(0); > + hdcBitmap = CreateCompatibleDC(0); > + > + /* create new bitmap */ > + hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, > bmp.bmPlanes, bmp.bmBitsPixel, NULL); > + hOldBitmapBitmap = SelectObject(hdcBitmap, (HBITMAP)bitmap- > >nID); > + hOldBitmapLoad = SelectObject(hdcImage, hbmLoad); > + > + /* Copy the user's image */ > + BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight, > + hdcBitmap, 0, 0, SRCCOPY); > + > + SelectObject (hdcImage, hOldBitmapLoad); > + SelectObject (hdcBitmap, hOldBitmapBitmap); > + DeleteDC (hdcImage); > + DeleteDC (hdcBitmap); > + } > else > hbmLoad = CreateMappedBitmap(bitmap->hInst, bitmap->nID, > 0, NULL, 0); > >

16 years, 10 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hyperion] 37054: deleted wine/mmsystem.h deleted wine/prsht.h deleted wine/winbase.h deleted wine/winnetwk.h deleted wine/winnt.h deleted wine/winuser.h Our SDK is in good enough shape to compile Wine: drop the #include_next hacks Wi

by Steven Edwards

On Wed, Oct 29, 2008 at 9:19 AM, <hyperion(a)svn.reactos.org> wrote: > Author: hyperion > Date: Wed Oct 29 08:19:21 2008 > New Revision: 37054 > > URL: http://svn.reactos.org/svn/reactos?rev=37054&view=rev > Log: > deleted wine/mmsystem.h > deleted wine/prsht.h > deleted wine/winbase.h > deleted wine/winnetwk.h > deleted wine/winnt.h > deleted wine/winuser.h > Our SDK is in good enough shape to compile Wine: drop the #include_next hacks > Wine compatibility fixes should go either in the SDK headers themselves or in the Wine porting SDK This is a little late but I wanted to let you know that I love you and want to bear your children! -- 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, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 37099: Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests.

by Steven Edwards

Hello, On Thu, Oct 30, 2008 at 9:33 AM, <jimtabor(a)svn.reactos.org> wrote: > URL: http://svn.reactos.org/svn/reactos?rev=37099&view=rev > Log: > Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests. If your using enough of the original implementation to credit Wine then to me that means someone else at least partly own copyright to these functions. Could you please use git blame or git web and see who the author was of the original implementation from Wine and credit them appropriately in the header? From time to time when someone says 'foo from wine' I get pinged from wine developers who's code is appropriated and they ask for proper attribution. If we don't do it right the first time, then at some point another audit of each commit from SVN will have to happen and we will have to go back and add those copyright holders to the files license header. -- 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, 10 months

2
3
0 0

generic graphics

by Matthias Kupfer

Hello, I would like to create a /media/graphics directory in trunk to store the template files for graphics we want to use in altered versions or different resolutions. I start with the replacement for the explorere shutdown icon and a question mark for message dialogs. Due to problems with drawing this icons at the moment I store the templates only, later we can create the icons from the templates and include in the resource files. I suggest to store all selfmade graphics (in alterable formats, e.g. svg) in this directory (if there is no other source). What do you think about the change of the message dialogs icons to the tango project icons and the question mark icon i provide, instead of the current icon set? Matthias -- Matthias Kupfer Telefon +49 (0) 371 236 46 52 Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54 09122 Chemnitz

16 years, 10 months

1
0
0 0

Trunk freeze

by Aleksey Bragin

Hello, trunk has been frozen until 0.3.7 blockers are fixed. Bugfix team having commit access for this freeze: Colin, Herve, Johannes, me. With the best regards, Aleksey Bragin.

16 years, 10 months

1
1
0 0

Win32k Foating Point

by James Tabor

Hi, I've tooled up libm from http://www.netlib.org/fdlibm/ and a hacked floatlib.c in lib/3rdparty. With -msoft-float added in win32k.rbuild, it works. I built the lib separate on XP mingw build environment and I compiled and ran a fp test program (tst-ieee754.c) than compared the results with standard gcc. The results are almost the same. The thing even boots and draws okay. Floatlib.c is very old and I will soon start testing with SoftFloat to replace the gcc soft float math. So,,,,, is it posiable to build our build environment (RosBE) to support full soft-float? So we can avoid more source in ReactOS..... Well, except libm.a ~ 93k. or,,, Just support the hardware floating point and move on........ Thanks, James

16 years, 10 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 37023: - Add PROVIDER_INFO_1 and PROVIDER_INFO_2 struct

by Aleksey Bragin

Is this providEr or providOr ? On Oct 27, 2008, at 6:16 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Mon Oct 27 10:16:05 2008 > New Revision: 37023 > > URL: http://svn.reactos.org/svn/reactos?rev=37023&view=rev > Log: > - Add PROVIDER_INFO_1 and PROVIDER_INFO_2 struct > > Modified: > trunk/reactos/include/psdk/winspool.h > > Modified: trunk/reactos/include/psdk/winspool.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ > winspool.h?rev=37023&r1=37022&r2=37023&view=diff > ====================================================================== > ======== > --- trunk/reactos/include/psdk/winspool.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winspool.h [iso-8859-1] Mon Oct 27 > 10:16:05 2008 > @@ -700,6 +700,24 @@ > ACCESS_MASK DesiredAccess; > } PRINTER_DEFAULTSW,*PPRINTER_DEFAULTSW,*LPPRINTER_DEFAULTSW; > > +typedef struct _PROVIDOR_INFO_1A{ > + LPSTR pName; > + LPSTR pEnvironment; > + LPSTR pDLLName; > +} PROVIDOR_INFO_1A, *PPROVIDOR_INFO_1A, *LPPROVIDOR_INFO_1A; > +typedef struct _PROVIDOR_INFO_1W{ > + LPWSTR pName; > + LPWSTR pEnvironment; > + LPWSTR pDLLName; > +} PROVIDOR_INFO_1W, *LPPROVIDOR_INFO_1W; > + > +typedef struct _PROVIDOR_INFO_2A{ > + LPSTR pOrder; > +} PROVIDOR_INFO_2A, *PPROVIDOR_INFO_2A, *LPPROVIDOR_INFO_2A; > +typedef struct _PROVIDOR_INFO_2W{ > + LPWSTR pOrder; > +} PROVIDOR_INFO_2W, *LPPROVIDOR_INFO_2W; > + > BOOL WINAPI AbortPrinter(HANDLE); > BOOL WINAPI AddFormA(HANDLE,DWORD,PBYTE); > BOOL WINAPI AddFormW(HANDLE,DWORD,PBYTE); > @@ -833,6 +851,10 @@ > typedef PRINTPROCESSOR_INFO_1W > PRINTPROCESSOR_INFO_1,*PPRINTPROCESSOR_INFO_1,*LPPRINTPROCESSOR_INFO_1 > ; > typedef FORM_INFO_1W FORM_INFO_1,*PFORM_INFO_1,*LPFORM_INFO_1; > typedef PRINTER_DEFAULTSW > PRINTER_DEFAULTS,*PPRINTER_DEFAULTS,*LPPRINTER_DEFAULTS; > +typedef PROVIDOR_INFO_1W PROVIDOR_INFO_1; > +typedef LPPROVIDOR_INFO_1W LPPROVIDOR_INFO_1; > +typedef PROVIDOR_INFO_2W PROVIDOR_INFO_2; > +typedef LPPROVIDOR_INFO_2W LPPROVIDOR_INFO_2; > #define AddForm AddFormW > #define AddJob AddJobW > #define AddMonitor AddMonitorW >

16 years, 10 months

2
1
0 0

[ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.

by Dmitry Gorbachev

Hi! Why not use newer GCC 4.3.2 and Binutils 2.19.50 in RosBE, they seems to work well with only a few changes in ReactOS sources.

16 years, 10 months

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev