Ros-dev

ros-dev@reactos.org

5788 discussions

by James Tabor

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

16 years, 10 months

Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation

by tamlin＠algonet.se

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

16 years, 10 months

Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

by Olaf Siejka

> > > - 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.

16 years, 10 months

About UNICODE<->ASCII support.

by carlo.bramix

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.

16 years, 10 months

Online translation service

by Olaf Siejka

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

16 years, 10 months

Mile Stones

by James Tabor

To all! A monumental mile stone was crossed today at 2000z 05/11/2007. ReactOS is now a true GUI/OS. Thread batching is functional and tested good. Solitaire was the program and it only ran once, the function was SetBrushOrgEx. Thanks goes out to all of you and my excitement is the fun I am having working with all of you with this project. Sorry for things said in the past and knowing in all good intentions you all did your best to bring this project to this point. Thanks! James PS: Keep coding! and go back to work!

16 years, 10 months

work on rbuild branch

by Marc Piulachs

As some of you may know I have been working in rbuild on my own branch (http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/) for the last two weeks. I will summarize my most important changes here so anyone can give me their opinion: - Created a new concept "the cd bootstrap folder" . The cd bootstrap folder is a user customizable folder in the cd's root that defaults to the current build architecture for example i386 o ppc. - Modifed the InstallBase from the BootStrap element to be relative to the bootstrap folder, for example the usetup bootstrap: <bootstrap installbase="system32" nameoncd="smss.exe" /> will be created in : (CD)\i386\system32\smss.exe on a I386 build and (CD)\ppc\system32\smss.exe on a powerpc build - Introduced a new element "bootstrapfile" equivalent to the bootstrap for module target but applied to regular files for example : <bootstrapfile>hivecls.inf</bootstrapfile> will be placed in : (CD)\i386\hivecls.inf on a I386 build and (CD)\ppc\hivecls.inf on a powerpc build With these changes we will be able to place complete installation for more than one architecture in the same cd .Only one of the architectures will be able to be booted by default but we can include the cdmake utility + some .bat files in a (CD)\tools folder so the user can download the official CD with all supported architectures and create a bootable boot CD for a particular architecture. cool huh? - Experimental support to autogenerate rsrc.rc equivalent and platform dependent manifest.xml to intermediate folder - Add preliminary support to track authors/contributors/developers/translators for each module. It can be useful to autogenerate uptodate \CREDITS file , module/authors reports (see for example: http://www.codexchange.net/rosdoc/authors.htm or http://www.codexchange.net/rosdoc/eventvwr.htm) or even source code for modules like notevil - Autogenerate CREDITS file in intermediate folder (for now) - 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 note: The produced iso images won't boot due to relocation of the \loader folder. boot/freeldr/bootsect/isoboot.asm and isobtrt.asm will have to be modified to search \i386\loader .Probably also setuldr.sys will have to be modified. /Marc

16 years, 10 months

Re: [ros-dev] [ros-diffs] [gbrunmar] 29929: Made each service have its own pipe name as done in Windows

by Aleksey Bragin

On Oct 28, 2007, at 5:13 PM, gbrunmar(a)svn.reactos.org wrote: > - DPRINT("CreateNamedPipeW() done\n"); > + DPRINT1("CreateNamedPipeW(%S) done\n", NtControlPipeName); Success reports should usually remain DPRINT, so that they don't pollute the debug log. WBR, Aleksey Bragin.

16 years, 11 months

Re: [ros-dev] Moving some screensavers to rosapps

by Aleksey Bragin

Hi, "reactos" should have only bare minimum, so I agree about 1 gdi and 1 opengl. Other must be moved to rosapps. WBR, Aleksey Bragin. On Oct 28, 2007, at 2:32 AM, Colin Finck wrote: > Hello everyone, > > Now that we have 5 screensavers in trunk, and they are all in the > "reactos" > directory, it might be a good idea to move some of them to "rosapps". > The big question is now: Which ones shall be kept in "reactos" and > which > ones shall be moved to "rosapps"? > >> From the technical view, it's probably the best idea to keep one >> OpenGL and > one GDI screensaver in "reactos" (for example 3dtext and logon). > Please share your ideas about that. > > Regards, > > Colin

16 years, 11 months

Moving some screensavers to rosapps

by Colin Finck

Hello everyone, Now that we have 5 screensavers in trunk, and they are all in the "reactos" directory, it might be a good idea to move some of them to "rosapps". The big question is now: Which ones shall be kept in "reactos" and which ones shall be moved to "rosapps"? >From the technical view, it's probably the best idea to keep one OpenGL and one GDI screensaver in "reactos" (for example 3dtext and logon). Please share your ideas about that. Regards, Colin

16 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev