Hello,
I suggest this patch for fixing the italian translation of SNDVOL32.
Sincerely,
Carlo Bramini
------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada
Hello,
I'm leaving for a 3 weeks vacation (starting today) and will be accessible
mostly via email.
Have fun with the ReactOS development, and do not introduce new bugs :).
Remember - when I'm back, we're going to prepare a new release - 0.3.2.
If trunk is not ready for a release by the moment I'm back, I'll start
killing devs one by one until it's ready.
--
WBR,
Aleksey Bragin
ReactOS Project Coordinator
http://www.reactos.org
P.S. The last sentence is a joke, obviously.
The source code for ReactOS is only 30MB.
The project has been going for 10 years so why so small?
Is there a need for any developers who can program assembler?
I use the ReactOS assembler. RosAsm. http://www.rosasm.org
Or do you only program in C and C++?
> We shouldn't allow attaching to a device that's still
> initlizaing, but ROS currently does because of some
> device that tries to do this, in the PnP manager or
> early boot-phase drivers (it has an auto-generated name).
> Please fix this!
Init function of that driver (PnpDriverInitializeEmpty() in pnpmgr.c) is
not called at all because of hack in IopCreateDriver(), line 1206.
Hi,
I promised a new testing/development environment but unfortunately I cannot
pursue my work because nobody has been able to fix rbuild to my
requirements. If anyone does want to see the standardized environment I
promised, please prod your local ReactOS developer for the following
features:
1) *Working* ROS_INTERMEDIATE and ROS_OUTPUT directories. They are
broken in many ways:
a. Don't work with relative pats.
b. Don't work at all for .pch files and/or compilation units.
c. Create other sorts of unpredictable errors due to hard-coded
strings/directories in makefiles or rbuild.
2) ROS_TOOLS_DIRECTORY. The ability for the tools to be outside the
ROS_OUTPUT directory, such as in c:\rosde\tools. Someone committed such a
patch but it was reverted without a newer version/fix.
a. Also requires making rbuild check if the binaries are present, and
if so, NOT to rebuild them.
b. Create -forcetools switch to rbuild which would force it to bypass
the check in 2a.
3) Tools must be built and work with the -O3 optimization setting.
Of course, I won't go into the fact that my request for the other rbuild
features such as a graphical dependency map have gone unanswered. Many
thanks to those who _have_ worked on some of the MSVC features/bugfixes I
brought forward and do the small attempt at a depmap.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
While I agree in spirit with the revert, we should use DDK #defines for compatibility. Please re-commit that part.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: March-30-07 11:39 AM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 26210: - Revert useless commit: * No need to copy stuff from DDK, it's prohibited (#define _INC_NEWDEV) * #pragma was put there especially, and no reason to remove it was said * pushpack /
I recenly found out about this website. I checked out the sources (great)
and tried to run React OS under VMware player (not so great) and even tried
some of my sw to run under it (disaster!).
I have a few questions:
1. I noted some inconsistencies in handling 8-bit/UTF-16 translation in
..A/..W calls between ...A functions in graphics (TextOut...) and
synchronization (CreateSemaphore...). Graphics part always allocates memory
(HeapAlloc) - a waste of time, IMHO.
2. I'm, not sure if is there a list of already checked/done, but not
verified/not implemented API?
3. How could I help (I know some C)
Regards,
dn
PS Meanwhile, I was reading Doxygen & could not figure out how
MultiByteToWideChar() works (=i.e. how you implemented it), but I think it
calls RtlMultiByteToUnicodeN(), which implements CP -> UTF-16 mapping for
currently selected CP, and RtlCustomCPToUnicodeN() for any other CP. Some my
programs use MultiByteToWideChar() with CP_UTF8 which is IMHO NOT
implemented!?!?
May I work on this (in my spare time)? Is somebody else working on this
area?
Is it possible, that one of the official ROS-developer can contact
http://scan.coverity.com/index.html
to let also searched the ROS-code for bugs?
Greatings
theuserbl
_________________________________________________________________
Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit
Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu!
http://desktop.msn.de/ Jetzt gratis downloaden!
We'll.... I found out how MultiByteToWideChar (MBTWC) is implemented, and
looks OK.
But then, there are following issues:
1 some functions (DefWindowProcA) call MBTWC, but with CP_ACP and HeapAlloc
ALWAYS (IMHO should be: CP_THREAD_ACP, use some local cache if the 8-bit
string is short enough, for performance)
2 some functions (GetMonitorInfoA) call MBTWC using CP_THREAD_ACP
3 yet other functions (RegisterClassExA) call
RtlCreateUnicodeStringFromAsciiz and and RtlFreeUnicodeString later (no TEB
cache, allocation ALWAYS)
4 and some other functions (CreateEventExA) call
RtlAnsiStringToUnicodeString and use cache from TEB
5 other functions use RtlAnsiStringToUnicodeString with allocation, and
RtlFreeUnicodeString later.
6 and some other functions (SetWindowTextA) call
RtlAnsiStringToUnicodeString and RtlFreeUnicodeString (allocation ALWAYS)
Is this inconsistent or what?!
Best regards
Daniel
