Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] [ros-diffs] [arty] 23765: Menu displays. Need stdin/hid objects.

by Thomas Weidenmueller

http://svn.reactos.org/svn/reactos/branches/powerpc/reactos/boot/freeldr/fr… > ============================================================================== --- branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c (original) > +++ branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c Tue > Aug 29 11:16:16 2006 > @@ -30,6 +30,7 @@ > BOOLEAN AcpiPresent = FALSE; > char BootPath[0x100] = { 0 }, BootPart[0x100] = { 0 }, CmdLine[0x100] = { > 0 }; > jmp_buf jmp; > +char *video_mem = 0; > > void le_swap( void *start_addr_v, > void *end_addr_v, To avoid incorrect code generation with enabled optimizations, the variable video_mem needs to be defined as: volatile char *video_mem = NULL; - Thomas

18 years

Frist test of clipboard patch from SoC project

by Magnus Olsen

Hi I I got the clipboard patch from thomas and waiting on the final dectsions from him. Thomas need some time to review it. for it is around 121Kbytes big I did test it in ReactOS and I alot happy 1. Copy text and picture betwin program is working with this big patch 2. Copy file from one place to anyther working. But I wisch it show file copy when it doing it 3. copy file to the desktop does not working nug in explore ?? 4. move icon on the desktop is a new bug in win32k. 5. mark the text is white background with white text instead for invert background with white text 6. cut/copy/paste is working 7. keys like cut/copy/paste (ctrl+x,ctrl+c,ctrl+v) is working in all program I tested. say this patch is really good sussess and adding a clipboard to reactos. that working betwin program and u can copy/paste files and more I say it it is up to thomas to aprove the code. I have not looked at the code at, more that a fast preview.

18 years

GetSiteSidFromToken in advapi32

by Grzegorz Jaskiewicz

Hi folks based on my knowledge and some docs I used to read ages ago. Plus some recent googling, I kinda recreated function GetSiteSidFromToken from advapi32.dll - as it was missing there, and I couldn't start w2k taskmgr because of that. Of course simple stub returning NULL should be sufficient, but I gave it a shot and tried to implement it fresh and fully functional. First, I am not sure of few things there. And if someone is more knowledgable than I am - please let me know your thoughts. As far as I know the function returns pointer to SID from token. But there's more than one token. So it returns token that has "SITE" SID. Now, there were quite few SIDs missing in ROS, I tried to add them - mainly guessing their names based on some googling. Some docs on msdn say that they are all defined in ntseapi.h - but I couldn't found that file anywhere. For more details lookup attachment 1043 and corresponding bug. Function is quite simple, it iterates through all sids, trying to match the one with "SITE" authority. Question now arises - what if there's more than one such SID ? Does ROS use SIDs 1-6 to 1-8 at all ? is the SECURITY_INTERNETSITE_AUTHORITY the SITE authority or perhaps SECURITY_SITESERVER_AUTHORITY ? I don't know. I will try to write simple code that would ask original function from original dll about it, and see what it comes up with. First part of the code comes as simple c&p from other functions. The iteration is quite obvious. I didn't knew what should I use to compare SIDs, so I used memcmp. But perhaps simple comparing values in the table one by one would be simple, or maybe there's some sort of ROSish/NTish specific function that is more "right" than memcmp. Another question I have - is it normal practice that you alloc extra ram and return pointer to copy (seems to be in other places in your code), or should I just simply return pointer to the SID ? I do appreciate any comment. Patch is attached. if someone has the ntseapi.h file anywhere on their discs, I would like you to verify SECURITY_*_AUTHORITY names as well as values. I spent whole day gathering info, and I used all info I could find. Sorry for such long letter. Much too long I suppose. this is my first attempt to hack anything for ros. I promise next time I would try to take care of something more obvious and better documented. till than, ta. -- GJ

18 years, 1 month

Status of trunk

by Aleksey Bragin

