- Ros-dev - ReactOS.org

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.

19 years

1
0
0 0

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

19 years

2
1
0 0

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

19 years

3
3
0 0

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

19 years

1
0
0 0

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

19 years

3
4
0 0

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

19 years

1
0
0 0

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)

19 years

1
0
0 0

GSoC Status Report

by Pablo

Hi, Google Summer of Code is is ending, and I'm going to report what I've been doing this last months. (yes I know that is my first status report when all is ending, but as I said to Thomas, i'm little shamed of my English :) but it's my mistake. By the other hand I joined many times on IRC with my mentor, Thomas Weidenmüller, and he teach me, many basic concept about ReactOS and integration between kernel and user mode spaces, he's always been nice and helpful with me, and always ask at my questions, and it's was very appreciated by me. With time I'm learning more and more about ReactOS internal implementations, and the start was a little slow. My coding state was sometimes exceeded by external situations, like Alex's ob* implementation, I wrongly make an update of my tree, and many changes magically coming into my code! then sometimes of no-booting-trunk that annoying someone! then come some cm* issues, well, a joyride of code! well, here is a resume of what I've been doing (and done) in the clipboard: *Implemented the APIs to put and get data into clipboard in this formats: Ansi Text, Oem Text, Unicode Text, Bitmap, DIB and Application specific clipboard formats, with the ability of register new formats. Graphic formats still need some testing. *Implement the capability of Delayed Render Format, is like put a specific format type, but not the data, and then, when some application request this data, in this format, the requested application must render it and put it into the clipboard. * Implement the implicit data format conversions between some types of format, in example: if you put an Ansi text, then you can request a Unicode Text, and the same for graphics. * All the function to work with Formats, (not its data), like registering, counting, enumerating, getting the priority formats, query availability, etc. * Implement the window chaining, of the clipboard's viewers (when a format is getting into clipboard all this windows are notified), add, remove, query windows, in the chain. * Appropriate handling of owner window, that rules the clipboard! *Of course, open, close and empty clipboard functions. *Added many test cases to the regression tests of user32, clipboard area. and More: I worked very hard on shell32.dll to make work cut/copy & paste capabilities on shellfolders of explorer. (not on desktop ): now working! This implementation is indirectly related to clipboard, but is directly related to final user! Now you can copy a file and then paste its link, and create shortcuts of any file (even in desktop, but not from desktop), I don't test make a shortcut of a shortcut! I'm work now on that. This time I worked too on many small patches that I put in bugzilla. Some others patches still here on my working copy. Sorry again for my no communication. If someone want to ask me about this or else, my nick in IRC is P43LOk, I'm going there very often. Best Regards, Pablo

19 years

1
0
0 0

ReactOS 0.3.0 RC2 Released

by Brandon Turner

I just released 0.3.0 RC2 to SourceForge and you can download it here: https://sourceforge.net/project/showfiles.php?group_id=6553&package_id=6629 This is our final sanity check before we release the final version. I am planing on uploading the release to to SourceForge on Wednesday night and then Thursday morning will be our official release time. Frik or MGW, will you be able to update the home page on Thursday morning? If not let me know and I can do it if we have a graphic ready. Note to all devs and contributors: We need a change log! I have made a svn log for all commits. It can be found at http://www.brandonturner.org/log.txt . Please let me know if you are going to do your own change log, otherwise I will do a change log for everyone else on Tuesday night, but no promises I will find everything you did. -- Brandon Turner ReactOS Release Engineer Blog: http://www.amateurgramming.com

19 years

7
10
0 0

[Fwd: Indonesian translation for ReactOS]

by Alex Ionescu

-- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

19 years

3
2
0 0

Request: SLOC stats of ReactOS 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0

by Klemens Friedl

Request: SLOC stats of ReactOS 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0 SLOC = source lines of code I would like to compose some neat statistics about ReactOS (for reactos.org) and I need help of people with unix compatible operating systems (because the only reasonable SLOC scan tool "sloccount") isn't available for Win32. If you get it working with Cygwin, CoLinux, etc. under Win32 it's fine too. sloccount: http://www.dwheeler.com/sloccount/ Please scan the source code (export it from svn; don't scan svn dir directly) of 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0 (current 0.3.0 rc3 branch). General information about SLOC: http://en.wikipedia.org/wiki/Source_lines_of_code If you don't want to hassle with svn, then download the following source code archives from sourceforge: 0.0.1.0: http://prdownloads.sourceforge.net/reactos/0010_source.zip 0.1.0: http://prdownloads.sourceforge.net/reactos/0100_source.zip 0.2.0: http://prdownloads.sourceforge.net/reactos/reactos-0.2.0-source.zip 0.3.0 (rc2): http://prdownloads.sourceforge.net/reactos/reactos0.3.0-RC2-src.zip If you think you found a better tool to count SLOC's then share the results too. And please share the results from "sloccount", even someone else already posted stats about the same version. There might be differences in the results and it's better to have more stats of the same version to verify and use average values. Please scan the "reactos" dir (and all it's sub-dirs) and add specific of which version of ReactOS & sloccount you have used to gather the stats. Thanks for your help. Klemens

19 years

4
5
0 0

About coding style / GNU indent

by Aleksey Bragin

Hello, I've experimented a little with the DrFred's GNU indent settings, they were good, however I advanced them more and found out almost perfect set of settings which suits our proposed/official coding style (the only debateble part was using TAB vs. SPACEs, but for some areas like ntoskrnl TAB-based indentind is de-facto not used at all). For further info / remaining problems, look to the following URL: http://www.reactos.org/wiki/index.php/GNU_Indent WBR, Aleksey Bragin.

19 years

1
0
0 0

ReactOS cmd.exe

by Klemens Friedl

If someone has some freetime and want improve cmd.exe, the following website has listed a lof of undocumented commands, flags, tricks, etc. of several win version: http://www.robvanderwoude.com/ (click on batch files in the navigation bar)

19 years

2
1
0 0

RC3 What?!?

by Brandon Turner

We are actually going to have an RC3 this release because we got 2 last minute bug fixes and will be adding a wallpaper to the bootcd. It will go out Sunday Aug 18th. This should be the last RC before final. Thanks for you time and understanding! -- Brandon Turner ReactOS Release Engineer Blog: http://www.amateurgramming.com

19 years

1
0
0 0

[ros-kernel] How do device drivers fit into the project goal

by James Tabor

-------- Original Message -------- Subject: [ros-kernel] How do device drivers fit into the project goal Resent-Date: Fri, 16 Oct 1998 22:08:57 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Fri, 16 Oct 1998 20:05:44 -0700 From: rex <rex(a)lvcablemodem.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com> In a recent response to a message I posted, dennis mentioned that the goal of the project is to build an OS that gives the user a Win32 compatable environment. He also stated in that message that the guts will not necessarily be the same as WinNT or Win98, insted that might actually work correctly. A while ago a similar discussion came up and it was agreed (or so I remember) that we would try to remain compatable with device drivers so we don't have to reinvent them all. I was reading a status message from Connor and I realized that he has some interesting ideas for building a high performance video subsystem, but my brief glance at his description left me thinking that legacy drivers probably will not plug into it. This does not bother me, however we should discuss this and decide on a clear goal for ReactOS regarding driver compatability. It's my impression that the following statement sums up the goal of the project: ReactOS will be a freely distributable operating system capable of running Win32 applications, that is Win98 and WinNT applications. The main project page states the following: "ReactOS will be a free operating system that can run software and drivers compatible with Windows NT." I hope I'm not stepping on any toes, but I think before Conner builds a fast but not necessarily compatable video system, or Arindam builds a compatable but not necessarily most effecient network subsystem, perhaps we should reaffirm the goal so noone takes the wrong path. Personally, I vote for driver compatability. I think there is enough room internally for improvement over the MS design (though I haven't actually seen it) that we dont need to change the structure of the driver interface. Of course, I haven't yet seen the Network or Video driver interface other than block diagrams and broad overviews. Rex.

