Hi,
Some time ago, I thought about implementing the appearance tab of the
desk.cpl, to allow some basic theming.
This is what I've done so far:
http://static.flickr.com/76/200954523_5f103460fd_o.png
On win XP you can change and apply the colors correctly. Fonts / size is
not yet implemented, nor loading of themes from the registry.
But it doesn't work on ROS.
On 0.3.0 RC1 the ColorPicker dialog doesn't work at all. On trunk you
can at least change the color by editing the values.
But they are not applied and either not saved to the registry (regedit
always crashes) or not loaded from registry at startup.
The color button on the background page doesn't work either.
1.) Is loading of syscolors from the registry already implemented? Is
someone going to do it in the near future?
2.) How should storage of themes be done on ROS? Exactly the same way XP
does it (Control Panel\Appearance\New Schemes\xx\...) or in a ROS
specific way?
On XP Scheme names are stored in themeui.dll, I think this is pretty
complicated and is only needed for systems with users having different
languages.
Greetings,
Timo
I manage to get it to boot and play on the net with mozilla and play quake in demo
mode and this bug check. Graphics mode was set to 32 bit 1024x7xx.
(./subsystems/win32/win32k/ntuser/message.c:1107) Copy message to kernel from t8
(dll/win32/winmm/mci.c:900) Couldn't load driver for type L"CDAUDIO".
If you don't have a windows installation accessible from Wine,
you perhaps forgot to create a [mci] section in system.ini
NPOOL: Low-side redzone overwritten, Block 8124d6c0, Size 4, Tag 656e6f4e(enoN)b
KeBugCheck at ntoskrnl/mm/npool.c:1514
(ntoskrnl/mm/mm.c:221) Page fault at high IRQL was 2, address c5b62
(ntoskrnl/mm/mm.c:221) Page fault at high IRQL was 2, address 5c39
Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fa)
(Look here, read on)
Memory at 0x00005C39 could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:71d92 (ntoskrnl/ke/i386/v86m_sup.S:122 (KiV86Complete))>
Frames:
<ntoskrnl.exe:6cabe (ntoskrnl/ke/i386/bios.c:70 (Ke386CallBios))>
<videoprt.sys:2722 (drivers/video/videoprt/int10.c:181 (IntInt10CallBios))>
<vbemp.sys:1ae5 (drivers/video/miniport/vbe/vbemp.c:773 (VBEResetDevice))>
<vbemp.sys:1b2f (drivers/video/miniport/vbe/vbemp.c:543 (VBEResetHw))>
<videoprt.sys:1f26 (drivers/video/videoprt/dispatch.c:49 (IntVideoPortResetDisp>
<8053881c>
<ntoskrnl.exe:1bd6 (ntoskrnl/ke/bug.c:311 (KeBugCheckWithTf))>
<ntoskrnl.exe:1d50 (ntoskrnl/ke/bug.c:493 (KeBugCheckEx))>
<ntoskrnl.exe:1d67 (ntoskrnl/ke/bug.c:514 (KeBugCheck))>
<ntoskrnl.exe:46b25 (ntoskrnl/mm/npool.c:1514 (check_redzone_header))>
<ntoskrnl.exe:46c24 (ntoskrnl/mm/npool.c:1579 (ExFreeNonPagedPool))>
<ntoskrnl.exe:5742b (ntoskrnl/ob/oblife.c:151 (ObpDeleteObject))>
<ntoskrnl.exe:12a45 (ntoskrnl/cm/registry.c:296 (CmiWorkerThread))>
<ntoskrnl.exe:63cd1 (ntoskrnl/ps/thread.c:126 (PspSystemThreadStartup))>
<ntoskrnl.exe:6cb45 (ntoskrnl/ke/i386/ctxswitch.S:82 (KiThreadStartup))>
kdb:>
Hi NG,
first I want to say that it is a great project which I want to join…
I develop since 5 years in C++, but I have only used M$ Dev Studio …
- Is there anything that can I do for the team ?
- Are there documents which describe the coding guidelines ?
BTW:
I have checked out the trunk and build the boot CD. During the setup I got a
BSOD for information check the attached screenshot…
The BSOD comes after the setup has copied the last file …
Kr
Christian
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.3/395 - Release Date: 21.07.2006
Myria wrote:
> I personally think ReactOS should support UTF-8 as a default code page, but I doubt that others agree. This function is one of the many that would have to change...
>
I should warn you: setting UTF-8 as the default codepage instantly
breaks all multibyte-aware code. How so you might wonder? UTF-8 is
"multibyte", only not "Windows multibyte": it doesn't have lead
bytes/trail bytes. Any code that parses multibyte strings needs a
special case for UTF-8 (try it yourself. Set a console's codepage to
UTF-8 and try to run a batch file). You can do it for code you write,
but for code that has already been written...
I've been looking forward to this :)
Would you like a native speaker to provide suggestions for text and grammar
improvements?
-----Original Message-----
From: fireball(a)svn.reactos.org [mailto:fireball@svn.reactos.org]
Sent: 24 July 2006 14:10
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 23265: ReactOS Status Report July 2006. If
no major issues will be found, it's going to be published today
Author: fireball
Date: Mon Jul 24 17:10:18 2006
New Revision: 23265
URL: http://svn.reactos.org/svn/reactos?rev=23265&view=rev
Log:
ReactOS Status Report July 2006. If no major issues will be found, it's
going to be published today
Added:
trunk/press-media/Status Reports/July 2006/
trunk/press-media/Status Reports/July 2006/ReactOS status report.doc
(with props)
Added: trunk/press-media/Status Reports/July 2006/ReactOS status report.doc
URL:
http://svn.reactos.org/svn/reactos/trunk/press-media/Status%20Reports/July%2
02006/ReactOS%20status%20report.doc?rev=23265&view=auto
============================================================================
==
Binary file - no diff available.
Propchange: trunk/press-media/Status Reports/July 2006/ReactOS status
report.doc
----------------------------------------------------------------------------
--
svn:mime-type = application/octet-stream
10 pages is quite an order, but I will do my best.
Can I get an approximate wordcount that you would be
looking for?
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Brandon Turner wrote:
> http://sourceforge.net/project/showfiles.php?group_id=6553&pac
> kage_id=6629
>
> I just released 0.3.0 RC1 to sourceforge. Enjoy.
I'm going to bring this up again. It's been well over a month now since RC1
was released.
What are we waiting for to get the final release out?
IMO, we should get 0.3.0 out of the door and immediately branch for 0.3.1.
More than enough work has been done to justify it.
Ged.
How long would you like the article to be? I have
nothing better to do, since I finished my Catia class
for this class cycle, and will be idleing until mid August.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
A Taiwanese user of ReactOS came into the IRC channel to report a bug. If
you set ReactOS's code page to 936, the function RtlMultiByteToUnicodeSize
will crash during startup.
I can't code a fix for it, but I can say how. The algorithm should work
like this:
- If the code page is not DBCS, don't bother, and just set *UnicodeSize to
MbSize * sizeof(WCHAR). This is already done.
- Begin counting with a length of 0.
- While MbSize is not zero:
-- Grab a byte and decrement MbSize.
-- Determine whether it is a DBCS lead byte for the code page.
-- If it is a lead byte:
--- If MbSize is now zero, increment length, set *UnicodeSize to your length
* sizeof(WCHAR) and return STATUS_SUCCESS. The broken half-character is
counted.
--- Decrement MbSize and increment your length. Two DBCS bytes just became
a single Unicode character. We ignore the value of the second byte.
-- If it is not:
--- Increment length.
- Set *UnicodeSize to length * sizeof(WCHAR) and return STATUS_SUCCESS.
Is it possible for a DBCS character's mapping to be a UTF-16 surrogate? If
so, the routine becomes more complicated.
I personally think ReactOS should support UTF-8 as a default code page, but
I doubt that others agree. This function is one of the many that would have
to change...
Melissa
ion(a)svn.reactos.org wrote:
>DstBuffer = (PWSTR)(DstPath + 1);
>
>
that looks pretty eye-burning itself... perhaps I'm just seeing things but,
1) you're incrementing a pointer without checking if it's null ( I
realize this might be safe if we can trust our caller ).
2) do we really want the address: DstPath + sizeof(PUNICODE_STRING)? I
realize this too might work, but do we want to assume that
sizeof(PUNICODE_STRING) == 2*sizeof(USHORT) ???
Hi,
Okay~ I am finishing up rewriting menu mask setting in win32 and use32. The reason
for so much junk in the menus was due to doing a full mask set for setting nothing
other than "Rect" so if the structure was packed with S$@%! it would keep it and
think it was valid data. MenuGetRosMenuItemInfo was naughty too. It set a full
mask and it was passed to MenuSetRosMenuItemInfo and saved! Until I figured this
out it was two weeks later! So I'm fixing this, Set will be selective and create
errors if the wrong combination is used.
Strings may have;
MIIM_TYPE & MFT_STRING == good
MIIM_STRING & MFT_STRING == good
MIIM_STRING == good
so you might have this -> if ((miiW.fMask & MIIM_STRING) || (IS_STRING_ITEM(miiW.fType)))
and this is good due to there might be one of them.
You can not have.
MIIM_TYPE & MIIM_STRING == bad
MIIM_TYPE & MIIM_FTYPE == bad
MIIM_TYPE & MIIM_BITMAP == bad
MIIM_FTYPE & MFT_BITMAP == bad
just read msdn doc on MENUITEMINFO structure, once you decode their logic it starts to make
sense. Remember one supersedes another.
What a mess,
James
WaxDragon wrote:
> The only bug
> I'm concerned about right now is the broken links in the start menu,
> which I think is even fixed in trunk. Nothing else can really be
> addressed at this point.
That is easily fixed with a small hack in the explorer code.
It's certainly not a correct fix, but it will ensure the links work for this
release and allow us to move on.
If you agree, I'll change it tonight.
Ged.
Dear ReactOS Developers,
I apologize for taking these extra ordinary steps in this matter but I
could not locate another way of bringing this issue to attention on your
site.
I was in the IRC channel on the 11th July '06 from about 3am to 5am
GMT... I was posing some very interesting and fundamental questions
about how the project began, it's direction. I was pleased that after a
few minutes most of the users had agreed that ReactOS is intending to be
much more than just NT compatible but in a sense 'Windows + Better'.
After this there was many hours of discussion of how to make it more
than just a windows clone, many of such involving the idea of ReactOS
being similar to Linux in some senses and how to get a Linux feel while
maintaining windows compatibility.
Near the end of the log (I hope these are saved, I have no copies
myself) an 'Alex_Ionescu' joined in on the conversation. He had many
interesting views that greatly heightened the debate to whether ReactOS
should intend to be more than windows now, or at a later date. I was
for the view that in order to gain a user base quicker that it must at
least intent to be more than a clone and was trying to illustrate why.
I first tried to illustrate this and got shot down due to my poor
phrasing of what I meant.
I tried to rephrase my point, and I began with a sentence talking about
firefox as a metaphor of another great piece of floss software. I was
interrupted by Alex_Ionescu (whom is an op in that channel) who told me
i 'must' state my reason using a single statement only and began quoting
regulations of the English language and structuring a proper argument...
so many regulations in fact i feel even if I did comply it would be
difficult to fit it in one statement.
I decided to wait until Alex_Ionescu had given up on such a silly and
clear attempt at limiting my free speech in this matter. However he
persisted to want to know what my point was on this matter, when trying
again... he shut me down. Eventually he set the entire channel to
moderated status only so only those he selected could discuss the
matter. Apparently this was until I could phrase my argument using just
one statement.
I waited until this was lifted and it was not, eventually I came back...
spoke Spanish and under another nick! Granted this was to yet again
give my point across... instead of this they knew who I was and quickly
identified me. A silly tactic I know, but having done this I was
quickly misquoted in the channel from my conversation with Alex_Ionescu
about things I was trying to explain to him as well as very childish
remarks as tho I had said "I love cock". I have high hopes for this
project and wish it every success, I had a very enlightened experience
up until meeting this person with the arguments put and listened and
responded to them well. Alex_Ionescu on the other hand obviously has no
understanding of what it means to express oneself freely, and it would
seem has a childish nature too.
I ask that the decision to give this person power of the level of
communication about the project in the channel be reviewed as quickly as
possible in light of these or other past events.
Thank you,
--
Steven Maddox
(Cyorxamp)
Cyorxamp
http://www.cyorxamp.info
Reactos can be ported to VMI instead:
http://www.vmware.com/interfaces/vmi_specs.htmlhttp://www.vmware.com/pdf/vmi_specs.pdf
It will allow reactos to switch between VMI and native HW on the fly.
Dmitriy Budko
VMware
________________________________
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
Behalf Of Jerry
Sent: Saturday, July 08, 2006 11:54 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Status of xen port?
Can reactos be made to run on Xen or native hardware by detecting either one
on the fly?
Steven Edwards wrote:
On 7/7/06, Pablo Menichini <pablo(a)menichini.com.ar>
<mailto:pablo@menichini.com.ar> wrote:
I look at xen port and it hasn't been touch in a year. Is it possible
to
port reactos to xen or is the kernel not mature enought? If it's
possible, how long can it take to have a bare minimum port?
Its possible there has just been a lack of developer resources. One of
the developers had the boot loader ported however those changes were
not merged in to the trunk.
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Tue Jul 11 01:03:26 2006
> New Revision: 23005
>
> URL: http://svn.reactos.org/svn/reactos?rev=23005&view=rev
> Log:
> [FORMATTING] / [AUDIT]
> - Cleanup a big coding-style mess
> - Add UNIMPLEMENTED macro in empty functions (otherwise we will never know if they are being called by a 3rd-party driver)
> - Add proper debug headers inclusion in every file
> - Add documentation headers into almost every file (except mcb.c and context.c - will be added later)
> - Standardize per-file headers (some files still lack contributors names, they will be added later too)
>
> No code change except for adding UNIMPLEMENTED macros in the code. Name.c unlocked because the implementations of functions are trivial and in fact could be derived from their names. Not documented functions will be further reviewed.
>
Good work... two things:
1) I think Brandon wrote a tool which does documentation headers using
TinyKRNL syntax. Since ROS's is the same (afaik), maybe you could talk
to him about it instead of doing everything by hand :).
2) Most of the functions are documented in te IFS, I'm not aware of any
undocumented FsRtl stuff... Captive also has implementations for nearly
all of them, and Captive was clean-roomed.
Best regards,
Alex Ionescu
Brandon Turner wrote:
> I have added a debug bootcd build of RC1 to sourceforge.
> So anyone out there looking to get there hands one for
> troubleshooting 0.3.0 can hop on there and grab it.
We've had this up for 3 weeks now.
Changes to trunk have been so heavy since we branched 0.3, we effectively
now have two _very_ different versions of ReactOS .... heh
Maybe our release process needs reviewing slightly ;)
Ged.
Brandon Turner wrote:
> Perhaps I am
> mistaken on the process and missed the time I should have
> made another
> release. If this is the case please feel free to let me know
> what I can
> do to resolve the the problem.
>
> Brandon
No no, nothing has gone wrong, I was just making an observation and putting
some traffic on ros-dev ;)
IIRC, a 2 month release cycle has been mentioned in the past.
Going off our recent release speed, we'd struggle to hit 1 per year ;)
At least we know ROS development is moving fast internally, even if releases
aren't.
Ged.
I opted for a different porting strategy than I originally thought. I
simply couldn't work effectively outside of Visual Studio, so I decided
to create a test application (rdesktop-core-tester), and turn the
smallest subset possible of rdesktop into a statically-linked library
(rdesktop-core). It needs a lot more work, but the results are very
encouraging
Here is the first screenshot *ever* of rdesktop running on pure Win32:
<http://img209.imageshack.us/my.php?image=whohoo3ts.png>
What's wrong with this picture, and why? All text is missing: text
output in RDP is tedious. I'll rip the code off from the X11 version,
but it's not vital for now. All bitmaps are black: this is a bug, or
rather a peculiarity, of rdesktop, which passes only part of raster
operation codes (specifically, the "source" mask), forcing me to do some
bit-juggling to turn them back into valid GDI raster operation codes -
just passing the "mutilated" code resulted in the code for the BLACKNESS
operation every time, and I think it shows. "Shut down..." is upside
down: this is a bitmap painted directly to the screen, without a raster
operation, so it worked out of the box, unlike the Windows logo in the
upper half of the dialog. It turns out RDP bitmaps are top-down, like
the framebuffer but unlike regular bitmaps. Easily solved by creating
all bitmaps with negative heights!
Also, I could not go further than this point at the time, because
keyboard input wasn't hooked up yet! I whipped up some quick support
(very easy, just pass the scancodes on the wire), and of course fixed
the aforementioned issues, tweaked a couple more things, blind-typed the
password (no text output) and...
<http://img62.imageshack.us/my.php?image=meh9ct.png>
... eh. I expected a lot better. So many bugs. And I really don't
understand why the strange "tile" effect... debugging drawing routines
is a pain, let me tell you. I would love to have a night-time bug-hunt,
but I have some *terrible* back pain, and it's becoming really hard to
sit at my desk
All in all, I must say I'm a bit disappointed that the rdesktop authors,
who in general stayed true to the Win32 equivalents of RDP features,
here and there placed annoying little idiosyncracies - like mutilating
rasterops, or using their own structures instead of the "standard"
LOGPEN, LOGBRUSH, etc. or calculating and passing around coordinates of
left-top + dimensions when they're actually RECTs on the wire, forcing
me to recalculate the RECT, and so on, and so on - that I *know* are
going to cause me headaches in the days to come (the off-by-one-pixel
bug must be caused by something like that)
Well, that's all for this week! see you soon!
Aleksey Bragin wrote:
> thanks for sharing, we appreciate more often and better communication
> with our SoC participants.
sorry for the long periods of silence, but I'm currently without
internet connectivity outside of weekends. It should go a lot better
starting next week!
I thought I might share my current progress on my Google Summer of Code
project with this lovely project... Briefly, I don't have a lot of code
but, I believe, a pretty solid design & a well laid down plan. Here is a
writeup I have made about it on my PlanetSoC 2006 blog:
<http://2006.planet-soc.com/node/361>
It's quite long, so I hope you understand why this here post is so short
:-) I'd love any kind of comment on it
See you all soon(er)!