Hi all,
Fixing GetDeviceCaps exposed a thread process shared memory issue with
WinLogon and Gimp.... Gimp bug, been around and the crash does not
make sense until you see where the fault was located. Where? In client
thread share memory. So, we need help and soon I will revert the hack
in GetDeviceCaps. Maybe we are not passing everything to User32 that
is needed.
Thanks,
James
Gentlemen,
If you don't mind me intruding, I'd like to propose some things I think
may ease life for us poor ROS devs, existing and new ones :)
First of all, I'd like to suggest 'apprenticeship programming', also
known by other names, but which commonly involves having one seasoned
programmer in charge of a particular (sub-)project and one or more
programmers following his lead. These latter programmers would be less
experienced but could work on relatively advanced stuff due to the lead
of the seasoned programmer. This model is commonly used in companies
already and if adapted for ROS it should make it much easier for
'newbie' devs to get started, pick up experience and become seasoned
devs themselves.
My own experience with picking up the USB subproject reflect this as
well. It's hard to get started without much of a lead, especially when
one's experience with the NT subsystems is limited. This is also where
documentation would have helped, bringing me to my second point:
Whenever I start a new project or implementation I first write a
technical specification detailing the exact layout, APIs and
implementation. I've heard that this is common practice in professional
programming as well as other areas. Benefits include having a good
overview of the project before one starts on it, being able to pick out
obvious oversights before writing a single line of code, having a
central place of reference (code does _not_ work for this), allows one
to quickly pick up on things during maintenance sessions (many months
later...). It'd also enable the apprentice programming system and make
it easy for the central project leader(s) to get an overview of the
progress being made.
Documentation and specifications are often ignored by programmers
because they're not deemed 'time-efficient', preferring to start
programming right away instead. In my experience and those of everyone
in high-level jobs involving anything from programming to hardware
design (like my housemate who is a senior engineer in a Dutch company
which designs chips for the telecom industry), specifications and
documentation are the lifeblood of any project.
I have elected to use both the apprentice method as well as the
documentation approach in my work on the new installer, bootloader and
USB stack for ReactOS, attracting two relatively inexperienced but
highly motivated devs for the installer (RI2, or ROSE) project already.
They have expressed interest in helping me with further projects in ROS
as well, even more low-level things. I think that this is a good example
of the future ROS should be heading towards.
So yeah, that's my rant I guess :)
*ducks and runs for cover*
Maya Posch
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