Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-17 Thread Riccardo Paolo Bestetti
Dear Can,
Your argument would hold if the objective of the project was to support edge 
cases by coding legacy support to eliminate the need for other people to 
modernize their infrastructure. Is this what ReactOS wants to achieve as its 
main goal?

I would get your argument if ReactOS was even remotely usable in the real 
world. But what you're supporting right now with your argument is to support an 
edge case in an operating system which cannot support general cases yet.
It is for this reason that not only I disagree with you, but I expressely 
oppose to your argument, for I think it would be harmful for the project to 
proceed with such mindset, which, as we've seen in the past (it is for this 
reason that I referenced the previous discussion on the target NT version) is 
not limited to this specific topic.

Sorry, but I just don't see how "WoW16" can make sense among items such as 
DirectX, AMD64 support, SMP, better translation support, etc.

Also, I think you didn't fully send point #2, but I can imagine where you were 
going, and I probably already gave an answer to that too.

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Can Tasan
Sent: 17 March 2017 12:48
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] New ideas added to GSoC Ideas list

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


 Orjinal mesaj 
Kimden: Riccardo Paolo Bestetti 
<riccardo.kyo...@live.it<mailto:riccardo.kyo...@live.it>>
Tarih: 17.03.2017 14:13 (GMT+03:00)
Alıcı: ReactOS Development List 
<ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Konu: Re: [ros-dev] New ideas added to GSoC Ideas list
Sorry for the non-developer intrusion, this is the point of view of an IT 
technician that would happily substitute Windows machines with ReactOS machine 
in an hypotetical future.

To me, this looks like an extension (and a perilous one) to the "which NT 
version should we target?" discussion, which at some point was interrupted and 
so a decision has never been made.
I understand that seamless 3.1 support would be "cool", but would it be of any 
use? If you can already get it working albiet in a non-seamless way, it seems 
more than enough to me, and I don't think that resources should be allocated to 
this if the objective of the project really is (as I understand) to create a 
viable replacement for Windows.

Just my two cents as a real-world user.

Regards,
Riccardo

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Can Tasan
Sent: 17 March 2017 05:40
To: ReactOS Development List <ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Subject: Re: [ros-dev] New ideas added to GSoC Ideas list

Wine still maintains and even improves Windows 3.x support! I hope they don't 
give up!

Can we use Wine code while implementing WoW16?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-17 Thread Can Tasan
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


 Orjinal mesaj 
Kimden: Riccardo Paolo Bestetti <riccardo.kyo...@live.it>
Tarih: 17.03.2017 14:13 (GMT+03:00)
Alıcı: ReactOS Development List <ros-dev@reactos.org>
Konu: Re: [ros-dev] New ideas added to GSoC Ideas list

Sorry for the non-developer intrusion, this is the point of view of an IT 
technician that would happily substitute Windows machines with ReactOS machine 
in an hypotetical future.

To me, this looks like an extension (and a perilous one) to the “which NT 
version should we target?” discussion, which at some point was interrupted and 
so a decision has never been made.
I understand that seamless 3.1 support would be “cool”, but would it be of any 
use? If you can already get it working albiet in a non-seamless way, it seems 
more than enough to me, and I don’t think that resources should be allocated to 
this if the objective of the project really is (as I understand) to create a 
viable replacement for Windows.

Just my two cents as a real-world user.

Regards,
Riccardo

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Can Tasan
Sent: 17 March 2017 05:40
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] New ideas added to GSoC Ideas list

Wine still maintains and even improves Windows 3.x support! I hope they don't 
give up!

Can we use Wine code while implementing WoW16?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-17 Thread Riccardo Paolo Bestetti
Sorry for the non-developer intrusion, this is the point of view of an IT 
technician that would happily substitute Windows machines with ReactOS machine 
in an hypotetical future.

To me, this looks like an extension (and a perilous one) to the “which NT 
version should we target?” discussion, which at some point was interrupted and 
so a decision has never been made.
I understand that seamless 3.1 support would be “cool”, but would it be of any 
use? If you can already get it working albiet in a non-seamless way, it seems 
more than enough to me, and I don’t think that resources should be allocated to 
this if the objective of the project really is (as I understand) to create a 
viable replacement for Windows.

Just my two cents as a real-world user.

Regards,
Riccardo

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Can Tasan
Sent: 17 March 2017 05:40
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] New ideas added to GSoC Ideas list

