Please list all VR IRQ in NT 5.1 and VI
IF my computer is not in ACPI m ode is it in Standard PC mode?
Please reply.. It is vary important.
_________________________________
Dave Johnson
http://www.davefilms.us DaveFILMS®
San Diego, CA & Nashville, TN
http://perditioncity.us/
Voice Talent
Writer, Producer, Director
Independent Audio Theater Producer
Voice mail and Fax#:(206)350-2915
Voice (615)722-2249
Skype & Msn Live messanger "DaveFilms"
AIM / iChat AV "DaveFilms2007"
Why not use a linked list structure in LOADER_PARAMETER_BLOCK,
describing hardware device tree? (I implemented a bit of it in winldr).
Or is it for a different purpose?
WBR,
Aleksey Bragin.
On Nov 11, 2007, at 12:27 PM, arty(a)svn.reactos.org wrote:
> Author: arty
> Date: Sun Nov 11 12:27:07 2007
> New Revision: 30352
>
> URL: http://svn.reactos.org/svn/reactos?rev=30352&view=rev
> Log:
> Add structures related to devtree.c
>
> Modified:
> trunk/reactos/include/reactos/ppcboot.h
Hi,
no, I was speaking about something different.
Take a look - http://www.reactos.org/wiki/index.php/Coding_Style
there I mean this:
/*++
* @name SomeAPI
* @implemented NT4
*
* Do nothing for 500ms.
*
* @param SomeParameter
* Description of the parameter. Wrapped to more lines on ~70th
* column.
*
* @param YetAnotherParameter
* Bleh, bleh :)
*
* @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL
* othwerwise.
*
* @remarks Must be called at IRQL == DISPATCH_LEVEL
*
*--*/
NTSTATUS
STDCALL
SomeAPI( ...
rgenstat-alike tool should be able to parse such header, not only the
old-style simple
/*
@implemented
*/
WBR,
Aleksey Bragin.
On Nov 10, 2007, at 1:06 AM, Marc Piulachs wrote:
> Hi Aleksey,
>
>
>
> I don’t know if I understood you completely, rgenstat works by
> parsing c/cpp source files not header files. What do you mean with
> “standard function header”?
>
>
>
> If we are seriously going to use it I would like to make some
> slightly modifications to it to make it more powerful but would
> require help from someone with more experience than me writing
> parsers in C.
>
>
>
> Regards,
>
> /Marc
On Nov 12, 2007, at 1:56 AM, Timo Kreuzer wrote:
>> Once again, the data extracted from parsing is not TRUE metadata just
>> meaningless strings that you can guess or interpret : "author :
>> jdoe" ,
>> "author : jhondoe" , "author : jhon doe" are 3 different persons and
>> Jhon Doe just one , I think it's obvious.
>>
> I disagree here. IMO information about developers and translators
> belong to svn. They should neither go into the sources nor into
> rbuild files. If you want to find out about it, ask svn and it will
> tell you the exact name. We also don't really have maintainers for
> most modules, so most rbuild files would be spammed with the names
> of lots of developers without saying anything about who wrote a
> paticular piece of code.
There is standard per-file header for ReactOS source code (if it's
not used everywhere, it's a temporary problem), which lists
programmers, and it's usually (almost always) maintained. Whenever
our code is indexed by systems like Google codesearch, everyone can
clearly see the license and authorship from the source file.
Additionally, SVN holds exact per-line history of changes.
What's the benefit of storing authoship in .rbuild too? (I agree it
is logical, but if there is no benefit, then...)
WBR,
Aleksey Bragin.
Your opinion does have a strong point.
Implemented/unimplemented were useful in the early stages, I think.
Right now, for both Wine and ReactOS, the quality of implementation
matters, not quantity.
How is Wine's system done, about documenting functions - where is it
done? Source code comments? Can it be adjusted to fit ReactOS coding
style?
WBR,
Aleksey Bragin.
On Nov 10, 2007, at 10:16 PM, Steven Edwards wrote:
> On Nov 10, 2007 4:00 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>> Hi,
>> no, I was speaking about something different.
>> Take a look - http://www.reactos.org/wiki/index.php/Coding_Style
>> there I mean this:
>
> The implemented/unimplemented tags are really worthless because what
> if the API takes 20 params and 18 of them are implemented
> and nothing known uses the other 2 params? Do you call it implemented
> or unimplemented? Its better to autogenerate the docs from the
> function comment headers. See here, I think this is a MUCH better
> system and it already works. No point in developing another.
>
> http://source.winehq.org/WineAPI/
>
> If the API does not show up in the documented API then it should be
> safe to assume its not implemented. If it is implemented and not
> documented then its a Janitorial project.
>
> --
> 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
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
I support that, though some modifications should be required, because
in the kernel a standard function header [should be]/is used. If it's
able to parse that header too (provided it contains the @implemented/
@unimplemented), then it's great.
WBR,
Aleksey Bragin.
On Nov 9, 2007, at 8:29 PM, Marc Piulachs wrote:
> As most of you know, Casper created a small tool rgenstat (tools/
> rgenstat) that is able to parse source code for modules specified
> on apistatus.lst seeking for public APIs decorated with the
> @implemented or @unimplemented C comment. Rgenstat when invoked
> typing “make rgenstat” it produces an xml file containing all the
> functions and it’s current implementation status. With this
> database we can do all sorts of automatic compatibility reports .
> see for example wine’s equivalent http://www.winehq.org/site/status
> or http://www.codexchange.net/roslib generated from incomplete
> reactos data , (work in progress)
>
>
>
> As it easy and not intrusive I would suggest using this feature to
> kernel and core developers. Fireball , GreatLord , Jim , what do
> you think about that ?
>
>
>
> /Marc
If it's impossible to make correct .rc files (without the hassle of
using backends), then Marc's way is a way to go.
There is such tool by Wine, which uses .spec, it may need writing a
MSVC-backend though,.
WBR,
Aleksey Bragin.
On Nov 9, 2007, at 10:56 PM, Alex Ionescu wrote:
> I think you're all missing the point.
>
> As it stands now, MSVC won't even READ most of your resource files
> because you've decided to write them in a way that violates the .rc
> standard and that only binres/windres/whatever-you-call-that-
> incompatible-garbage can parse.
>
> Mark's proposal, apart from fixing all the problems he brought up,
> will finally allow you to write resource files that both MSVC and
> your-retarded-rc-compiler-name-goes-here can understand, with minimum
> effort. Right now, you're all stuck rewriting all your .rc files and
> creating .msvc.rc files.
>
> By the way Mark, you should extend this to definition files. Once
> again, MSVC is incompatible with all the ReactOS .def files, which
> have been tailored so that Mangle32-gcc can understand them, so
> you'll have to create msvc.def files as well.
>
> The more rbuild can generate independently, the better. You get MSVC
> files *after* running "make msvc8", and it's that step that would be
> creating the .def/.rc files for MSVC anyway -- what exaclty is it all
> you're complaining about regarding "MSVC" compatibility? You don't
> have it, how the hell can you lose it, and more importantly, why is
> the only suggestion that will finally let you have it "disliked"?!
>
> You make no sense.
>
> --
> Best regards,
> Alex Ionescu
Forgot to attach autogenerated sample files
_____
From: Marc Piulachs [mailto:marc.piulachs@codexchange.net]
Sent: Friday, November 09, 2007 7:24 PM
To: 'ReactOS Development List'
Subject: rbuild auto generated resources
>From all changes introduced on my rbuild branch auto generated resources
seems to be the most controversial by far so I will try to explain here the
design decision behind it
One of my particular obsessions is trying to optimize and automate the
maxium ammout of things, if something can be reasonably created
automatically why do it by hand?
CURRENT SITUATION
=================
Currently the version common defines REACTOS_STR_FILE_DESCRIPTION ,
REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized
resources and theme manifest are added to [modulename].rc , rsrc.rc or
splitted between both.
Problems:
- Theme manifests files "manifest.xml" are architecture
dependent (X86)
- Duplicated content, we will have hundreds of identical
manifest files for every aplication
- No way to compile an aplication without manifest
- No way to compile an aplication with only specified
localizations
- Duplicated work, rbuild has all the information required to
automatically generate the defines
- If we decide to rename or introduce a new define in the future
we will have to edit all resources by hand.
- Resource localizations are compiled with any control , the
only way to check if they are included is by hand.
Advantatges to my proposal:
- It solve all the above problems.
- Reduce man work
- Allows future changes in the format (editing the resource
generator source code (1 file) vs all resources files on SVN)
- It's the base to other future enchancments , when a new
feature is added to rbuild we have just to modify it and all modules will
automatically inherit it.
An most important of all , it represents a change of the model to a metadata
oriented build process. You describe the content (source code , resources
...) rather than the build , rbuild uses that information to generate the
apropiate image (as always) but this information can also be used for
multiple other things, analitics , reports , web ....
How does it work?
=================
First of all IT'S OPTIONAL , you can decide to use it or not, your choice.
We will use the eventvwr.rbuild as sample:
<?xml version="1.0"?>
<module name="eventvwr" type="win32gui" installbase="system32"
installname="eventvwr.exe">
<include base="eventvwr">.</include>
<include base="eventvwr" root="intermediate">.</include>
...
<!-- Auto generated stuff -->
<automanifest>manifest.xml</automanifest>
<autoresource>auto.rc</autoresource>
<!-- Authors -->
<developer>mpiulachs</developer>
<translator>cfinck</translator>
<translator>fireball</translator>
<translator>mpiulachs</translator>
<metadata description="ReactOS Event Log Viewer" />
<!-- Avialable localizations for this module -->
<localization isoname="de-DE">lang/de-DE.rc</localization>
<localization isoname="en-US">lang/en-US.rc</localization>
<localization isoname="es-ES">lang/es-ES.rc</localization>
<localization isoname="fr-FR">lang/fr-FR.rc</localization>
<localization isoname="ru-RU">lang/ru-RU.rc</localization>
</module>
to turn auto resources on we have to add the <autoresource> element with the
name of the resource that will be created in the INTERMEDIATE folder in this
case it will be named "auto.rc".
It will also automatically create the apropiate manifest.xml file for the
architecture being build (x86 or PPC) and will reference it in "auto.rc"
Also it will validate and include the localizations, even it has
localizations for 5 languages it will only compile those specified on
languages.rbuild
See attached files for autogenerated content
I tried to explain the motivation behind my changes and why I think they are
positive , of course I'm open to your questions , ideas or comments but
please be contructive and argument your point of view , "I don't like it ,
we won't use it" as someone said is not an expected opinion.
/Marc
As most of you know, Casper created a small tool rgenstat (tools/rgenstat)
that is able to parse source code for modules specified on apistatus.lst
seeking for public APIs decorated with the @implemented or @unimplemented C
comment. Rgenstat when invoked typing "make rgenstat" it produces an xml
file containing all the functions and it's current implementation status.
With this database we can do all sorts of automatic compatibility reports .
see for example wine's equivalent http://www.winehq.org/site/status or
http://www.codexchange.net/roslib generated from incomplete reactos data ,
(work in progress)
As it easy and not intrusive I would suggest using this feature to kernel
and core developers. Fireball , GreatLord , Jim , what do you think about
that ?
/Marc
Hi,
Here is a list of files that use ntuser/object.c
As you all see, we Dereference more than we Reference! Reference is 0 so we are
using Dereference as a delete? This is a mess! Not once is a Thread referenced!
Thanks,
James
./callproc.c:52: ObmDeleteObject(Handle,
./hook.c:209: ObmDeleteObject(Hook->Self, otHook);
./cursoricon.c:413: ObmDeleteObject(hCurIcon, otCursorIcon);
./cursoricon.c:487: Ret = ObmDeleteObject(CurIcon->Self, otCursorIcon);
./menu.c:320: ObmDeleteObject(Menu->MenuInfo.Self, otMenu);
./window.c:433: ObmDeleteObject(Window->hSelf, otWindow);
./accelerator.c:365: ObmDeleteObject(hAccel, otAccel);
./accelerator.c:374: ObmDeleteObject(hAccel, otAccel);
./accelerator.c:414: ObmDeleteObject(hAccel, otAccel);
./callproc.c:64: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable,
./callproc.c:88: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable,
./hook.c:113: Hook = ObmCreateObject(gHandleTable, &Handle, otHook,
sizeof(HOOK));
./monitor.c:92: Monitor = ObmCreateObject(gHandleTable, &Handle,
otMonitor, sizeof (MONITOR_OBJECT));
./cursoricon.c:399: CurIcon = ObmCreateObject(gHandleTable,
&hCurIcon, otCursorIcon, sizeof(CURICON_OBJECT));
./menu.c:333: Menu = (PMENU_OBJECT)ObmCreateObject(
./menu.c:442: Menu = (PMENU_OBJECT)ObmCreateObject(
./window.c:1537: ObmCreateObject(gHandleTable, (PHANDLE)&hWnd,
./accelerator.c:351: Accel = ObmCreateObject(gHandleTable,
(PHANDLE)&hAccel, otAccel, sizeof(ACCELERATOR_TABLE));
./input.c:1045: ObmDereferenceObject(DesktopWindow);
./msgqueue.c:776: ObmDereferenceObject(Window);
./hook.c:449: ObmDereferenceObject(HookObj);
./hook.c:455: ObmDereferenceObject(HookObj);
./hook.c:624: ObmDereferenceObject(Hook);
./hook.c:639: ObmDereferenceObject(Hook);
./hook.c:656: ObmDereferenceObject(Hook);
./hook.c:673: ObmDereferenceObject(Hook);
./hook.c:738: ObmDereferenceObject(HookObj);
./monitor.c:119: ObmDereferenceObject(pMonitor);
./cursoricon.c:375:// ObmDereferenceObject(CurIcon);
./cursoricon.c:386:// ObmDereferenceObject(CurIcon);
./cursoricon.c:414: ObmDereferenceObject(CurIcon);
./cursoricon.c:420: ObmDereferenceObject(CurIcon);
./cursoricon.c:532:// ObmDereferenceObject(Object);
./cursoricon.c:369:// ObmReferenceObject( CurIcon);
./cursoricon.c:519:// ObmReferenceObject(CurIcon);
