Hi,
First of all, what's up with ntvdmpath in the freeloader tree? I fail to
see what it has to do with ROS, much less with freeloader...I'm
recommending removal. Secondly... is there any problem with freeloader
using the ros depends tool instead of deptool? I know before this was
necessary because of different trees, but I would like to share as much
as possible.
Best regards,
Alex Ionescu
arty(a)svn.reactos.com wrote:
>Patch to fix NtCreateSempahore, in the case where the initial lookup
>succeeds. We previously left the function without initializing
>hSemaphore. Patch suggested by me and executed by hpoussin.
>
>
To me it looks totally wrong. First of all, the handle in my tests is
never written if the function fails (just create a testcase where your
application tries to create thousands of semaphore objects to reproduce
it). Second of all you initialize the semaphore object only if creating
it failed, as in you initialize a semaphore object on a NULL pointer.
Third of all you insert a handle to the object no matter if you
previously could create it, so you would end up creating a handle to a
null-pointer.
The previous version I wrote just had one small bug, it checked if
ObCreateObject failed to continue initialization and handle creation
instead of checking if it succeeded. I'm going to revert this version of
NtCreateSemaphore as it introduces even more bugs and adds behavior
neither documented nor reproducable. I guess in case an application
failed due to this function it was because of the fact that the function
succeeded and didn't return a handle to a semaphore object even though
one was created.
Best Regards
Thomas
The good news is that vncviewer is oh so close to running. If you apply
this patch it *does* run, but I think the patch is wrong. Hopefully,
after illustrating a wrong solution somebody might be able to see a right
one.
The problem it runs into is that the 2nd 'Alertability failed' message in
KeWaitForMultipleObjects is always triggered, which makes vncviewer unable
to display anything.
If i #if 0 that block out, then it appears to work fine. I suspected that
either we were being too conservative or there are too many APCs happening
on that thread, and this confirms that one of the suspicions is true.
The attached patch illustrates the probably broken solution.
Screen: http://64.81.145.152/~arty/vncviewer2.jpg
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
Hi,
did you know it is possible to configure Subversion, such that it automatically sets the correct properties for new checked in files? It looks at the file extensions to set properties such as the EOL style, mime type and to configure keyword expansion strings. For Windows the settings are stored in the registry, and for Unix they are stored in the file ~/.subversion/config. I attached a registry import file as an example, which contains settings I am using myself.
Regards,
Martin
> From: weiden(a)svn.reactos.com
>
> moved smdll to rosrtl. We just _can't_ have separate dlls for
> everything internal, that's what static libraries are for.
> Unless we want a dll hell even worse than necessary...
I think you are acting unbelievably rude here. Please revert your change and
discuss this on the mailinglist first.
Gé van Geldorp.
ion(a)svn.reactos.com wrote:
>+ /* Gotta check 3GB setting right *here* before we use KERNEL_BASE! */
>+ if (!_strnicmp(KeLoaderCommandLine, "3GB", 3)) {
>
This looks obviously wrong, you're comparing the beginning of kernel
command line with "3GB". It would make more sense to actually check if
the "3GB" is somewhere in the command line (even though that's not
correct too)...
- Filip
Hi,
something has changed in freeldr. If freeldr founds a problem (missing
driver) it shows a message box with an OK button. Since some days, it
isn't possible to continue with pressing the enter key.
- Hartmut
Hi,
I worked on direct3d for ros last year. But nothing useful came out. The
problem is in "subsys/win32k/ntddraw/*.c". There are a some functions,
which need to be implemented. They are called by DirectX and just pass
the call to the display diver. Should be easily to implement - but not
for me.
I think it would be a real milestone for ReactOs, if a experienced
kernel hacker would implement this, because the coder of the code that
is already there "Peter Bajusz" had also coded a basic direct3d
implementation about a year ago, that ran under winxp, but not under
ros, because of this. (see old mailinglist arrive)
However... I found out Peters new email address. He said that had to no
time to work on it, but it still would be a huge step.
Maarten Bosma
Hi,
I have some header trouble: I can't include STL headers and window.h
together.
I also notice, that there isn't a urlmon.h except that form wine, and it
isn't possible to include that for me. Maybe i have to include other
headers, too ?
Maarten Bosma
Now with source in svn trunk ! Well done !
Cordialement,
Usurp (aka Sylvain PETREOLLE)
Service de Production & d'Exploitation Informatique
GEFCO - #DMIT/DATO/PSI/PEI
Mail : <mailto:exploit@gefco.fr>
Tel : 01.49.05.29.29
-----Message d'origine-----
De : weiden(a)svn.reactos.com [mailto:weiden@svn.reactos.com]
Envoyé : vendredi 4 février 2005 21:39
À : ros-svn(a)reactos.com
Objet : [ros-svn] [weiden] 13406: Trevor McCort implemented desktop
wallpaper changing
Trevor McCort implemented desktop wallpaper changing
----------------------------------------------------------------------------
Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels
et sont exclusivement destinés à l'usage de la personne à laquelle ils sont
adressés. Tout point de vue ou toute opinion contenus dans ce message
expriment la pensée personnelle de leur auteur et ne représentent pas
nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas
la personne à laquelle ce message est destiné, veuillez noter que vous avez
reçu cet e-mail par erreur et qu'il vous est strictement interdit
d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message.
Si vous avez reçu ce message par erreur, merci de contacter la personne qui
vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO
déclinent toute responsabilité en cas d'altération, de modification,
d'édition, de diffusion sans autorisation de ce message ou en cas
d'affection de ce message par un virus.
This message and any attachments (the "message") are confidential and
intended solely for the use of the individual to whom they are addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the GEFCO Group of Companies. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing, or copying of
this message is strictly prohibited. If you have received this message in
error please contact the sender and delete the message immediately. The
GEFCO Group of Companies shall not be liable for the message if altered,
changed, falsified, edited, diffused without authorization or affected by
any virus.
----------------------------------------------------------------------------
> From: hbirr(a)svn.reactos.com
>
> - Prevent from calling PsTerminateCurrentThread from within
> an apc if PsTerminateThread was already called.
This change prevents terminating a thread from another thread. In that case,
PsTerminateOtherThread() is called, which sets up an APC and sets
Thread->HasTerminated to TRUE. This will make
PiTerminateThreadNormalRoutine() skip the call to
PsTerminateCurrentThread().
A side effect is that a multi-threaded app will not exit on an ExitProcess()
call. The thread calling ExitProcess() will terminate, but the other threads
will happily continue running. This is the reason GUI console windows don't
close anymore when you click their close button.
Gé van Geldorp.
Magnus Olsen wrote:
> Hi
> NtUserChangeDisplaySettings UNIMPLEMENTED
> changes that stub to return DISP_CHANGE_FAILED
> and use cmd winquake -noautostretch -startwindowed
>
> it will not work 100% fine until the NtUserChangeDisplaySettings
> are being implemnet. it is old news. That I think most people know
> last time, w3seek was working on more easy way to implement
> this api. it need a globa desktop pointer. last time I check
> reactos did not have one. And that make it hard to implement
> NtUserChangeDisplaySettings api
>
From,
http://cvs.cosoft.org.cn/cgi-bin/viewcvs.cgi/fileshare/FreeWin/include/win3…
LONG
STDCALL
NtUserChangeDisplaySettings(
PUNICODE_STRING lpszDeviceName,
LPDEVMODEW lpDevMode,
HWND hwnd,
DWORD dwflags,
LPVOID lParam);
Oh well, I guess this is from a ROS fork,
James
Post to wrong list.
Start WinQuake, no prob;
(objects/color.c:317) NtGdiRealizePalette is unimplemented
(objects/gdiobj.c:866) Attempted to lock object 0x0 that is deleted!
Frames: <win32k.sys: 47c2d> <win32k.sys: 3d159> <ntoskrnl.exe: 3b4b> <7FFE0304>
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED
(mci.c:536:MCI_LoadMciDriver) Couldn't load driver for type CDAUDIO.
If you don't have a windows installation accessible from Wine,
you perhaps forgot to create a [mci] section in system.ini
Freeing page with rmap entries.
But in the game the system goes down, no reboot, just shutdown!
KeBugCheck at mm/freelist.c:719
Page fault at high IRQL was 2
Bug detected (code 0 param 0 0 0 0)
The bug code is undefined. Please use an existing code instead.
Frames: <ntoskrnl.exe: cb0c>
<ntoskrnl.exe: cb2c>
<ntoskrnl.exe: 5ae96>
<ntoskrnl.exe: 570f2>
<ntoskrnl.exe: 16975>
<ntoskrnl.exe: 5cce7>
<ntoskrnl.exe: 169b5>
<ntoskrnl.exe: 16dcc>
<ntoskrnl.exe: 17324>
<ntoskrnl.exe: 3a30>
Wow!
James
Ge van Geldorp wrote:
> If symbolic info was present in file.nostrip.ext (i.e. it was compiled
with
> -g, which at present implies DBG := 1), then it will also be present in
> file.ext. So, the backtrace on e.g. BSODs should print the function
> name/source file/source line in addition to the address. Which means we
> won't have to use addr2line very often. If there was no symbolic info in
> file.nostrip.ext, addr2line wouldn't be of help anyway.
I like this idea.
Me, Alex and Steven were discussing something similar the other day in IRC.
I never expected things to move so fast :)
Ged
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
In anticipation of doing some work on performance issues, I've been
experimenting with our kernel profiler the last few days. For those who
don't know, you can activate the profiler by including the /PROFILE option
on the command line. On each timer interrupt the current EIP will be saved,
after 30 sec a background task will convert the saved EIPs to function
name/file name, count how often each function name occurs and write the
results to a file %system_root%\profiler.log. There are 100 timer ticks per
second, a 30 sec measuring interval will therefore generate 3000 EIPs.
This works very nice, but I'm running into one problem on my 300MHz test
machine: conversion of the EIPs to function name by the background thread
takes about 60 sec. Almost all of that time is spent looking up the correct
.stabs entry from the info in the .sym file. This is done using a linear
search. Since there can be 100000 .stabs entries in a .sym file, going
through these for each of the 3000 measurements can mean 300000000 compares.
Even worse, two passes are made through the .stabs list for each
measurement, one to find the function name and one to find the file name. No
wonder this takes 60 sec.
So, we need to improve the search. I've done some simulations, and when I
use a binary search instead of a linear search, the performance is
dramatically better. Time required to convert all measurements drops from 60
sec to 0.06 sec, a 1000 fold improvement.
To be able to use a binary search, the information in the .sym file needs to
be sorted and uniform (each element contains the same type of data) which it
currently isn't. We have .stabs entries defining a function (N_FUN), source
line (N_SLINE) and source file (N_SO). Currently, we only use the .sym files
to convert an address to function name/file name/source line, not the other
way around (no function name to address for example). I'd like to drop using
the .stab format in the .sym files and change to the following format:
+----------+
|header |
+----------+
|symentries|
+----------+
|strings |
+----------+
The header would just contain the start location and number of symentries
plus start location and total size of the strings. Each symentry would have
the following info:
typedef struct tagSYM_ENTRY {
ULONG_PTR Address;
ULONG FunctionOffset;
ULONG FileOffset;
ULONG SourceLine;
} SYM_ENTRY, *PSYM_ENTRY;
where Address is an address relative to the beginning of the module,
FunctionOffset and FileOffset are offsets from the beginning of the strings
section and SourceLine contains the source line number. The symentries are
sorted by Address (done by rsym). Each Address would only appear once, and
information would be made as complete as possible (e.g. when creating the
symentries from the .stabs in the .nostrip.exe file each FunctionOffset
would be set to point to the function name from the most recently
encountered N_FUN .stab). This will allow us to retrieve all 3 pieces of
information (function name, file name and source line) by doing just a
single binary search.
Comments, thoughts, objections?
Gé van Geldorp.
Hello ROS-Devs,
I've been sharing some thoughts about DOS subsystem on ReactOS forum. I
am pasting my last post
(http://reactos.com/forum/viewtopic.php?p=2864#2864 )
<http://reactos.com/forum/viewtopic.php?p=2864#2864>
here for your comments
========================================================
hello,
I am back with my silly posts Smile
But this time, after seriously reading and experimenting with FreeDos
and DosEmu code.
As many people suggested FreeDOS as an option to run as ReactOS
subsystem, I concentrated more on FreeDOS.
Something I came to know are
1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS
applications on ReactOS.
2) FreeDOS itself is 16bit system
3) Compiling FreeDOS code with 32bit compiler is so difficult that it
gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code
with MinGW with no success)
4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS
applications
5) DOSEmu is really slow
Please give your valuable suggestions.
AcetoliNe: I agree with your last post.
=====================================================================
~AzeemArif
(ReactOS IRC channel - "azar")
Hello ROS-Devs,
I've been sharing some thoughts about DOS subsystem on ReactOS forum. I
am pasting my last post
(http://reactos.com/forum/viewtopic.php?p=2864#2864 )
<http://reactos.com/forum/viewtopic.php?p=2864#2864>
here for your comments
========================================================
hello,
I am back with my silly posts Smile
But this time, after seriously reading and experimenting with FreeDos
and DosEmu code.
As many people suggested FreeDOS as an option to run as ReactOS
subsystem, I concentrated more on FreeDOS.
Something I came to know are
1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS
applications on ReactOS.
2) FreeDOS itself is 16bit system
3) Compiling FreeDOS code with 32bit compiler is so difficult that it
gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code
with MinGW with no success)
4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS
applications
5) DOSEmu is really slow
Please give your valuable suggestions.
AcetoliNe: I agree with your last post.
=====================================================================
~AzeemArif
(ReactOS IRC channel - "azar")
Hi Gunnar:
>And about the strlen=ntdll.strlen stuff. Forwarded functions doesnt show
>up as imported because they arent really imported, so this is normal.
I think that it is not normal. The better way should be to really forward them, this is just half baked stuff.
If you are not going to forward it, I think that it would be better to not declare them as such because that can cause confusion.
>Dont understand what XP's ntdll exporting "WindowsCE" functions has to
>do with anything?
Was just a comment about ntdll, they are exported and nothing is mentioned in msdn. I said that because I think
ntdll is very close to the runtime.
Best Regards
Waldo
It works here, computer is put into low power state everytime you click on
logoff.
Usurp (aka
Sylvain PETREOLLE)
Service de Production & d'Exploitation Informatique
GEFCO - #DMIT/DATO/PSI/PEI
Mail : <mailto:exploit@gefco.fr>
Tel : 01.49.05.29.29
-----Message d'origine-----
De : Gge [mailto:gerard.gatineau@laposte.net]
Envoyé : vendredi 28 janvier 2005 07:59
À : ReactOS Development List
Objet : [ros-dev] ACPI status
I built Ros with ACPI=1 but the feature is not working (in real
hardware) as the computer does not go into low power state .
At boot the debug messages displayed are :
DriverBase for acpi.sys : 9ce1300
Advanced Configuration and Power Interface Bus Driver
ACPI: System firmware supports:
+------------------------------------------------------------
| Sx states: +S0 +S1 -S2 -S3 +S4 +S5
+------------------------------------------------------------
What is the status of the ACPI feature ? Is it supported actually ?
Best regards
Gerard
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
----------------------------------------------------------------------------
Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels
et sont exclusivement destinés à l'usage de la personne à laquelle ils sont
adressés. Tout point de vue ou toute opinion contenus dans ce message
expriment la pensée personnelle de leur auteur et ne représentent pas
nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas
la personne à laquelle ce message est destiné, veuillez noter que vous avez
reçu cet e-mail par erreur et qu'il vous est strictement interdit
d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message.
Si vous avez reçu ce message par erreur, merci de contacter la personne qui
vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO
déclinent toute responsabilité en cas d'altération, de modification,
d'édition, de diffusion sans autorisation de ce message ou en cas
d'affection de ce message par un virus.
This message and any attachments (the "message") are confidential and
intended solely for the use of the individual to whom they are addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the GEFCO Group of Companies. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing, or copying of
this message is strictly prohibited. If you have received this message in
error please contact the sender and delete the message immediately. The
GEFCO Group of Companies shall not be liable for the message if altered,
changed, falsified, edited, diffused without authorization or affected by
any virus.
----------------------------------------------------------------------------
navaraf(a)svn.reactos.com wrote:
>Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497.
>
>
>Updated files:
>trunk/reactos/lib/kjs/makefile
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
Aren't you forcing non-inlining of EVERY function by doing this? Isn't
it better to enable the special no ctype inline macro?
Best regards,
Alex Ionescu