19 years

4
4
0 0

[ros-kernel] Re: How do device drivers fit into the project goal

by James Tabor

-------- Original Message -------- Subject: [ros-kernel] Re: How do device drivers fit into the project goal Resent-Date: Sat, 17 Oct 1998 03:03:33 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Sat, 17 Oct 1998 01:03:07 -0700 (PDT) From: Jason Filby <jasonfilby(a)yahoo.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com Hi, ---rex <rex(a)lvcablemodem.com> wrote: >I hope I'm not stepping on any toes, but I think >before Conner builds a fast but not necessarily >compatable video system, or Arindam builds a >compatable but not necessarily most effecient >network subsystem, perhaps we should reaffirm >the goal so noone takes the wrong path. The goal states that WinNT drivers must be compatible with ReactOS. I should be able to take a graphics or network driver that was written for NT and use it with ReactOS. Compatibility is extremely important. That said, ReactOS drivers don't necessarily have to run under NT. See what I'm saying here? We MUST provide the mechanisms for NT drivers to work - but CAN also add additional mechanisms that only ReactOS drivers use so that they perform better. Personally, I'd prefer that the mechanisms that allow NT drivers to run 100% are implemented first -- then we can add our own mechanisms that only drivers written to take advantage of them use. But you don't necessarily have to go in that order. At the end of the day, we'll run drivers for NT perfectly (1st priority) and drivers for ReactOS even better (2nd priority). I don't know if I explain this all clearly enough -- so, if not, just tell me. - Jason Filby _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

19 years, 1 month

1
0
0 0

mkhive changes

by Aleksey Bragin

Hi, currently head has problems with the registry due to changes in structures which were not replicated in mkhive tool (thanks to a "good" code duplication between them). I'm now porting mkhive to use cmlib's headers so that there is no need to keep the same structure in a few places and forget to change it everywhere. It will be commited in a few hours when I get back. WBR, Aleksey Bragin.

19 years, 1 month

1
1
0 0

OpenOffice.org 2.0.3

by David Ianno

I tried to install OpenOffice.org 2.0.3 using r23543. The installation stopped because of an ASSERT in cmlib. nl\ps\thread.c:503) FIX PS SDs!! (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase\Content Type\application/vnd.stardivision.writer"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase\Content Type"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME"!) Assertion 'CellIndex != HCELL_NULL' failed at lib\cmlib\hivecell.c line 19 Entered debugger on embedded INT3 at 0x0008:0x8007fda0. kdb:> cont Assertion 'CellBlock < RegistryHive->Storage[CellType].BlockListSize' failed at lib\cmlib\hivecell.c line 29 Entered debugger on embedded INT3 at 0x0008:0x8007fda0. kdb:> cont Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x003FFFFC could not be read: Page not present. kdb:> cont KeBugCheckWithTf at ntoskrnl\ke\i386\exp.c:1241 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 Technical information: *** STOP: 0x0000001E (0xC0000005,0x8007F050,0x00000000,0x003FFFFC) *** ntoskrnl.exe - Address 0x8007F050 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:8007f050 <ntoskrnl.exe:7f050 (lib/cmlib/hivecell.c:30 (HvGetCell))> cr2 3ffffc cr3 299e000 Proc: 810401e8 Pid: 118 <msiexec.exe> Thrd: 820cb468 Tid: 134 DS 23 ES 23 FS 30 GS 0 EAX: 00000000 EBX: 8d22bd40 ECX: 00000032 EDX: 00000000 EBP: 9e879c98 ESI: 0007ffff ESP: 9e879c14 EDI: 8d22bcd8 EFLAGS: 00010286 kESP 9e879c14 kernel stack base 9e877000 Frames: <ntoskrnl.exe:fe79 (ntoskrnl/cm/regfile.c:1571 (CmiDeleteValueFromKey))> <ntoskrnl.exe:d94e (ntoskrnl/cm/ntfunc.c:2157 (NtDeleteValueKey))> <ntoskrnl.exe:6ec74 (ntoskrnl\ke\i386\trap.s:306 (KiFastCallEntry))> <advapi32.dll:88c0 (dll/win32/advapi32/reg/reg.c:2109 (RegDeleteValueA))> Entered debugger on embedded INT3 at 0x0008:0x8007fda6. kdb:> cont --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta.

19 years, 1 month

2
3
0 0

ReactOS 0.3.0 RC2 problems

by Andrew Smith

Hi, I'm not sure if this is the correct place to post this, if it's not I'm sorry, just let me know where I should post things like this to. Right then, I downloaded the VMware RC2 image and loaded it up in VMware player. Booted fine (and i like the boot time ;-) and thought that I'd try the networking out. I was able to open up ibrowser and download the mozilla control fine and browse like that to a few sites (getfirefox.com, sf.net, 7-zip.org and guildwars.com). I wanted to try out Guild Wars (a DirectX MMORPG, very ambitious I know). I was able to go to the site fine and download the client, however, when I went to download 7-zip I was given a BSoD. I restarted and tried to download firefox instead and install that. The download was fine however part way through the install it just dropped out. I tried again and the same thing happened. I then noticed the 'Get Firefox' link in the start menu, which didn't do anything (just opened the download window and sat there). I looked around the C: drive and noticed that Firefox had installed the exe so I tried to run it but didn't get anything. I closed the 'Get Firefox' window and tried that again, same problem as before, this time though it wouldn't close. Opened up task manager and saw 2 firefox.exe running so I tried to kill them, this didn't worked. Tried to kill 'Get Firefox' process and that worked, but then a few seconds after that I got another BSoD. I've attached the vmware.log in case it's any use. The debug.txt file is empty for some reason, so I've not attached that. I'm going to try a few more things and I'll let you know what happens. If this kind of feedback isn't useful let me know, or let me know where to post it so it can become useful :-) -- Andy Smith - Def since birth

