Ros-dev

ros-dev@reactos.org

5791 discussions

ARM port: SWI call numbering
by Theo Markettos 28 Jan '10

28 Jan '10

I wonder if I could get in touch with the folks doing the ARM port... Executive summary: From a look at the code I think ARM ReactOS uses SWIs (syscalls) numbered from zero. There's a de-facto ARM standard that splits up SWI numbering so different OSs get allocated different numbering ranges. It would be handy if ReactOS could pick one that doesn't clash with other OSs. I wondered if the ARM port folks might consider changing SWI base at some point. For more details, a brief history lesson. The ARM1 and ARM2 chips were originally developed at Acorn Computers in 1983-7. The first ARM machine was the Archimedes, launched by Acorn in 1987. The Archimedes was supplied with Arthur, which in 1988 became RISC OS, a co-operatively multitasking OS. RISC OS is still around and runs on modern hardware such as the BeagleBoard - see http://www.riscosopen.org/ SWI instructions on the ARM have a 24 bit 'comment' field. As originally envisaged this would hold the syscall number, a bit like INT on x86 and TRAP on 68k. Acorn for their OSs (and there were no other ARM OSs at the time) chose a numbering scheme where bits 20-23 denote the OS. For the ones I know about: 23--20 0000 RISC OS 1000 RISC iX (4.3 BSD ported to ARM2/3) 1001 Formerly Linux (they've now don't use the comment field) 1111 ARM's OS independent routines And NetBSD use another value that I forget. The advantage of having non-overlapping SWI bases is that it allows cross-platform execution of binaries (a bit like WINE in effect, though I don't know the details of how WINE works). So it means RISC OS code (of which there is lots) could run on ReactOS, or vice versa, if somebody writes a syscall implementation for the other platform. So I wondered if there was any interest in making sure the syscall numbers didn't clash with other OSs? From what I see in: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/arm/usercall.c… it looks like your SWIs are numbered from zero, which is a clash. If you were interested in changing, do you have any idea how many SWIs you might use? RISC OS uses hundreds of thousands (SWIs are used as the interface to DLL-like code), but if you were to only need, say, 2^16 that might save the number space a bit. Thoughts? Comments? Flames? Thanks Theo

1 0

Re: [ros-dev] [ros-diffs] [dreimer] 45286: - Add piperead to the setup. - Update ChangeLog.txt - Sync clean.ps1 to Colin's changes.
by Colin Finck 28 Jan '10

28 Jan '10

dreimer(a)svn.reactos.org wrote: > + if ("$ENV:ROS_AUTOMAKE" -eq "") { > + $ENV:ROS_AUTOMAKE = "makefile-$ENV:ROS_ARCH.auto" > + } > [...] That's not properly ported. My script only sets these variables locally due to "setlocal", yours permanently changes the environment variables. This will result in obvious problems when ROS_ARCH is changed. Don't know whether PS provides an equally elegant way to overwrite these variables locally like Batch does ;-) Best regards, Colin

2 3

AbiWord, Worse Written Application
by James Tabor 28 Jan '10

28 Jan '10

Hi! These are Class Owned DCE starting at the end of allocations. When closing the application the thread cleanup routine I added frees the DCE's. (This was not implemented yet, so they never freed and the side effect of slowing the system down due to hashing the long list of allocations) Amazing! Look at the count! For every allocation of a Class Owned DCE there is a menu and even one for every item in the menu and not reusing the ones allocated and allocating more! This is one reason AbiWord is slow when drawing! The overhead is crippling! Most (mean all) applications use one or two DCE's and common to the DCX_CACHE type. This is the best example of an UNIX ported program to Windows I've ever seen. Unix hackers hacking it to draw in windows without the proper research! This is a modest debug list here, what would happen working with AbiWord all day? ReactOS would most likely get the blame! Must I write more? (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 152 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 153 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 154 (dll/win32/gdi32/misc/misc.c:317) Get Handle! Count 1 PEB 0x7ffdf000 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 155 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 156 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 157 [Close App] err:(dll/win32/user32/windows/menu.c:3687) MenuTrackMenu 2 (subsystems/win32/win32k/ntuser/timer.c:428) Invalid window handle (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 156 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 155 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 154 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 153 (subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 154 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 153 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 152 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 151 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 150 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 149 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 148 <Snip>..... (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 11 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 10 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 9 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 8 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 7 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 6 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 5 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 4 (subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 3

3 3

Re: [ros-dev] [ros-diffs] [sir_richard] 45281: [NTOS]: Trunk boots now (interesting that buildbot's QEMU does not support SYSENTER, as newer versions do), so remove the test DPRINTs.
by Ged Murphy 27 Jan '10

27 Jan '10

sir_richard(a)svn.reactos.org wrote >... (interesting that buildbot's QEMU does not support SYSENTER, as newer versions do)... Buildbot doesn't use QEMU it uses KVM. I realise that KVM uses parts of QEMU, but I don't know to what extent. Maybe this is the reason for the difference? Maybe one day we'll have a real operating system running our build machine instead of linux ;) Ged.

5 5

[ros-diffs] [sir_richard] 45223
by Dmitry Gorbachev 24 Jan '10

24 Jan '10

> Since __builtin_unreachable is only for GCC 4.5, we use > exit(0) for now (it will never be reached) to trick GCC. There is also __builtin_trap() …

4 5

Does Arwinss build right now?
by Brian 22 Jan '10

22 Jan '10

on Ubuntu with rosbe 1.42, i just checked it out and tried to build. im sure its my fault but... -- brian

3 3

Arwinss presentation
by Aleksey Bragin 21 Jan '10

21 Jan '10

All, today I would like to officially announce the (sub)project I was working on for the last half a year, and make a call to developers to participate. ReactOS has been around for about 11 years, and it's been growing each year since then. The demand for an open source Windows- compatible operating system is huge: geek, servers, netbooks, accounting, point of sales, CAD... The list could go on and on. Time goes by, new versions of Windows operating systems are being released. ReactOS usability still has not reached any significant value. Not to say ReactOS didn't even officially enter the Beta stage. Separately, there are many achievements: audio support appeared, bootloader is able to boot real Windows, some Windows binary drivers could be loaded and work in ReactOS, networking is being improved every day, the kernel is being actively worked on too. But all of that does not really matter for the end user. For a user it's important that a web-browser loads websites, instant messenger client connects and works, [Microsoft/Open] Office shows documents, email client gets new messages. This bare usability is what's still missing, and if ti continues to be like this, I am afraid our project won't be of much use in another 10 years. Certainly, I became very concerned and started analyzing situation. Being opensource project without major commercial sponsors, there are certain limitations as to what could be done to improve the situation, so mainly it's a matter of picking right priorities and properly managing (motivating) existing human resources. The part of ReactOS which plays major role in compatibility and usability is Win32 subsystem. Right now, it's a huge monster which requires a lot more human resources than we have now. It's very hard and time consuming to reach even Windows 2000 level of compatibility with current amount of participating developers, and high entry level. I came up with something which could solve this problem: Arwinss. To better explain what it is, I made a special presentation (URL to slides in PDF format is in the end of this email). Please imagine myself talking through it as I didn't perform/record it. Now, after you read through the presentation, I would like to make a proposal to all developers (even newcomers, who never worked on ReactOS before). Let's make an Arwinss week, or Arwinss month. Every developer could definitely find a few hours during a week to hack Arwinss. Entry level is rather low, there are some basic docs about Arwinss in the wiki, and I am happy to consult about details. If I could make this new subsystem out of nothing (out of Wine and ReactOS) almost alone (Kamil and Smiley help is very valued and appreciated!) within a few months, imagine what we could do all together? With the best regards, Aleksey Bragin. The presentation: (links to further information are in the presentation too) http://www.reactos.org/media/docs/2010/arwinss.pdf

20 28

Sir_Xxx Wise Guys
by James Tabor 21 Jan '10

21 Jan '10

This project is not wine so please keep it nice! You guys are newbies and need to play nice! We old timers can kick it around, not you! Until a year or two you guys can be asses.... Friendly warning, James

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 45182: [HAL]: The HAL is a mess. Fix build.
by Gabriel ilardi 21 Jan '10

21 Jan '10

Thanks for the prompt fix. Gabriel. > Date: Thu, 21 Jan 2010 13:36:30 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 45182: [HAL]: The HAL is a mess. Fix build. > > Author: sir_richard > Date: Thu Jan 21 14:36:30 2010 > New Revision: 45182 > > URL: http://svn.reactos.org/svn/reactos?rev=45182&view=rev > Log: > [HAL]: The HAL is a mess. Fix build. > > Modified: > trunk/reactos/hal/halx86/mp/halinit_mp.c > trunk/reactos/hal/halx86/mp/ioapic.c > > Modified: trunk/reactos/hal/halx86/mp/halinit_mp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/mp/halinit_mp.c… > ============================================================================== > --- trunk/reactos/hal/halx86/mp/halinit_mp.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/mp/halinit_mp.c [iso-8859-1] Thu Jan 21 14:36:30 2010 > @@ -22,7 +22,7 @@ > > /***************************************************************************/ > > -VOID NTAPI HalpInitPICs(VOID) > +VOID NTAPI HalpInitializePICs(IN BOOLEAN EnableInterrupts) > { > UNIMPLEMENTED; > } > > Modified: trunk/reactos/hal/halx86/mp/ioapic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/mp/ioapic.c?rev… > ============================================================================== > --- trunk/reactos/hal/halx86/mp/ioapic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/mp/ioapic.c [iso-8859-1] Thu Jan 21 14:36:30 2010 > @@ -32,7 +32,7 @@ > * EISA conforming in the MP table, that means its trigger type must > * be read in from the ELCR */ > > -#define default_EISA_trigger(idx) (EISA_ELCR(IRQMap[idx].SrcBusIrq)) > +#define default_EISA_trigger(idx) (EISA_ELCR_Read(IRQMap[idx].SrcBusIrq)) > #define default_EISA_polarity(idx) (0) > > /* ISA interrupts are always polarity zero edge triggered, > @@ -64,7 +64,7 @@ > /* > * EISA Edge/Level control register, ELCR > */ > -static ULONG EISA_ELCR(ULONG irq) > +static ULONG EISA_ELCR_Read(ULONG irq) > { > if (irq < 16) > { > > _________________________________________________________________ Un mondo di personalizzazioni per Messenger, PC e cellulare http://www.pimpit.it/

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 45170: [Win32k] - Implement IntGdiSetBrushOwner for bug 5124.
by Ged Murphy 21 Jan '10

21 Jan '10

Spot the deliberate mistake : IntGdiSetRegeionOwner -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jimtabor(a)svn.reactos.org Sent: 21 January 2010 01:39 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jimtabor] 45170: [Win32k] - Implement IntGdiSetBrushOwner for bug 5124. Author: jimtabor Date: Thu Jan 21 02:39:19 2010 New Revision: 45170 URL: http://svn.reactos.org/svn/reactos?rev=45170&view=rev Log: [Win32k] - Implement IntGdiSetBrushOwner for bug 5124. Modified: trunk/reactos/subsystems/win32/win32k/include/brush.h trunk/reactos/subsystems/win32/win32k/include/gdiobj.h trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c trunk/reactos/subsystems/win32/win32k/objects/gdiobj.c Modified: trunk/reactos/subsystems/win32/win32k/include/brush.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/include/brush.h [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/include/brush.h [iso-8859-1] Thu Jan 21 02:39:19 2010 @@ -132,4 +132,6 @@ VOID FASTCALL FreeObjectAttr(PVOID); +BOOL FASTCALL IntGdiSetBrushOwner(PBRUSH,DWORD); + #endif Modified: trunk/reactos/subsystems/win32/win32k/include/gdiobj.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/include/gdiobj.h [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/include/gdiobj.h [iso-8859-1] Thu Jan 21 02:39:19 2010 @@ -82,9 +82,10 @@ #define GDIOBJFLAG_IGNOREPID (0x1) #define GDIOBJFLAG_IGNORELOCK (0x2) -BOOL FASTCALL GreDeleteObject(HGDIOBJ hObject); -BOOL FASTCALL IsObjectDead(HGDIOBJ); -BOOL FASTCALL IntGdiSetDCOwnerEx( HDC, DWORD, BOOL); +BOOL FASTCALL GreDeleteObject(HGDIOBJ hObject); +BOOL FASTCALL IsObjectDead(HGDIOBJ); +BOOL FASTCALL IntGdiSetDCOwnerEx( HDC, DWORD, BOOL); +BOOL FASTCALL IntGdiSetRegeionOwner(HRGN,DWORD); /*! * Release GDI object. Every object locked by GDIOBJ_LockObj() must be unlocked. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c [iso-8859-1] Thu Jan 21 02:39:19 2010 @@ -195,8 +195,7 @@ Monitor->rcMonitor.right, Monitor->rcMonitor.bottom ); - // Replace with IntGdiSetRegeionOwner(Monitor->hrgnMonitor, GDI_OBJ_HMGR_PUBLIC); - GDIOBJ_SetOwnership(Monitor->hrgnMonitor, NULL); + IntGdiSetRegeionOwner(Monitor->hrgnMonitor, GDI_OBJ_HMGR_PUBLIC); if (gMonitorList == NULL) { Modified: trunk/reactos/subsystems/win32/win32k/objects/gdiobj.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/objects/gdiobj.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/objects/gdiobj.c [iso-8859-1] Thu Jan 21 02:39:19 2010 @@ -1562,6 +1562,36 @@ BOOL FASTCALL +IntGdiSetRegeionOwner(HRGN hRgn, DWORD OwnerMask) +{ + INT Index; + PGDI_TABLE_ENTRY Entry; +/* + System Regions: + These regions do not use attribute sections and when allocated, use gdiobj + level functions. + */ + // FIXME! HAX!!! Remove this once we get everything right! + KeEnterCriticalRegion(); + Index = GDI_HANDLE_GET_INDEX(hRgn); + Entry = &GdiHandleTable->Entries[Index]; + if (Entry->UserData) FreeObjectAttr(Entry->UserData); + Entry->UserData = NULL; + KeLeaveCriticalRegion(); + // + if ((OwnerMask == GDI_OBJ_HMGR_PUBLIC) || OwnerMask == GDI_OBJ_HMGR_NONE) + { + return GDIOBJ_SetOwnership(hRgn, NULL); + } + if (OwnerMask == GDI_OBJ_HMGR_POWNED) + { + return GDIOBJ_SetOwnership((HGDIOBJ) hRgn, PsGetCurrentProcess() ); + } + return FALSE; +} + +BOOL +FASTCALL IntGdiSetBrushOwner(PBRUSH pbr, DWORD OwnerMask) { HBRUSH hBR; @@ -1608,7 +1638,6 @@ } return TRUE; } - BOOL FASTCALL @@ -1672,7 +1701,6 @@ } return Ret; } - W32KAPI HANDLE

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