Hi,
I know that for some open source projects React OS sign's windows drivers.
Could you please sign the driver for virtual floppy drive?
Motivation:
Virtual Floppy drive is very helpfull, for example take freedos floppy image,
include Samsung SpinPoint F4 EcoGreen HD204UI firmware update into the image
and put it with unetbootin on usb stick.
Problem: virtual floppy drive didn't run on windows 7 x64 because the need of
driver signing.
Homepage:
http://vfd.sourceforge.net/
Description:
>This is a virtual floppy drive for Windows NT / 2000 / XP developed by Ken Kato
>(Reported to work also on 2003 Server and Vista). <-- and windows 7 x86, too.
>
>You can mount a floppy image file as a virtual floppy drive and directly access the contents --
>view, edit, rename, delete or create files on a virtual floppy, format a virtual floppy,
>launch a program on a virtual floppy... almost anything you can do with a real floppy.
vfdwin x64 driver build (unsigned) from "critical0"
http://sourceforge.net/projects/vfd/files/2.1%20(February%2006%2C%202008)/v…
vfdwin x64 driver build (unsigned) from "Igor Levicki"
http://levicki.net/downloads/sendfile.php?path=vfd_x64/vfd_x64.zip
Discussion about the different versions:
http://levicki.net/articles/stories/2007/08/17/The_story_of_the_vfdwin_21_6…
greetings
Carsten
Hi all,
Even though Chemnitzer Linux-Tage has not been that long ago, I can
already announce that the ReactOS Project has received a sponsored booth
at LinuxTag 2011 in Berlin. LinuxTag is considered to be Europe's most
important Open-Source event and it takes place from 11th to 14th May at
the Berlin Fairgrounds.
As it is much more directed at an international audience compared to the
Chemnitz event, it would be nice if we can get many ReactOS team members
to attend it.
So far, I already got a positive answer from Aleksey for 1-2 days,
Matthias for the whole time and Victor for an unspecified time. I myself
will still be away from Germany during this time, so I won't be able to
come.
The German foundation might be able to refund some of the transport and
accomodation costs, but this also depends on the number of ReactOS
members present.
On the other hand, this mail should of course also serve as a call for
interested people to visit us in Berlin :-)
With best regards,
Colin
Hi folks,
As proposed in our urgent meeting in February, we are going to have
regular meetings at 20:00 UTC on the last Thursday of every month. Next
Thursday will be the first time to hold such a meeting.
While I was preparing the technical side (we're going to have a
dedicated IRC server with voting capabilities this time), Amine and
Victor have come up with a meeting agenda. We have agreed on the
following points in this order:
- ReactOS member definition. Proposal is not to establish a fixed
definition, but decide upon always keeping a list of people and just
giving hints on how you can get on this list
- Current ReactOS work. Developers saying what they are working on
- Status of our GSoC participation, in particular students and mentors
- Upcoming LinuxTag event on 11th to 14th May
- Sum up of previous events, ideas for next ones
- Website revamp. Current status, who is working, who is willing to help
You see that the list is more about inquiring and getting information
than doing vital decisions this time. The agenda is also prioritized so
that people may leave if they don't want to participate in website
discussions for example.
If nobody else volunteers, Amine would be in the minute taker position
again and I would take the meeting leader role.
My current list of ReactOS members is as follows. Only these people will
be able to participate in the discussions and votings, so please tell me
if I have forgotten anybody or if you want to be added to this list:
- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas (niski)
- Aleksey Bragin (abragin)
- Colin Finck (Colin_Finck)
- Danny Götte (dangerground)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
- Rafal Harabien (rafalh)
- Kamil Hornicek (Pigglesworth)
- Amine Khaldi (AmineKhaldi)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Art Yerkes (arty)
Everybody may join the meeting channel as a non-participating observer
though. I'll hand you all connection details when we're ready.
With best regards,
Colin
Hi!
My name is Ilie Halip, and I'm a student at the Faculty of Computer Science,
in Iasi, Romania. I'd like to take part in this year's Google Summer of
Code, and I was browsing the ideas page earlier.
What caught my eye was the Management Console, but after some discussions on
IRC, I got very excited about another thing not listed on the wiki page for
GSoC. It's about implementing support for Windows Error Reporting. It's
listed at http://reactos.org/wiki/Missing_ReactOS_Functionality. I think
it's doable in less than 3 months, and might prove to be helpful too (the
wiki page sais that :P). I'm not sure if you would accept this kind of
proposal, so I'm here to ask about that. Also, I would need a mentor to help
me with this project - so... would anyone be willing to mentor me, if this
project would be accepted? I was also looking at WMI, but I know it's huge,
and I'm not sure how much of it would be required to consider such a project
successful.
Also, another thing I should mention. I do have a full time job right now.
That's a reason I didn't dive into anything bigger listed on the ideas page.
Even though I do have some experience writing Windows drivers (I wrote a
file system filter driver 2 years back), I don't think I'd be able to write
an Intel HDA driver in less than 3 months. But I talked to my superiors, and
they are willing to let me work part-time during GSoC, so I should be able
to work for my would-be project about 30 hours/week. Do you think that's
enough?
Regards,
Ilie.
Hi Alexey,
Since you are still working on these LdrXXX functions then you maybe
find possibility
to add there some code to prevent them trapping into infinite cycle (bug 5881:
http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 )
While booted up with RAM 25 or 24 MB ROS kernel falls into infinite
cycle there,
but being booted up with 15 Mbs ROS stalls and and hangs up.
To test it is enough to run it on any VM with 24Mb of RAM.
What occurs there is infinite recursive calls, in form of
LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule ->
LdrpLoadModule and so forth.
(detailed bt is in bug 5881 description).
Maybe ROS kernel doesn't check memory availability, something like
XXXMalloc returning NULL or so.
Thanks!
-M.A.
On Wed, Mar 23, 2011 at 4:25 PM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Wed Mar 23 12:25:53 2011
> New Revision: 51123
>
> URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev
> Log:
> [NTDLL/LDR]
> - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.
> - Wrap LdrpSnapThunk() invocations into SEH.
>
> Modified:
> trunk/reactos/dll/ntdll/ldr/ldrpe.c
>
> Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=…
Hello fellow ReactOS developers and users,
Most of you might know me from IRC as encoded. I am a Computer Science
student at the Polytechnic University of Puerto Rico. Although at
times not the best IRC citizen, I've always had the best intentions
for ReactOS at heart. The following is my proposal/plan outline for
Implementing SSPI and secure authentication mechanisms for ReactOS,
including Interactive Logon.
First, some definitions:
Security Support Provider Interface (SSPI) allows applications to use
various security models available on a computer or network without
changing the interface to the security system. SSPI does not establish
logon credentials because that is generally a privileged operation
handled by the operating system(LSA).
Windows Challenge/Response (NTLM) is the authentication protocol used
on systems running Windows. NTLM credentials are based on data
obtained during the interactive logon process and consist of a domain
name, a user name, and a one-way hash of the user's password. NTLM
uses an encrypted challenge/response protocol to authenticate a user
without sending the user's password over the wire(in case there is a
wire). Instead, the system requesting authentication must perform a
calculation that proves it has access to the secured NTLM credentials.
Secure Channel, also known as Schannel, is a security support provider
(SSP) that contains a set of security protocols that provide identity
authentication and secure, private communication through encryption.
Mainly SSL and TLS, with a variety of cipher options.
Primary goals:
- Utilize wine secur32 as starting point for implementing SSPI.
- NTLM Security Support Provider (SSP)
-- Authentication
-- feature flags
-- SignMessage
-- VerifyMessage
-- EncryptMessage
-- DecryptMessage
- Small, low footprint, maintainable code
- Implement create credentials/logon/authentication in LSA
-- LogonUser
-- LsaConnectUntrusted
-- others, as necessary.
- Separate secur32 and schannel(wine has them unified)
Secondary goals:
- implement SSL/TLS/ptc SSP (using 3rd party libs)
-- GnuTLS, OpenSSL are huge and have many dependencies
-- secur32 is (theoretically) loaded and used by many system dlls,
would be very bad if it is a performance/memory hog.
-- Need to severely trim them down or use alternatives.
- run extensive tests/fix other system code paths that have been dormant/stubs
why wine secur32 is bad:
- Wine is a *nix program so its ok for them to use
dlopen(gnutls.so)... and use the system native library but we cant.
- Uses fork() to call a program in winbind(samba extra) package!
- if we want to use gnutls and such in reactos the following problems occur:
-- too many dependencies
-- problems running in native mode(lsa)
-- big footprint
-- too much code/hard to maintain
- Wine's implementation of schannel loads GnuTLS, and is barely functional.
- wine winhttp and wininet don't use schannel, and instead use OpenSSL
directly to implement SSL and TLS. This can lead to confusing
differences in certificate verification between applications. Ideally,
schannel would use crypt32 for certificate chain verification, and
winhttp and wininet would use schannel. (fixme later)
-- good news is, wine crypt32 is relatively good and feature complete
(at least seems that way).
Hi,
I guess I don't have to introduce myself all that much anymore ;)
Please see [1] if you disagree.
I plan to submit a GSoC project proposal concerning the kernel-mode
test suite, and would like to discuss a few key points to better shape
the project idea and its timeline.
Because of the broadness of the subject, I'm posting here to reach
as many ears (er... eyes) as possible, hoping for feedback from people
working on several different areas of ROS.
My "state of mind" is currently the following regarding the project:
Basic key points (I hope everyone agrees; please tell me if I'm wrong :p)
- follow Winetest "feeling" - syntax for writing tests should be almost
identical; like current kmtests demonstrate
- tests should be startable individually from a command line launcher and
follow Winetest behavior in that regard, so that an integration with
Testman is made easy
- code should be CMake and MSVC/WDK compatible from the beginning
Ideas I deem useful (would appreciate any comments)
- include buffer overrun checks, much like DPH (DPH can't be used for
this though, can it?), using e.g. a guard/noaccess page behind each
buffer. See [2] for a userland example; I'm working on a kernel-mode
one
- inspired by Winetest's broken(), one could make tests Windows-version
specific. Something like [but better thought-out in syntax]
ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...)
This would help compare different versions of Windows and much
facilitate future kernel-target switching
Questions
- as there are ... many... kernel-mode functions, it is unfeasible to
write tests for all during the project. My idea would be to create
some very thorough sample tests, then focus on the most critical
functions. "If there's time", thinly covering a more broad area might
also be very useful (as extending existing tests is probably deemed
easier than creating new ones by people later on).
I have no doubt there's enough to do, ;) but would be interested to
hear if you agree with the general strategy and what you think those
"critical" areas might be.
So what do you guys think?
Excited for your input. Thanks. :)
Regards,
Tom
[1] Hi! I'm Thomas, 23, from Germany, currently studying Computer
Engineering in Berlin. I've been hanging out on IRC as ThFabba
for some time now and submitted some hopefully-not-totally-useless
patches ;) I'm interested in.... oh well, pretty much all parts
of ROS. *g* Nice to meet you!
[2] http://www.reactos.org/paste/index.php/8697/
Good day to all,
my name is Fabio Cristini. I work as a software designer and developer in
Italy, I'm a student in Software Engineering and I would like to apply for a
React OS project proposal.
I especially like the idea of implementing an SSH Service for Windows, and I
hope I can do it for you (I like to develop an OpenSSH clone).
Please let me know if you may be intrested.
Fabio Cristini
Italian, English +1 UTC
fcristini(a)gmail.com (not registered yet)
if you can contact me in private, I can give you more details and my full
contact informations.
Many thanks
Time Commitment
I can work at this project about 20 hours a week
Optional (But Suggested)
SSH Service for Windows
http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#SSH_Service
Legal Requirements
Students are required to affirm that the following is true. I hereby swear
that I have not used nor seen the source code to any version of the Windows
operating system nor any Microsoft product that may be related to the
proposed project that is under a license incompatible with contribution to
ReactOS, including but not limited to the leaked Windows 2000 source code
and the Windows Research Kernel.
Hello friends,
I am Syed Armani, i am a 3rd year computer science student at DCE ,NCR,
INDIA
Email: dce3062(a)gmail.com
IRC: #armaan
Jabber: syedarmani(a)jabber.org
*ABOUT ME:*
I have experience of
- c/c++
- GUI development with c++.
- python
- java
- lua
- NETWORK PROTOCOLS
- NETWORK PROGRAMMING
- xhtml/css/javascript
- Assembly (mid level 8085 n 8086)
- BASH scripting.
- VIRTUALIZATION, WORKING OF HYPERVISORS AND LIBVERT.
- PHP
- MYSQL
- DEEP LEVEL LINUX OS
- BASH SCRIPTING
- LAMP/WAMP
- WEB 2.0
- Android apps development
I have a personality of a creative explorer and i always seek knowledge. I
consider experience as a very very important thing.
My wish is to take part in the development process of react os.
Regards
Syed Armani