Introduction Hi all! My name is Victor Perevertkin and I am the only GSoC student in ReactOS project this year :) This is my first GSoC and I was very excited when I realized that I was selected and there will be four mentors for me. I will definitely learn a lot from this internship! My project is both simple and complicated. I want to add to ReactOS an option to install on and boot from BTRFS partitions.
This is a detailed summary of the work I've performed over the course of Google Summer of Code 2017. This was a continuation of my GSoC project from last year. Code Submitted You can check out my branch with SVN at https://svn.reactos.org/reactos/branches/GSoC_2016/NTFS You can find a list of commits made to my branch during GSoC 2017 at this link. I also worked on this project after GSoC last year and before the coding period officially began this year.
Introduction ReactOS App Manager (RAPPS) is an app used in ReactOS to download apps, tested by ReactOS team and community. It also manages apps that are installed - you can view apps that are present on your system and uninstall them. The goal of this project was to improve RAPPS and add some very useful features. Here is a video presenting it's features: Quick Links SVN branch link Unified diff as a Gist Commits Overview Table of contents Introduction Building Testing Changes made during development Application List Improvements Bulk installing Script installation Other improvements Future work Conclusions Building Building RAPPS is no different as building parts of ReactOS.
Hello, everyone! It’s me, Shriraj (a.k.a sr13). The time has come to summarize all the work I have done in this Summer of Code with ReactOS and complete this journey of my first ever GSoC, though my story with ReactOS is just beginning! TL;DR of Project Taskbar Shell Extensions: # Designed & Implemented the Quick Launch Toolbar for ReactOS. # Designed & Added support for Battery Status in notification area (System Tray).
Links: Link to my work:https://svn.reactos.org/svn/reactos/branches/GSoC_2017/usbxhci/reactos/drivers/usb/usbxhci/ Link to check out using svn:https://svn.reactos.org/reactos/branches/GSoC_2017/usbxhci/reactos/ All the commits log:https://svn.reactos.org/svn/reactos/branches/GSoC_2017/usbxhci/?view=log https://code.reactos.org/changelog/~br=GSoC_2017/reactos/branches/GSoC_2017/usbxhci?max=30&view=fe Introduction: My aim is to develop driver for xHCI which is compatible with ReactOS. For the development I’ve used Windows 2003 server edition running on Vmware Workstation. The first link points to the folder in which all main code and header files are present. To view any file, click on it and in the log; against any revision, click on view/download to see the code.
Hello, everyone! 0/ As you can see in the title, this is officially the last week of coding but not the least as we still have a week left until final evaluation period ends. As we are coming close towards the end of GSoC, you all might feel sad as I won't be able to share about my work anymore... :`( But hold your hankies, fellas, GSoC might end soon but my journey with ReactOS is just beginning.
Home stretch! Just a matter of days before Google opens up the GSoC final submission! I'll be using every minute I have available to me in the interim. Splitting A B-Tree Node Have I finally finished my magnum opus, allowing for file creation without limits on the number of files? Well, the bad news is, no, I still have more work to do on this. The good news, however, is I have this working in ReactOS!
Finally the driver is generating multiple interrupt without any issues. Whenever a device is connected or disconnected an interrupt is being generated. In windows 2003 server edition, when a device is attached windows is recognizing that some unknown device is attached and also in the device manager we can see attached devices though they are not initiated. This is a crucial step, as now any USB device can be safely initiated.
Last week went pretty well! :) In my last post, I talked about how I needed to refactor some code to fix a bug. I'm really happy with how this turned out. Refactoring As I mentioned before, the driver has a struct called an NTFS_ATTR_CONTEXT which keeps track of information related to attributes. The main purpose of the structure is to keep vital information about the attribute cached in memory, but it's also just a convenient way to pass information about attributes between functions and the driver relies on it quite extensively.
Hi, everyone! 0/ Tick-Tock is coming to an end, and the next week is perhaps the last week of coding before final evaluation starts! ;P But let's be calm and discuss what happened last week. And as promised, I managed to get some demonstrable snaps this time. So, here we go! As told in my last blog, we got some flashy new icons for the stobject modules I worked on.