Hello, after recent fixes by Alex Ionescu and Thomas Weidenmueller trunk works rather good again. What I tested: - bootcd: installs, 2nd stage install works, explorer shows up and is usable - livecd: doesn't boot due to broken mkhive (it should use cmlib and it doesn't do at the moment) - GDB support in ntoskrnl: I was able to connect to the GDB with a cmdline client, disassembly, however I wasn't able to test it more because our keyboard/mouse drivers don't work when vmware has no focus during booting. WBR, Aleksey Bragin.

18 years, 1 month

Shutdown

by James Tabor

Hi, Instead of posting things on chat and coming across as flames, so here we go. I added excerpts and opt edited from "Inside Microsoft Windows 2000". http://www.reactos.org/wiki/index.php/ShutdownProcess "Csrss in turn impersonates the caller and sends a Window message to a hidden window owned by Winlogon telling it to perform a system shutdown." The best way I could do this at one time, take for example. Find the program ntpmon.exe run it and open a console window. Type ctrl-C or break at the same time watch ntpmon. You will see cmd clone itself. One step further in the console window run listdlls.exe and watch ntpmon. You will see "impersonation", threads created under processes to access each process context. Cool right! I could have written this for lib/rtl/dbgbuffer.c but I thought KJK_Hyperions way was cooler and used NtReadVirtualMemory to peek at process context instead. I did have a note in lib/rtl/dbgbuffer.c alluded to this process but one of "the coders that knows more" removed it. So, impersonates; user access rights, its a thread in Csrss created under the user program process context, it finds the parent and sends the shutdown message. I guess, James

18 years, 1 month

serial.sys

by Rick Parrish

This email is directed mostly to Herve and anyone else familiar with SERIAL.SYS and how it works. Two years ago I implemented a small (5 kilobyte) WDM driver that "wrapped" SERIAL.SYS. It's an ugly hack that (almost) works. What I did was "hook" the interrupt service routine by directly modifying the IDT. It works most of the time but occassionally I get BSOD (and I don't know why). The driver installed ISR reads the MSR (modem status register) of the UART. The RDTSC instruction is used to generate a timestamp of when the MSR changed. Both pieces of data are stored in a FIFO - on every interrupt. A user mode program can later retrieve the information at regular time intervals. Hint: using the CTS, DCD, and DSR pins on a standard RS232 port, you can create a Poor Man's 3 Channel Logic Analyzer. Other applications include packet radio interface for amateur radio. What I'd like to do is merge the functionality directly into SERIAL.SYS (eg. work with the OS instead of around it). The extra functionality would be exposed through IOCTL or some other means but would not break ordinary serial COMM functionality. Disclaimer: I'm not a veteran author of kernel mode drivers. This is a relatively obscure application so if you want to reply off-list, that's perfectly fine by me. Here are my questions: 1. how robust is the current SERIAL.SYS driver (I see a few "FIXME"s in the comments) ? 2. does ReactOS support or require code-signing of drivers? (probably not yet) 3. Can I run the "Genuine" Reactos SERIAL.SYS on "Genuine" Windows 2K/XP? I think so (setting WFP aside). 4. is anyone in the ReactOS community interested in such a driver extension as described above? (probably not) Also, if anyone would like to see the logic analyzer program and related driver - please send me an email. Regards, Rick

18 years, 1 month

Re: [ros-dev] [ros-diffs] [gedmurphy] 23696: add an 'uptime' command. Available in either Windows or Linux output. (defaulted to Windows)

by Michele Cicciotti [Khamsa S.A.]

Alex Ionescu wrote: > Please don't add 3rd-party utilities to the tree. Such applications need to go in ros-apps. Base is only for BASE applications. "uptime" isn't. > besides, we already have one. I wrote it. It's called tickcount

18 years, 1 month

Re: [ros-dev] [ros-diffs] [gedmurphy] 23696: add an 'uptime' command. Available in either Windows or Linux output. (defaulted to Windows)

by Alex Ionescu

gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Fri Aug 25 04:33:27 2006 > New Revision: 23696 > > URL: http://svn.reactos.org/svn/reactos?rev=23696&view=rev > Log: > add an 'uptime' command. > Available in either Windows or Linux output. (defaulted to Windows) > Please don't add 3rd-party utilities to the tree. Such applications need to go in ros-apps. Base is only for BASE applications. "uptime" isn't. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 1 month

Network card crash with Mozilla and Firefox.

by James Tabor

Hi, I forgot to leave this posted last thursday, @ revision 23605. sorry, James work/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0xA256B780) Packet (0xA256B784) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address: 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/miniport.c:808)(MiniportDpc) back from miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355370). (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x813553B8). (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/memory.c:39)(NdisAllocateMemoryWithTag) Called. (drivers/network/ndis/ndis/miniport.c:311)(MiniIndicateReceivePacket) indicating a 60-byte packet (drivers/network/ndis/ndis/miniport.c:237)(MiniIndicateData) XXX (875d1862) 8134bf60 0 8228c1f0 e 8228c1fe 2e 2e XXX (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0xA1745B58) Packet (0xA1745B5C) PoolHandle (0x81355000). (ntoskrnl/ex/work.c:658) Requesting a new thread. CurrentCount: 0. MaxCount: 1 (drivers/network/ndis/ndis/miniport.c:257)(MiniIndicateData) Leaving. (drivers/network/ndis/ndis/memory.c:121)(NdisFreeMemory) Called. (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (ntoskrnl/ex/work.c:658) Requesting a new thread. CurrentCount: 0. MaxCount: 1 (ntoskrnl/ex/work.c:397) EX: Creating new dynamic thread as requested (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (ntoskrnl/ex/work.c:397) EX: Creating new dynamic thread as requested (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355010). (driver(drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D7D9C8) Packet (0x80D7D9CC) PoolHandle (s/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355058).x81355000). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D7D964) Packet (0x80D7D968) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address : 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/miniport.c:808)(MiniportDpc) back from miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355010). (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355058). (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355448). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D869C8) Packet (0x80D869CC) PoolHandle (0x81355000). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D86964) Packet (0x80D86968) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address: 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (ntoskrnl/mm/mm.c:221) Page fault at high IRQL was 2, address c000009a Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0xC000009A could not be written: Page not present. kdb:> bt Eip: <fetnd5.sys:1b8e> Frames: <fetnd5.sys:2aba> <fetnd5.sys:26da> <ndis.sys:77bc (drivers/network/ndis/ndis/miniport.c:805 (MiniportDpc))> <ntoskrnl.exe:2628 (ntoskrnl/ke/dpc.c:558 (KiDispatchInterrupt))> <80550e52> <80550ece> <805511e3> <tcpip.sys:81bd (drivers/network/tcpip/tcpip/lock.c:27 (TcpipReleaseSpinLock))> <tcpip.sys:1f9f (drivers/network/tcpip/datalink/lan.c:688 (LANTransmit))> <tcpip.sys:11fc5 (lib/drivers/ip/network/neighbor.c:46 (NBSendPackets))> <tcpip.sys:12b6f (lib/drivers/ip/network/neighbor.c:467 (NBQueuePacket))> <tcpip.sys:14f0d (lib/drivers/ip/network/transmit.c:71 (IPSendFragment))> <tcpip.sys:15356 (lib/drivers/ip/network/transmit.c:212 (SendFragments))> <tcpip.sys:15573 (lib/drivers/ip/network/transmit.c:254 (IPSendDatagram))> <tcpip.sys:14633 (lib/drivers/ip/transport/tcp/event.c:107 (TCPPacketSend))> <tcpip.sys:231f5 (lib/drivers/oskittcp/oskittcp/ip_output.c:524 (ip_output))> <tcpip.sys:1b5be (lib/drivers/oskittcp/oskittcp/tcp_output.c:735 (tcp_output))> <tcpip.sys:1a544 (lib/drivers/oskittcp/oskittcp/tcp_input.c:1663 (tcp_input))> <tcpip.sys:16354 (lib/drivers/oskittcp/oskittcp/interface.c:426 (OskitTCPReceiveDatagram))> <tcpip.sys:d7e2 (lib/drivers/ip/transport/tcp/tcp.c:327 (TCPReceive))> <tcpip.sys:a467 (include/ddk/ndis.h:157 (IPDispatchProtocol))> --- Press q to abort, any other key to continue --- <tcpip.sys:c6c4 (lib/drivers/ip/network/receive.c:469 (ProcessFragment))> <tcpip.sys:c967 (lib/drivers/ip/network/receive.c:565 (IPv4Receive))> <tcpip.sys:c9d6 (lib/drivers/ip/network/receive.c:608 (IPReceive))> <tcpip.sys:1605 (drivers/network/tcpip/datalink/lan.c:331 (LanReceiveWorker))> <tcpip.sys:25d60 (lib/drivers/chew/workqueue.c:56 (ChewWorkItem))> <ntoskrnl.exe:305d0 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:1dee8 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:62637 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:6b6f5 (ntoskrnl/ke/i386/ctxswitch.S:82 (KiThreadStartup))> kdb:>

