- Ros-dev - ReactOS.org

Committing to trunk
by Aleksey Bragin 28 Jul '09

28 Jul '09

Hello, our debug buildslave is currently offline, I'd like to ask developers to abstain from committing to trunk till it comes back online (hopefully we can thing something up, have a spare buildslave, turn release buildslave into a debug one or something). Otherwise we may miss potential regressions. Thanks for understanding, Aleksey Bragin.

1 1

[BUG] Utterly incorrect implementation of input device coordinates.
by codeforfood＠pulseforce.com 27 Jul '09

27 Jul '09

Here's the information required to patch the incorrect implementation. Abstract: - SendInput()/NtUserSendInput() broken: --- Relative hardware mouse input "working", but not well implemented due to lack of modifying the travel distance using cursor acceleration and movement speeds (I've provided info on this as well below), input-virtual vs screen-real coordinates (even in the relative moves), etc. The two coordinate spaces are not the same thing! --- Absolute hardware mouse input broken (used by things like touchscreens), by a complete misunderstanding of how the virtual input device coordinate space works (it's NOT in ANY way a 1:1 map that's translatable to the screen, but the function uses it this way everywhere!) read below for full info since this is the serious problem. - SetCursorPos() broken (should NOT be using SendInput() since that's pointless and ineffective and is meant for the hardware input queue, we already have the desired coordinates and should move the cursor directly; and even its use of SendInput() is incorrect since it should FIRST convert the desired SCREEN coordinates to absolute-INPUT-coordinate-space), BUT since it's using the broken SendInput() (which currently doesn't know that absolute input coordinates have NOTHING to do with screen coordinates) it works correctly and will place cursors at the right location. This will have to be changed when SendInput() is patched; preferrably to a direct cursor update (elaborated in the recap below, before the log), rather than the current indirect/slow approach which places a message in the serial (as in serial-processing, first-come-first-serve) mouse-input-translation queue. So to recap: - Need to improve relative movement (to handle acceleration and mouse speed modifiers) - Need to change the code everywhere where you've been thinking that input coordinates are the same as screen coordinates (most likely only within SetCursorPos(), and SendInput()/NtUserSendInput()) - Absolute cursor placement inside SendInput() needs to be rewritten to convert absolute input-space coordinates to absolute screen-space coordinates (quite an easy change) using the algorithm I provide below, which is what Windows uses internally. - SetCursorPos() needs to COMPLETELY stop using SendInput() and instead manipulate the cursor X/Y struct directly, or equivalent methods, instead of injecting itself into the input queue. Alternatively, if it keeps using the input queue, it needs a reverse-algorithm to turn the desired screen-coordinates into virtual inputspace-coordinates, such as int mouseinput_abs_x_or_y_pos = (((65536 * screen_x_or_y_pos) / screen_width_or_height) + 1). The +1 is necessary for proper rounding. However, I see no reason to use the input queue within this function as that involves much more work than simply writing the cursor's location directly (which is what SendInput EVENTUALLY gets around to doing after LOTS of processing, and saving on cycles/jumps/calls is GOOD ;)). All details on how to fix these things are in the below log. Let me know if there's any questions. Log (most unrelated discussions/events snipped and long breaks between explaining different details have been separated with "..."): 19:56 Yewbacca . I am sure you've implemented SetCursorPos() incorrectly. Checking your source code for it at cursor.c:280. This function is SUPPOSED to take a SCREEN X/Y coordinate (ie X=1400, Y=800 on a 1440x900 screen, and then moves the cursor location directly, without emulating mouse movement. 19:57 Yewbacca . Instead, your version calls SendInput() with the x/y unmodified, that's awful. SendInput()'s absolute space is a virtual desktop square that stretches from 0-65535 in each direction and will not even be remotely close to what the intended destination is. 19:57 _0_ . sounds like a patch is in order Yewbacca 19:57 _0_ . :P 19:58 +encoded . Yewbacca, file bug report! 19:58 Yewbacca . _0_ Well I'd have to know how you're writing the cursor position inside NtSendUserInput etc. 19:58 Yewbacca . Or file a bug report, I'll do that. 20:01 Yewbacca . Related to this, Windows actually uses a slightly unexpected algorithm for its SendInput() absolute-mode coordinates-to-screen conversion. 20:01 Yewbacca . int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:01 Yewbacca . If you want pixel precise SendInput() that works as on windows you'd have to verify this. I'll bug report that too. 20:02 +encoded . <3 Yewbacca 20:02 Yewbacca . :) 20:02 +encoded . you can ofcourse see the source code of NtSendUserInput 20:03 Yewbacca . Yeah I was about to check that to make sure it's not already correct 20:04 +encoded . its in \subsystems\win32\win32k\ntuser\input.c 20:04 Yewbacca . Ah thanks, that saves a slow grep. 20:05 +encoded . wait opps 20:05 . garrythefish_ [n=fisher@unaffiliated/garrythefish] has joined #reactos 20:05 +encoded . oh well, nvm me 20:05 garrythefish_ . community choice award today. hope you guys win. :D 20:10 Yewbacca . Okay after brief confusion I noticed that IntMouseInput() contains the actual logic for mouse-type input to SendInput(), input.c:1081. Time to check it. ... 20:14 Yewbacca . Okay now I'm really confused. I read through IntMouseInput() from input.c:1081-1333 and unless I missed a call to a driver-coordinates-to-screen-coordinates somewhere, this function is miscoded as well. That'd mean that SetCursorPos() would work correctly since SendInput() would work incorrectly, and that normal SendInput() calls that expect a 0 to 65535 range would not work at all. 20:15 Yewbacca . It really seems to directly write the pointers for cursor X and Y with the values it has received 20:15 Yewbacca . with no conversion whatsoever 20:15 Yewbacca . even though the incoming values are in a 0 to 65535 range 20:15 Yewbacca . of that virtual space ... 20:16 Yewbacca . Basically for anyone unfamiliar with it, the driver implements a virtual space for the cursor to either move relatively within, or absolutely, to allow things like touchscreens to function easily (they'd just have to SendInput() their current position as a percentage of the 65535 range). 20:16 Yewbacca . So all incoming absolute-mode coordinates must be converted to screen coordinates, and microsoft does it with int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:17 Yewbacca . I'm going to re-read it again to see if I missed some conversion call. If not, that'll be 2 reports. Quite easy fixes luckily. 20:18 +encoded . <3 Yewbacca 20:18 Yewbacca . I think the reason you got by this far is because the HARDWARE mouse sends coordinates relatively 20:18 Yewbacca . The problem'd only appear with absolute input like touchscreens. And since SendInput()'s absolute mode is broken that means program's SetCursorPos() would work, so it's doubly broken and would only cause problems for absolute hardware-input (again, touchscreens mainly). 20:18 Yewbacca . :P 20:19 Yewbacca . Reading again 20:20 +encoded . Yewbacca, we can use someone like you who has knowledge of windows internals 20:20 Yewbacca . Maybe, right now I'm tied up with some major work :) ... 20:28 Yewbacca . Alright I've finished checking everything. IntMouseInput() stretches from input.c:1081-1333 and is the function that's called when NtUserSendInput()/SendInput() receives a mouse-type event. At line 1140 it grabs the pointer to the cursor's X/Y struct with IntGetCursorLocation(WinSta, &MousePos). Then we get to the significant errors. 20:29 Yewbacca . At lines 1146-1150 it incorrectly writes the virtual x/y of the INPUT coordinate system right into the memory holding the SCREEN x/y cursor location 20:30 Yewbacca . At lines 1151-1155 it handles relative movement but doesn't take into account cursor acceleration and movement speed (those settings we all love in the control panel->mouse), which in turn can increase the movement distance as much as 4 times the input value. 20:31 Yewbacca . Those two behaviours right there would need to be patched. The first should determine the destination on the screen through int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536. The latter should implement handling for cursor acceleration (check MSDN, it describes acceleration on SendInput()). 20:32 Yewbacca . And lastly, SetCursorPos() (forgot which file it's in) needs to *completely* skip the SendInput() baloney that it's doing right now (http://pastebin.com/d2db76985) and just directly grab the cursor X/Y pointer and update it in a simple assignment, AFTER checking that it's in range of course (otherwise clamping it to the screen). 20:33 +Lone_Rifle . Yewbacca, suggest that you subscribe to ros-dev and retype or copy-paste your findings there, it's quite a bit of text to go through in one sitting 20:33 Yewbacca . Oh yeah and if you wanna be 100% complete, also implement a check for ClipCursor() and don't allow the cursor to move outside that, no matter if it's from hardware input or SetCursorPos(). If it's outside, it should be clamped to the nearest inside value. 20:34 Yewbacca . Lone_Rifle Yeah, I agree and was going to submit it. I'll do that now. ... 20:37 Yewbacca . Acceleration is described at http://msdn.microsoft.com/en-us/library/ms646273(VS.85).aspx (info for the MOUSEINPUT struct). I'll submit this log to the mailing list. =EOF=

2 1

[ros-diffs] [ros-arm-bringup] 42250: - Fix a ridiculous copy-paste-error-while-writing-the-commit-log error. Sorry for breaking the build!
by James Tabor 27 Jul '09

27 Jul '09

Oh, okay, I'll do the same,,,,, oh,,,,,, never mind,,,,,, I do that too.

1 0

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 42220: - This is a HIGH RISK patch.
by Gabriel ilardi 26 Jul '09

26 Jul '09

Hi Everyone, I've encountered this assert after restarting in 2nd stage. Rev 42235, vbox 3.0.2, "cont" lets ros continue to 3rd stage: It's not random, I've tried three times with the same result. Best regards, Gabriel. Assertion 'EndPfn == MiGetPfnEntry(Page + 1)' failed at ntoskrnl\mm\freelist.c line 301 PuTTYEntered debugger on embedded INT3 at 0x0008:0x808c1502. kdb:> bt Eip: <NTOSKRNL.EXE:c1503 (lib\rtl\i386\debug_asm.S:33 (DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:7df7e (ntoskrnl/mm/freelist.c:306 (MiFindContiguousPages@20))> <NTOSKRNL.EXE:75ef8 (ARMÂ³::CONTMEM:156 (MiFindContiguousMemory@20))> <NTOSKRNL.EXE:75fcc (ARMÂ³::CONTMEM:232 (MiAllocateContiguousMemory@20))> <NTOSKRNL.EXE:761d0 (ARMÂ³::CONTMEM:382 (MmAllocateContiguousMemorySpecifyCache@32))> <HAL.DLL:2a72> <usbdriver.sys:1610f (drivers/usb/nt4compat/usbdriver/td.c:51 (init_td_pool))> <usbdriver.sys:162c5 (drivers/usb/nt4compat/usbdriver/td.c:266 (expand_pool_list))> <usbdriver.sys:163da (drivers/usb/nt4compat/usbdriver/td.c:233 (init_td_pool_list))> <usbdriver.sys:100c9 (drivers/usb/nt4compat/usbdriver/uhci.c:1033 (uhci_init_sc edule))> <usbdriver.sys:10505 (drivers/usb/nt4compat/usbdriver/uhci.c:818 (uhci_alloc))> <usbdriver.sys:1076a (drivers/usb/nt4compat/usbdriver/uhci.c:659 (uhci_probe))> <usbdriver.sys:1082b (drivers/usb/nt4compat/usbdriver/uhci.c:3861 (DriverEntry@ ))> <NTOSKRNL.EXE:4a75b (ntoskrnl/io/iomgr/driver.c:1389 (IopCreateDriver@24))> <NTOSKRNL.EXE:49b4d (ntoskrnl/io/iomgr/driver.c:467 (@IopInitializeDriverModule 20))> <NTOSKRNL.EXE:4ac88 (ntoskrnl/io/iomgr/driver.c:1765 (IopLoadUnloadDriver@4))> <NTOSKRNL.EXE:4ae20 (ntoskrnl/io/iomgr/driver.c:1843 (NtLoadDriver@4))> <NTOSKRNL.EXE:b9afc (ntoskrnl\ke\i386\trap.s:244 (KiFastCallEntry))> <NTOSKRNL.EXE:be4a5 (obj-i386\ntoskrnl\ex\zw.S:929 (ZwLoadDriver))> <NTOSKRNL.EXE:4b3c2 (ntoskrnl/io/iomgr/drvrlist.c:540 (@IopInitializeSystemDriv rs@0))> <NTOSKRNL.EXE:d9948 (ntoskrnl/io/iomgr/iomgr.c:529 (IoInitSystem@4))> <NTOSKRNL.EXE:36846 (ntoskrnl/ex/init.c:1711 (Phase1InitializationDiscard@4))>- - Press q to abort, any other key to continue --- <NTOSKRNL.EXE:37567 (ntoskrnl/ex/init.c:1921 (Phase1Initialization@4))> <NTOSKRNL.EXE:af375 (ntoskrnl/ps/thread.c:158 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:b92f6 (ntoskrnl\ke\i386\ctxswitch.S:306 (KiThreadStartup@156))> kdb:> _________________________________________________________________ Condividi i tuoi ricordi online con chi vuoi tu. http://www.microsoft.com/italy/windows/windowslive/products/photos-share.as…

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 42225: - Begin using ws2help_new - I have tested this with various applications in ROS - Part 2 of 2
by Aleksey Bragin 26 Jul '09

26 Jul '09

That's a good first step into using proper winsock! WBR, Aleksey Bragin. On Jul 26, 2009, at 10:00 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Jul 26 08:00:32 2009 > New Revision: 42225 > > URL: http://svn.reactos.org/svn/reactos?rev=42225&view=rev > Log: > - Begin using ws2help_new > - I have tested this with various applications in ROS > - Part 2 of 2 > > Added: > trunk/reactos/dll/win32/ws2help/ (props changed) > - copied from r42178, trunk/reactos/dll/win32/ws2help_new/ > Removed: > trunk/reactos/dll/win32/ws2help_new/

1 0

Re: [ros-dev] [ros-diffs] [sginsberg] 42218: - Fix most freeldr compilation issues, most notably: - Define structure packing correctly for msvc. - Define Ke386EraseFlags for msvc too. - Don't return a function returning void in a function returning void. - VideoFadeIn: Don't rely on some fishy gcc extension for allocating memory from the stack -- just use the heap instead. - Winldr remains
by Timo Kreuzer 26 Jul '09

26 Jul '09

sginsberg(a)svn.reactos.org schrieb: > Author: sginsberg > Date: Sat Jul 25 22:17:23 2009 > New Revision: 42218 > > URL: http://svn.reactos.org/svn/reactos?rev=42218&view=rev > Log: > - Fix most freeldr compilation issues, most notably: > - Define structure packing correctly for msvc. > - Define Ke386EraseFlags for msvc too. > hint: __writeeflags()

1 0

IServ
by Colin Finck 23 Jul '09

23 Jul '09

Hello all, Now that also the mail migration is more or less completed, let me introduce you to IServ. IServ is a Groupware solution, which we will be using now for managing E-Mail accounts, appointments, contact data and a common FTP space. It will be available to everybody, who is qualified for a @reactos.org E-Mail address. (so basically developers with SVN access and official testers) For your @reactos.org E-Mail address, IServ provides a 250 MB mailbox. You can send and receive E-Mails over the Web interface and also over POP3, IMAP and SMTP. The Web interface also offers an option to set up a redirection if you want to use another mailbox for incoming mails. Files can be uploaded either over the Web interface or over FTP. Our IServ Web interface is available at http://iserv.reactos.org. The POP3, IMAP, SMTP and FTP services can be accessed over the same domain. If you have an @reactos.org E-Mail address, but no IServ account yet, I will shortly send you your account name along with an initial password. Your account name will also serve as your primary E-Mail address from now on. (i.e. colin.finck(a)reactos.org). Of course, your previous E-Mail aliases will continue to work. They are linked to your primary address now. As most of you used a redirection from your @reactos.org address to another mailbox, I've set up these redirections in the Web interface already. You can change them anytime. A big thanks go to Martin von Wittich and the IServ GmbH, who provided us with a site license for IServ and helped us with the setup. Also thank our translators Amine Khaldi, Gabriel Ilardi and Alex/care2debug for the French, Italian, Spanish and Russian translations of the Web interface. Best regards, Colin

2 1

Let's push winetests farther!
by Jérôme Gardou 23 Jul '09

23 Jul '09

As you all know, reactos is tested against the wine test suite. While this is a great tool, I think this is not enough to be sure that ReactOS is fully tested. I've been trying to fix some kernel32 tests. As you all know, in ReactOS it is written on top of ntdll. So I wanted to fix some tests, and then a question arose : is it that kernel32 calls ntdll the wrong way, or is it that ntdll does the wrong job? The only way to verify this would be to test kernel32.dll out of reactOS, meaning replacing the windows one with the reactos one, and run the test. To be brief : I think that a weekly "reactos dlls against windows" test would be very helpful to be sure that things are done the right way! I began with the kernel32:file winetest. I managed to not make it crash when used on winXP, the resulting patch is there : http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result of this test is attached there. As miracles happen, it also fixes some tests on ReactOS. Seems like this is a good approach. Jérôme Gardou (aka zefklop on IRC and forums)

2 3

how can I create my own code page?
by Creatxr 22 Jul '09

22 Jul '09

hi, I have a question: how can I create my own code page? where can I get the documents about it? thanks. creatxr

3 8

Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify SwitchToThread and QueueUserWorkItem - Remove unneeded InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT structure - Other small changes
by Thomas Bluemel 22 Jul '09

22 Jul '09

This explains why we are using a trampoline function and not just typecast there... Is there a reason you changed this? - Thomas dchapyshev(a)svn.reactos.org wrote: > - /* NOTE: Don't use Function directly since the callback signature > - differs. This might cause problems on certain platforms... */ > - Status = RtlQueueWorkItem(InternalWorkItemTrampoline, > - WorkItemContext,

8 11

Arwinss
by Aleksey Bragin 21 Jul '09

21 Jul '09

Hello, I've heard many question about a branch I was working on recently, arwinss, so I'd like to write some explanation (you may skip the boring history part of the message) Arwinss is a rewrite (the most advanced so far out of all previous attempts) of some parts of the Win32 subsystem, namely the USER32 and GDI32 API interfaces, along with the kernel counterpart win32k.sys. The kernel32.dll, csrss, and other parts remain in their present condition, and getting bugfixes if they come in the way of a rewrite. [History and reasoning part starts here] Why rewrite and not fix an existing Win32 subsystem? Timo, James and all our other great developers were and are doing a great work. I put a considerable amount of time in it to fix problems too. But, since our project is a volunteer-driven one, everyone has a real life, real work to do, and is not able to sit 24 hrs researching Windows internal structures, inventing new algorithms, trying out thousands of applications, not to say about graphics drivers. Time is ticking, Win32 is improving, but most annoying bugs are there for years - e.g. vmware installer hang, Firefox move the mouse bug, drawing glitches, concurrency hacks in the code ("if (!a) /* someone else was faster than us and already freed it */"), probable heap misusage (relying on our heap implementation for desktop heaps) and heap memory corruptions (I kept trying to update rtl/heaps to the newest Wine code - and always failed without any obvious reason), inability to change video mode on the fly, and the list can go on. So I thought, that something should be done with it. I would even want to trade off some speed gain in favor of stability (optimizing is an enjoyable task which could be done later). After teaming up with Stefan, we created an nwin32 branch - a totally stubbed out win23k, user32 and gdi32. They had exactly matched exports, and win32k had exactly same system calls and Windows 2003 SP1's win32k.sys. However, due to really huge amount of work, the branch didn't went farther than trying to boot Windows 2003 with it and see a few stubbed functions being called. Since then I started thinking on an alternative design of a Win32 subsystem. The idea turned out to be very simple, and is based on the following questions: - Why put so much effort into keeping the internal win32k system calls interface the same as in Windows, why put so much effort in converting to internal Windows structures, if we don't have something working first? - Why base on a stoneage Wine's code which James and Christoph occasionally sync, and all my attempts to get more people into this boring task failed? - Why not use achievements of our closest project - Wine? [End of reasoning, fancy stuff starts] The result came by itself: Try to build up a win32 subsystem based as much on Wine code as possible, and using Wine's modular design. Before publicly announcing it, I have spent a month actually trying all that stuff, and surprisingly it went very well, and a nice byproduct: support of remote sessions via X Windows. Proof of concept screenshots are here: http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg Noone has ever done this before: This is Windows 2003 inside VMware, running my custom Win32 subsystem, with an X graphics driver module, communicating with an X Server running in the host OS (Windows XP, XMing X windows server), and with ReactOS's winlogon.exe and msgina.dll (for ease of debugging and source code availability)! Let's go straight to the architecture: GDI32.dll and USER32.dll are ported Wine usermode code, with very few modifications. GDI32 and USER32 depend on two things: Gdi and User driver, and a server. Gdi and User driver is a loadable DLL, which provides an abstraction of a graphics driver in the system through a certain set of APIs. A typical example of such a driver is winex11.drv, which routes all drawing to the X Windows "client". However, this is not very useful for a local system which has a Windows NT architecture, where there is no need for remote windows displaying. The server. GDI32 and USER32 rely on the server for managing all global information. In Wine, the server is run as a usermode wineserver.exe process, which communicates with gdi32/user32 via custom RPC, and emulates quite a lof of stuff which Windows NT kernel provides by default. My decision was to convert the RPC protocol from a slow interprocess filedescriptors-based unix-specific invocations to a fast system calls to win32k module. This way, win32k contains small part (~300 kb vs 1.5Mb+) of wineserver's source code, which deals with windows, window classes, atoms, windows stations, desktops and other totally platform/implementation independent stuff. It will be reduced further, because I even ported their own object manager for win32 objects, which will be exchange to our native ntoskrnl's object manager soon, when the testing phase is over. The graphics driver, kernelmode part. As I said above, it's not very convinient to fully rely on X Windows for graphics output, because it's just not possible to run it in an NT-based OS which has no Win32 subsystem. Thus, I decided to create a totally native gdi/user driver ("winent.drv"), which would rely on win32k module to actually perform all drawing. However, compared to our current implementation, the drawing would be way more simple. For example, if currently LineTo operation in win32k involves complex PATHOBJ, maintaining graphics cursor -- all of that in a strictly windows compatible way because apps depend on it, in this alternative win32k, LineTo is a simple line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same applies to other functions, including e.g. text output, where all rendering happens using a usermode freetype.dll, and win32k just needs to display bitmap glyphs got from gdi32. Don't be scared if you don't understand all that right away. I will put up a good short summary, along with a TODO and FIXME lists, and a HACKING guide. Just a few cool facts about the new win32 subsystem: - Based on a solid, very well maintained codebase, used by commercial vendors. - Ease of updating from upstream (vendor importing) - Tested against more than 12 000 Windows applications (http:// appdb.winehq.org) - ... I think it's enough for the first introduction. WBR, Aleksey Bragin.

7 12

Second-stage keyboard bug
by Joshua Rice 21 Jul '09

21 Jul '09

Well, after some extensive revision hunting, the strange keyboard bug some people (notably VBox users and people on RHW) has been traced to r41291 (the commit that activated USB keyboard and mice support) Now, i know this isn't an "important" bug, but it's a bug none-the-less. It's up to the devs to decide what to do with it, but i thought it was worthy of looking into. Also, rather interestingly, this bug seems to be restriced to debug builds only. The (very few) release builds i have tried seem perfectly free of this bug,which seems rather stange to me. It's getting rather late now, but i'll probably try and get a debug log of r41291 sometime tommorow, so i'm sory i can't do any more tonight. Please post here with your experience of this bug! :) Yours sincerely Joshua Rice.

3 2

Status of the server migration
by Colin Finck 21 Jul '09

21 Jul '09

Hello all, As most of you probably noticed, the downtime of the website was quite long now due to the server migration. But finally, we switched the DNS records of the ReactOS domains now, so as soon as the DNS servers around the world got the update, you should see the website again at the new server. So far, the migration only affected the Website itself. Originally, we planned to do the mail system migration as well on the same day, but ran out of time due to some unforeseen problems with the Website migration. This also means that you currently cannot send any E-Mails from our web services (such as Bugzilla and phpBB). Also the mailing list archives are currently not available. Anyway, we're going to do the mail migration in the next 24 hours and target these problems by then. After all, let's come to some advantages of the upgrade: First of all, we finally upgraded to RosCMS version 4. This version was mainly developed by Danny and went through beta testing for quite some months now. Some of the new features it provides include dependency handling (so you don't need to regenerate all pages affected by your change manually), a faster generator and a much better codebase. Secondly, there should be notably performance improvements. A component that especially benefits from them is Bugzilla. Besides, we don't use a reverse-proxy for static pages any longer. This means as much as that you don't have to press Ctrl+F5 anymore to see updated web pages, which weren't noticed by our caching proxy. Just try the Website out now and if you find any problems not mentioned here, post them to this list or try to contact Danny or me on IRC directly. Best regards, Colin

1 0

Re: [ros-dev] Arwinss
by yardkarter456＠gmail.com 20 Jul '09

20 Jul '09

Hyperion is riht here; take a look at WINE code then look at ros...WINE appears much more professional than ros code. Good luck aleksey. ------Original Message------ From: KJK::Hyperion Sender: ros-dev-bounces(a)reactos.org To: ReactOS Development List ReplyTo: ReactOS Development List Subject: Re: [ros-dev] Arwinss Sent: Jul 20, 2009 8:47 AM Timo Kreuzer wrote: > Wine emulates the kernel through a server. Of cause we don't use it, > because it has a totally different design. Says who? So far, and only counting official implementations, Win32 has been implemented as: - a shared-memory user mode subsystem (Windows 95, 98) - a RPC user mode subsystem (Windows NT 3) - a kernel mode subsystem (Windows NT 4 and later) - ??? (Windows CE) > We have an NT kernel and > every kernel developer would eat me alive if I tried to put a single > line of wine code into our kernel. It's considered crap there. Wine code has to pass quality reviews and test suites. ReactOS code only has to pass the warmth-and-fuzziness test. Wine can prove their code is right, ReactOS is based on code that feels right The idea that Wine code is better than ReactOS code really needs to die. Compared to theirs, our code is sloppy, highly unprofessional and often inexplicable. We copy the form but tend to completely miss the intent. Wine development is test-driven and entirely based on intent and end results, while our development model is, apparently, to dick around in our spare time pretending we work at Microsoft > How do you expect display drivers to work at all? NT display drivers used to run in user mode with the same identical API, and probably the same ABI. I'm sure Aleksey will do just fine > More hacks on top of the huge pile of hacks? And how do you deal with > missing functionality in wine code? Shove more code in there? Or ignore > it, like if wine doesn't need it, we also don't need it? Or again fork > the code? I would sell my mother to Carthage for even a fraction of the kind of application support that Wine enjoys, thank you. My only gripe with arwinss is that Aleksey beat me to the first landmark controversial side project _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev Sent on the Sprint® Now Network from my BlackBerry®

3 3

Web and Mail system migration
by Colin Finck 19 Jul '09

19 Jul '09

Hello, We're planning to migrate the Web and Mail system to a new server and upgrade these components in the next 24 hours. This affects the whole Website at www.reactos.org plus all @reactos.org mail addresses including the mailing lists. During the migration, these services may be temporarily unavailable. The Web server migration includes upgrading the server components (e.g. Apache, MySQL, PHP) and applications (e.g. RosCMS, phpBB) to newer versions. Besides, the configuration of the server components was tuned for a better overall performance. The mail boxes, mail relays and mailing lists will be moved to a dedicated virtual machine, which will also offer a groupware system for official ReactOS developers and testers. Our plan is to do this upgrade in two big steps, namely first the Website and afterwards the mail stuff, to keep the downtime as low as possible. Minor problems are expected after the migration and will be fixed shortly. In case of major unforeseen problems, the downtime of particular components might be extended to the next 48 hours. Best regards, Colin Finck

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 42005: - Re-implement FreeLibrary (for support LOAD_LIBRARY_AS_DATAFILE) - HeapAlloc -> RtlAllocateHeap, GetProcessHeap -> RtlGetProcessHeap, HeapFree -> RtlFreeHeap, CloseHandle -> NtClose - Remove FIXME in LoadModule
by Aleksey Bragin 19 Jul '09

19 Jul '09

I think that part you removed was right, because that is ntdll's job. Wine, for historic reasons, have this code in kernel32, which is wrong. Same applies to the LoadLibrary call. WBR, Aleksey Bragin. On Jul 17, 2009, at 9:15 PM, dchapyshev(a)svn.reactos.org wrote: > Author: dchapyshev > Date: Fri Jul 17 19:15:17 2009 > New Revision: 42005 > > URL: http://svn.reactos.org/svn/reactos?rev=42005&view=rev > Log: > - Re-implement FreeLibrary (for support LOAD_LIBRARY_AS_DATAFILE) > - HeapAlloc -> RtlAllocateHeap, GetProcessHeap -> > RtlGetProcessHeap, HeapFree -> RtlFreeHeap, CloseHandle -> NtClose > - Remove FIXME in LoadModule > > Modified: > trunk/reactos/dll/win32/kernel32/misc/ldr.c

2 1

Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. "<XXX> people will eat you alive anyway so it doesn't really matter"
by Steven Edwards 18 Jul '09

18 Jul '09

On Fri, Jul 17, 2009 at 8:49 AM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Fri Jul 17 14:49:16 2009 > New Revision: 42000 > > URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev > Log: > - Create a branch for upcoming work. > > "<XXX> people will eat you alive anyway so it doesn't really matter" And your going to make children cry when people see what your doing... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

7 12

To all gurus out there
by Johannes Anderwald 18 Jul '09

18 Jul '09

Hello, It seems to have been come a ReactOS tradition, that every 2 / 3 weeks somebody turns up on the mailing list and shows her / his _unbelievable_ exciting groundbreaking phenomenal concept which will bring us to beta and save our boring sad, depressed sucicidal lifes. I do honor your efforts, but I can only speak for myself: 1) I do coding ReactOS for fun 2) I do coding ReactOS because I enjoy the challenge Please keep your ideas for yourself unless you come up with a business plan! Thanks Johannes

3 2

On the growth of the reactos project
by Samuel serapion 18 Jul '09

18 Jul '09

Hello everyone. I find myself today thinking, as I sometimes do, about the ReactOS problem. How come we are trying to clone the biggest and arguably the most popular desktop OS in the world and still have such a small community/user base? The obvious answer to this question is that ros doesn’t do what it promises. Indeed it does almost run a lot of windows applications... some of the time, but that’s not the whole picture. Let us examine the typical(in my experience) first time encounter of a random computer user with reactos. <fanboy> Look, this is a free open source windows clone called ReactOS. It has solitaire and runs firefox. Awesome, isn’t it? <noob> so does it run my windows drivers and Office and COD4 and… !? <fanboy> well…. Umm… not really. Let’s analyze what went wrong: *1) *ReactOS base distribution is fine and great, I totally like my reactos with just a cmd window and dwnl.exe; but it’s not enough, except perhaps for someone that’s *extremely* motivated to do *something*interesting with ros. ** The solution, host a reactos distribution. I think its been proven that the reactos community doesn’t want to host more 3rd party code in the repository unless it’s absolutely necessary. But that doesn’t matter. We don’t need to build firefox, mono, or anything from source. The Windows model of software distribution is binary. There doesn’t have to be an update manager, reactos is just a toy(more on that later) and it needs to look useful so that people buy into it. Maybe a nice list of packages and some checkboxes in second stage installed with a script… 2) Hardware support is very poor, on recent hardware it almost never works(wild guess 75% fail rate on modern hardware) Problems range from unsupported video cards/ros driver uses wrong/unsupported mode, wrong storage bus, random crashes from unsupported usb devices + pcmcia other similar alien buses and just random bullshit. Even if nothing manages to bring down reactos, it of course has the wrong nic card and since usb storage doesn’t exist there’s no chance to get a driver and see ros crash because of course we only support a couple of drivers. I know this can’t just be magically fixed, but we need people dedicated to do hardware testing/debugging and provide real bug reports with traces. (Suggestion: allow kdbg to take ownership of the screen/give it back, provide visual console. I don’t care if it’s not a windows feature.) 3) Who cares about all the above? Not noobs, the question they really ask is: “Does it run XYZ?” What is XYZ? Flagship applications. The ones everyone knows and uses, commercial and opensource. The following, I think, are universally recognized as very important. a) Firefox + Flash (this works most of the time… maybe god will kill that mouse move bug) b) A recent version of Microsoft Office. (2007 would be very nice) c) Latest OpenOffice( imagine a make distro command that would tell ros setup to install it automagically, wouldn’t that make testing easier… heck we could have a super build bot that wrote documents in office and compiled shit with gcc and took 3 days to run….) d) .NET Framework (atleast 2.0) (This means fixing its installer bug) e) Java runtime. (it installs and almost launches limewire!! Christ!!) f) Visual Studio 2008 (installer fails, but the c++ compiler works and the IDE almost works!!) g) Recent versions of Adobe Photoshop, Dreamweaver or Flash. Extra points: h) Msn Messenger (its expected by windows users) i) Internet Explorer (screenshots floated around at some point with IE6, I think.. or maybe it was a dream) j) Virtual Box (with its drivers!) ( I just love the vm inside vm screenshot) k) Nmap (only pcap driver is broken!) l) Silverlight (seems to install) m) Itunes (with ipod support) (please dont be pricks about this list, make a poll or something if you must, but someone has to arbitrarily set it) The sad truth is that most of these applications are known to work to a certain degree. However, good bug reports don’t even exist. I’m confident that with a bit of determined effort these apps can be made to work. Atleast we need to compile a list of whats missing in ros that is need to support these and other important applications with real bug reports, and focus the project... give defined tasks to noobs that stumble into the project but are not knowledgable enought to dive into our huge code base and decide what are the missing features/features that need work/bugs. But really, what is the point of this email… 0.4.0 will be a milestone release(nice round number), people really want these and other similar applications to work(perhaps they are the reasons people still use windows). It makes sense to try and support them and would provide a nice PR boost if 0.4.0 can honestly be said to support any or all of the above applications. ReactOS is a developer toy, a cute little model of windows that almost works. If we can at least make it work for applications that most users actually use we could maybe, oh I don’t know… spark some interest. Yes, it’s about users, which we still won’t condone being alpha and all. But users are the ones that get excited and twitter and facebook and blog about the little OS that could; Excitement that will get developers exited, that will provide testers (I’m praying for some sort of reactos error reporting service, atleast a minidump….. atleast in usermode… support event logs…. for Christ sakes our bug reports suck and they suck10x worse when they come from noobs!). Right now we are stuck in the vm, so atleast make that experience enjoyable. There’s no need to rant about explorer, I hope… We have to start thinking about 0.5 and making reactos “beta”, and I still haven’t seen plans on how that’s going to happen or what exactly that means. ReactOS development needs to speed up and get more organized….. that’s all I have to say about that…. probably not…

9 15

Open-source and newcomers
by Alex 18 Jul '09

18 Jul '09

Hello all, Open-source and newcomers ~~~~~~~~~~~~~~~~~~~~~~~~~ I've been here for 2 weeks already and I want to share some thoughts from the point of view of a newcomer. I want to make a claim as an axiom and see where it goes from there. If you don't agree with the axiom you should probably read something on ethology and group behavior. I beg you to be open-minded. -- So the axiom is: "A closed group of humans (and many other social animals) usually is emotionally and irrationally unfriendly to newcomers, due to the evolutionary baggage we all share." The group assumes a hostile position to a newcomer. Many members don't realize what is going on. It simply feels like: "I just hate this guy!" Members, of course, feel special and somewhat better, just because they are part of the group. They see newcomers as not-worthy to some extent, just because the newcomer is not in the group. They see the newcomer as an alien and – as a threat. Subconsciously. Don't bother to reply and tell me that I am not-worthy to be seen as a threat :) The general feeling is "Who the f#ck he thinks he is? He's not from our group, he is not one of us (he didn't do anything to our project yet). Blah-blah-blah... I just hate this guy!". This irrational hate is very tangible, believe me. It is very de-motivational. (And I probably shouldn't have reacted the way I did to some of it, but, hey, I am no Jesus Christ, and it's only now that I've sorted those things out for myself). But you can say: Hey, we are not hostile, because: - "I, personally, entered the group in the past and it was Ok." - "Look at that guy and that guy – we were soooo nice to them!" Let's see... When can a closed group readily accept a newcomer? When it doesn't perceive him as a threat. This means the newcomer must come in a very submissive pose and exhibit not a slightest sign of aggressive attitude. Actually, the more you cry for mercy, the more chances are that you will be easily accepted into the group. Broken leg or being a total looser may help, as compassion will start to overtake the initial hostility. The "pose" on the text-based Internet is mainly how one talks. This is an example of a submissive pose: "Oh, Great Lords, you are so cool and I am not worthy. I beg you to let me develop for ReactOS, I am not much, but I will dutifully learn from you, Wise Masters, I will catch every word you say and ignore any insults you will throw my way. I will not criticize you in any way. I will do all the shitty tasks silently and obediently for several years until I slowly climb your social ladder. I will not complain of being called stupid and not-worthy 'cause that's who I am..." And so it goes... An ass-kisser, to be short. And then the Wise Great Masters will generously allow this no-worthy worm into their Temple. This happens everywhere. Just take a closer look. -- But this constitutes a problem. The group acts as a filter that favors the wrong kind of people. Because a good developer, after all, is usually opinionated, criticizes what he thinks is wrong, doesn't like to be called stupid and be given insults and shitty tasks. He challenges existing routines and things the group got used to. He is a threat. -- Unfortunately, I do not have a solution. I just want to attract your attention to it. P.S. You may ask – didn't you think that this hostility is a consequence of you being a jerk? If being a jerk means not kissing asses of Great Masters – then yeah, I may be guilty of that. P.P.S. Before posting a reply, please take a look inside you and try to see if that reply is based on "I just hate this guy!" :) Thanks! -- Best regards, Alex mailto:care2debug@gmail.com

8 10

Very nice.
by Alex 17 Jul '09

17 Jul '09

Hello ReactOS, I am not sure if this is an appropriate place to write, but someone with the name Physicus has banned me from the #reactos channel, because he doesn't know physics and is ignorant enough. Ok, you want to stay ignorant - it's your life choice. But what right does he have to ban me from _reactos_ channel? So now I can't develop for ROS, just because one guy is closed-minded about his view of physics?!! Is it how you treat people around here? No wonder you have such a small number of developers... Human stupidity and arrogance has certainly no limits... -- Best regards, Alex mailto:care2debug@gmail.com

10 10

Re: [ros-dev] [ros-diffs] [jimtabor] 41994: - Fix fixed math, thanks Lentin.
by Timo Kreuzer 16 Jul '09

16 Jul '09

jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Thu Jul 16 21:34:42 2009 > New Revision: 41994 > > URL: http://svn.reactos.org/svn/reactos?rev=41994&view=rev > Log: > - Fix fixed math, thanks Lentin. > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/class.c > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/class.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/class.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/class.c [iso-8859-1] Thu Jul 16 21:34:42 2009 > @@ -61,7 +61,7 @@ > { > int i; > > - for ( i = 0; i < 10; i++) > + for ( i = 0; i < 11; i++) > { > if (FnidToiCls[i].FnId == FnId) > { > Isn't there a constant for this?

2 1

Re: [ros-dev] Very nice.
by WaxDragon 16 Jul '09

16 Jul '09

#reactos is not ##physics, so you weren't on topic. If this email is an example of your behaviour, I probably would have banned you too. -WD On Jul 15, 2009 7:30 PM, "Alex" <care2debug(a)gmail.com> wrote: Hello ReactOS, I am not sure if this is an appropriate place to write, but someone with the name Physicus has banned me from the #reactos channel, because he doesn't know physics and is ignorant enough. Ok, you want to stay ignorant - it's your life choice. But what right does he have to ban me from _reactos_ channel? So now I can't develop for ROS, just because one guy is closed-minded about his view of physics?!! Is it how you treat people around here? No wonder you have such a small number of developers... Human stupidity and arrogance has certainly no limits... -- Best regards, Alex mailto:care2debug@gmail.com _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 1

Re: [ros-dev] [ros-diffs] [janderwald] 41970: - Interrupt is only shareable if the type is latched
by Dmitry Gorbachev 15 Jul '09

15 Jul '09

> (Descriptor->Flags & CM_RESOURCE_INTERRUPT_LATCHED) Is this right? ReactOS' KeConnectInterrupt() does not support interrupts edge-triggered and shared.

3 3

SVN to be down
by Aleksey Bragin 13 Jul '09

13 Jul '09

Hello, SVN server is going to be down for some time within the next 24hrs due to transfer to another datacenter. Minor problems after the transfer are expected and will be fixed appropriately. Thanks for your patience. WBR, Aleksey Bragin.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev