Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 11 Nov '07

11 Nov '07

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

5 4

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 09 Nov '07

09 Nov '07

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

2 1

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 09 Nov '07

09 Nov '07

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

1 0

Re: [ros-dev] rbuild auto generated resources
by Marc Piulachs 09 Nov '07

09 Nov '07

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> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <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

1 0

Tracking implementation API status
by Marc Piulachs 09 Nov '07

09 Nov '07

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

1 0

Window Handle Leak
by James Tabor 09 Nov '07

09 Nov '07

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);

2 1

Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation
by tamlin＠algonet.se 08 Nov '07

08 Nov '07

jimtabor wrote: >I noticed WndProc messages originate from win32k too. The window thread is >locked and then the message is sent out. > >Example: Function call User32 -> Win32k -> send message. > >Maybe we are doing double the work when we scroll on a bar. The rapid >blinking of the bar too. We maybe sending more than one message out. Trying a hypothesis here, could it work if all such w32k-registered- and-managed window classes, if not subclassed by the app, lock visual updates while calling back into usermode (cmp. LockWindowUpdate(hWnd) )? (recursive calls, whether intentional or from buggy user-mode app code could invalidate it) >4. Fix bugs. >5. Get paid! If you solve that... :-) -- Mike

2 2

Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1
by Olaf Siejka 07 Nov '07

07 Nov '07

> > > - Declarative module localizations : Now module localizations are created > in > a declarative way which makes trivial tasks like listing non existent or > outdated language localizations in real time for example : > > http://www.codexchange.net/rosdoc/localizations.htm > > Let me know your opinions and suggestions as I would like to start > finishing > some of this features and merge all/part of my changes back to trunk > I find this part extremely important. It would allow real-time tracking of translation progress/status (if i understood it correctly) which would greatly help maintain all the growing ROS localizations and help all ROS translating teams. Such webpage, as you presented here, should be created on ROS website as soon as it would be possible.

5 17

About UNICODE<->ASCII support.
by carlo.bramix 06 Nov '07

06 Nov '07

Hello everyone, I just would like talk about a recent fix applied to one of the components of ReactOS. It is not my intention to make problems in any way with this topic, or pretending a change of the direction taken by the project (peace!). In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped. I would like that you try to review your opinion on such changes. Me too, I want final builds of executables in unicode format. I think to know almost all advantages of international support. However, I also believe that you should not see the ASCII support as something to throw out of the window, but as a chance, because not all applications in the world are compiled as unicode, so having something to test the ASCII implementation included into ROS is not a so bad idea. As I said, it is a chance for testing. Some of the work here seems derived from wine, but probably (or better: surely) people behind wine had to face to the problem called "debugging" before they got something stable. A closed-source application may not work, but at least there is a chance (perhaps minimal or even less) to replicate a bug into one of the applications available to us. Technically, it isn't a problem for me to make things working on win9x, since I just need to link to UNICOWS.DLL and the problem is almost solved. I just don't like very much that position. And I also understand that my opinion isn't important at all in front of your decisions or the ReactOS standard. Sincerely, Carlo Bramini.

5 5

Online translation service
by Olaf Siejka 05 Nov '07

05 Nov '07

I have no idea on what is being prepared or planned, nor i do not need any mean for translating RC files online. My only concern is for easier control of localisation for a given language, so i dont have to manually check every single one of the rc files. Best regards

2 1

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