Dear developers of Reactos,
As i promised in my previous E-mail, i AM sending You The list of dlls, on which NVDA screen reader is strictly depend and without them will not work.
Thank You for any feetback provided.
OLEAUT32.dll - C:\WINDOWS\system32\OLEAUT32.dll
USER32.dll - C:\WINDOWS\system32\USER32.dll
POWRPROF.dll - C:\WINDOWS\system32\POWRPROF.dll
SHELL32.dll - C:\WINDOWS\system32\SHELL32.dll
ole32.dll - C:\WINDOWS\system32\ole32.dll
WINMM.dll - C:\WINDOWS\system32\WINMM.dll
WSOCK32.dll - C:\WINDOWS\system32\WSOCK32.dll
COMDLG32.dll - C:\WINDOWS\system32\COMDLG32.dll
ADVAPI32.dll - C:\WINDOWS\system32\ADVAPI32.dll
msvcrt.dll - C:\WINDOWS\system32\msvcrt.dll
WS2_32.DLL - C:\WINDOWS\system32\WS2_32.DLL
GDI32.dll - C:\WINDOWS\system32\GDI32.dll
VERSION.dll - C:\WINDOWS\system32\VERSION.dll
KERNEL32.dll - C:\WINDOWS\system32\KERNEL32.dll
COMCTL32.dll - C:\WINDOWS\system32\COMCTL32.dll
RPCRT4.dll - C:\WINDOWS\system32\RPCRT4.dll
Extracting all API calls from NVDA source code written in Python will not be easy task, and extracting those calls from source code written in C language for several helper libraryes will not be asy to.
Hello everybody,
After some more updates, fixes and strange problems, Daniel and I finally
released new RCs of RosBE-Windows and RosBE-Unix 1.5.
Daniel published a changelog for the Windows version at
http://dreimer.de.vu.
The Unix version fixes building problems on many hosts, especially 64-bit
ones. Like RosBE-Windows, it also includes updated tools such as GCC 4.4.3.
Besides, all supplied libraries are guaranteed to contain STABS+ symbols
useful for debugging with e.g. GDB. Finally, make/makex now reports the
correct return value instead of always 0 :-)
You can download RosBE-Windows 1.5-RC4 and RosBE-Unix 1.5-RC2 at
http://reactos.colinfinck.de.
Please test out both of them using the latest code patch at
http://www.reactos.org/bugzilla/show_bug.cgi?id=4810, so that we can move to
RosBE 1.5 and GCC 4.4.x soon.
For the Unix version, I'm especially looking for testers using non-Linux
operating systems such as Mac OS X or FreeBSD. Current RosBE works well on
them, but the previous RC made problems.
Best regards,
Colin
This change keeps the ability to plug GDB into ReactOS and fixes libxlst.
It also fixes bootcd with Rosbe 1.5 trunk builds.
With -g0 enabled in RosBE-Unix 1.5 instead of STABS+,
previous builds of bootcd used to fail to allocate memory and crash.
Kind regards,
Sylvain Petreolle
This is really interesting. It'd be great to have this up in testman somehow.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sir_richard(a)svn.reactos.org
Sent: 28 January 2010 15:51
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [sir_richard] 45297: [PERF]: Not in any way a scientific number you should bet the farm on, but we do now count the number of cycles at the very first instruction of kernel initialization, at the moment SMSS initializes the registry (when we c
Author: sir_richard
Date: Thu Jan 28 16:51:18 2010
New Revision: 45297
URL: http://svn.reactos.org/svn/reactos?rev=45297&view=rev
Log:
[PERF]: Not in any way a scientific number you should bet the farm on, but we do now count the number of cycles at the very first instruction of kernel initialization, at the moment SMSS initializes the registry (when we call kernel initialization complete), and at the moment there have been 12 processes created (10 without counting idle/system), which is a bit less than a normal GUI boot. We also display the number if interrupts, system calls, and context switches it took to get us there. A purely comparative number, perhaps worthy for inclusion in testman/regression tests?
Modified:
trunk/reactos/ntoskrnl/config/ntapi.c
trunk/reactos/ntoskrnl/include/internal/ke.h
trunk/reactos/ntoskrnl/ke/i386/kiinit.c
trunk/reactos/ntoskrnl/ps/process.c
Modified: trunk/reactos/ntoskrnl/config/ntapi.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/ntapi.c?re…
==============================================================================
--- trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] Thu Jan 28 16:51:18 2010
@@ -890,6 +890,14 @@
/* Always do this as kernel mode */
if (KeGetPreviousMode() == UserMode) return ZwInitializeRegistry(Flag);
+ /* Enough of the system has booted by now */
+ BootCyclesEnd = __rdtsc();
+ DPRINT1("Boot took %I64d cycles!\n", BootCyclesEnd - BootCycles);
+ DPRINT1("Interrupts: %d System Calls: %d Context Switches: %d\n",
+ KeGetCurrentPrcb()->InterruptCount,
+ KeGetCurrentPrcb()->KeSystemCalls,
+ KeGetContextSwitches(KeGetCurrentPrcb()));
+
/* Validate flag */
if (Flag > CM_BOOT_FLAG_MAX) return STATUS_INVALID_PARAMETER;
Modified: trunk/reactos/ntoskrnl/include/internal/ke.h
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…
==============================================================================
--- trunk/reactos/ntoskrnl/include/internal/ke.h [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/include/internal/ke.h [iso-8859-1] Thu Jan 28 16:51:18 2010
@@ -139,6 +139,8 @@
extern ULONG KiFreezeFlag;
extern ULONG KiDPCTimeout;
extern PGDI_BATCHFLUSH_ROUTINE KeGdiFlushUserBatch;
+extern ULONGLONG BootCycles, BootCyclesEnd;
+extern ULONG ProcessCount;
/* MACROS *************************************************************************/
Modified: trunk/reactos/ntoskrnl/ke/i386/kiinit.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/kiinit.c?…
==============================================================================
--- trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] Thu Jan 28 16:51:18 2010
@@ -24,6 +24,10 @@
/* Spinlocks used only on X86 */
KSPIN_LOCK KiFreezeExecutionLock;
KSPIN_LOCK Ki486CompatibilityLock;
+
+/* Perf */
+ULONG ProcessCount;
+ULONGLONG BootCycles, BootCyclesEnd;
/* FUNCTIONS *****************************************************************/
@@ -683,6 +687,9 @@
PKTSS Tss;
PKIPCR Pcr;
+ /* Boot cycles timestamp */
+ BootCycles = __rdtsc();
+
/* Check if we are being booted from FreeLDR */
if (!((ULONG_PTR)LoaderBlock & 0x80000000)) KiRosPrepareForSystemStartup((PROS_LOADER_PARAMETER_BLOCK)LoaderBlock);
Modified: trunk/reactos/ntoskrnl/ps/process.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/process.c?rev=…
==============================================================================
--- trunk/reactos/ntoskrnl/ps/process.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ps/process.c [iso-8859-1] Thu Jan 28 16:51:18 2010
@@ -843,6 +843,18 @@
/* Run the Notification Routines */
PspRunCreateProcessNotifyRoutines(Process, TRUE);
+
+ /* If 12 processes have been created, enough of user-mode is ready */
+ if (++ProcessCount == 12)
+ {
+ /* Enough of the system has booted by now */
+ BootCyclesEnd = __rdtsc();
+ DPRINT1("User Boot took %I64d cycles!\n", BootCyclesEnd - BootCycles);
+ DPRINT1("Interrupts: %d System Calls: %d Context Switches: %d\n",
+ KeGetCurrentPrcb()->InterruptCount,
+ KeGetCurrentPrcb()->KeSystemCalls,
+ KeGetContextSwitches(KeGetCurrentPrcb()));
+ }
CleanupWithRef:
/*
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
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
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