Hi.
I am Boris Atamanovskiy, first year undergraduate student from Moscow
aviation institute, Russia. I am interested in rapps.
I have some questions about it. What should I use, rapps_new C++ or rapps C?
Should rapps be a command-line tool with GUI frontend or GUI app with
command line args?
I am new to Windows development, so any advices about resources for
learning it will be helpful.
Regards,
Boris Atamanovskiy
Hello everyone,
My name is Oleg Brezhnev, i am 3rd course student of Software
Engineering in Penza State University, Russia. It would be very cool
to get some driver programming experience, since recently i got a work,
where driver programming skills will be really useful.
So i want to implement the AHCI SATA Storage Driver or anything related
to drivers.
But the problem is i do not have any experience in driver devleopment
besides one chapter of a small book about NT-drivers, i've bought
today, so i can not estimate amount of work properly.
I have some experience of user-space C programming, i've wrote several
application like user control app and device manager for my company's
products.
My question is: is it ok to apply on a GSOC with proposal like this
considering this circumstances? I ready to work really hard to learn
all i need during my work and complete the task.
Sincerely yours,
Oleg Brezhnev
Hello everyone,
I am Anchit Jain, Computer Science undergraduate from BITS PILANI, India.
I am interested in pursuing SSH Service project.
I have some experience in Socket Programming and Network Protocol development
in C. Some of my work could be seen at [https://github.com/anchitjain1234](https://link.nylas.com/link/ezhvubksgc7dhi29sglp2mpvq/7af2e7b30ed04821b97b5daf…
9e7a5/0?redirect=https%3A%2F%2Fgithub.com%2Fanchitjain1234).
In past, I have implemented some basic network services like TFTP protocol and
some minor part of FTP client.
Regarding the project :- Would this project require a new SSH Server to be
written from scratch or to be build upon some existing codebase like Apache
Mina etc.?
I would request potential mentors to guide me for the same.
Thanks,
Anchit Jain

> Hi,I'm Chu Bingxiang, from Harbin Engineering University, China, and this is my third year in this University. This is my first time met with ReactOS, and I found that I really love this project. And maybe "Fully Integrate lwIP" is my dish.After reading the idea-list, I think this one is to fit IwIP well with ReactOS and I need to try my best to make further progress in it.Now I'm facing a big problem, that the newest version of lwIP is 1.4.1, and 1.5.0 is going to be released, which one should I learn?
Hi Chu, welcome to ReactOS!
The lwip version won't be a problem for two reasons:
* We try to stay up to date whenever a new release is available.
* There *shouldn't* be significant differences between lwip versions to
the point of needing to rewrite the whole tcpip driver when a new lwip
version is released.
Also, please consider joining our IRC channel if you need realtime
discussions/interactions.
Good luck!
Cheers,
Amine.
Hi,I'm Chu Bingxiang, from Harbin Engineering University, China, and this is my third year in this University. This is my first time met with ReactOS, and I found that I really love this project. And maybe "Fully Integrate lwIP" is my dish.After reading the idea-list, I think this one is to fit IwIP well with ReactOS and I need to try my best to make further progress in it.Now I'm facing a big problem, that the newest version of lwIP is 1.4.1, and 1.5.0 is going to be released, which one should I learn?
Cheers,
初炳享Chu Bingxiang哈尔滨工程大学计算机科学与技术学院Computer Science and Technology of Harbin Engineering University
Registration is closed! They cant report to JIRA.
> Hello, we normally ask that bug reports be opened on our JIRA at https://jira.reactos.org/
>
> Some months ago I had an issue with VMware, where boot would fail if I upgraded the VM to hardware version 11 or 12, and I had to set it to hardware version 10 for it to work correctly. I thoguht that issue was fixed a while ago, but it may be worth checking.
>
> On 3 March 2016 at 15:20, Thomas Schweikle <tschweikle(a)gmail.com> wrote:
>
>> Hi!
>>
>> After I managed to build ReactOS with the build system I noticed that
>>
>> live- and bootcd do not work within VMware Workstation 12. I've tried
>>
>> ESX Server too. Same: livecd just displays a black screen, while
>>
>> bootcd shows a startup menu. After selecting (or letting timeout) an
>>
>> item the screen goes black.
>>
>> Since the downloadable versions of live- and bootcd do have the same
>>
>> problem I assume this not being a problem of my build, but something
>>
>> they just do not work together with VMware Workstation/ESX-Server.
>>
>> --
>>
>> Thomas
>>
>> _______________________________________________
>>
>> Ros-dev mailing list
>>
>> Ros-dev(a)reactos.org
>>
>> http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
After I managed to build ReactOS with the build system I noticed that
live- and bootcd do not work within VMware Workstation 12. I've tried
ESX Server too. Same: livecd just displays a black screen, while
bootcd shows a startup menu. After selecting (or letting timeout) an
item the screen goes black.
Since the downloadable versions of live- and bootcd do have the same
problem I assume this not being a problem of my build, but something
they just do not work together with VMware Workstation/ESX-Server.
--
Thomas
Hi!
Building ReactOS from scratch is not really magic! It is easy. But now
I am trying to set up an automated build by jenkins, and it starts to
be a challenge ...
I could not find any repository for the build system RosBE? Is there
one? I'd like to check it out, compile it, install it and if this went
OK -- start compiling ReactOS.
Here's an other point: I've to start the build system; this offers a
shell I can enter the next commands. It doesn't seem to be possible to
handle commands to the build system in some way, without typing them
in -- exactly this would be nice to have. It would be useful for
automating with jenkins ...!
Any idea? I've gut some to push the commands in, but all of them are
crude and not really simple and stupid adding some more points of
failure to this build process.
Thanks in advance for any help!
--
Thomas
Hello all,
I am Pratik Singhal, a 3rd year undergraduate student studying Computer
Science studying in BITS-Pilani, Goa Campus, India.
I want to pursue the project NTFS Driver Improvement project as a part of
Google summer of code 2016.
I have previously participated in Google summer of Code 2015 for FreeBSD
operating system and have done some kernel hacking before.(
https://wiki.freebsd.org/SummerOfCode2015/CubieBoardSupport)
I have also made a mini operating system of my own.
I am sure, that the experience I gained while previously for FreeBSD will
certainly help me in understanding the ReactOS code base quickly which will
be useful for the project. I don't have any significant experience on
working with file systems before, but I am confident that with some
guidance from fellow developers I will be able to learn new things which
will help in completion of the project. Also, I haven't had any access to
Windows source code , so that shouldn't be a problem.
We will have to figure out concrete goals of the project, full term and mid
term deliverable and a plan for completion of project, if it is to be
selected for Google summer of Code.
It'll be great if somebody, could mentor me for this project.
Thanks,
Pratik Singhal
Hi,
After five years the ReactOS Project is returning to the Google Summer
of Code[1]!
On the heels of the 0.4.0 release the project's aim is on creating
smoother user experiences and generally making the system feel more
robust and pleasant to use. The team is looking for students interested
in learning more about the NT architecture that underpins the most
widely used desktop operating system in the world and who wants to take
part in the creation of an open source implementation of it.
Please head on over to the project proposal page[2] to see some of the
ideas we've come up with so far. If you have your own bright idea on how
to make ReactOS even better don't be afraid to share as we're always
open to new ideas.
Either way please head over to the IRC channel[3] to give us a shout if
you're interested. We promise, we don't bite. Mostly of the time ;)
Cheers,
Amine.
[1] https://summerofcode.withgoogle.com/organizations/6324900541235200/
[2] https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas
[3] https://reactos.org/irc
Hi guys,
I would like to understand whats the rationale behind changing the ReactOS
trunk version from 0.4-SVN to 0.5-SVN (see revision 70818) whereas we
have just started to release ROS 0.4.0 only?
Thanks in advance for your explanations!
Cheers,
Hermès.
Hello there,
A couple of you have already seen me make this request in IRC, but I
will make a more formal one here.
I've noticed that ReactOS still uses the Subversion VCS, and while this
might have been a good choice when it was initially set up, in 2016, it
is a rather backwards and self-defeating method to develop software.
For users without write access to the repository, developing against it
means that SVN serves barely better than copying a whole directory just
to do a diff against it. Submitting patches means that they'll not be
split up into logical steps (commits), and increases the difficulty of
determining what a patch contains, or even making a sane commit message
for it.
In the modern DVCS world, this simply doesn't need to hold true. Each
clone of the repository is exactly as the name implies: it's a clone.
Users that want to hack away on the source are freer to do so, create
their own private branches, commit to all their heart's content, and
submit a pull request back to the project (don't think of GitHub as the
only example of pull requests: they come in many forms and can even
include "sending patches to a mailing list", which would still retain
better properties than the Subversion model).
I do urge to give consideration to moving development infrastructure to
Git[*]. It would greatly ease both developer burden, and especially
contributors' burden. It is, simply, what the modern world uses. :-)
Secondary tale: I'm aware of git.reactos.org and GitHub both having a
git-svn clone of the repository. These are "okay" for the most basic
glances of the repo, but be warned that git-svn is unmaintained,
extremely buggy, and should never be used for a serious migration. For
a migration, we'll use reposurgeon. Each repository is unique and the
problems cannot be fully automated away, sorry. Human intervention is
required to do these properly.
---
Now that I've talked about why, I'll note some observations about the
Subversion repository in its present state:
* Multiple logical projects exist in the namespace. At the very least,
each of the subdirectories under /trunk should be translated to
independent Git repositories. If there are even more historical ones
(I've only looked at HEAD), we should get a list of them.
* Old versions of RosBE are under /tags. Is RosBE maintained
elsewhere?
* A lot of old and new branches. If any of these are already merged
into trunk, it may be best to just discard their preservation. Per-
developer branches might work out best if each developer took
'ownership' of them with independent repository clones. An
infrastructure and organization like https://git.kernel.org/ may be
worth looking into.
* Tagging conventions at least appear sane and logical, but they
should be named with more conventional names for Git, usually a bare
number or prefixed with v. For example, "0.3.17", "0.4.0", or
"v0.3.17", "v0.4.0" -- this is a pure policy decision, but with one-
project-per-repository, it keeps things looking clean.
* It is very large. Over a gigabyte as a live repository, 14GB as a
full stream dump. It will require a lot of memory to process and I'm
not sure my own system will handle that. It will also take a long time
to process and develop a migration -- the upper bound can be on the
order of months of work. Development in Subversion should not be halted
until the day the migration is being completed.
[*] Okay, it doesn't have to be Git. Hypothetically, any DVCS will do,
but only Mercurial has enough traction to be a viable alternative.
Thanks for listening,
Mike
On Thu, Feb 25, 2016 at 5:54 AM, David Quintana (gigaherz)
<gigaherz at gmail.com> wrote:
> I think the real goal with moving to a platform such as github is reducing
> the entry barriers for new contributors. As it has been mentioned already,
> almost all projects who moved from SVN with "send patches" contribution
> system, to Git/Hg with Pull Requests have got non-negligible growth in
> contributions.
>
I don't know... Speaking about "the entry barriers for new
contributors", this is contributing now:
1. svn checkout svn://svn.reactos.org/reactos/trunk/reactos
2. // make changes
3. svn diff > patch_for_JIRA_issue
compare it with "Git/Hg with Pull Requests":
1. Create/Log in to your GitHub account
2. Go to the page for the code respository you want to contribute to
(the “upstream”)
3. “Fork” the repository (this creates a clone to your GitHub account)
4. Create a local clone of your fork with git clone
5. Create a local branch for your changes
6. Make your changes and commit them to your local branch with git
commit, ensuring to include a descriptive commit message
7. Push the branch to your GitHub fork using git push
8. Go to the page for the upstream repository go to the pull requests
tab
9. Click the “New Pull Request” Button
10. Select the branch you want to submit, and write a summary of what
your change explaining what it is intended to do and how it is
implemented
which is the process for "Raising a Pull Request" described in here:
http://oss-watch.ac.uk/resources/pullrequest (the preferred source
chosed by Google search for explaining to me what a "pull request" is).
Ignoring the fact that new ReactOS contributions will have as
prerequisite the signing up for a (commercial) third party service,
GitHub may appear a good move for those familiar with GitHub intrinsic
knowledge, but it doesn't to for the rest of us.
I know that Amine Khaldi offered (on IRC, on #reactos-dev) to help to
"resort to manually relaying to GH" "only if someone doesn't want to"
sign up, but this will be counterproductive (who wants to be a burden
and to abuse in such a way precious developer's time?) and will most
likely prevent many not-so-motivated (but potentially precious)
contributions outside this cherished GitHub community.
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of a month, 25th of February, 19:00 UTC, as usual.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Please send agenda proposals to me before the meeting.
Regards,
Aleksey Bragin
Nearly ten years ago the ReactOS Project released version 0.3.0. Today
we are proud to announce the formal release of version 0.4.0!
A great deal of work has gone into making this release happen and as we
look back it is remarkable to consider how far the project has come
since that release a decade ago. This release is both a celebration of
and a testament to everything that the ReactOS team and community has
achieved together.
Here we document some of the highlights that separate 0.4.0 from not
just the 0.3.17 release but also the cumulative achievements that the
0.3.x series achieved: https://reactos.org/project-news/reactos-040-released
A changelog is available at: https://reactos.org/wiki/ChangeLog-0.4.0
Thank you to all of you for having stood by the project for this long
and we hope rewarding journey.
For those of you chomping at the bit to check out the release, please go
to the download page to get it now: https://reactos.org/download
Hi all ! Please have a look at
http://www.reactos.org/forum/viewtopic.php?f=2
<http://www.reactos.org/forum/viewtopic.php?f=2&t=14713> &t=14713 , I think
these two posts (at the time of writing this mail) show/remind few points
about ReactOS that need to be more emphased/better explained in our website
(and concerning the license, better be shown; notice that we run with GPL +
BSD for some parts of the code).
Regards,
Hermès
IIRC, it's a hack because neither x nor y is usually -32000, so those are flag values instead of fixed actual values. You have enough physical screens laid out in a line it's possible (16 1080p + a 1280 wide one), but still unlikely on one system given it would take multiple video cards to drive that many. The desktop as a decorated window hides the resize frame and title bar by positioning outside the effective area of a multiple screen layout and using a width and height that just encompasses the layout in Display Properties as the client area dimensions, with (0,0) of the viewports being one of the corners of the primary screen's client area. This forces at least one position coordinate to be negative by at least the width of the resize frame. I forget whether this is documented in the DDK or SDK, sorry, and which edition.
------ Original message------From: James TaborDate: Sat, Feb 13, 2016 12:03 AMTo: ReactOS Development List;Cc: Subject:[ros-dev] [ros-diffs] [hbelusca] 70713: [WIN32SS] - Fix orthograph - Mention in the code that some stuff are hacks & need to be fixed. - Add parentheses around bit checks.
Hello,
Why is this a hack?
Thanks,
James
Modified: trunk/reactos/win32ss/user/ntuser/winpos.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/winpos…
==============================================================================
--- trunk/reactos/win32ss/user/ntuser/winpos.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/user/ntuser/winpos.c [iso-8859-1] Fri Feb 12
16:40:36 2016
@@ -724,8 +724,8 @@
pwndParent = Window->spwndParent;
if (pwndParent == UserGetDesktopWindow())
{
- ERR("Parent is Desktop, Min off screen!\n");
- /* ReactOS doesn't support iconic minimize to desktop */
+ ERR("FIXME: Parent is Desktop, Min off screen!\n");
+ /* FIXME: ReactOS doesn't support iconic minimize to desktop */
Pos->x = Pos->y = -32000;
Window->InternalPos.flags |= WPF_MININIT;
Window->InternalPos.IconPos.x = Pos->x;
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Feb 10, 2016 at 5:28 PM, <hbelusca(a)svn.reactos.org> wrote:
> else // if (SecurityData->ReferenceCount <= 1)
Is the intent to free the data while SecurityData->RefCount will remain at 1?!
Best regards,
Alex Ionescu