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