khornicek(a)svn.reactos.org wrote:
> [RAPPS]
> - Add a custom build of the Mesa 3D Graphics Library. This build
> contains mesa, gallium and llvmpipe. It provides an enormous
> performance boost over the software implementation present in
> opengl32.
That sounds fantastic! I'm just wondering, if it is better than our
current OpenGL software rendering in every regard, can't we just have it
as the default in our tree?
- Colin
Hi there,
I feel extremely enthusiastic about contributing to reactos through gsoc. I
looked into the idea list for 2017 and "Audio Mixer" looks the most
interesting to me. But I have absolutely no experience writing windows
services, let alone kernel streaming. I have experience with linux
internals and I have used Windows APIs in the past. I am really interested
in this. How do I get a mental map of what all things I need to do to
achieve this? What all stuff do I learn for this and how?
Also suggest me if I should drop this entirely and conribute through coding
something less "ambitious".
--
*Pranay Pratyush,*
3rd year undergraduate ,
Computer Science and Engineering Department
Indian Institute Of Technology, Kharagpur
--
Hi, I've a question concerning legal restrictions. As mentioned on this
page
https://reactos.org/wiki/Subversion#Prerequisites
I'm not allowed to contribute to ReactOS when I'm an employee of
Microsoft or of any subsidiary of Microsoft.
In the past, I worked for a German company which was a Certified Partner
of Microsoft. As far as I know, it was not a subsidiary of Microsoft.
It's not even listed here
https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_Microsoft
(but I don't know if this list is complete).
Since a Certified Partner is not automatically a MS subsidiary or
equivalent to it in a sense (as I think), there shouldn't be a problem
for me contributing to ReactOS. Is there anybody who can confirm that?
Tobias
Hi all!
Let me announce a definite date for our JIRA/FishEye upgrade:
Wednesday, March 8, around 9:00 UTC
Expect downtimes of several hours at https://code.reactos.org and
https://jira.reactos.org around this time.
I can say for sure that I will have enough time on this day and the
following to deal with all possible incidents that could happen during
the complex upgrade.
This also allows me to get direct in-person feedback from all the devs
attending CLT on the weekend after that :)
The upgrade to JIRA 7.x is a major one, and Atlassian recommends
everyone to have a look at the new features:
https://confluence.atlassian.com/migration/jira-7/server_jira_product-chang…
Best regards,
Colin
Dear Ricardo,
Firstly, Win16 application support doesn't interrupt our project. It strengthens us. On technical view, supporting them doesn't make any design change to NT architecture, apps won't be able to access hardware directly. Like any app, they'll obey the rules.
Secondly, there are a number of reasons to support Win16:
1) Many people and corporations still use DOS and Win16 apps today, thus their system can't be upgraded easily. Most of the cases, DOSBOX will do the job but what if any problem occurs, or integration with system is needed? With Win16 support out of the box, people will get much more technical support and security updates.
2) Many apps released in 90s have 16 bit setups, even they are actually 32-bit. In this case, compatibility and usability of ReactOS greatly decreases.
3) Sometimes emulation may be not enough for special cases.
4) There are many games from 16 bit age which is still played today. Supporting them makes a bonus.
In my opinion, this cases makes WoW16 support viable. Apologizes if I forget something and sending this twice, accidentally pressed the send button.
Best regards,
Can
I also have some ideas here, not fully sure about their feasibility. Tried to be wise as much as I can.
-Continuing USB work that vardanm started. Yes, I know a developer is working on that. Another joining student would be great and speed up things.
-Continuing TCP/IP stack work if noone is working on rewrite.
-Working on DirectX support: bringing new features, fixing bugs, optimising, if possible fixing some driver issues...
-Fixing driver unloading/fallback problem (CORE-8294) I think it's a hurdle on our hardware compatibility, but not sure its priority.
-Would some kind of Win32 subsystem work be too hard?
-Implementing some missing things in shell.
-Implementing more user mode stuff, or is it enough for now?
-Extending printing support.
-Fixing current audio support, if our devs don't want to tinker with it.
-Implementing WoW16 support. I suppose that'll draw attention.
And as said before, proper application compatibility database. :) By the way, I'm too pleased to join and see you here all!
With my best regards,
Can Taşan
Hi all!
We used to remove any ISOs at https://iso.reactos.org that were older
than 2 years. Then some devs wanted access for a little longer and we
stopped deleting any. Now we recently ran out of space on that server...
Even though we are about to double our storage capacity, I want a
definite decision about the lifetime of ISOs at iso.reactos.org.
Something that serves us well over the next few years. Otherwise, we
will just run into the same problem again in the near future.
My proposal
===========
bootcd-dbg: 5 years
bootcd-dbg-msvc: 5 years
bootcd-rel: 0.5 years
bootcdregtest: 1 week
livecd-dbg: 0.5 years
livecd-dbg-msvc: 0.5 years
livecd-rel: 0.5 years
Having the DBG Boot-CDs up for 5 years should cover all reasonable
regression testing in my opinion.
I'm not that much into testing as you though, so if any of these
lifetimes are too short for you, please speak up now.
Otherwise, I'm going to implement this by next Wednesday, March 22.
Cheers,
Colin