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
Marți, 14 martie 2017 12:00:02 +0000, Mark Jansen
<learn0more+ros(a)gmail.com> a scris:
> How about a better way to translate ros?
> For example integrating .po files with our rc files (possibly needs a
> preprocess step or something tho),
> Or creating a resource editor that allows multiple files to be edited
> at once?
>
Please don't push for .po resources, for these are not better. As for
improving the process, I doubt it'd repay the investment. After the
initial translation effort, the further maintenance requires very
little.
Hi all!
Some people have noticed that Smart Commits (#resolve, #comment, etc.)
have stopped working after the JIRA/FishEye upgrade. This is due to the
new per-user OAuth authentication between both systems, which means that
every committer needs to authorize FishEye once to impersonate as your
JIRA account.
FishEye only tells you this and the URL to fix it after the first failed
Smart Commit, but here it is:
https://code.reactos.org/plugins/servlet/applinks/oauth/login-dance/authori…
Click that, confirm and all subsequent Smart Commits should work.
Make sure you are logged into JIRA and FishEye before.
Cheers,
Colin
I would like to see support for GPT partititioning :)
Best regards,
Alex Ionescu
On Sun, Mar 12, 2017 at 3:51 PM, Javier Agustìn Fernàndez Arroyo <
elhoir(a)gmail.com> wrote:
> i dont think anyone has any problems on downloading a 100MB ISO file....
> but... what about any kind of minimal network install ISO file support?
>
> On Sun, Mar 12, 2017 at 11:34 PM, Thomas Mueller <mueller6723(a)twc.com>
> wrote:
>
>> > Victor thought also about adding registry hive healing.
>> > Hermès.
>>
>> > -----Message d'origine-----
>> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin
>> Finck
>> > Envoyé : dimanche 12 mars 2017 17:27
>> > À : 'ReactOS Development List'
>> > Objet : [ros-dev] New ideas added to GSoC Ideas list
>>
>> > Hi all!
>>
>> > Daniel and me collected some additional ideas for GSoC today, which
>> I've added to our Wiki Ideas list:
>> > https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas
>>
>> > In particular:
>> > * Fundamental WiFi components
>> > * USBXHCI driver for supporting USB 3.x controllers
>> > * Bluetooth Stack
>> > * WebKit-based MSHTML implementation
>>
>> > I'm open for comments and suggestions!
>> > We can still add ideas until March 20, so let's give students a large
>> pool to draw from.
>>
>> > Cheers,
>>
>> > Colin
>>
>> Would GPT partitioning support for ReactOS be appropriate for GSoC?
>>
>> Also, the ability to build or cross-build ReactOS and install directory
>> to a FAT32 partition, mounted on a directory, without having to burn to CD
>> and boot/install from there: would that be appropriate?
>>
>> Tom
>>
>>
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
Hi,
Couple of days ago I have started dxg.sys functions implementation.
There is some progress but it would be good to write tests for this api.
Dxg mostly is just wrapper between driver and win32k, so win32k api tests
should be enough.
I saw some tests in rostests\dxtest\win32kdxtest but can't figure out how
to enable them in build.
Could some help me with this and add proper cmake files? :)
Best regards,
Sebastian
After some strike related problems we lost one of our supporters @
Chemnitzer Linux Tage (https://chemnitzer.linux-tage.de/2017/de)
SO if someone wants to join. Here we are, waiting for ya. Start is on
THIS saturday and ending is THIS sunday evening.
Yes, quite a bit early I ask here, but... sadly the problems showed up
today. We might even have a hotel room left if our hotel does not cancel
it that close to booking date. Otherwise we find a way, too.
So, first come first served. Sell your soul/come to us ^^
