You're obliged to keep it up-to-date now :-), so it doesn't become
like VFAT "documentation".
On Oct 31, 2008, at 2:26 PM, janderwald(a)svn.reactos.org wrote:
> Author: janderwald
> Date: Fri Oct 31 06:26:23 2008
> New Revision: 37110
>
> URL: http://svn.reactos.org/svn/reactos?rev=37110&view=rev
> Log:
> - Add Documentation for netshell
>
> Added:
> trunk/reactos/dll/win32/netshell/README (with props)
On Wed, Oct 29, 2008 at 9:19 AM, <hyperion(a)svn.reactos.org> wrote:
> Author: hyperion
> Date: Wed Oct 29 08:19:21 2008
> New Revision: 37054
>
> URL: http://svn.reactos.org/svn/reactos?rev=37054&view=rev
> Log:
> deleted wine/mmsystem.h
> deleted wine/prsht.h
> deleted wine/winbase.h
> deleted wine/winnetwk.h
> deleted wine/winnt.h
> deleted wine/winuser.h
> Our SDK is in good enough shape to compile Wine: drop the #include_next hacks
> Wine compatibility fixes should go either in the SDK headers themselves or in the Wine porting SDK
This is a little late but I wanted to let you know that I love you and
want to bear your children!
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
On Thu, Oct 30, 2008 at 9:33 AM, <jimtabor(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=37099&view=rev
> Log:
> Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests.
If your using enough of the original implementation to credit Wine
then to me that means someone else at least partly own copyright to
these functions. Could you please use git blame or git web and see who
the author was of the original implementation from Wine and credit
them appropriately in the header? From time to time when someone says
'foo from wine' I get pinged from wine developers who's code is
appropriated and they ask for proper attribution. If we don't do it
right the first time, then at some point another audit of each commit
from SVN will have to happen and we will have to go back and add those
copyright holders to the files license header.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
I would like to create a /media/graphics directory in trunk to store the
template files for graphics we want to use in altered versions or different
resolutions. I start with the replacement for the explorere shutdown icon and
a question mark for message dialogs. Due to problems with drawing this icons
at the moment I store the templates only, later we can create the icons from
the templates and include in the resource files.
I suggest to store all selfmade graphics (in alterable formats, e.g. svg) in
this directory (if there is no other source).
What do you think about the change of the message dialogs icons to the tango
project icons and the question mark icon i provide, instead of the current
icon set?
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
Hello,
trunk has been frozen until 0.3.7 blockers are fixed.
Bugfix team having commit access for this freeze: Colin, Herve,
Johannes, me.
With the best regards,
Aleksey Bragin.
Hi,
I've tooled up libm from http://www.netlib.org/fdlibm/ and a hacked
floatlib.c in lib/3rdparty. With -msoft-float added in win32k.rbuild,
it works. I built the lib separate on XP mingw build environment and I
compiled and ran a fp test program (tst-ieee754.c) than compared the
results with standard gcc. The results are almost the same. The thing
even boots and draws okay. Floatlib.c is very old and I will soon
start testing with SoftFloat to replace the gcc soft float math.
So,,,,, is it posiable to build our build environment (RosBE) to
support full soft-float? So we can avoid more source in ReactOS.....
Well, except libm.a ~ 93k.
or,,,
Just support the hardware floating point and move on........
Thanks,
James
> If the current tree really builds 100% with GCC 4.3.2 or you (or someone
> else) could provide patches for getting it to work, the update should be
> done as soon as possible (but after 0.3.7 :P)
I use GCC 4.3.2 and new binutils for about a month without difficulties; if
you need any patches then please email me.
Of course, I do not insist on including it in RosBE.
Best wishes,
Dmitry