18 years, 1 month

Summer of Code, status report

by Michele Cicciotti [Khamsa S.A.]

And so this year's Summer of Code is over. I am moderately optimistic about the outcome, but it could have gone much better... What's there: * the porting! I gutted rdesktop and isolated the smallest subset possible required for the protocol and nothing else. Then I made it re-entrant, as rdesktop was affected by the "accumulate and fire" anti-pattern, setting function arguments in global variables and preventing multiple instances of the library from running (a no-no for an ActiveX control, and for any library in general. Then, again, rdesktop was no library in the first place) * the porting, part 2. I implemented all the "orders" supported by the RDP protocol in terms of Win32 GDI, meaning the display is fully functional (barring the occasional artifact) * the porting, part 3. I implemented mouse/keyboard input. You can interact with your session. That's it. Basically, the RDP client just... works. That's it * the ActiveX control itself, in its glorious hundreds of methods and properties. By far the hardest part of the project. Friends don't let friends code ActiveX controls without ATL! What's not there: * the effort in learning as quickly as possible the most fucked up component model in the history of computing had by far the largest impact on the project, meaning in practice I was stopped halfway through integrating the *actual* code with the extensive ActiveX dressing. In other words, the code currently in the repository is non-functional. Go back a couple of revisions to skip the ugly ActiveX meatworks and see the working proof-of-concept. My biggest mistake was assuming I could tame the ActiveX beast only armed with a stick * some useless ActiveX glue that does not pertain to the kind of control the RDP client is, but has to be there nonetheless * the redirectors were not ported, and no support yet for virtual channel plug-in DLLs. Not a giant effort, though * the mstsc.exe shell Miscellaneous issues: dependency on OpenSSL. This will be hard to eradicate. CryptoAPI isn't an option, beacuse it was designed primarily for PKI, not random arbitrary encryption protocols. In particular, the following limitations make it unfit for use in the RDP protocol: * each provider only supports a single size for RC4 keys, either 40 or 128 bits. Not a major obstacle, but it gets worse * it cannot import plaintext RC4 session keys, at least not without a convoluted workaround (see <http://support.microsoft.com/kb/228786/en-us>). Still not major, but a little bit worse * it cannot perform RSA encryption without padding, required for the session key exchange protocol. CryptoAPI will always pad the cipher with PKCS #1 padding, limiting the plaintext to 11 bytes less than the key size. No workaround for this Best solution: reimplement the internal cryptography library used by Microsoft (the library exported as SystemFunctionXXX from advapi32.dll), which is what the original client uses Afterword: I'll certainly continue working on this. It felt extremely irritating to be so close to a working implementation and just burning time on a huge glue layer probably larger than the implementation itself. Watch this space for future news on my progress! (not in the immediate future though. I'm still recovering from the trauma of hand-coding an ActiveX control)

18 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev