- Ros-dev - ReactOS.org

by LiGen

When I compile reactos, I find a problem, my make report: string: [DEPENDS] i386/.wcsrchr.d /bin/sh.exe: ....toolsdepends.exe: command not found make[1]: *** [i386/.wcsrchr.d] Error 127 make: *** [string] Error 2 I find the problem is that sh.exe ignored ��\��. The command line is : @gcc -Wall -Werror -D_DISABLE_TIDENTS -D__USE_W32API -fno-strict-aliasing -O6 - I. -I../../include -I../../w32api/include -pipe -march=i486 -D_M_IX86 -Os -Wno-s trict-aliasing -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 - funit-at-a-time -fweb -g -M i386/wcsrchr.s | ..\..\tools\depends.exe i386 i386/. wcsrchr.d And ��..\..\tools\depends.exe�� was changed into ��....tools\depends.exe�� by sh.exe My msys is MSYS-1.0.10 So I made a patch on rules.mak , and the problem solved . F:\SVNReactos\reactos>svn diff rules.mak Index: rules.mak =================================================================== --- rules.mak （修订版 14957�? +++ rules.mak （工作拷贝） @@ -122,7 +122,7 @@ export NASM_CMD = $(Q)nasmw export DOSCLI = yes export FLOPPY_DIR = A: -export SEP := \$(EMPTY_VAR) +export SEP := /$(EMPTY_VAR) export PIPE := -pipe endif

20 years, 4 months

2
1
0 0

Re: [ros-svn] [hbirr] 14964: Do always set the UserIosb of an irp in IoSecondStageCompletion.

by Alex Ionescu

hbirr(a)svn.reactos.com wrote: >Do always set the UserIosb of an irp in IoSecondStageCompletion. > > > >Updated files: >trunk/reactos/ntoskrnl/io/irp.c > > This is incorrect. 1) The IOSB should not always be set. Create a driver and fail an operation that you send to yourself by an IRP. Make that IRP not SYNCH_API, or better yet, make sure you don't have a File Object. You will notice that the Status Block is not touched. 2) The IOSB is not checked if it exists, it should ALWAYS be there. IRPs without a IOSB are invalid. To verify this, set the IOSB of your IRP to 0 and run Windows with a Debugger. You will see that it will break in many places, because Windows has simply placed SEH to make sure that the write is valid. So the correct thing to do is wrap the write in SEH, which protects both against invalid pointers and zero ones, but that still doesn't mean they are"valid" and should be checked that way. Best regards, Alex Ionescu

20 years, 4 months

3
5
0 0

Both CMD Consoles Go Puff!

by James Tabor

Hi All! Wow! Ros on ros build and I walk away come back and both consoles are gone. Thank god for taskmgr! It shows both cmds', ctm, and three make.exe, not running but still in memory. Build 14598 (KERNEL32:mem/global.c:412) Memory Load: 23 (KERNEL32:mem/global.c:412) Memory Load: 23 (MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2 f0, fdflags 0 (MSVCRT:io/open.c:700) _setmode: inval fd (0) (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi 32.dll (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 850000) C:\ReactOS\system32\gdi 32.dll (NTDLL:rtl/critical.c:446) Deadlock: 8517f8 Unhandled exception Address: 7c90a05c C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c90a3d2 DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 EBP: 019afdd8 ESI: 00000000 ESP: 019afde0 EDI: 00000000 EFLAGS: 00000212 Frames: 7c900000+a05c C:\ReactOS\system32\ntdll.dll 5ffb0000+8381 C:\ReactOS\system32\win32csr.dll 5ffb0000+8eac C:\ReactOS\system32\win32csr.dll 220000+12a8f C:\ReactOS\system32\user32.dll 220000+12ced C:\ReactOS\system32\user32.dll 5ffb0000+91c4 C:\ReactOS\system32\win32csr.dll 7c800000+26554 C:\ReactOS\system32\kernel32.dll (NTDLL:rtl/critical.c:446) Deadlock: 8517f8 (ke/catch.c:191) Unhandled UserMode exception, terminating thread Explorer is running btw, James

20 years, 4 months

2
4
0 0

ping

by Hartmut Birr

20 years, 4 months

3
2
0 0

RE: [ros-dev] gcc problem or not

by Waldo Alvarez Cañizares

Hi: I doubt this could be a bug. A lot of code would break with it. Maybe it does violates the short circuit in the small number of cases where that can be done. As in this case, it doesn't matters. Regards Waldo ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Hartmut Birr Sent: Tue 5/3/2005 2:43 PM To: ReactOS Development List Subject: [ros-dev] gcc problem or not Hi, I've looked on a map file from an optimized build. I found the following code: /* * If the directory containing the file to open doesn't exist then * fail immediately */ if (Status == STATUS_OBJECT_PATH_NOT_FOUND || 12015: 83 c4 0c add $0xc,%esp 12018: 89 c3 mov %eax,%ebx 1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax 1201f: 0f 94 c2 sete %dl 12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax 12027: 0f 94 c0 sete %al 1202a: 09 d0 or %edx,%eax 1202c: a8 01 test $0x1,%al 1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9> 12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx 1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9> Status == STATUS_INVALID_PARAMETER || Status == STATUS_DELETE_PENDING) { if (ParentFcb) { vfatReleaseFCB (DeviceExt, ParentFcb); } return(Status); } I was always the opinion that the examination of a test condition stops if the result can not change again. A test condition like this: if (pointer == NULL || pointer->member == 0) should never access pointer->member if pointer is zero. Compared with the code above, it is possible that gcc build the result from the right side of the OR statement. This may hit a page fault. Is this a bug in gcc? - Hartmut _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

20 years, 4 months

1
0
0 0

gcc problem or not

by Hartmut Birr

Hi, I've looked on a map file from an optimized build. I found the following code: /* * If the directory containing the file to open doesn't exist then * fail immediately */ if (Status == STATUS_OBJECT_PATH_NOT_FOUND || 12015: 83 c4 0c add $0xc,%esp 12018: 89 c3 mov %eax,%ebx 1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax 1201f: 0f 94 c2 sete %dl 12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax 12027: 0f 94 c0 sete %al 1202a: 09 d0 or %edx,%eax 1202c: a8 01 test $0x1,%al 1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9> 12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx 1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9> Status == STATUS_INVALID_PARAMETER || Status == STATUS_DELETE_PENDING) { if (ParentFcb) { vfatReleaseFCB (DeviceExt, ParentFcb); } return(Status); } I was always the opinion that the examination of a test condition stops if the result can not change again. A test condition like this: if (pointer == NULL || pointer->member == 0) should never access pointer->member if pointer is zero. Compared with the code above, it is possible that gcc build the result from the right side of the OR statement. This may hit a page fault. Is this a bug in gcc? - Hartmut

20 years, 4 months

7
9
0 0

RE: [ros-svn] [ion] 14799: KD System Rewrite:

by Ge van Geldorp

> From: ion(a)svn.reactos.com > > KD System Rewrite: This utterly broke the GDB stub, to the point that I can't even use DbgPrint anymore to try and figure out what's wrong. May I suggest you go and read http://www.joelonsoftware.com/articles/fog0000000069.html first, revert this patch (so I can get on with my work), and then, if you still feel this overwhelming urge to rewrite, test all the functionality you're replacing (you obviously didn't even consider a "/DEBUGPORT=GDB" and boot test necessary) before recommiting. If I sound a little bit pissed-off, that's because it's exactly how I feel. This is not the first time I've been bitten by a rewrite. Back in January I spent a lot of time improving symbol handling and profiling, only to see you remove the profiling code a few weeks later, for a "new and improved" rewrite. Only problem is, the "new and improved" profiling system doesn't produce any output and is therefore useless. You said you would fix that in a weeks time, but now, months later, still nothing. I'll be damned if I'm going to let the same happen to the GDB stub, which I use on a daily basis. We all break stuff sometimes (God knows I do) and I can live with that. I can even live with rewrites when they're necessary for binary compatibility (after all, that's what this project is all about) but I'm highly suspicious of rewrites because of "well, uhmm, I think my way is cleaner". Gé van Geldorp.

20 years, 4 months

2
3
0 0

keyboard problem in qemu

by Hartmut Birr

Hi, since the keyboard driver has changed, I'm not able to install ros within qemu if i want change the selection of some components. The cursor keys doesn't work. They has worked with the old driver and they do work with freeldr or other OS. I've enabled the debug output from keyboard driver. There is a little difference between qemu and real hardware. The debug output is from hitting the cursor up key. - Hartmut QEMU (keyboard.c:107) PortStatus: 1d (keyboard.c:120) Got: 48 (keyboard.c:145) Irq is keyboard input (keyboard.c:74) Irq completes key (keyboard.c:231) Send a key (kbdclass.c:81) ServiceCallback called (kbdclass.c:64) Send scancode: 48 (kbdclass.c:68) Success! (kbdclass.c:164) DeviceObject 8086b618 (kbdclass.c:165) Irp 808c94a8 (kbdclass.c:167) Dispatch: stk->MajorFunction 3 (kbdclass.c:168) AlreadyOpened 1 (kbdclass.c:189) Queueing packet (kbdclass.c:115) KeyboardStartIo(DeviceObject 8086b618 Irp 808c94a8) (kbdclass.c:62) Pending... (NrRead 0, NrToRead 1 (keyboard.c:107) PortStatus: 1d (keyboard.c:120) Got: c8 (keyboard.c:145) Irq is keyboard input (keyboard.c:74) Irq completes key (keyboard.c:231) Send a key (kbdclass.c:81) ServiceCallback called (kbdclass.c:64) Send scancode: 48 (kbdclass.c:68) Success! (kbdclass.c:164) DeviceObject 8086b618 (kbdclass.c:165) Irp 808c94a8 (kbdclass.c:167) Dispatch: stk->MajorFunction 3 (kbdclass.c:168) AlreadyOpened 1 (kbdclass.c:189) Queueing packet (kbdclass.c:115) KeyboardStartIo(DeviceObject 8086b618 Irp 808c94a8) (kbdclass.c:62) Pending... (NrRead 0, NrToRead 1 Real Hardware (keyboard.c:107) PortStatus: 11 (keyboard.c:120) Got: e0 (keyboard.c:145) Irq is keyboard input (keyboard.c:107) PortStatus: 11 (keyboard.c:120) Got: 48 (keyboard.c:145) Irq is keyboard input (keyboard.c:74) Irq completes key (keyboard.c:231) Send a key (kbdclass.c:81) ServiceCallback called (kbdclass.c:64) Send scancode: 48 (kbdclass.c:68) Success! (kbdclass.c:164) DeviceObject 80873a50 (kbdclass.c:165) Irp 808d2ed8 (kbdclass.c:167) Dispatch: stk->MajorFunction 3 (kbdclass.c(keyboard.c:107) PortStatus: 11 (keyboard.c:120) Got: e0 (keyboard.c:145) Irq is keyboard input (keyboard.c:107) PortStatus: 11 (keyboard.c:120) Got: c8 (keyboard.c:145) Irq is keyboard input (keyboard.c:74) Irq completes key (keyboard.c:231) Send a key (kbdclass.c:81) ServiceCallback called :168) AlreadyOpened 1 (kbdclass.c:189) Queueing packet (kbdclass.c:115) KeyboardStartIo(DeviceObject 80873a50 Irp 808d2ed8) (kbdclass.c:64) Send scancode: 48 (kbdclass.c:68) Success! (kbdclass.c:164) DeviceObject 80873a50 (kbdclass.c:165) Irp 808d2ed8 (kbdclass.c:167) Dispatch: stk->MajorFunction 3 (kbdclass.c:168) AlreadyOpened 1 (kbdclass.c:189) Queueing packet (kbdclass.c:115) KeyboardStartIo(DeviceObject 80873a50 Irp 808d2ed8) (kbdclass.c:62) Pending... (NrRead 0, NrToRead 1

20 years, 4 months

1
0
0 0

Using BOCHS and external gdb

by Mark Junker

Hi, I just want to mention that COM port redirection is possible in Bochs CVS HEAD. Currently it only supports "null", "file", "raw", and "mouse". I extended it in my local copy so that you can use "pipe" too. I attached my patch and my own version of pipetunnel. This patch is already on the Bochs "Patches" page. I hope that it'll be added ASAP to the main source trunk. BTW: I've seen a patch to allow COM <-> TCP/IP redirection on the "Patches" page. When there is interest, I can combine the two patches and publish them here ... Regards, Mark Index: config.cc =================================================================== RCS file: /cvsroot/bochs/bochs/config.cc,v retrieving revision 1.34 diff -u -r1.34 config.cc --- config.cc 3 Apr 2005 15:00:44 -0000 1.34 +++ config.cc 3 May 2005 00:39:58 -0000 @@ -863,6 +863,7 @@ static char *serial_mode_list[] = { "null", "file", + "pipe", "term", "raw", "mouse", Index: iodev/serial.cc =================================================================== RCS file: /cvsroot/bochs/bochs/iodev/serial.cc,v retrieving revision 1.64 diff -u -r1.64 serial.cc --- iodev/serial.cc 19 Jan 2005 18:21:37 -0000 1.64 +++ iodev/serial.cc 3 May 2005 00:54:44 -0000 @@ -45,6 +45,148 @@ #define LOG_THIS theSerialDevice-> +#ifdef WIN32 +class TPipe { +private: + HANDLE hPipe; + char *pszPipeName; + +public: + TPipe(const char *pszPipeName_arg=NULL) { + pszPipeName = NULL; + hPipe = INVALID_HANDLE_VALUE; + Open(pszPipeName_arg); + } + ~TPipe(void) { + Close(); + if (pszPipeName!=NULL) { + free(pszPipeName); + } + } + + bool Open(const char *pszPipeName_arg=NULL) { + Close(); + if (pszPipeName_arg!=NULL) { + if (pszPipeName!=NULL) { + free(pszPipeName); + } + pszPipeName = strdup(pszPipeName_arg); + } + if (pszPipeName==NULL) + return false; + hPipe = + CreateFileA(pszPipeName, + GENERIC_READ | GENERIC_WRITE, + 0, + NULL, + OPEN_EXISTING, + 0, + NULL); + if (hPipe!=INVALID_HANDLE_VALUE) { + DWORD dwMode = PIPE_READMODE_BYTE | PIPE_NOWAIT; + if (!SetNamedPipeHandleState(hPipe, + &dwMode, + NULL, + NULL)) + { + Close(); + } + } + } + void Close(void) { + if (hPipe!=INVALID_HANDLE_VALUE) { + CloseHandle(hPipe); + hPipe = INVALID_HANDLE_VALUE; + } + } + + bool Ok(void) const { + return hPipe!=INVALID_HANDLE_VALUE; + } + + size_t Write(const void *pcv,size_t size) { + assert(hPipe!=INVALID_HANDLE_VALUE); + DWORD dwWritten = 0; + if (!WriteFile(hPipe, + pcv, + (DWORD) size, + &dwWritten, + NULL)) + return 0; + return (size_t) dwWritten; + } + + size_t Read(void *pv,size_t size) { + assert(hPipe!=INVALID_HANDLE_VALUE); + DWORD dwRead = 0; + if (!ReadFile(hPipe, + pv, + (DWORD) size, + &dwRead, + NULL)) + { + return 0; + } + return (size_t) dwRead; + } + + bool Flush(void) { + assert(hPipe!=INVALID_HANDLE_VALUE); + return FlushFileBuffers(hPipe)!=0; + } + + bool Terminated(void) { + assert(hPipe!=INVALID_HANDLE_VALUE); + DWORD dwBytesAvail = 0; + if (!PeekNamedPipe(hPipe, + NULL, + 0, + NULL, + &dwBytesAvail, + NULL)) + return true; + return false; + } + + HANDLE GetHandle(void) const { + return hPipe; + } +}; +#else +class TPipe +{ +private: + int iHandle; + +public: + TPipe(const char *pszFileName) { + iHandle = open(pszFileName, O_RDWR | O_NONBLOCK, 600); + } + ~TPipe(void) { + if (iHandle >=0 ) + close(iHandle); + } + bool Ok(void) const { + return iHandle >= 0; + } + size_t Write(const void *pv, size_t size) + { + return write(iHandle, pv, size); + } + size_t Read(void *pv, size_t size) + { + return read(iHandle, pv, size); + } + bool Flush(void) { + return commit(iHandle)==0; + } + + int GetHandle(void) const { + return iHandle; + } +}; +#endif + bx_serial_c *theSerialDevice = NULL; int @@ -82,6 +224,11 @@ if (BX_SER_THIS s[i].output != NULL) fclose(BX_SER_THIS s[i].output); break; + case BX_SER_MODE_PIPE: + // Close the handler + // It must not happen that io_handler is NULL at this point + delete (TPipe*) BX_SER_THIS s[i].io_handler; + break; case BX_SER_MODE_TERM: #if defined(SERIAL_ENABLE) if (s[i].tty_id >= 0) { @@ -227,6 +374,23 @@ if (BX_SER_THIS s[i].output) BX_SER_THIS s[i].io_mode = BX_SER_MODE_FILE; } + } else if (!strcmp(mode, "pipe")) { + if (strlen(bx_options.com[i].Odev->getptr ()) > 0) { + TPipe *pIo = new TPipe(bx_options.com[i].Odev->getptr ()); + if (!pIo->Ok()) { + // It's not an error if the connection to the pipe failed + // because the listening process might be available only + // when a developer wants to debug something without changing + // the configuration file + BX_INFO(("open of com%d (%s) failed\n", i+1, bx_options.com[i].Odev->getptr ())); + // Delete TPipe class to avoid a memory leak + delete pIo; + } else { + BX_DEBUG(("com%d pipe: %s", i+1, bx_options.com[i].Odev->getptr ())); + BX_SER_THIS s[i].io_mode = BX_SER_MODE_PIPE; + BX_SER_THIS s[i].io_handler = pIo; + } + } } else if (!strcmp(mode, "term")) { #if defined(SERIAL_ENABLE) if (strlen(bx_options.com[i].Odev->getptr ()) > 0) { @@ -1031,6 +1195,17 @@ fputc(BX_SER_THIS s[port].tsrbuffer, BX_SER_THIS s[port].output); fflush(BX_SER_THIS s[port].output); break; + case BX_SER_MODE_PIPE: + { + // Get the redirection target object. + TPipe *pIo = (TPipe*) BX_SER_THIS s[port].io_handler; + BX_DEBUG(("com%d: write: '%c'", port+1, BX_SER_THIS s[port].tsrbuffer)); + // The status of this object must be Ok()==true so there's no need + // to test for this status explicitly. + pIo->Write((bx_ptr_t) & BX_SER_THIS s[port].tsrbuffer, 1); + pIo->Flush(); + } + break; case BX_SER_MODE_TERM: #if defined(SERIAL_ENABLE) BX_DEBUG(("com%d: write: '%c'", port+1, BX_SER_THIS s[port].tsrbuffer)); @@ -1178,6 +1353,18 @@ } #endif break; + case BX_SER_MODE_PIPE: + { + // Get the redirection target object. + TPipe *pIo = (TPipe*) BX_SER_THIS s[port].io_handler; + // The status of this object must be Ok()==true so there's no need + // to test for this status explicitly. + if (pIo->Read(&chbuf, 1)==1) { + BX_DEBUG(("com%d: read: '%c'", port+1, chbuf)); + data_ready = 1; + } + } + break; case BX_SER_MODE_MOUSE: if (BX_SER_THIS mouse_internal_buffer.num_elements > 0) { chbuf = BX_SER_THIS mouse_internal_buffer.buffer[BX_SER_THIS mouse_internal_buffer.head]; Index: iodev/serial.h =================================================================== RCS file: /cvsroot/bochs/bochs/iodev/serial.h,v retrieving revision 1.25 diff -u -r1.25 serial.h --- iodev/serial.h 5 Dec 2004 20:23:39 -0000 1.25 +++ iodev/serial.h 3 May 2005 00:41:34 -0000 @@ -67,6 +67,7 @@ #define BX_SER_MODE_TERM 2 #define BX_SER_MODE_RAW 3 #define BX_SER_MODE_MOUSE 4 +#define BX_SER_MODE_PIPE 5 enum { BX_SER_INT_IER, @@ -110,6 +111,7 @@ int io_mode; int tty_id; FILE *output; + void *io_handler; #if USE_RAW_SERIAL serial_raw* raw; // // pipetunnel.cpp // // Martin Fuchs, 30.11.2003 // // // Invoke as: "pipetunnel [pipe_name]", // for example: "pipetunnel com_2" // // Then start up RectOS in VMWare, wait for the serial connect. // After that you can connect GDB using the command "target remote :9999". // #define _WIN32_WINNT 0x0501 #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winsock.h> #ifdef _MSC_VER #pragma comment(lib, "wsock32") #endif #include <stdio.h> #include <stddef.h> #include <string.h> #include <assert.h> #include <errno.h> #include <queue> #include <vector> // This definition currently missing in MinGW. #ifndef FILE_FLAG_FIRST_PIPE_INSTANCE #define FILE_FLAG_FIRST_PIPE_INSTANCE 0x00080000 #endif void dumphex(const char *buf, int len, int pos) { int i, j; for(j = 0; j < len; j += 16) { for(i = 0; i < 16; i++) { if(i + j < len) printf("%02x%c", (unsigned char)buf[i + j], j + i + 1 == pos ? '*' : ' '); else printf(" "); } for(i = 0; i < 16; i++) { if(i + j < len) printf("%c", buf[i + j] >= ' ' ? buf[i + j] : '.'); else printf(" "); } printf("\n"); } } class WinSockInit { private: WSADATA wsa_data; bool bIsOK; public: WinSockInit(void) { bIsOK = WSAStartup(MAKEWORD(2,2), &wsa_data)==0; } ~WinSockInit(void) { if (bIsOK) WSACleanup(); } bool Ok(void) const { return bIsOK; } }; class TSocketServer { private: SOCKET sckServer; SOCKADDR_IN addr; SOCKET sckClient; public: TSocketServer(void) { memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(9999); sckClient = INVALID_SOCKET; sckServer = socket(PF_INET, SOCK_STREAM, 0); if (sckServer==INVALID_SOCKET) return; u_long nbio_value = 1; ioctlsocket(sckServer, FIONBIO, &nbio_value); if (bind(sckServer, (struct sockaddr*) &addr, sizeof(addr))!=0) { sckServer = INVALID_SOCKET; return; } if (listen(sckServer, 4)!=0) { sckServer = INVALID_SOCKET; return; } } bool Ok(void) const { return (sckServer!=INVALID_SOCKET); } bool IsConnected(void) { if (sckClient==INVALID_SOCKET) { sckClient = accept(sckServer, NULL, NULL); if (sckClient!=INVALID_SOCKET) { BOOL bValue = TRUE; setsockopt(sckClient, IPPROTO_TCP, TCP_NODELAY, (const char *) &bValue, sizeof(BOOL)); } } return sckClient!=INVALID_SOCKET; } size_t Write(const void *pcv,size_t size) { assert(sckClient!=INVALID_SOCKET); int count = send(sckClient, (const char *) pcv, (int) size, 0); if (count==SOCKET_ERROR) { sckClient = INVALID_SOCKET; return 0; } return (size_t) count; } size_t Read(void *pv,size_t size) { assert(sckClient!=INVALID_SOCKET); int count = recv(sckClient, (char*) pv, (int) size, 0); if (count==SOCKET_ERROR) { int iErrCode = WSAGetLastError(); switch (iErrCode) { case WSAEWOULDBLOCK: break; case WSAECONNRESET: sckClient = INVALID_SOCKET; break; } return 0; } else if (count==0) { sckClient = INVALID_SOCKET; } return (size_t) count; } }; class TPipeServer { private: HANDLE hPipe; char *pszPipeName; private: bool Listen(void) { assert(hPipe!=INVALID_HANDLE_VALUE); if (ConnectNamedPipe(hPipe, NULL)!=0) return true; if (GetLastError()==ERROR_PIPE_LISTENING) return true; return false; } public: TPipeServer(const char *pszPipeName_arg=NULL) { pszPipeName = NULL; hPipe = INVALID_HANDLE_VALUE; Open(pszPipeName_arg); } ~TPipeServer(void) { Close(); if (pszPipeName!=NULL) { free(pszPipeName); } } bool Open(const char *pszPipeName_arg=NULL) { if (hPipe!=INVALID_HANDLE_VALUE) { Close(); } if (pszPipeName_arg!=NULL) { if (pszPipeName!=NULL) { free(pszPipeName); } pszPipeName = strdup(pszPipeName_arg); } if (pszPipeName==NULL) return false; hPipe = CreateNamedPipeA(pszPipeName, PIPE_ACCESS_DUPLEX | FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_WRITE_THROUGH, PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_NOWAIT, 1, 4096, 4096, 0, NULL); if (hPipe!=INVALID_HANDLE_VALUE) { if (!Listen()) { Close(); } } return true; } void Close(void) { if (hPipe!=INVALID_HANDLE_VALUE) { Flush(); DisconnectNamedPipe(hPipe); CloseHandle(hPipe); hPipe = INVALID_HANDLE_VALUE; } } bool Ok(void) const { return hPipe!=INVALID_HANDLE_VALUE; } bool IsConnected(void) { assert(hPipe!=INVALID_HANDLE_VALUE); if (ConnectNamedPipe(hPipe, NULL)!=0) return false; DWORD dwErrCode = GetLastError(); if (dwErrCode==ERROR_PIPE_CONNECTED) return true; if (dwErrCode==ERROR_NO_DATA) { // reopen Open(); } return false; } size_t Write(const void *pcv,size_t size) { assert(hPipe!=INVALID_HANDLE_VALUE); DWORD dwWritten = 0; if (!WriteFile(hPipe, pcv, (DWORD) size, &dwWritten, NULL)) return 0; return (size_t) dwWritten; } size_t Read(void *pv,size_t size) { assert(hPipe!=INVALID_HANDLE_VALUE); DWORD dwRead = 0; if (!ReadFile(hPipe, pv, (DWORD) size, &dwRead, NULL)) return 0; return (size_t) dwRead; } bool Flush(void) { assert(hPipe!=INVALID_HANDLE_VALUE); return FlushFileBuffers(hPipe)!=0; } }; typedef std::vector<unsigned char> TByteBuffer; typedef std::queue<TByteBuffer> TBufferQueue; int main(int argc, char** argv) { // initialize winsock WinSockInit SocketInit; if (!SocketInit.Ok()) { fprintf(stderr, "Failed to initialize sockets\n"); return 1; } // Get name of named pipe char path[MAX_PATH]; const char* pipe_name; if (argc > 1) { pipe_name = *++argv; } else { pipe_name = "com_2"; } sprintf(path, "\\\\.\\pipe\\%s", pipe_name); // increment priority to be faster than the cpu eating VMWare process SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS); SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST); TPipeServer PipeServer(path); if (!PipeServer.Ok()) { fprintf(stderr, "Failed to create pipe %s\n", path); return 1; } TSocketServer SocketServer; if (!SocketServer.Ok()) { fprintf(stderr, "Failed to create socket\n"); return 1; } bool bSocketWasOpen = false; bool bPipeWasOpen = false; TBufferQueue PipeReadQueue; TBufferQueue SocketReadQueue; TByteBuffer ReadBuffer(4096); for (;;) { if (PipeServer.IsConnected()) { if (!bPipeWasOpen) { printf("Pipe connected\n"); bPipeWasOpen = true; } size_t BufSize = PipeServer.Read(&*ReadBuffer.begin(), ReadBuffer.size()); if (BufSize!=0) { // send to socket TByteBuffer TempBuffer(BufSize); memcpy(&*TempBuffer.begin(), &*ReadBuffer.begin(), BufSize); printf("PIPE >>\n"); dumphex((const char *) &*TempBuffer.begin(), TempBuffer.size(), 0); PipeReadQueue.push(TempBuffer); } if (SocketReadQueue.size()!=0) { const TByteBuffer &TempBuffer(SocketReadQueue.front()); printf("PIPE <<\n"); dumphex((const char *) &*TempBuffer.begin(), TempBuffer.size(), 0); PipeServer.Write(&*TempBuffer.begin(), TempBuffer.size()); SocketReadQueue.pop(); } } else { if (bPipeWasOpen) { printf("Pipe disconnected\n"); // reopen pipe PipeServer.Open(); bPipeWasOpen = false; PipeReadQueue = TBufferQueue(); } } if (SocketServer.IsConnected()) { if (!bSocketWasOpen) { printf("TCP connection established\n"); bSocketWasOpen = true; } size_t BufSize = SocketServer.Read(&*ReadBuffer.begin(), ReadBuffer.size()); if (BufSize!=0) { // send to socket TByteBuffer TempBuffer(BufSize); memcpy(&*TempBuffer.begin(), &*ReadBuffer.begin(), BufSize); printf("TCP >>\n"); dumphex((const char *) &*TempBuffer.begin(), TempBuffer.size(), 0); SocketReadQueue.push(TempBuffer); } if (PipeReadQueue.size()!=0) { const TByteBuffer &TempBuffer(PipeReadQueue.front()); printf("TCP <<\n"); dumphex((const char *) &*TempBuffer.begin(), TempBuffer.size(), 0); SocketServer.Write(&*TempBuffer.begin(), TempBuffer.size()); PipeReadQueue.pop(); } } else { if (bSocketWasOpen) { printf("TCP connection closed\n"); bSocketWasOpen = false; SocketReadQueue = TBufferQueue(); } } if (!bPipeWasOpen && !bSocketWasOpen) { Sleep(50); } else { Sleep(1); } } return 0; }

20 years, 4 months

1
0
0 0

memory leakage

by Hartmut Birr

Hi, we have somewhere a leakage which doesn't free unicode strings in kernel mode. After a short time of compiling ros on ros, I see many blocks with the tag USTR: ... Tag 52545355 (USTR) Blocks 714270 Total Size 53114920 Average Size 74 ... TotalBlocks 758557 TotalSize 66314608 AverageSize 87 Freeblocks 21427 TotalFreeSize 323088 AverageFreeSize 15 - Hartmut

20 years, 4 months

1
0
0 0

Re: [ros-svn] [Phreak] 14886: Renamed another makefile in the xmlbuildsystem branch that had the wrong case

by Steven Edwards

Hi, --- Phreak(a)svn.reactos.com wrote: > Renamed another makefile in the xmlbuildsystem branch that had the wrong case I don't really care which case we use but if its going to be upper case Makefile can you add it somewhere on the Wiki? Also maybe note about MixEd CaSeFileNames in SoUrce FIles. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

20 years, 4 months

2
1
0 0

request for a grep tool expert

by Hartmut Birr

Hi, I'm searching for a position in our kernel mode code, which compares a variable with STATUS_UNSUCCESSFUL. That does mean, there is somewhere a '==' followed by 'STATUS_UNSUCCESSFUL' or 'STATUS_UNSUCCESSFUL' followed by '=='. - Hartmut

20 years, 4 months

2
2
0 0

VMS environment subsystem for ReactOS

by ea

Hi all, even if it is only an empty framework, I want to make you know yesterday I committed the source code of an optional environment subsystem for emulating VMS. Note it is far from complete and it has no ReactOS specific code (which will be *required* to run), but it may be used as a template. Recently ReactOS, which is a free and open source reimplementation of the core NT kernel+executive and driver model with multiple user mode OS personalities, was added the effective ability to load other optional subsystem, like POSIX (researched) or, say, VMS. If somebody on the list is interested in this project, please, feel free to contact me privately. Emanuele Aliberti ea(a)reactos.com

20 years, 4 months

1
0
0 0

Multiple problems with HEAD

by Ge van Geldorp

1st problem: when booting rev 14873 (DBG := 1, KDBG := 0) it crashes with: DriverBase for \SystemRoot\system32\drivers\fs_rec.sys: 9cf7c000 (io/file.c:898) Status :0 (io/file.c:898) Status :0 (io/file.c:898) Status :0 DriverBase for \SystemRoot\system32\drivers\beep.sys: 9cf8b000 (io/file.c:898) Status :0 Assertion NewRefCount >= 0 failed at ob/object.c:1150 KeBugCheckWithTf at ke/catch.c:217 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe KMODE_EXCEPTION_NOT_HANDLED Technical information: *** STOP: 0x0000001E (0x80000003,0x800057a4,0x8005d08b,0x8071c9ec) *** ntoskrnl.exe - Address 0x800057a4 base at 0x80000000, DateStamp 0x0 Breakpoint Exception: 3(0) Processor: 0 CS:EIP 8:800057a4 <ntoskrnl.exe: 57a4> cr2 8ccfc000 cr3 27000 Proc: 8053fcf8 Pid: 4 <System> Thrd: 805407f0 Tid: 0 DS 10 ES 10 FS 30 GS 10 EAX: 00000036 EBX: 8004515d ECX: 00000000 EDX: 000003f8 EBP: 800e47a4 ESI: 800e4a84 ESP: 800e4730 EDI: 800e49f4 EFLAGS: 00200286 kESP 800e4730 kernel stack base 800e3000 Frames: <ntoskrnl.exe: 72a9f> <ntoskrnl.exe: 45f2a> <ntoskrnl.exe: 456e1> <vfatfs.sys: 2d00> <vfatfs.sys: d1de> <vfatfs.sys: d3ee> <ntoskrnl.exe: 45158> <ntoskrnl.exe: 40487> <ntoskrnl.exe: 414dd> <ntoskrnl.exe: 3602> <7D83F045> <ntoskrnl.exe: 3e6c0> <ntoskrnl.exe: 3602> <EC83FC45> <ntoskrnl.exe: 3de8e> <800A48CE> <800A21D4> <ntoskrnl.exe: 10004> <800A07AA> <ntoskrnl.exe: 104b> 2nd problem: the crash info is only written to the debug log and not shown as a BSOD. 3rd problem: the stack trace only shows addresses, not source file/line as it should for a DBG build 4th problem: booting with /DEBUGPORT=GDB results in a kernel stack fault very early in the boot process. Gé van Geldorp.

20 years, 4 months

3
6
0 0

Re: [ros-svn] [ion] 14884: Add hack for ROS's weird behavior. Will investigate but this lets you boot for now

by Alex Ionescu

ion(a)svn.reactos.com wrote: >Add hack for ROS's weird behavior. Will investigate but this lets you boot for now > > >Updated files: >trunk/reactos/ntoskrnl/io/irp.c > > > The problem is that a bunch of places in the code set the FileObject Event as the UserEvent. This is incredibly wrong, because both are used to signal completely different things and shouldn't be used like that. I've changed them to local stack KEVENTS, but this still fails, because you cannot dereference them. The check for !IRP_SYNCHRONOUS_API is meant to ensure against this (Syncronous IRPs have KEVENTS, Async ones have Executive Events, in short terms.) I've researched some more and this is because of a bigger problem. The routines doing the hack all assumed that the File Object is Synchronous and build a Sync FSD (with IRP_SYNCH_API set), and then set a KEVENT UserEvent. They should actually check if the File Object is Sync or Async, and in case of Async they should use the Local Stack KEVENT (which won't be dereferenced because of the check in IoCompleteRequest APC (2nd stage)), while in case of async they shouldn't use any event at all and wait on the file object instead of waiting on the local event. Also, in case of a sync operation, we must eventually include some sort of locking/unlocking of the file object for serialized access which is required. I will spend some time tomorrow working with these issues so the hack can be removed and proper kernel functionality to be restored, but I wanted to share the background information. Best regards, Alex Ionescu

20 years, 4 months

1
0
0 0

Re: [ros-dev] 0.2.7?

by reactos

>>> It's still not fully stable, card support is not great and it's only configurable through regedit at the moment. However it's all being worked on. Arty has done a fantastic job so far. Ged. <<< Actually lately no regedit is needed, as long as reactos registry supports your card only the dhcp software is needed, then everything is working... ...and soon the controlpanel app will be ready and everyone with a compatible card will be able to configure easy. The thing that we really need is support for driver installation. But on the other hand when we releas a new version we could transfer it to a usual textfile and put it on the welcome screen. /Jaix Bly ----Ursprungligt meddelande----- From: Gedi gedi(a)ntlworld.com Date: Sat, 30 Apr 2005 15:21:39 +0200 To: ReactOS Development List ros-dev(a)reactos.com Subject: Re: [ros-dev] 0.2.7? > Michael B. Trausch wrote: > > >Uh... Networking? > > > >I know at the very least *I* haven't seen ping working yet... > > > Networking has been up and running since before christmas now. > Along with the Mozilla control, you can now browse the web with ROS' > built in ibrowser, or use something like dillo. > There are many other programs running too, email, IRC too name but a few. > > >Networking support at the very least should be a staple for most overly > >popular cards before you think about trying to require a web page be > >displayed for something. Instead, put a static page on the CD that gets > >copied to the installed system. > > > > > It's still not fully stable, card support is not great and it's only > configurable through regedit at the moment. > However it's all being worked on. Arty has done a fantastic job so far. > > Ged. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

20 years, 4 months

2
1
0 0

Re: [ros-dev] 0.2.7?

by reactos

Good idea, but ones a month is to frequent, people will get tired of testing new versions that they can't see any difference between. I think it has to be focust releases where something actually can be tested or seen, a feature not just read about in a change-log, everyone doesn't read the changelog. By the way, to be able to get people test the right thing when a new versin is released, we should have a welcome-screen packed with information about things changed since last release and so forth, this in a way that people can know how to test the new feature. This welcome screen could be a page in the WIKI so every developer easy can add what they want the testers to try out and how to do it. I know this opens for another problem, we need a browser to do that, can we add the mozilla-com plugin to the release? Or can we include another one? ----Ursprungligt meddelande----- From: WaxDragon waxdragon(a)gmail.com Date: Fri, 29 Apr 2005 19:13:29 +0200 To: ReactOS Development List ros-dev(a)reactos.com Subject: [ros-dev] 0.2.7? > I would like to see a 0.2.7 release soon. 0.3.0 is getting closer > every day, but it's not there yet IMHO. On the other hand, we have > had lots of big patches from Mr. Ionescu (and others), major changes, > go in and appear to be stable since we have released 0.2.6. I would > like to see us have another release in this lull, instead of having a > release right after committing a pile of patches *right before* the > release like we did with 0.2.6. > > I know it's been less than a month since 0.2.6, but my the time we > branch and do a couple RC's, it will have been over a month. > > I just have this feeling that we miss some regressions from release to > release, since alot of us just use HEAD on a regular basis? > > Just my $0.2US > WD > -- > "<tinus_> and also win32k should be fixed up a bit" > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

20 years, 4 months

3
3
0 0

ROS System Updater

by Rick Langschultz

I have a simple request for when ReactOS wants to add updates to system software when Service Packs and Updates become available. I think that a ReactOS computer should utilize a small system service that indexes file version numbers, indexes them on importance, size, type, and other information. This can be done on a flatfile, XML, or a SQL Database connection. Then the server sends reponses back to the computer offering service packs, files, device drivers, etc. I think that kind of system will allow easy updates to ReactOs on users computers while not having to reinstall or reformat. Something like up2date, or mac os x¹s update program. The system can maybe support rollback of files. Just an idea.

20 years, 4 months

1
0
0 0

reactos.com available again

by Ge van Geldorp

Yesterday reactos.com crashed. Unfortunately, I was unable to go onsite to fix the problem yesterday. This morning, I rebooted the box and everything seems to be up and running again. It seems some mail sent to @reactos.com yesterday may have been dropped. Ge van Geldorp.

20 years, 4 months

1
0
0 0

Re: [ros-general] ROS installer scribbled over my ext2 partition :-(

by Michael B. Trausch

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Christof Petig wrote: | | This limitation really hurts if you do not plan to use ROS exclusively | on that computer (e.g. if you do not want to throw XP away completely or | you already use a first primary partition for linux). | ROS and XP can share the same partition. It just cannot be NTFS. You can always move partitions around. And yes, while the limitation "hurts," that's a workaround that you can use. Short of editing the source code, I'm not sure if there's much that can be done. I'll cc: this to the dev list and ask if the limitation still is there, but I personally don't see anything about it having changed. Consider that ROS is still in "early" stages of use/release. 0.3 hasn't even been released yet. I am sure that when the partition/fs code is better able to deal with multiple partition setups, it will all work as it would be anticipated it would. - Mike - -- Michael B. Trausch <fd0man(a)gmail.com> Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647 =================================================================== Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCbiTLPXInbkqM7nwRAwl+AJ9U7aJ/HjCf72KuEkj4SjcM0wrpXgCfb6bs k9UbhobagYdusxcub9csK7U= =w/H8 -----END PGP SIGNATURE-----

20 years, 4 months

1
0
0 0

gcc-4.0 mingw crossbuild script

by Steven Edwards

Hi, If you need it here it is. Only explorer.exe does not build. The rest will compile if you shutup -Werror. For the C++ code that I have compared vs 3.4.1 its almost 2x faster. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

20 years, 4 months

1
0
0 0

not sure if it's been said already but...

by Jeff Smith

Vote results (Which kernel you prefer to see as base of osFree kernel?): What Percentage Votes L4 30.6 % 609 Linux 13.4 % 267 Mach 7.2 % 144 ReactOS 43.9 % 874 Other 4.4 % 87 This poll is taken from http://www.osfree.org/index.php

20 years, 4 months

3
2
0 0

ReactOS Package Manager - Online (Website)

by Klemens Friedl

Hi! I programmed the ReactOS Package Manager - Online Website (started yesterday). It provide the online database (xml database) for the ReactOS Package Manager (exe) (svn: /trunk/rosapps/packmgr). Some important main function of the page already work. The page (written in php with mysql database) provide the database files (static xml files) for the client (packmgr.exe). So the Package Manager only download some static xml files (spare server resources). Url: http://frik85.fr.funpic.de/packmgr/ (for test purposes) Test the package manager (in Win32) with the new online database: * Compile the packmgr files (gui-app + dll) * change the server in option.xml to: <options> <source>http://frik85.fr.funpic.de/packmgr/db/</source> </options> * start the gui application (packmgr.exe) Wiki-Page: http://reactos.com/wiki/index.php/ReactOS_Package_Manager Klemens Friedl -- +++ GMX - Die erste Adresse f�r Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

20 years, 4 months

2
1
0 0

Re: [ros-svn] [ion] 14799: KD System Rewrite:

by Hartmut Birr

Hi, I've found some other problems. For the serial debug, the default baudrate is set to 19200 baud and the baudrate option has no effect. Two debug port options like "/DEBUGPORT=BOCHS /DEBUGPORT=COM2" switches my pc off. The on/off switch has no effect after this. I must remove/insert the power plug to boot the pc again. I use this option for the bootcd. The previous debug implementation has enabled the bochs and serial debug at boot phase 0 and all other debug variants at boot phase 1. Currently KdInitSystem(0, ..) is called twice. The first call is in _main and the second in ExpInitializeExecutive. - Hartmut

20 years, 4 months

2
1
0 0

Re: [ros-svn] [ion] 14799: KD System Rewrite:

by Hartmut Birr

Hi, your changes breaks compiling with DBG := 1 and KDBG := 0. - Hartmut ion(a)svn.reactos.com wrote: >KD System Rewrite: > > - Totally dynamic based on the principle of Native Providers built-in the Kernel (like Screen, > FileLog and Serial) and a pluggable Wrapper which is optionally compiled (Bochs, GDB) > - Nothing changed in KDBG, except for that its settings (KDSERIAL/KDNOECHO) are now stored in > KdbDebugState instead. > - Wrappers are currently built uncondtionally. With rbuild, I'll make them easily removable. > - Debug Log code simplified greatly, sped up and now supports printing even the first boot messages, > which wasn't supported before. > - Removed most of KDBG compile-time settings, ones which are needed are in include/dbg as macros now. > - Left in some kdbg init code and break code, but it could be made to be used as a 'wrapper' for those > functions. I will do it later. > - Made a hack for KdpEnterDebuggerException..it seems to be called differently and at different times > for GDB vs KDBG and I couldn't unite them. > - KdpServiceDispatcher now does both the documented and ros-internal debug functions and will eventually > be called through INT2D from keyboard.sys instead of as an API. > >All in all, this patch makes KD separated from KDBG and creates a pluggable architecture for creating future wrappers that don't require changing tons of code in the future. It improves the debug >log by printing even the earliest debug messages to it and it removes many of the manual ifdef(KDBG) but making them automatic though a single macro file. It makes extra debugging functionality optional and it >allows removal of a private API from our exports. > > >Added files: >trunk/reactos/ntoskrnl/include/internal/kdbochs.h >trunk/reactos/ntoskrnl/include/internal/kdgdb.h >trunk/reactos/ntoskrnl/kd/kdinit.c >trunk/reactos/ntoskrnl/kd/kdio.c >trunk/reactos/ntoskrnl/kd/kdmain.c >trunk/reactos/ntoskrnl/kd/wrappers/ >trunk/reactos/ntoskrnl/kd/wrappers/bochs.c >trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c > >Updated files: >trunk/reactos/drivers/input/keyboard/keyboard.c >trunk/reactos/include/ddk/kefuncs.h >trunk/reactos/ntoskrnl/Makefile >trunk/reactos/ntoskrnl/ex/init.c >trunk/reactos/ntoskrnl/include/internal/dbg.h >trunk/reactos/ntoskrnl/include/internal/kd.h >trunk/reactos/ntoskrnl/include/internal/kdb.h >trunk/reactos/ntoskrnl/include/internal/ke.h >trunk/reactos/ntoskrnl/include/internal/module.h >trunk/reactos/ntoskrnl/include/ntoskrnl.h >trunk/reactos/ntoskrnl/io/iomgr.c >trunk/reactos/ntoskrnl/io/pnpreport.c >trunk/reactos/ntoskrnl/kd/service.c >trunk/reactos/ntoskrnl/kdbg/kdb.c >trunk/reactos/ntoskrnl/kdbg/kdb_cli.c >trunk/reactos/ntoskrnl/kdbg/kdb_serial.c >trunk/reactos/ntoskrnl/kdbg/kdb_symbols.c >trunk/reactos/ntoskrnl/ke/bug.c >trunk/reactos/ntoskrnl/ke/catch.c >trunk/reactos/ntoskrnl/ke/i386/exp.c >trunk/reactos/ntoskrnl/ke/i386/irq.c >trunk/reactos/ntoskrnl/ke/i386/syscall.S >trunk/reactos/ntoskrnl/ldr/loader.c >trunk/reactos/ntoskrnl/mm/RPoolMgr.h >trunk/reactos/ntoskrnl/mm/marea.c >trunk/reactos/ntoskrnl/ntoskrnl.def > >Deleted files: >trunk/reactos/ntoskrnl/kd/dlog.c >trunk/reactos/ntoskrnl/kd/gdbstub.c >trunk/reactos/ntoskrnl/kd/kdebug.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > >

20 years, 4 months

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