Wine still maintains and even improves Windows 3.x support! I hope they don't 
give up!

Can we use Wine code while implementing WoW16?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Can Tasan
Wine still maintains and even improves Windows 3.x support! I hope they don't 
give up!

Can we use Wine code while implementing WoW16?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Can Tasan
Wine still maintains and even improves Windows 3.x support! I hope they don't 
give up!

Can we use Wine code while implementing WoW16?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread David Quintana (gigaherz)
That second Windows should have been ros.

On 17 March 2017 at 01:25, David Quintana (gigaherz) 
wrote:

> Running windows inside a vdm window isn't the same as running the apps
> directly in windows, as if they were native apps.
>
> On 17 March 2017 at 01:07, Javier Agustìn Fernàndez Arroyo <
> elh...@gmail.com> wrote:
>
>> some people have had success in running Win 3.1 under ReactOS thanks to
>> NTDVM, so win3.1 apps can be run too :)
>>
>> On Thu, Mar 16, 2017 at 11:49 PM, David Quintana (gigaherz) <
>> gigah...@gmail.com> wrote:
>>
>>> That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order
>>> to support 16bit (windows 3.1) applications, a whole other system is needed.
>>>
>>> On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo <
>>> elh...@gmail.com> wrote:
>>>
 "-Implementing WoW16 support. I suppose that'll draw attention." -->
 NTVDM, already done :)

 "Working on DirectX support: bringing new features, fixing bugs,
 optimising, if possible fixing some driver issues..." ---> ReactX, would be
 great!

 On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber  wrote:

> I can tell you some possible next steps:
> - x64: implement PAE support in the 32 bit kernel
> - SMP: Implement resource translators and arbiters (I have some
> initial work for this somewhere)
> - Also SMP: build a CONFIG_SMP kernel (with some hack to use the
> regular HAL) and debug any issues coming from broken spinlock usage
>
> On March 16, 2017 5:50:39 AM EDT, Colin Finck 
> wrote:
>>
>> Am 16.03.2017 um 00:03 schrieb Huw Campbell:
>>
>>>  SMP or 64 bit processor support would be great. Too hard?
>>>
>>
>> I think that's too much for a single GSoC student. But we also keep
>> saying this for a long time... The result is that everybody is afraid of
>> those "big topics".
>>
>> What we need is some kernel dev looking into these topics and giving a
>> rough overview what needs to be done and in what places. Then we can
>> have a roadmap and split the work up into smaller tasks that are even
>> doable by GSoC students.
>>
>> If nobody makes this first step, we will never have SMP or x64 CPU
>> support. People also kept saying that full printer support is too much
>> for a 6-month bachelor thesis, and they were right, but nevertheless I
>> was able to build the foundations and documentation in that
>> time.
>> And now I could guide everyone interested how to continue on achieving
>> full printing support.
>>
>>
>> - Colin
>>
>> --
>>
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>


 ___
 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev

>>>
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread David Quintana (gigaherz)
Running windows inside a vdm window isn't the same as running the apps
directly in windows, as if they were native apps.

On 17 March 2017 at 01:07, Javier Agustìn Fernàndez Arroyo  wrote:

> some people have had success in running Win 3.1 under ReactOS thanks to
> NTDVM, so win3.1 apps can be run too :)
>
> On Thu, Mar 16, 2017 at 11:49 PM, David Quintana (gigaherz) <
> gigah...@gmail.com> wrote:
>
>> That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order
>> to support 16bit (windows 3.1) applications, a whole other system is needed.
>>
>> On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo <
>> elh...@gmail.com> wrote:
>>
>>> "-Implementing WoW16 support. I suppose that'll draw attention." -->
>>> NTVDM, already done :)
>>>
>>> "Working on DirectX support: bringing new features, fixing bugs,
>>> optimising, if possible fixing some driver issues..." ---> ReactX, would be
>>> great!
>>>
>>> On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber 
>>> wrote:
>>>
 I can tell you some possible next steps:
 - x64: implement PAE support in the 32 bit kernel
 - SMP: Implement resource translators and arbiters (I have some initial
 work for this somewhere)
 - Also SMP: build a CONFIG_SMP kernel (with some hack to use the
 regular HAL) and debug any issues coming from broken spinlock usage

 On March 16, 2017 5:50:39 AM EDT, Colin Finck 
 wrote:
>
> Am 16.03.2017 um 00:03 schrieb Huw Campbell:
>
>>  SMP or 64 bit processor support would be great. Too hard?
>>
>
> I think that's too much for a single GSoC student. But we also keep
> saying this for a long time... The result is that everybody is afraid of
> those "big topics".
>
> What we need is some kernel dev looking into these topics and giving a
> rough overview what needs to be done and in what places. Then we can
> have a roadmap and split the work up into smaller tasks that are even
> doable by GSoC students.
>
> If nobody makes this first step, we will never have SMP or x64 CPU
> support. People also kept saying that full printer support is too much
> for a 6-month bachelor thesis, and they were right, but nevertheless I
> was able to build the foundations and documentation in that
> time.
> And now I could guide everyone interested how to continue on achieving
> full printing support.
>
>
> - Colin
>
> --
>
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 ___
 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev

>>>
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Javier Agustìn Fernàndez Arroyo
some people have had success in running Win 3.1 under ReactOS thanks to
NTDVM, so win3.1 apps can be run too :)

On Thu, Mar 16, 2017 at 11:49 PM, David Quintana (gigaherz) <
gigah...@gmail.com> wrote:

> That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order
> to support 16bit (windows 3.1) applications, a whole other system is needed.
>
> On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo <
> elh...@gmail.com> wrote:
>
>> "-Implementing WoW16 support. I suppose that'll draw attention." -->
>> NTVDM, already done :)
>>
>> "Working on DirectX support: bringing new features, fixing bugs,
>> optimising, if possible fixing some driver issues..." ---> ReactX, would be
>> great!
>>
>> On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber 
>> wrote:
>>
>>> I can tell you some possible next steps:
>>> - x64: implement PAE support in the 32 bit kernel
>>> - SMP: Implement resource translators and arbiters (I have some initial
>>> work for this somewhere)
>>> - Also SMP: build a CONFIG_SMP kernel (with some hack to use the regular
>>> HAL) and debug any issues coming from broken spinlock usage
>>>
>>> On March 16, 2017 5:50:39 AM EDT, Colin Finck  wrote:

 Am 16.03.2017 um 00:03 schrieb Huw Campbell:

>  SMP or 64 bit processor support would be great. Too hard?
>

 I think that's too much for a single GSoC student. But we also keep
 saying this for a long time... The result is that everybody is afraid of
 those "big topics".

 What we need is some kernel dev looking into these topics and giving a
 rough overview what needs to be done and in what places. Then we can
 have a roadmap and split the work up into smaller tasks that are even
 doable by GSoC students.

 If nobody makes this first step, we will never have SMP or x64 CPU
 support. People also kept saying that full printer support is too much
 for a 6-month bachelor thesis, and they were right, but nevertheless I
 was able to build the foundations and documentation in that
 time.
 And now I could guide everyone interested how to continue on achieving
 full printing support.


 - Colin

 --

 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev


>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Hermès BÉLUSCA-MAÏTO
To be the most accurate, WoW16 is an addition to NTVDM. NTVDM alone provides 
16-bit emulation plus DOS support. WoW16 adds on top of that, Win 3.1 support 
(which is also 16-bit). WoW16 is implemented using wow32.dll (the 32-bit part 
that interfaces directly with NTVDM), wowexec.exe (the corresponding 16-bit 
part), krnl386.exe (the “kernel” of Win 3.1) and the thunk dlls/exes user, gdi …

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David Quintana 
(gigaherz)
Envoyé : jeudi 16 mars 2017 23:50
À : ReactOS Development List
Objet : Re: [ros-dev] New ideas added to GSoC Ideas list

 

That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order to 
support 16bit (windows 3.1) applications, a whole other system is needed.

 

On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo <elh...@gmail.com> 
wrote:

"-Implementing WoW16 support. I suppose that'll draw attention." --> NTVDM, 
already done :)

"Working on DirectX support: bringing new features, fixing bugs, optimising, if 
possible fixing some driver issues..." ---> ReactX, would be great!

 

On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber <thomas.fa...@reactos.org> wrote:

I can tell you some possible next steps:
- x64: implement PAE support in the 32 bit kernel
- SMP: Implement resource translators and arbiters (I have some initial work 
for this somewhere)
- Also SMP: build a CONFIG_SMP kernel (with some hack to use the regular HAL) 
and debug any issues coming from broken spinlock usage

On March 16, 2017 5:50:39 AM EDT, Colin Finck <co...@reactos.org> wrote:

Am 16.03.2017 um 00:03 schrieb Huw Campbell:
 SMP or 64 bit processor support would be great. Too hard?

I think that's too much for a single GSoC student. But we also keep
saying this for a long time... The result is that everybody is afraid of
those "big topics".

What we need is some kernel dev looking into these topics and giving a
rough overview what needs to be done and in what places. Then we can
have a roadmap and split the work up into smaller tasks that are even
doable by GSoC students.

If nobody makes this first step, we will never have SMP or x64 CPU
support. People also kept saying that full printer support is too much
for a 6-month bachelor thesis, and they were right, but nevertheless I
was able to build the foundations and documentation in that
time.
And now I could guide everyone interested how to continue on achieving
full printing support.


- Colin


  _  


Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread David Quintana (gigaherz)
That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order to
support 16bit (windows 3.1) applications, a whole other system is needed.

On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo  wrote:

> "-Implementing WoW16 support. I suppose that'll draw attention." -->
> NTVDM, already done :)
>
> "Working on DirectX support: bringing new features, fixing bugs,
> optimising, if possible fixing some driver issues..." ---> ReactX, would be
> great!
>
> On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber 
> wrote:
>
>> I can tell you some possible next steps:
>> - x64: implement PAE support in the 32 bit kernel
>> - SMP: Implement resource translators and arbiters (I have some initial
>> work for this somewhere)
>> - Also SMP: build a CONFIG_SMP kernel (with some hack to use the regular
>> HAL) and debug any issues coming from broken spinlock usage
>>
>> On March 16, 2017 5:50:39 AM EDT, Colin Finck  wrote:
>>>
>>> Am 16.03.2017 um 00:03 schrieb Huw Campbell:
>>>
  SMP or 64 bit processor support would be great. Too hard?

>>>
>>> I think that's too much for a single GSoC student. But we also keep
>>> saying this for a long time... The result is that everybody is afraid of
>>> those "big topics".
>>>
>>> What we need is some kernel dev looking into these topics and giving a
>>> rough overview what needs to be done and in what places. Then we can
>>> have a roadmap and split the work up into smaller tasks that are even
>>> doable by GSoC students.
>>>
>>> If nobody makes this first step, we will never have SMP or x64 CPU
>>> support. People also kept saying that full printer support is too much
>>> for a 6-month bachelor thesis, and they were right, but nevertheless I
>>> was able to build the foundations and documentation in that
>>> time.
>>> And now I could guide everyone interested how to continue on achieving
>>> full printing support.
>>>
>>>
>>> - Colin
>>>
>>> --
>>>
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Thomas Faber
I can tell you some possible next steps:
- x64: implement PAE support in the 32 bit kernel
- SMP: Implement resource translators and arbiters (I have some initial work 
for this somewhere)
- Also SMP: build a CONFIG_SMP kernel (with some hack to use the regular HAL) 
and debug any issues coming from broken spinlock usage

On March 16, 2017 5:50:39 AM EDT, Colin Finck  wrote:
>Am 16.03.2017 um 00:03 schrieb Huw Campbell:
>> SMP or 64 bit processor support would be great. Too hard?
>
>I think that's too much for a single GSoC student. But we also keep
>saying this for a long time... The result is that everybody is afraid
>of
>those "big topics".
>
>What we need is some kernel dev looking into these topics and giving a
>rough overview what needs to be done and in what places. Then we can
>have a roadmap and split the work up into smaller tasks that are even
>doable by GSoC students.
>
>If nobody makes this first step, we will never have SMP or x64 CPU
>support. People also kept saying that full printer support is too much
>for a 6-month bachelor thesis, and they were right, but nevertheless I
>was able to build the foundations and documentation in that time.
>And now I could guide everyone interested how to continue on achieving
>full printing support.
>
>
>- Colin
>
>___
>Ros-dev mailing list
>Ros-dev@reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-16 Thread Colin Finck
Am 16.03.2017 um 00:03 schrieb Huw Campbell:
> SMP or 64 bit processor support would be great. Too hard?

I think that's too much for a single GSoC student. But we also keep
saying this for a long time... The result is that everybody is afraid of
those "big topics".

What we need is some kernel dev looking into these topics and giving a
rough overview what needs to be done and in what places. Then we can
have a roadmap and split the work up into smaller tasks that are even
doable by GSoC students.

If nobody makes this first step, we will never have SMP or x64 CPU
support. People also kept saying that full printer support is too much
for a 6-month bachelor thesis, and they were right, but nevertheless I
was able to build the foundations and documentation in that time.
And now I could guide everyone interested how to continue on achieving
full printing support.


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-15 Thread Huw Campbell
Hi all,

SMP or 64 bit processor support would be great. Too hard?

Cheers,
Huw

On Thu, Mar 16, 2017 at 7:28 AM, Can Tasan  wrote:

> 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
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-15 Thread Can Tasan
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
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-15 Thread Rafał Harabień
Do we really need custom layouts for languages? Wine is handling it
somehow by making labels/buttons big enough. Cant we do it the same way
if we don't need pixel perfect positioning?

W dniu 15.03.2017 o 21:21, Mark Jansen pisze:
> Well,
>
> I was thinking a sort of 'hybrid' approach:
> We have a generic resource 'template' file (english?), that is used
> for strings / dialogs.
> Then each translation will have it's .po file.
> Translations that need a different dialog layout create a new 'template' file.
>
> To build this, we will need an extra pre-process step (like we do for
> utf16 .inf files), to combine the resource template and .po file into
> a real resource file.
>
> This saves developers from having to edit 30 resource files when
> altering one dialog.
>
>
>
>
> On Wed, Mar 15, 2017 at 1:52 AM, Hermès BÉLUSCA-MAÏTO
> <hermes.belu...@sfr.fr> wrote:
>> I’m sorry but I should remind you that we *already* have *MANY* apps & dlls
>> (not from Wine) where dialog layouts are already different for different
>> locales, examples being for French and German languages (amongst others)
>> where having adapted sizes for buttons, static text controls, … are
>> mandatory, because these languages use frequently long words, etc… . So it’s
>> clear we will never go back to a single layout that is shared between
>> different locales.
>>
>>
>>
>> I should reassure you however, that we don’t care at all about
>> “pixel-perfect layout compatibility with windows”.
>>
>>
>>
>> A suggestion then, would be to have a resource editor, that can display
>> nicely, for a given dialog ID, all the (possibly only the selected ones)
>> different dialogs of the different languages, in e.g. mosaic positioning,
>> which should help the translator to easily see whether he needs to adapt a
>> layout for a given language, or whether he can just copy/paste an existing
>> layout.
>>
>>
>>
>> Hermès.
>>
>>
>>
>> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Rafal
>> Harabien
>> Envoyé : mardi 14 mars 2017 23:44
>> À : ReactOS Development List
>> Objet : Re: [ros-dev] New ideas added to GSoC Ideas list
>>
>>
>>
>> PO files supports "context" markers to make it possible to differentiate
>> usage of the same string in different contexts.
>> About different layout - yes, we would have only one layout but IMO for
>> project like this with human resource problems its more important to make
>> development less boring and easier to maintain than to customize dialogs for
>> every locale without significant profit. If project treats pixel-perfect
>> layout compatibility with windows as requirement it would be a problem but I
>> don't think ROS needs it.  We already import multiple dialogs from Wine...
>>
>>
>> W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:
>>
>> Gettext-style translations are really really bad, because they use the
>> original text (usually in english) as a translation key, which means they
>> simply can not handle situations where the same english text needs different
>> translations depending on where the text is used. And yes, I have come
>> across that issue once upon a time.
>>
>> You are right that editing a dialog is annoying, but due to the way win32
>> resource dialogs work, it's unavoidable. Even if we could have a serpate
>> file for reaching the translations, there's often the situation where
>> certain languages need different layouts, or at least different control
>> sizes, to accomodate for longer / taller text, or RTL. So even if we
>> switched to a different system, that annoyance wouldn't go away.
>>
>> I do agree that it would be nice to have some nicer tool for translators,
>> but IMO, .po files are not it.
>>
>>
>>
>>
>>
>> On 14 March 2017 at 23:14, Rafał Harabień <raf...@reactos.org> wrote:
>>
>> In my opinion it's very sensible proposal. I remember changing  dialog
>> layout in resources was a big pain because of amount of repeated work
>> for all languages (and error prone). It was demotivating.
>> On the other hand there are free translation platforms making project
>> translation more organized and easier than editing raw resources. WINE
>> is using PO for years and ReactOS IMO should do it as well.
>> Just my two cents...
>>
>> W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
>>
>>> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
>>> <learn0more+...@gmail.com> a scris:
>>>> How abo

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-15 Thread Mark Jansen
Well,

I was thinking a sort of 'hybrid' approach:
We have a generic resource 'template' file (english?), that is used
for strings / dialogs.
Then each translation will have it's .po file.
Translations that need a different dialog layout create a new 'template' file.

To build this, we will need an extra pre-process step (like we do for
utf16 .inf files), to combine the resource template and .po file into
a real resource file.

This saves developers from having to edit 30 resource files when
altering one dialog.




On Wed, Mar 15, 2017 at 1:52 AM, Hermès BÉLUSCA-MAÏTO
<hermes.belu...@sfr.fr> wrote:
> I’m sorry but I should remind you that we *already* have *MANY* apps & dlls
> (not from Wine) where dialog layouts are already different for different
> locales, examples being for French and German languages (amongst others)
> where having adapted sizes for buttons, static text controls, … are
> mandatory, because these languages use frequently long words, etc… . So it’s
> clear we will never go back to a single layout that is shared between
> different locales.
>
>
>
> I should reassure you however, that we don’t care at all about
> “pixel-perfect layout compatibility with windows”.
>
>
>
> A suggestion then, would be to have a resource editor, that can display
> nicely, for a given dialog ID, all the (possibly only the selected ones)
> different dialogs of the different languages, in e.g. mosaic positioning,
> which should help the translator to easily see whether he needs to adapt a
> layout for a given language, or whether he can just copy/paste an existing
> layout.
>
>
>
> Hermès.
>
>
>
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Rafal
> Harabien
> Envoyé : mardi 14 mars 2017 23:44
> À : ReactOS Development List
> Objet : Re: [ros-dev] New ideas added to GSoC Ideas list
>
>
>
> PO files supports "context" markers to make it possible to differentiate
> usage of the same string in different contexts.
> About different layout - yes, we would have only one layout but IMO for
> project like this with human resource problems its more important to make
> development less boring and easier to maintain than to customize dialogs for
> every locale without significant profit. If project treats pixel-perfect
> layout compatibility with windows as requirement it would be a problem but I
> don't think ROS needs it.  We already import multiple dialogs from Wine...
>
>
> W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:
>
> Gettext-style translations are really really bad, because they use the
> original text (usually in english) as a translation key, which means they
> simply can not handle situations where the same english text needs different
> translations depending on where the text is used. And yes, I have come
> across that issue once upon a time.
>
> You are right that editing a dialog is annoying, but due to the way win32
> resource dialogs work, it's unavoidable. Even if we could have a serpate
> file for reaching the translations, there's often the situation where
> certain languages need different layouts, or at least different control
> sizes, to accomodate for longer / taller text, or RTL. So even if we
> switched to a different system, that annoyance wouldn't go away.
>
> I do agree that it would be nice to have some nicer tool for translators,
> but IMO, .po files are not it.
>
>
>
>
>
> On 14 March 2017 at 23:14, Rafał Harabień <raf...@reactos.org> wrote:
>
> In my opinion it's very sensible proposal. I remember changing  dialog
> layout in resources was a big pain because of amount of repeated work
> for all languages (and error prone). It was demotivating.
> On the other hand there are free translation platforms making project
> translation more organized and easier than editing raw resources. WINE
> is using PO for years and ReactOS IMO should do it as well.
> Just my two cents...
>
> W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
>
>> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
>> <learn0more+...@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.
>>
>> ___
>> Ros-dev mailing list
>>

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-14 Thread Hermès BÉLUSCA-MAÏTO
I’m sorry but I should remind you that we *already* have *MANY* apps & dlls 
(not from Wine) where dialog layouts are already different for different 
locales, examples being for French and German languages (amongst others) where 
having adapted sizes for buttons, static text controls, … are mandatory, 
because these languages use frequently long words, etc… . So it’s clear we will 
never go back to a single layout that is shared between different locales.

 

I should reassure you however, that we don’t care at all about “pixel-perfect 
layout compatibility with windows”.

 

A suggestion then, would be to have a resource editor, that can display nicely, 
for a given dialog ID, all the (possibly only the selected ones) different 
dialogs of the different languages, in e.g. mosaic positioning, which should 
help the translator to easily see whether he needs to adapt a layout for a 
given language, or whether he can just copy/paste an existing layout.

 

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Rafal Harabien
Envoyé : mardi 14 mars 2017 23:44
À : ReactOS Development List
Objet : Re: [ros-dev] New ideas added to GSoC Ideas list

 

PO files supports "context" markers to make it possible to differentiate usage 
of the same string in different contexts.
About different layout - yes, we would have only one layout but IMO for project 
like this with human resource problems its more important to make development 
less boring and easier to maintain than to customize dialogs for every locale 
without significant profit. If project treats pixel-perfect layout 
compatibility with windows as requirement it would be a problem but I don't 
think ROS needs it.  We already import multiple dialogs from Wine...


W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:

Gettext-style translations are really really bad, because they use the original 
text (usually in english) as a translation key, which means they simply can not 
handle situations where the same english text needs different translations 
depending on where the text is used. And yes, I have come across that issue 
once upon a time.

You are right that editing a dialog is annoying, but due to the way win32 
resource dialogs work, it's unavoidable. Even if we could have a serpate file 
for reaching the translations, there's often the situation where certain 
languages need different layouts, or at least different control sizes, to 
accomodate for longer / taller text, or RTL. So even if we switched to a 
different system, that annoyance wouldn't go away.

I do agree that it would be nice to have some nicer tool for translators, but 
IMO, .po files are not it.

 

 

On 14 March 2017 at 23:14, Rafał Harabień <raf...@reactos.org> wrote:

In my opinion it's very sensible proposal. I remember changing  dialog
layout in resources was a big pain because of amount of repeated work
for all languages (and error prone). It was demotivating.
On the other hand there are free translation platforms making project
translation more organized and easier than editing raw resources. WINE
is using PO for years and ReactOS IMO should do it as well.
Just my two cents...

W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:

> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
> <learn0more+...@gmail.com <mailto:learn0more%2b...@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.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-14 Thread Rafał Harabień
PO files supports "context" markers to make it possible to differentiate
usage of the same string in different contexts.
About different layout - yes, we would have only one layout but IMO for
project like this with human resource problems its more important to
make development less boring and easier to maintain than to customize
dialogs for every locale without significant profit. If project treats
pixel-perfect layout compatibility with windows as requirement it would
be a problem but I don't think ROS needs it.  We already import multiple
dialogs from Wine...


W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:
> Gettext-style translations are really really bad, because they use the
> original text (usually in english) as a translation key, which means
> they simply can not handle situations where the same english text
> needs different translations depending on where the text is used. And
> yes, I have come across that issue once upon a time.
>
> You are right that editing a dialog is annoying, but due to the way
> win32 resource dialogs work, it's unavoidable. Even if we could have a
> serpate file for reaching the translations, there's often the
> situation where certain languages need different layouts, or at least
> different control sizes, to accomodate for longer / taller text, or
> RTL. So even if we switched to a different system, that annoyance
> wouldn't go away.
>
> I do agree that it would be nice to have some nicer tool for
> translators, but IMO, .po files are not it.
>
>
> On 14 March 2017 at 23:14, Rafał Harabień  > wrote:
>
> In my opinion it's very sensible proposal. I remember changing  dialog
> layout in resources was a big pain because of amount of repeated work
> for all languages (and error prone). It was demotivating.
> On the other hand there are free translation platforms making project
> translation more organized and easier than editing raw resources. WINE
> is using PO for years and ReactOS IMO should do it as well.
> Just my two cents...
>
> W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
> > Marți, 14 martie 2017 12:00:02 +, Mark Jansen
> > > 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.
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org 
> > http://www.reactos.org/mailman/listinfo/ros-dev
> 
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org 
> http://www.reactos.org/mailman/listinfo/ros-dev
> 
>
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-14 Thread David Quintana (gigaherz)
Gettext-style translations are really really bad, because they use the
original text (usually in english) as a translation key, which means they
simply can not handle situations where the same english text needs
different translations depending on where the text is used. And yes, I have
come across that issue once upon a time.

You are right that editing a dialog is annoying, but due to the way win32
resource dialogs work, it's unavoidable. Even if we could have a serpate
file for reaching the translations, there's often the situation where
certain languages need different layouts, or at least different control
sizes, to accomodate for longer / taller text, or RTL. So even if we
switched to a different system, that annoyance wouldn't go away.

I do agree that it would be nice to have some nicer tool for translators,
but IMO, .po files are not it.


On 14 March 2017 at 23:14, Rafał Harabień  wrote:

> In my opinion it's very sensible proposal. I remember changing  dialog
> layout in resources was a big pain because of amount of repeated work
> for all languages (and error prone). It was demotivating.
> On the other hand there are free translation platforms making project
> translation more organized and easier than editing raw resources. WINE
> is using PO for years and ReactOS IMO should do it as well.
> Just my two cents...
>
> W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
> > Marți, 14 martie 2017 12:00:02 +, Mark Jansen
> >  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.
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-14 Thread Rafał Harabień
In my opinion it's very sensible proposal. I remember changing  dialog
layout in resources was a big pain because of amount of repeated work
for all languages (and error prone). It was demotivating.
On the other hand there are free translation platforms making project
translation more organized and easier than editing raw resources. WINE
is using PO for years and ReactOS IMO should do it as well.
Just my two cents...

W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
>  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.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-14 Thread Ștefan Fulea
Marți, 14 martie 2017 12:00:02 +, Mark Jansen
 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.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-13 Thread Mark Jansen
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?



On Mon, Mar 13, 2017 at 11:50 AM, Colin Finck <co...@reactos.org> wrote:
> Added that too together with Windows hive compatibility. Please check!
>
> - Colin
>
>
> Am 12.03.2017 um 22:28 schrieb Hermès BÉLUSCA-MAÏTO:
>> Victor thought also about adding registry hive healing.
>> Hermès.
>>
>> -Message d'origine-
>> De : Ros-dev [mailto:ros-dev-boun...@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
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-13 Thread Colin Finck
Added that too together with Windows hive compatibility. Please check!

- Colin


Am 12.03.2017 um 22:28 schrieb Hermès BÉLUSCA-MAÏTO:
> Victor thought also about adding registry hive healing.
> Hermès.
> 
> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@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
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
> 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-13 Thread Colin Finck
Am 12.03.2017 um 23:34 schrieb Thomas Mueller:
> 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?

That's basically our previous "make install", which can also be
supported through CMake.

See my add_rostests_file() function in CMakeMacros.cmake, which uses
CMake's install() function to realize it for rostests.
Someone just has to write a similar function that does add_cd_file() and
install() and can be used by all other modules. And then do the tedious
job of replacing all add_cd_file() calls by calls to this function in
all CMakeLists.txt files...

Feel free to do that :)
Or open a JIRA ticket.

Cheers,

Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-13 Thread Colin Finck
Added that! Please check if I got the details right.

- Colin


Am 13.03.2017 um 02:32 schrieb Alex Ionescu:
> 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
> <elh...@gmail.com <mailto:elh...@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
> <mueller6...@twc.com <mailto:mueller6...@twc.com>> wrote:
> 
> > Victor thought also about adding registry hive healing.
> > Hermès.
> 
> > -Message d'origine-
> > De : Ros-dev [mailto:ros-dev-boun...@reactos.org
> <mailto:ros-dev-boun...@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
> <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@reactos.org <mailto:Ros-dev@reactos.org>
> http://www.reactos.org/mailman/listinfo/ros-dev
> <http://www.reactos.org/mailman/listinfo/ros-dev>
> 
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org <mailto:Ros-dev@reactos.org>
> http://www.reactos.org/mailman/listinfo/ros-dev
> <http://www.reactos.org/mailman/listinfo/ros-dev>
> 
> 
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
> 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-12 Thread Alex Ionescu
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 <
elh...@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 <mueller6...@twc.com>
> wrote:
>
>> > Victor thought also about adding registry hive healing.
>> > Hermès.
>>
>> > -Message d'origine-
>> > De : Ros-dev [mailto:ros-dev-boun...@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@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-12 Thread Thomas Mueller
> Victor thought also about adding registry hive healing.
> Hermès.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] New ideas added to GSoC Ideas list

2017-03-12 Thread Hermès BÉLUSCA-MAÏTO
Victor thought also about adding registry hive healing.
Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@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

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] New ideas added to GSoC Ideas list

2017-03-12 Thread Colin Finck
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

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev