Dear all,
Due to an unexpected outage touching our hoster infrastructure, our DB server is currently down and it affects all the web services relying on it. So, don't expect Jira, boards, wiki, website, and so on to work properly for now,
I'll keep you informed when I have more information.
Cheers,
Pierre
Hi all,
Our last 3 servers are finally being migrated on Friday morning (UTC).
Expect downtimes for the following services during this period:
* https://reactos.org
* https://jira.reactos.org
* https://lam.reactos.org
As always, I will try my best to keep the downtimes low and let you know
when everything is over.
Best regards,
Colin Finck
Hi all!
ReactOS 0.4.10 will be released tomorrow, Tuesday, November 6, 2018!
The download will be officially available around noon (CEST).
A Press Kit for the ReactOS 0.4.10 release is already available:
https://download.reactos.org/reactos/ReactOS/0.4.10/ReactOS-0.4.10-PressKit…
Feel free to send it to interested parties to let them know about the
upcoming release in advance.
Best regards,
Colin Finck
The ReactOS project is pleased to announce the release of version
0.4.10, the latest of our quarterly cadence of releases. The project has
seen an increasing emphasis on consistency and stability over the past
few months, an emphasis the rapid release schedule helps reinforce to
provide a better end-user experience. Even as new pieces of
functionality are added, all this would be for naught if a user could
not access them reliably.
Booting from BTRFS
==================
The headline feature for 0.4.10 would have to be ReactOS’ ability to now
boot from a BTRFS formatted drive. The work enabling this was part of
this year’s Google Summer of Code with student developer Victor
Perevertkin. While the actual filesystem driver itself is from the
WinBtrfs project by Mark Harmstone, much of Victor’s work was in filling
out the bits and pieces of ReactOS that the driver expected to interact
with. The filesystem stack in ReactOS is arguably one of the less mature
components by simple dint of there being so few open source NT
filesystem drivers to test against. Those that the project uses
internally have all gone through enough iterations that gaps in ReactOS
are worked around. WinBtrfs on the other hand came with no such baggage
to its history and instead made full use of the documented NT filesystem
driver API.
Parallel to this effort was more basic work needed to expose the option
to use BTRFS in the ReactOS installer and bootloader. It is all well and
good for ReactOS to have a working driver, but the user ultimately needs
to have a way to put it into use. The combined effort proved fruitful
indeed, and users are invited to try out BTRFS support in 0.4.10. The
newness of the feature will mean there will be the inevitable bug here
and there, but it can only be with the community’s assistance in
reporting them that the project can further improve.
https://reactos.org/sites/default/files/imagepicker/1249/reactos_0410_1.png
Frontend Improvements
=====================
When someone uses ReactOS, the interface through which they do so is the
shell. And underpinning the shell’s functionality is the shell32
library, whose improvements are often directly exposed to the end user.
For the past few months Katayama Hirofumi, a longtime contributor to the
project, has fleshed out several new features while making improvements
to other existing ones.
For those of us whom do any significant amount of work on the command
prompt, a wide range of tricks and shortcuts exist to make our lives
easier. One such trick is being able to drag and drop a file or
directory from the file explorer onto the command line in order to get
its full path. And to complement this trick, Katayama-san has also made
improvements to those of us that are steeped in the graphical shell more
than the command prompt. In the past ReactOS offered only extremely
limited means of interacting with things in the shell. Folders in
explorer were rendered only a certain way, you could not change whether
to use a single versus double click to enter them, and interacting with
multiple windowed applications was clunky and more limited than one
might expect. All this and more have been improved, and the following
screenshot sums up that improvement far more succinctly than mere words can.
https://reactos.org/sites/default/files/imagepicker/1249/reactos_0410_2.pnghttps://reactos.org/sites/default/files/imagepicker/1249/reactos_0410_3.gif
The overall look and feel of ReactOS has also improved, or rather that
of applications that run upon it. One special class of applications
would be installers, of which the MSI family performs graphical
rendering based on font heights. Users are likely to recall in the past
a certain something just looking off when running MSI installers, just
something slightly askew in how these installers appeared.
https://reactos.org/sites/default/files/imagepicker/1249/reactos_0410_4.png
As seemingly small as these features may sound, many of them are
expected by a user and their absence does not go unnoticed. Indeed the
greatest success ReactOS could achieve is to have a user not even have
to think when they navigate the system, everything working the way they
expect. Katayama-san’s work takes us further down that path, the
culmination of a multitude of small steps along the way.
Finally, the project would be remiss to not mention the contributions of
other developers to the shell’s continuing improvement. While Hermès
Bélusca-Maïto’s important backend work remains somewhat inscrutable to
end users, fixes by Denis Malikov and Jared Smudde to deal with file
copying and shortcut creation will likely be more easily appreciated as
another sign that ReactOS works, as expected.
Stability
=========
Stability is generally a hard thing to quantify, since it is often very
subjective. Probably one thing that we can all agree on is that anything
that prevents ReactOS, or applications running on it from crashing is a
plus in the stability column. To that end while improvements to the
memory management stack by Timo Kreuzer and Pierre Schweitzer might
sound opaque and vague, they are nonetheless instrumental to ReactOS’
stability.
Simultaneously, each time a major widely used application achieves full
functionality on ReactOS, also constitutes a victory. A contribution by
Stanislav Motylkov to the C Runtime library used in ReactOS now allows
Git, the version control software used by this very project, to finally
work correctly. A nice follow-up to the self-hosting achievement from
last time around, we think many would agree.
And of course no one is a fan of BSoDs, even if they evoke a slight
sense of nostalgia. Fortunately for ReactOS’ sake, Mark Jansen was able
to nail the cause of one such crash relating to the FreeType font
library. Better that blue screens are consigned to our memories than be
a perennial part of our daily computing experience.
The surest metric of stability is however arguably how much of ReactOS
and the desired collection of applications one wants to run actually
work. For this, there as yet remains no substitute for human testing. To
that end Joachim Henze has invested a tremendous amount of time,
performing what amounts to continuous regression testing even before the
formal process of preparing the release began. The fruit of his labors
sits before you today, and while you may not see the countless number of
fixes, reversions, and tweaks that were selectively filtered to produce
version 0.4.10, rest assured that together they combine to provide a
worthy testament to the effort that is the ReactOS Project. We hope you
enjoy.
Other Improvements
==================
Stanislav Motylkov did some work on correctly retrieving BIOS
information. Now the blank entries in dxdiag are filled with actual
values. The community helped him to gather over 1000 unique BIOS dumps
to help him test the implementation.
https://reactos.org/sites/default/files/imagepicker/1249/reactos_0410_5.png
Third Party Attributions
========================
As always, it would be remiss for the project to not provide
acknowledgement of the third party bits we make use of. For this
release, Amine Khaldi has synchronized the user-mode DLLs to
WINE-Staging version 3.9. Furthermore as mentioned above, ReactOS’
support for BTRFS owes a debt of gratitude to the WinBTRFS project, of
which Pierre has synchronized to the latest version, 1.0.2.
Statistics
==========
JIRA Issues fixed (this includes both bugs and improvements) - 148
Number of commits - 660
The oldest bug fixed for 0.4.10 - https://jira.reactos.org/browse/CORE-1246
0.4.10-release branch was forked from master on 2018-08-23 after
0.4.10-dev-630-gb8e98c4
- Press Release: https://reactos.org/project-news/reactos-0410-released
- General Notes: https://reactos.org/wiki/0.4.10
- Tests: https://reactos.org/wiki/Tests_for_0.4.10
- Changelog: https://reactos.org/wiki/ChangeLog-0.4.10
- Community Changelog: https://reactos.org/wiki/Community_Changelog-0.4.10
- Community video showcasing some 0.4.10 features:
https://youtu.be/4JxfyPoCl8I
- Download page: https://reactos.org/download
_______________________________________________
Ros-announce mailing list
Ros-announce(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-announce
I've some working code for event tracing APIs like StartTrace, OpenTrace,
ControlTrace etc. Those works in Windows 10 but are not present in ReactOS
Advapi.dll. How can I add those APIs?
The ReactOS Project is pleased to announce the release of version 0.4.9,
the latest in our accelerated cadence targeting a release every three
months.
While a consequence of this faster cycle might mean fewer headliner
changes, much of the visible effort nowadays comes in the form of
quality-of-life improvements in how ReactOS functions. At the same time
work continues on the underlying systems which provide more subtle
improvements such as greater system stability and general consistency.
Self-Hosting
============
The ability to build ReactOS on ReactOS, known as self-hosting, has
often been touted as a sort of milestone in the OS’ maturity, but the
details are far more nuanced. Compiling any large codebase, whether it
be an operating system or even a web browser, stresses the system in a
myriad of ways, with one of the biggest being memory usage and storage
I/O. Code being compiled needs to be loaded from storage into memory,
and more memory is required to hold all of the compiled objects as they
are linked together. Scheduling is also to a certain extent stressed, as
most modern build systems will attempt to spawn multiple compilation
processes to speed up the build process.
In the past, ReactOS was actually capable of self-hosting, but this
capability came with significant caveats, with the biggest being this
was achieved in a much older version of the ReactOS kernel. Since the
reworking of the kernel into a more NT-compliant design and
implementation, various gaps in functionality that remained to be
completed rendered ReactOS unable to build itself again. After many
years of hard effort, including the most recent batch of filesystem
related changes done by Pierre Schweitzer, ReactOS is once more able to
self-host. And in the spirit of open source, it was the FreeBSD
project’s implementation of qsort that helped Pierre bridge some of the
last pieces needed to achieve this.
https://reactos.org/sites/default/files/imagepicker/1249/image2.jpg
Stability
=========
A major source of system instability came from the complex interplay
between the memory manager, the common cache, the hardware abstraction
layer (HAL), and the FastFAT driver. The biggest culprit in the
instability came from the significant resource leakages caused by the
FastFAT driver, resulting in it eating up the common cache to the point
where attempts to copy large files would result in a crash. To rectify
this problem, Thomas Faber and Pierre worked together to correct the
FastFAT driver’s behavior, adding in write throttling support and
restraining its usage of the cache. While a more conservative usage of
the cache might see the system behave a bit more slowly during IO
operations, it ensures that resources remain available to service for
large IO operations instead of crashing like before.
Another notable improvement on FastFAT is the rewrite of the support for
dirty volumes greatly reducing the chance of file corruptions. Whenever
a dirty volume is been detected during boot “chkdsk” (Check Disk) will
trigger a repair on those volumes. This often can protect the system
from becoming unusable after a crash. The two images below are showing
chkdsk in action:
https://reactos.org/sites/default/files/imagepicker/1249/image4.pnghttps://reactos.org/sites/default/files/imagepicker/1249/image1.png
In addition to the work done during regular development, Joachim Henze
made a significant effort during the release candidate testing to track
down regressions and other bugs that have crept in since the last
release. It cannot be overstated just how much work such manual testing
takes, and Joachim should be applauded for his dedication and
perseverance in ensuring 0.4.9 would be the best release to date.
Shell Improvements & Features
=============================
Several quality of life improvements have come to the shell, the first
of which is a built in zipfldr (Zip Folder) extension by Mark Jansen.
While Windows has long possessed this capability, now ReactOS can also
uncompress zipped files without needing to install third-party tools to
accomplish it. And as the gif below demonstrates, ReactOS’
implementation is indeed very zippy.
https://reactos.org/sites/default/files/imagepicker/1249/image3.gif
And of course with such new extensions it would probably be useful to be
able to manage them, something that Katayama Hirofumi MZ has been
working on, along with plenty of other improvements to the shell.
Another major piece of functionality that might appear simple but is
actually quite complex is the ability to choose whether to move, copy,
or link a file or folder when you drag it with the right mouse button.
This piece was completed by Giannis Adamopoulos, whose prior work has
been so integral in making the current ReactOS shell behave and function
in ways users are long used to from Windows.
https://reactos.org/sites/default/files/imagepicker/1249/image5.gif
Other Improvements
==================
There are of course plenty of other changes in less trodden parts of
ReactOS, with many people providing contributions and improvements.
These range from the functional, like zooming no longer crashing in the
Paint application thanks to Stanislav Motylkov, to more behind the
scenes like Timo Kreuzer’s continued efforts to prepare the codebase to
actually function when building a x64 target (the project owes Timo many
bottles of beer for taking on that one).
Other quality of life improvements include a new mouse properties dialog
in the GUI component of the ReactOS installer by Eric Kohl, while Eric’s
work involving starting and stopping of services, the device manager,
and the sound mixer are more geared towards long term improvement and
functionality. Hermès Bélusca-Maïto has continued his work in what might
be termed the utilitarian applications of ReactOS, such as the clipboard
viewer, the event viewer, the log-off dialog box, and the command prompt
shell. And of course one can never forget RAPPS, the gateway program
used for getting various applications installed on ReactOS. Considering
ReactOS is intended to support many different languages, it is only
appropriate that its unicode support be a priority, something that
Alexander Shaposhnikov has lent his hand to.
Compatibility in Windows is reliant on a ShimEngine that allows the
loading of slightly different versions of libraries and APIs. ReactOS is
much the same, and Mark has added the ability for ReactOS to present
itself as Windows 8.1 with the Version APIs. As a sidenote, the engine
itself proved useful in a rather unconventional manner when it was
demonstrated to help reduce the loading time of the game Globulation 2.
Of course ReactOS is not just about the features in the here and now,
but also about preparations for the future. Thomas and Vadim Galyant
have started merging in their improvements to the USB stack in
preparation for native, official support for the oft requested booting
from such devices. We’re not there yet, but we’re getting closer with
every release.
Since the transition to GitHub, the project has also received many pull
requests from old and new contributors alike. The team offers its
sincere thanks to everyone that has taken an interest in helping improve
the project, and we look forward to meeting even more of you in the future.
Syncing third parties
=====================
ReactOS, being an open source project as well as its ecosystem, uses
several bits of other open source projects. In 0.4.9 release Amine
Khaldi has synced many user mode DLLs to WINE Staging version 3.3.
Statistics
==========
JIRA Issues fixed (this includes both bugs and improvements) - 137+
Number of commits - 922
The oldest bug fixed for 0.4.9 - https://jira.reactos.org/browse/CORE-7744
Pull requests merged - 109
0.4.9-release branch was forked from master on 2018-05-20 after
0.4.9-dev-885-gddd03a8
- Press Release: https://reactos.org/project-news/reactos-049-released
- General Notes: https://reactos.org/wiki/0.4.9
- Tests: https://reactos.org/wiki/Tests_for_0.4.9
- Changelog: https://reactos.org/wiki/ChangeLog-0.4.9
- Community Changelog: https://reactos.org/wiki/Community_Changelog-0.4.9
- Download page: https://reactos.org/download
_______________________________________________
Ros-announce mailing list
Ros-announce(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-announce
Hello all,
Our website has been migrated to a new Login system today and all
components have been upgraded to their latest versions.
In the course of that, the user database has also been moved into an
LDAP directory and cleaned from accounts that have never been used.
Please check that everything is working alright and report bugs in our
JIRA: https://jira.reactos.org
You are also advised to change your password in the self-service at
https://reactos.org/roslogin/?p=selfservice - even to the same one.
Every password change from now on will use a state-of-the-art hashing
algorithm (salted SHA-512 with 6000 rounds) to protect your account from
credential theft.
Unfortunately, there have been several newer accounts, for which the
password could not be migrated.
If you encounter problems logging in, please reset your account password
at https://reactos.org/roslogin/?p=forgot to regain access.
Best regards,
Colin Finck
Hi all!
The ReactOS Website along with the Forum, Wiki, and JIRA bug tracker
will be down for maintenance for several hours during the day (European
time) on Wednesday, July 4.
In the course of this process, the user database will be migrated to the
new RosLogin Single-Sign-On system
(https://github.com/reactos/web/tree/master/www/www.reactos.org/roslogin)
and the Forum and Wiki software will be upgraded to their latest releases.
This is expected to put an end to our login weirdnesses (dead Login
buttons, 30 minute propagation delay to JIRA), solve the CAPTCHA
problems people were reporting, and increase the maintainability of the
website.
I will be on the #reactos IRC channel during the migration and give
status updates there.
Best regards,
Colin
Hi all!
Starting with build 0.4.8-dev-655-g63a3a2c, ReactOS has first support
for NT6+ applications (aka programs written for Windows Vista, Windows
7, etc.). Please retest such applications under ReactOS!
As newer Windows APIs are still missing in ReactOS, I would be surprised
if a high number of NT6+ applications suddenly works.
However, many applications may just be compiled by a new Visual Studio
without using any modern APIs. They could work now.
My "Hello World" compiled by VS 2017 v141 toolchain printed many
messages about missing apiset DLLs in the debug log, but otherwise works
well. So the next step should obviously be finishing and integrating
Mark's work on the apiset DLLs in
https://github.com/learn-more/reactos/commits/apisets
But interestingly, the build produced by the v141_xp toolchain also
looks for these apiset DLLs. Therefore, it would be possible that an
application expects a full NT6 system when finding them. Consequently,
application compatibility could be compromised if we just dump all
apiset DLLs into ReactOS, applications now expect NT6, but the OS
continues to behave like NT5 by default.
This is why I suggest detecting an NT6+ application in ntdll to have it
auto-apply a shim that lets ReactOS behave like an NT6 OS. The apiset
DLLs should only be available in this mode, but not for the NT5
personality of ReactOS. Let's not import the apisets before the ntdll
shim work is done in order to preserve our existing application
compatibility.
Cheers,
Colin
Now, where Should I turn mailing list-wise or #IRC-wise for answers folks?
On 10/11/2017 3:53 PM, fc wrote:
>
> What Web server do you folks like?
>
> I'm considering *Abyss Web Server X1/X2 *
>
> My needs are:
>
> . running ASP/ASPX
> . mime support for .mp4
> . .net 2.0-4.0
> . a C# SOAP service.
> . SQL Server (and possibly PostgreSQL) as the DB.
>
> Thank you!
The Forum is a better place to ask questions, because it is more active
than this mailing list! Never used IRC, so I do not know how active the
general IRC is, but the one used by the developers receives more attention.
I have had nginx working in real hardware in the past, but I would not
rely upon it running smoothly and consistently! You could also try:
http://www.xgarreau.org/zazouminiwebserver/en/
You will be very lucky if you can run all in your list!
.net is problematic! I think that it currently has issues.
PostgreSQL will not even install. But you may be more lucky with
Microsoft's SQL server.
I have no idea about others in your list, you will need to test them!
oldman.