19 years, 1 month

1
0
0 0

[ros-diffs] [hpoussin] 23540: Add code to start the screensaver from winlogon

by James Tabor

Hi, It's worse! > This code should replace the existing one in win32k/csrss, but is not activated (yet) due to some bugs: > - Calling SetWindowsHookEx with WH_KEYBOARD_LL gives a BSOD when pressing a key Not sure,,, The hook code is a Wineie/GvG/w3seek hod podge thingy. > - Time field in PKBDLLHOOKSTRUCT/PMSLLHOOKSTRUCT should be in milliseconds > - Screen saver parameters can't be retrieved with SystemParametersInfoW > - Probably others... In ntuser/message.c & desktop.c, I noticed that the switch code uses a static PW_O InputDesktop. This is used in message.c when looking for broadcasting,, etc. It's indirectly called by IntGetDesktopWindow which returns the active desktop that is stored in InputDesktop. SO,,,,, multi desktops w/o a common root message hook?,,,,,, > > Plus a few less important ones: > - When sending a message with HWND_BROADCAST, the invisible SAS window doesn't get the message In ntuser/message.c, co_IntDoSendMessage doesn't support recursive entry for HWND_BROADCAST. A good example for doing this is UserPostMessage. If it does, I did not see yet. > - When calling (NtUser)SystemParametersInfo, WM_SETTINGSCHANGE message is not sent > - desk.cpl doesn't save (some) screensaver parameters to registry > SendNotifyMessage is UNIMPLEMENTED! Oh the Shock of seeing that! 8^O !NOOOOOOO! Okay, James

19 years, 1 month

1
1
0 0

svcctl.idl: Why "Scmr"-prefix?

by Elrond

Hi, I was looking at svcctl.idl in ros. I wonder, where the "Scmr"-prefix comes from? googling for say "ScmrCloseServiceHandle" gives only results from reactos, nothing else. "CloseServiceHandle" gives lots of results, of course. Was the prefix choosen arbitrarily and could have well been "Ros" instead? Elrond

19 years, 1 month

4
6
0 0

(no subject)

by Alex Ionescu

-- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

19 years, 1 month

1
1
0 0

2nd stage unattend setup - solution for locale setting

by Aleksey Bragin

Hello, after just a bit of searching I could find this: http://blogs.msdn.com/michkap/archive/2006/03/10/548670.aspx http://blogs.msdn.com/michkap/archive/2006/02/23/538455.aspx So instead of creating some weird function export, duplicating code or even creating a whole locality static lib, we can just use that compatible /F:unattend.inf switch! Also, it looks like we use exported func "LocalePageProc@16", which looks like a hack too. WBR, Aleksey Bragin.

19 years, 1 month

1
0
0 0

Big Bug in CreateWindowEx

by James Tabor

Hi, I guess Hervé has found something similar. We can not create a desktop window in createwindowex. I've looked at it again and at it's current state it would be imposable to do w/o some rewriting (already started). We need to fix this Atom issue I'm pushing! With a common atom we can fix this message problem. Setup the children so they can talk to each other. So far, we have four desktops w/o a root. Non of them can talk to each other. I can't see it! If this can be fixed, I bet things will magically start working. Well, look at this, it's from wine, I think they got it. #define DESKTOP_CLASS_ATOM MAKEINTATOMW(32769) /* create the desktop window */ hwnd = CreateWindowExW( 0, DESKTOP_CLASS_ATOM, NULL, WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CLIPCHILDREN, 0, 0, width, height, 0, 0, 0, NULL ); if (hwnd == GetDesktopWindow()) { SetWindowLongPtrW( hwnd, GWLP_WNDPROC, (LONG_PTR)desktop_wnd_proc ); SendMessageW( hwnd, WM_SETICON, ICON_BIG, (LPARAM)LoadIconW( 0, MAKEINTRESOURCEW(OIC_WINLOGO))); SetWindowTextW( hwnd, desktop_nameW ); SystemParametersInfoA( SPI_SETDESKPATTERN, -1, NULL, FALSE ); SetDeskWallPaper( (LPSTR)-1 ); <snip> LiteStep and DarkStep, look about the same thing except for the atom. We dont need much of this but the process looks sound. B^| James

19 years, 1 month

1
0
0 0

Problem drawing the desktop in the updated color

by Timo Kreuzer

Hi, First, this is going to be a long post, sorry ;-) You might have noticed, that I have been working on the desk.cpl appearance tab, wich is working partly. Here's the first version: http://www.reactos.org/bugzilla/show_bug.cgi?id=1732 Some things still don't work. For example the desktop doesn't get repainted in the new color. > ------- /Comment #5 > <http://www.reactos.org/bugzilla/show_bug.cgi?id=1732#c5> >From > jimtabor 2006-08-05 04:46:36 CET / [reply > <http://www.reactos.org/bugzilla/show_bug.cgi?id=1732#add_comment>] > ------- > Hi, > You can use WM_SYSCOLORCHANGE in the desktop proc if it is used, should be!, > user32/misc/desktop.c; > > static > LRESULT > WINAPI > DesktopWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) > { > DPRINT1("Desktop Class Atom!\n"); > switch(message) > { > case WM_NCCREATE: > return TRUE; > > case WM_CREATE: > /* when I spy I see notify */ > SendNotifyMessageW( hwnd, WM_SYSCOLORCHANGE , 0, 0 ); > break; > > case WM_SYSCOLORCHANGE: > /* update everything, well in theory anyway */ > RedrawWindow( hwnd, NULL, 0, RDW_INVALIDATE | RDW_ERASE | > RDW_ALLCHILDREN ); > break; > > default: > return DefWindowProcW(hwnd,message,wParam,lParam); > } > return 0; /* all other messages are ignored */ > } > > Its crude, I'm not sure if it will compile, its off the top of my head ATM. > 8^D > Thanks, > James > Thanks for helping, James. I tried it, but it doesn't work. 1.) Sending WM_SYSCOLORCHANGE on WM_CREATE will probably do nothing, because the desktop has just been created with the initial SysColors, no need to update them. 2.) RedrawWindow calls NtUserRedrawWindow wich calls co_UserRedrawWindow wich calls co_IntPaintWindows wich sends a WM_PAINT message to the desktop window. WM_PAINT is then passed to DefWindowProc and passed on to User32DefWindowProc wich does only repaint the icon as it seems. So WM_PAINT must be evaluated in DesktopWndProc. I tried the following: > case WM_PAINT: > { > PAINTSTRUCT ps; > HDC hdc = BeginPaint(hwnd, &ps); > PaintDesktop(hdc); > EndPaint(hwnd, &ps); > } PaintDesktop calls NtUserPaintDesktop, wich then paints the desktop. I have also replaced DesktopBrush = (HBRUSH)UserGetClassLongPtr(WndDesktop->Class, GCL_HBRBACKGROUND, FALSE); with DesktopBrush = IntGetSysColorBrush(COLOR_BACKGROUND); But the desktop is still painted in the original color, whereas the icon text is in the color I have set in the registry. I played a little around with the code in NtUserPaintDesktop. I added the following code before the desktop background is painted: > if (IntGetSysColor(COLOR_BACKGROUND) == 0) // This is true after > SysColors are loaded from Registry > { > DesktopBrush = IntGetSysColorBrush(COLOR_ACTIVECAPTION); > } And suddenly the desktop is painted in COLOR_ACTIVECAPTION. This is strange, because I also added CreateSysColorObjects(); at the beginning of NtUserPaintDesktop. Anybody any idea?

19 years, 1 month

4
8
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