Hi
Why not create two diffrent changelog for each release.
one that contain all svn commit msg
next one is what is benefit for the user.
I think this is good idea. ´Then the user
can read what new for them. If some want really
know what we have done. Then they can read all
commit msg. I think this is good idea, and will benfit
alot of people.
I would think that ReactOs is not anywhere near being ready for themeing partially because it needs to write much more of the system software. Themeing can always be an option later. I have mentioned an alternate filesystem, and other services, but since I have not submitted code, people on the mailing list think i can not program something of the sort. I think it is great that people are wanting to understand the process of themeing but keep in mind that loading a theme may cut down on the resources available to the opertating system or may interfere with someone elses environment.
>
> From: Jonathan Wilson <jonwil(a)tpgi.com.au>
> Date: 2005/03/23 Wed PM 09:19:23 EST
> To: wine-devel(a)winehq.org, ros-dev(a)reactos.com
> Subject: [ros-dev] I think I know how uxtheme works...
>
> What I strongly suspect happens is this:
> 1.The themes service is always loaded and running and holds the theme data
> (and it contains details of which .msstyles file to use)
> 2.At some point (either at startup if the changes are global or when an app
> loads if the changes are app specific, I cant find where this bit happens
> but I suspect the themes service does this) control passes to ordinal 34 in
> uxtheme.dll (aka ThemeHooksInstall acording to uxtheme.pdb). This function
> calls an undocumented function in user32 called RegisterUserApiHooks (which
> appears to be taylor made for uxtheme to do what it needs to do).
> The function hooks:
> GetScrollInfo
> SetScrollInfo
> EnableScrollBar
> SetWindowRgn
> DefWindowProcW
> DefWindowProcA
> PreWndProc (probobly stuff that happens internally before the window
> procedure gets called)
> PostWndProc (probobly stuff that happens internally after the window
> procedure gets called)
> PreDefDlgProc (probobly connected to dialog boxes)
> PostDefDlgProc (probobly connected to dialog boxes)
> GetSystemMetrics
> SystemParametersInfoA
> SystemParametersInfoW
> DrawFrameControl
> DrawCaption
> MDIRedrawFrame (probobly related to MDI frame windows)
> This is what causes all apps (including non-theme-aware ones) to get themed
> non-client areas (window borders etc)
> 3.Apps that are theme aware have a manifest, load comctl32.dll 6.0 and
> probobly have to call InitCommonControlsEx (although I think some of the
> code in the dllmain for comctl32.dll 6.0 may also end up calling
> InitCommonControlsEx). This causes new versions of the stock classes
> (button, list box, edit, combo box etc etc etc) to be created and
> registered. A cursory examination of some of these classes shows that they
> dont seem to "pull code" from the stock implementation in user32.dll (i.e.
> anything they dont themselves handle goes back to DefWindowProc). In
> particular, it doesnt appear as though they have any knowledge of the
> classes or window procedures contained in user32.dll.
> then 4.Apps that need to do something extra call into functions exported by
> uxtheme.dll to do whatever they need to do.
>
> user32.dll seems to have no knowledge whatsoever about themeing and
> uxtheme. All that user32 has is RegisterUserApiHooks (and the matching
> UnregisterUserApiHooks) that uxtheme uses to hook into user32.dll and do stuff.
>
> Exactly how the theme service and theme engine works "under the hood"
> doesnt matter.
> But for ReactOS and WINE purposes, I suggest we implement the following:
> 1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks (either
> reverse engineer the MS function or write our own). This will allow uxtheme
> to hook into the global drawing for things like window borders without
> user32 needing to care about uxtheme and what uxtheme does (just like how
> MS hooks into user32 that way)
> 2.Whatver code is necessary to get the hooks installed right so that all
> apps get the "global" theming like on real windows
> 3.Support to read the manifest and load a new comctl32.dll that would be
> like the version 6 from microsoft (and would contain complete theme-aware
> implementations of the stock controls just like MS comctl32.dll 6.0 does)
> and 4.All the needed uxtheme exports to make stuff run
>
> This would be the same way Microsoft does things.
> User32.dll would have no idea whatsoever about uxtheme and theming
> All apps would get non-client-area themeing like on windows.
> And only theme aware apps would get themed controls etc (the rest would get
> "stock" windows controls)
>
> Oh and btw, if this "reverse engineering" is not "clean room" enough for
> WINE and ReactOS, let me know and I will stop posting it :)
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
Hi,
with my last changes (r14296), coLinux does start and does mount the
root partition. It exist an second problem. The coLinux window is only
shown for a very short time. I'm not so familiar with the gdi, user and
win32k code. I cannot fix the second problem.
- Hartmut
On 24-28 of March, between 05:00 and 08:00 CET, svn.reactos.com may be unavailable
for a duration of up to 1 hour each day due to maintenance work at the hosting center.
Sorry for the inconvenience,
Casper
Hi,
--- Boaz Harrosh <boaz(a)hishome.net> wrote:
> How is ReactOS's current (future) system?
I think ReactOS's registry is binary compatible with NT4. It and the windows 2000 format was
documented/reversed for samba and the linux ntchpwd bootdisk projects. If I remeber right Eirc
Kohl offered to release some of his work to Wine for the binary format so you might want to ping
him about the implementation details.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
Hi Emanuele,
--- ea <ea(a)iol.it> wrote:
> I tested twice fresh builds before committing and the 3rd time right now
> with local repository at revision 14248. For me it compiles, installs
> and boots correctly (qemu 0.6.1). Can you tell me more about the lock? I
> can't rollback right now because I am going out to work in a few
> seconds. Feel free to restore subsys/csrss and subsys/smss to 14243 if
> you feel this is a blocking bug for you.
Sorry, its not your problem. I rm -fr'd my reactos tree and did a clean CVS checkout and things
are cool now. I guess the current build system left some crap around that caused problems. Nice
work btw on the smss stuff. How much trouble do you think it would be possible to make a native
mode console application in smss like the Windows recovery console? I have been thinking about
doing this for the boot CD for a while but would like to make it more powerful than the Windows
recovery console.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
James Hawkins wrote:
>>Nobody's working on it, so it won't be supported until someone cares
>>enough to do it. I encouraged a few people to start working on it but
>>nobody did, so taking out the existing support is a way to provide
>>more encouragement. If that's not enough then the feature simply won't
>>be supported anymore.
>>
>>
I started toying around the current and old code, Gathering knowledge
and ideas. What I think of doing is:
keep the boot registry as is (more less). Put in on wine/wine/config a
key system that enables a "plugin" system of registry loaders/savers.
Builtin plugins are current format and Windows binary format. Other
formats could be easily implemented; candidates could be XML, MySQL etc...
The system I thought of would also save the hives and sub trees, to the
files/plugins it was loaded from. Each plugin could also implement a
write behind so Data don't get lost in case of a crash or power lost.
Good point with the on demand-loading/cache of keys. It should be done
this way. So in summary:
1. Implement a Memory registry with plugin drivers and mount semantics.
This driver goes here, that driver mounts there.
2. Implement 2 basic drivers: Wine builtin format, Windows binary format.
3. Enable dynamic load of external drivers.
The Initial registry system is always loaded from system.reg builtin
format which is also the "fstab" file of the registry. At minimum every
thing is exactly like now one (two) files builtin format, and that's it.
At the maximum it can be highly object oriented with per user, per
application, per group management.
Please tell me what you think.
Any libraries I should look into?
How is ReactOS's current (future) system?
Free Life
Boaz
Hi,
--- ea(a)svn.reactos.com wrote:
> trunk/reactos/subsys/smss/initss.c
"Debug Windows" fails to be registered causing it to not boot the Win32 subsystem and hard lock.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
Hi,
I just finished uploading the RC1 to sf.net
The last build worked quite well, but improvements to the branch are
welcome. If no major issues occour, we may perhaps advance to Release as
next step, already.
BTW: RosApps is from 2003, still.
They are already in the installation, aren't they?
So should they be hidden?
