And so this year's Summer of Code is over. I am moderately optimistic
about the outcome, but it could have gone much better...
What's there:
* the porting! I gutted rdesktop and isolated the smallest subset
possible required for the protocol and nothing else. Then I made it
re-entrant, as rdesktop was affected by the "accumulate and fire"
anti-pattern, setting function arguments in global variables and
preventing multiple instances of the library from running (a no-no for
an ActiveX control, and for any library in general. Then, again,
rdesktop was no library in the first place)
* the porting, part 2. I implemented all the "orders" supported by the
RDP protocol in terms of Win32 GDI, meaning the display is fully
functional (barring the occasional artifact)
* the porting, part 3. I implemented mouse/keyboard input. You can
interact with your session. That's it. Basically, the RDP client just...
works. That's it
* the ActiveX control itself, in its glorious hundreds of methods and
properties. By far the hardest part of the project. Friends don't let
friends code ActiveX controls without ATL!
What's not there:
* the effort in learning as quickly as possible the most fucked up
component model in the history of computing had by far the largest
impact on the project, meaning in practice I was stopped halfway through
integrating the *actual* code with the extensive ActiveX dressing. In
other words, the code currently in the repository is non-functional. Go
back a couple of revisions to skip the ugly ActiveX meatworks and see
the working proof-of-concept. My biggest mistake was assuming I could
tame the ActiveX beast only armed with a stick
* some useless ActiveX glue that does not pertain to the kind of
control the RDP client is, but has to be there nonetheless
* the redirectors were not ported, and no support yet for virtual
channel plug-in DLLs. Not a giant effort, though
* the mstsc.exe shell
Miscellaneous issues: dependency on OpenSSL. This will be hard to
eradicate. CryptoAPI isn't an option, beacuse it was designed primarily
for PKI, not random arbitrary encryption protocols. In particular, the
following limitations make it unfit for use in the RDP protocol:
* each provider only supports a single size for RC4 keys, either 40 or
128 bits. Not a major obstacle, but it gets worse
* it cannot import plaintext RC4 session keys, at least not without a
convoluted workaround (see
<http://support.microsoft.com/kb/228786/en-us>). Still not major, but a
little bit worse
* it cannot perform RSA encryption without padding, required for the
session key exchange protocol. CryptoAPI will always pad the cipher with
PKCS #1 padding, limiting the plaintext to 11 bytes less than the key
size. No workaround for this
Best solution: reimplement the internal cryptography library used by
Microsoft (the library exported as SystemFunctionXXX from advapi32.dll),
which is what the original client uses
Afterword: I'll certainly continue working on this. It felt extremely
irritating to be so close to a working implementation and just burning
time on a huge glue layer probably larger than the implementation
itself. Watch this space for future news on my progress! (not in the
immediate future though. I'm still recovering from the trauma of
hand-coding an ActiveX control)
Hi,
Google Summer of Code is is ending, and I'm going to report what I've been
doing this last months. (yes I know that is my first status report when all
is ending, but as I said to Thomas, i'm little shamed of my English :) but
it's my mistake.
By the other hand I joined many times on IRC with my mentor, Thomas
Weidenmüller, and he teach me, many basic concept about ReactOS and
integration between kernel and user mode spaces, he's always been nice and
helpful with me, and always ask at my questions, and it's was very
appreciated by me.
With time I'm learning more and more about ReactOS internal implementations,
and the start was a little slow. My coding state was sometimes exceeded by
external situations, like Alex's ob* implementation, I wrongly make an
update of my tree, and many changes magically coming into my code! then
sometimes of no-booting-trunk that annoying someone! then come some cm*
issues, well, a joyride of code!
well, here is a resume of what I've been doing (and done) in the clipboard:
*Implemented the APIs to put and get data into clipboard in this formats:
Ansi Text, Oem Text, Unicode Text, Bitmap, DIB and Application specific
clipboard formats, with the ability of register new formats. Graphic formats
still need some testing.
*Implement the capability of Delayed Render Format, is like put a specific
format type, but not the data, and then, when some application request this
data, in this format, the requested application must render it and put it
into the clipboard.
* Implement the implicit data format conversions between some types of
format, in example: if you put an Ansi text, then you can request a Unicode
Text, and the same for graphics.
* All the function to work with Formats, (not its data), like registering,
counting, enumerating, getting the priority formats, query availability,
etc.
* Implement the window chaining, of the clipboard's viewers (when a format
is getting into clipboard all this windows are notified), add, remove, query
windows, in the chain.
* Appropriate handling of owner window, that rules the clipboard!
*Of course, open, close and empty clipboard functions.
*Added many test cases to the regression tests of user32, clipboard area.
and More:
I worked very hard on shell32.dll to make work cut/copy & paste capabilities
on shellfolders of explorer. (not on desktop ): now working! This
implementation is indirectly related to clipboard, but is directly related
to final user!
Now you can copy a file and then paste its link, and create shortcuts of any
file (even in desktop, but not from desktop), I don't test make a shortcut
of a shortcut!
I'm work now on that.
This time I worked too on many small patches that I put in bugzilla. Some
others patches still here on my working copy.
Sorry again for my no communication.
If someone want to ask me about this or else, my nick in IRC is P43LOk, I'm
going there very often.
Best Regards,
Pablo
I just released 0.3.0 RC2 to SourceForge and you can download it here:
https://sourceforge.net/project/showfiles.php?group_id=6553&package_id=6629
This is our final sanity check before we release the final version. I
am planing on uploading the release to to SourceForge on Wednesday night
and then Thursday morning will be our official release time. Frik or
MGW, will you be able to update the home page on Thursday morning? If
not let me know and I can do it if we have a graphic ready.
Note to all devs and contributors:
We need a change log! I have made a svn log for all commits. It can be
found at http://www.brandonturner.org/log.txt . Please let me know if
you are going to do your own change log, otherwise I will do a change
log for everyone else on Tuesday night, but no promises I will find
everything you did.
--
Brandon Turner
ReactOS Release Engineer
Blog: http://www.amateurgramming.com
Request: SLOC stats of ReactOS 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0
SLOC = source lines of code
I would like to compose some neat statistics about ReactOS (for
reactos.org) and I need help of people with unix compatible operating
systems (because the only reasonable SLOC scan tool "sloccount") isn't
available for Win32. If you get it working with Cygwin, CoLinux, etc.
under Win32 it's fine too.
sloccount: http://www.dwheeler.com/sloccount/
Please scan the source code (export it from svn; don't scan svn dir
directly) of 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0 (current 0.3.0 rc3 branch).
General information about SLOC:
http://en.wikipedia.org/wiki/Source_lines_of_code
If you don't want to hassle with svn, then download the following
source code archives from sourceforge:
0.0.1.0: http://prdownloads.sourceforge.net/reactos/0010_source.zip
0.1.0: http://prdownloads.sourceforge.net/reactos/0100_source.zip
0.2.0: http://prdownloads.sourceforge.net/reactos/reactos-0.2.0-source.zip
0.3.0 (rc2): http://prdownloads.sourceforge.net/reactos/reactos0.3.0-RC2-src.zip
If you think you found a better tool to count SLOC's then share the results too.
And please share the results from "sloccount", even someone else
already posted stats about the same version. There might be
differences in the results and it's better to have more stats of the
same version to verify and use average values.
Please scan the "reactos" dir (and all it's sub-dirs) and add specific
of which version of ReactOS & sloccount you have used to gather the
stats.
Thanks for your help.
Klemens
Hello,
I've experimented a little with the DrFred's GNU indent settings,
they were good, however I advanced them more and found out almost
perfect set of settings which suits our proposed/official coding
style (the only debateble part was using TAB vs. SPACEs, but for some
areas like ntoskrnl TAB-based indentind is de-facto not used at all).
For further info / remaining problems, look to the following URL:
http://www.reactos.org/wiki/index.php/GNU_Indent
WBR,
Aleksey Bragin.
If someone has some freetime and want improve cmd.exe, the following
website has listed a lof of undocumented commands, flags, tricks, etc.
of several win version:
http://www.robvanderwoude.com/
(click on batch files in the navigation bar)
We are actually going to have an RC3 this release because we got 2 last
minute bug fixes and will be adding a wallpaper to the bootcd. It will
go out Sunday Aug 18th. This should be the last RC before final.
Thanks for you time and understanding!
--
Brandon Turner
ReactOS Release Engineer
Blog: http://www.amateurgramming.com
-------- Original Message --------
Subject: [ros-kernel] How do device drivers fit into the project goal
Resent-Date: Fri, 16 Oct 1998 22:08:57 -0500
Resent-From: ros-kernel(a)sid-dis.com
Date: Fri, 16 Oct 1998 20:05:44 -0700
From: rex <rex(a)lvcablemodem.com>
Reply-To: <ros-kernel(a)sid-dis.com>
To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com>
In a recent response to a message I posted, dennis
mentioned that the goal of the project is to build an
OS that gives the user a Win32 compatable
environment. He also stated in that message that
the guts will not necessarily be the same as WinNT
or Win98, insted that might actually work correctly.
A while ago a similar discussion came up and it was
agreed (or so I remember) that we would try to
remain compatable with device drivers so we don't
have to reinvent them all. I was reading a status
message from Connor and I realized that he has
some interesting ideas for building a high performance
video subsystem, but my brief glance at his description
left me thinking that legacy drivers probably will not
plug into it. This does not bother me, however we
should discuss this and decide on a clear goal for
ReactOS regarding driver compatability.
It's my impression that the following statement
sums up the goal of the project:
ReactOS will be a freely distributable operating
system capable of running Win32 applications,
that is Win98 and WinNT applications.
The main project page states the following:
"ReactOS will be a free operating system that
can run software and drivers compatible with
Windows NT."
I hope I'm not stepping on any toes, but I think
before Conner builds a fast but not necessarily
compatable video system, or Arindam builds a
compatable but not necessarily most effecient
network subsystem, perhaps we should reaffirm
the goal so noone takes the wrong path.
Personally, I vote for driver compatability. I think
there is enough room internally for improvement
over the MS design (though I haven't actually seen
it) that we dont need to change the structure of
the driver interface. Of course, I haven't yet seen
the Network or Video driver interface other than
block diagrams and broad overviews.
Rex.
-------- Original Message --------
Subject: [ros-kernel] Re: How do device drivers fit into the project goal
Resent-Date: Sat, 17 Oct 1998 03:03:33 -0500
Resent-From: ros-kernel(a)sid-dis.com
Date: Sat, 17 Oct 1998 01:03:07 -0700 (PDT)
From: Jason Filby <jasonfilby(a)yahoo.com>
Reply-To: <ros-kernel(a)sid-dis.com>
To: ros-kernel(a)sid-dis.com
Hi,
---rex <rex(a)lvcablemodem.com> wrote:
>I hope I'm not stepping on any toes, but I think
>before Conner builds a fast but not necessarily
>compatable video system, or Arindam builds a
>compatable but not necessarily most effecient
>network subsystem, perhaps we should reaffirm
>the goal so noone takes the wrong path.
The goal states that WinNT drivers must be compatible with ReactOS. I
should be able to take a graphics or network driver that was written
for NT and use it with ReactOS. Compatibility is extremely important.
That said, ReactOS drivers don't necessarily have to run under NT. See
what I'm saying here? We MUST provide the mechanisms for NT drivers to
work - but CAN also add additional mechanisms that only ReactOS
drivers use so that they perform better.
Personally, I'd prefer that the mechanisms that allow NT drivers to
run 100% are implemented first -- then we can add our own mechanisms
that only drivers written to take advantage of them use. But you don't
necessarily have to go in that order.
At the end of the day, we'll run drivers for NT perfectly (1st
priority) and drivers for ReactOS even better (2nd priority).
I don't know if I explain this all clearly enough -- so, if not, just
tell me.
- Jason Filby
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
