Ros-dev

ros-dev@reactos.org

5790 discussions

[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

Jump to page:

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