[ros-dev] R: [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the "%02d:%02d:%02d" time format and get rid of the safe string printf be

[Riccardo Paolo Bestetti]

Some people use the very same argument to write OS’s in Rust. It’s not like it 
doesn’t make sense, it’s just not necessary.
If C++ and Rust can compile to safe code, so can C. You just gotta define and 
abide by sensible safety practices.



BR,
Riccardo P. Bestetti

Da: Ros-dev [mailto:ros-dev-boun...@reactos.org] Per conto di Huw Campbell
Inviato: giovedì 5 aprile 2018 13:35
A: ReactOS Development List 
Oggetto: Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace 
the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the "%02d:%02d:%02d" 
time format and get rid of the safe string printf because the string will NEVER 
be longer than 8 charac...

Hey,

I'm going to chime in here.

If you want to fix this problem: Don't use C! Use C++, C#, Java etc. instead!

Honestly, this is inane right? ReactOS currently uses C predominantly, but we 
can't
use that as an excuse for shitty code which breaks, crashes, or has buffer 
overflows.
Security issues are not ok.

Cheers,
Huw


On Tue, Apr 3, 2018 at 5:53 AM, Thomas Faber 
> wrote:
Finding bugs is definitely a valid concern. But there is, of course,
a version that addresses both problems:
NT_VERIFY(NT_SUCCESS(RtlStringCbPrintfW(...)));

This will assert in case the buffer is too small, while still never
causing an overflow.

We could provide wrappers to require less typing or raise an exception
even on release builds, if that's more desirable.

Best,
Thomas



On 2018-04-02 20:28, Magnus Johnsson wrote:
> Eric, the thing is, buffer overflows don't just crash the program unless
> you have some really nifty guard pages, but overwrite other things in
> memory. This means an attacker can, in certain situations, use it to create
> something that not just crashes, but with a nifty input create an exploit.
> Having a 'Oh it will just crash' attitude is 'not the best'.
>
> 2018-04-02 19:41 GMT+02:00 Eric Kohl 
> >:
>
>> Hello Thomas,
>>
>> you're right, using the run-time size checks are a good way to keep
>> application from crashing because of buffer overflows. They'll just keep
>> on using corrupt data instead! If you want to fix this problem: Don't
>> use C! Use C++, C#, Java etc. instead!
>>
>> I prefer to see an application crash because of a buffer overflow rather
>> than seeing it store truncated phone numbers in a database.
>>
>> PS: If the timeout is longer than a day, winlogon uses the "%d days"
>> format. In the end, a buffer of 10 characters is still large enough.
>>
>> PPS: I'll keep using the old functions until you remove them from the
>> runtime code.
>>
>>
>> Regards
>> Eric
>>
>> Am 02.04.2018 um 14:12 schrieb Thomas Faber:
>>> Hey Eric,
>>>
>>> On 2018-04-02 12:58, Eric Kohl wrote:
 -RtlStringCbPrintfW(strbuf, sizeof(strbuf), L"%d:%d:%d", hours,
 minutes, seconds);
 +swprintf(szBuffer, L"%02d:%02d:%02d", iHours, iMinutes, iSeconds);
>>>
>>> Unfortunately I must disagree with this change.
>>>
>>> Buffer overflows are a big enough threat that code review and
>>> static analysis are not generally considered sufficient to protect
>>> against them.
>>> So it's best practice for new code to always verify sizes at run-time,
>>> and never to use s(w)print.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> PS: from what I see, iHours can be as large as 1193046, which won't
>>>  fit in 2 digits


___
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] Merging our x86 HALs

[Riccardo Paolo Bestetti]

Supporting old hardware does not mean it will consume fewer resources. The fact 
that you’re carefully optimizing the code, because it has to run on old 
hardware, means that it will consume fewer resources.
And nothing in particular stops you from doing that even without supporting old 
hardware.

It would be wonderful indeed, but one has to draw the line somewhere. What I 
was proposing is to draw the line in a useful place, i.e., in a place that 
would have ReactOS support hardware that is actually of any interest for new 
setups.

I gave a variation of this argument when discussing what NT version(s) ReactOS 
should target. Let me give a slightly updated variation today.

It seems to me that this project is terribly undermanned. Today, the codebase 
is missing most of what makes an OS modern and useful, and at this pace, even 
if you target the most modern Windows OS currently in existence, the gap is 
going to get bigger. Targeting legacy systems is not going to do any good. 
Unless you only want to run on legacy systems, that is.
Let’s say for the sake of argument that that is the case. How many systems have 
legacy hardware *and* can’t be replaced with newer systems *and* are likely to 
break down (i.e. non-redundant hardware or insufficient maintenance), *and* are 
not just getting a cloned image of whatever was installed on there before in 
case they do break down? Because these would be the only possible candidates 
for such a ReactOS. Other that 14 years old tech-savvy kids trying to 
resuscitate their father’s old PC and Christian youth organizations fixing old 
PCs for the local Community, but I doubt this is what any of you think as your 
target.

one of the companies I work for, every year we make a list of the older 
computers, and we change them. Every time this happens, I try to install the 
latest ReactOS and to run their CRM software on there, with the hope that one 
day I will be able to experimentally run one of these computers with ReactOS. 
The last two times I tried this, it was worse than the year before. And yet, 
the discussion is whether to support legacy hardware. This is why I said it is, 
plain and simple, a waste of resources. It is.
28 years ago GEOS 2.0 was released for the C128. 22 years ago Windows 95 was 
released for “legacy hardware”. ReactOS is many years away from becoming 
usable. You do the math…

Thank you for the time you took to read this.

BR,
Riccardo P. Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: mercoledì 13 dicembre 2017 12:49
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Merging our x86 HALs

"supporting very old hardware, which I see as a plain and simple waste of 
resources."
I completely disagree.
Supporting very old hardware  means that it will consume very very fewer 
resources in very new hardware, too.
But, speaking about the former, it would be wonderful to be able to run Windows 
software in such hardware.
The question in this last case is, how HAL supports new CPU instructions? but 
that`s an off-topic question

On Wed, Dec 13, 2017 at 8:24 AM, Riccardo Paolo Bestetti 
<riccardo.kyo...@live.it<mailto:riccardo.kyo...@live.it>> wrote:
Hi David,

I was talking about supporting very old hardware, which I see as a plain and 
simple waste of resources. There may be legacy computers running legacy 
software around, but you can be sure that no one is gonna redeploy these 
computer, especially with a different software configuration (i.e. installing 
ReactOS instead of Windows [2000|XP|2003] on it). Of course I leave the (very) 
technical discussion about how to implement HALs to you.

BR.
Riccardo P. Bestetti

From: Ros-dev 
[mailto:ros-dev-boun...@reactos.org<mailto:ros-dev-boun...@reactos.org>] On 
Behalf Of David Quintana (gigaherz)
Sent: martedì 12 dicembre 2017 22:45

To: ReactOS Development List <ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Subject: Re: [ros-dev] Merging our x86 HALs

I think yes, on the fact that duplicate code is already causing bugs. Now 
wether we want to unify everything into one megaHAL, or compile multiple HALs 
fom the same codebase, or merge into two medium-sized HALs, that's what the 
discussion is meant to be about.

On 12 December 2017 at 22:00, Riccardo Paolo Bestetti 
<riccardo.kyo...@live.it<mailto:riccardo.kyo...@live.it>> wrote:
My bi-annual IT guy peak:

Is there a real need to?
I think not.

B.R.
Riccardo P. Bestetti

From: Ros-dev 
[mailto:ros-dev-boun...@reactos.org<mailto:ros-dev-boun...@reactos.org>] On 
Behalf Of Javier Agustìn Fernàndez Arroyo
Sent: martedì 12 dicembre 2017 18:13
To: ReactOS Development List <ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Subject: Re: [ros-dev] Merging our x86 HALs

Win8 does not support old hardware as ReactOS do!

El 12 dic. 2017 17:52, "Alex Ionescu" 
<ion...@videotron.ca&l

Re: [ros-dev] Merging our x86 HALs

[Riccardo Paolo Bestetti]

Hi David,

I was talking about supporting very old hardware, which I see as a plain and 
simple waste of resources. There may be legacy computers running legacy 
software around, but you can be sure that no one is gonna redeploy these 
computer, especially with a different software configuration (i.e. installing 
ReactOS instead of Windows [2000|XP|2003] on it). Of course I leave the (very) 
technical discussion about how to implement HALs to you.

BR.
Riccardo P. Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of David Quintana 
(gigaherz)
Sent: martedì 12 dicembre 2017 22:45
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Merging our x86 HALs

I think yes, on the fact that duplicate code is already causing bugs. Now 
wether we want to unify everything into one megaHAL, or compile multiple HALs 
fom the same codebase, or merge into two medium-sized HALs, that's what the 
discussion is meant to be about.

On 12 December 2017 at 22:00, Riccardo Paolo Bestetti 
<riccardo.kyo...@live.it<mailto:riccardo.kyo...@live.it>> wrote:
My bi-annual IT guy peak:

Is there a real need to?
I think not.

B.R.
Riccardo P. Bestetti

From: Ros-dev 
[mailto:ros-dev-boun...@reactos.org<mailto:ros-dev-boun...@reactos.org>] On 
Behalf Of Javier Agustìn Fernàndez Arroyo
Sent: martedì 12 dicembre 2017 18:13
To: ReactOS Development List <ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Subject: Re: [ros-dev] Merging our x86 HALs

Win8 does not support old hardware as ReactOS do!

El 12 dic. 2017 17:52, "Alex Ionescu" 
<ion...@videotron.ca<mailto:ion...@videotron.ca>> escribió:
I would move to the Win8+ HAL Model -- a single HAL for APIC, ACPI with runtime 
support for UEFI (if present) and MP (if present).

If people still want to run on a PIC VM (why???) or old computer, then we can 
also maintain the HAL PIC x86 for UP.

Hence there would only be 2 HALs.

Best regards,
Alex Ionescu

On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck 
<co...@reactos.org<mailto:co...@reactos.org>> wrote:
Am 11.12.2017 um 01:18 schrieb Hermès BÉLUSCA-MAÏTO:> If you basically
put all the HALs into one, then you obtain bloated stuff (which remains
in memory for the whole life of the OS). Example: standard HAL is 1MB
vs. ACPI HAL which is few kBHave you actually checked what makes up this
difference?
Hint: hal/halx86/legacy/bus/pci_vendors.ids


> Note that if Windows nowadays has only one hal, it's because they now support 
> basically only one "architecture"/platform, namely, ACPI multiprocessor (to 
> put it simple). It has its pros, but also a lot of cons.

That doesn't mean we need to do the same. We can have one HAL for all
(Pentium and newer) x86 platforms. The overhead of additional checks at
boot-up is negligible. That should be a solution for 99% of the people
out there. The rest may still go and trim down our HAL to their needs.

But let's not pretend we can maintain multiple x86 HALs for all x86
computers out there. Do you really want to test X HALs with Y different
systems? Ensure that a legacy HAL runs on a modern ACPI system? What
would be the point?


> Besides this, I've a question about your observation that in the APIC hal 
> (not ACPI) there's different implementation of HalpCalibrateStallExecution 
> and HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because 
> these stuff are completely different from the standard PICs used in platforms 
> for which the standard HAL (and possibly the ACPI HAL) are used?

Absolutely not! You need to reprogram the standard PICs also on an APIC
system, and this is precisely what both functions do. Put them into a
diff tool to see for yourself.

The same goes for timers. Even with the introduction of ACPI Timers,
Local APIC Timers, and Time-Stamp Counters, you still need a traditional
one (like RTC or PIT) for calibration at system startup. Simply because
the newer ones don't run at a known fixed frequency.
The Legacy HAL successfully employs an algorithm based on the RTC while
the APIC HAL unsuccessfully tries to use the PIT.


> Actually we should, because the detection might not work (of course in our 
> simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other 
> platforms where there can be subtle differences)

Tell me about a single one we cannot detect and which is worth to
support. I don't recall that we ever recommended our testers to choose a
different HAL at setup.


> And normally it's not the setup that decides about the HAL, but the 
> bootloader.

That defies your previous point about the setup initializing the
registry depending on the HAL.
If we can let the user select a Legacy HAL in the boot loader after
installing with an ACPI HAL, it is also technically possible to have one
HAL that encompasses both.


- Colin

__

Re: [ros-dev] Merging our x86 HALs

[Riccardo Paolo Bestetti]

My bi-annual IT guy peak:

Is there a real need to?
I think not.

B.R.
Riccardo P. Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: martedì 12 dicembre 2017 18:13
To: ReactOS Development List 
Subject: Re: [ros-dev] Merging our x86 HALs

Win8 does not support old hardware as ReactOS do!

El 12 dic. 2017 17:52, "Alex Ionescu" 
> escribió:
I would move to the Win8+ HAL Model -- a single HAL for APIC, ACPI with runtime 
support for UEFI (if present) and MP (if present).

If people still want to run on a PIC VM (why???) or old computer, then we can 
also maintain the HAL PIC x86 for UP.

Hence there would only be 2 HALs.

Best regards,
Alex Ionescu

On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck 
> wrote:
Am 11.12.2017 um 01:18 schrieb Hermès BÉLUSCA-MAÏTO:> If you basically
put all the HALs into one, then you obtain bloated stuff (which remains
in memory for the whole life of the OS). Example: standard HAL is 1MB
vs. ACPI HAL which is few kBHave you actually checked what makes up this
difference?
Hint: hal/halx86/legacy/bus/pci_vendors.ids


> Note that if Windows nowadays has only one hal, it's because they now support 
> basically only one "architecture"/platform, namely, ACPI multiprocessor (to 
> put it simple). It has its pros, but also a lot of cons.

That doesn't mean we need to do the same. We can have one HAL for all
(Pentium and newer) x86 platforms. The overhead of additional checks at
boot-up is negligible. That should be a solution for 99% of the people
out there. The rest may still go and trim down our HAL to their needs.

But let's not pretend we can maintain multiple x86 HALs for all x86
computers out there. Do you really want to test X HALs with Y different
systems? Ensure that a legacy HAL runs on a modern ACPI system? What
would be the point?


> Besides this, I've a question about your observation that in the APIC hal 
> (not ACPI) there's different implementation of HalpCalibrateStallExecution 
> and HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because 
> these stuff are completely different from the standard PICs used in platforms 
> for which the standard HAL (and possibly the ACPI HAL) are used?

Absolutely not! You need to reprogram the standard PICs also on an APIC
system, and this is precisely what both functions do. Put them into a
diff tool to see for yourself.

The same goes for timers. Even with the introduction of ACPI Timers,
Local APIC Timers, and Time-Stamp Counters, you still need a traditional
one (like RTC or PIT) for calibration at system startup. Simply because
the newer ones don't run at a known fixed frequency.
The Legacy HAL successfully employs an algorithm based on the RTC while
the APIC HAL unsuccessfully tries to use the PIT.


> Actually we should, because the detection might not work (of course in our 
> simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other 
> platforms where there can be subtle differences)

Tell me about a single one we cannot detect and which is worth to
support. I don't recall that we ever recommended our testers to choose a
different HAL at setup.


> And normally it's not the setup that decides about the HAL, but the 
> bootloader.

That defies your previous point about the setup initializing the
registry depending on the HAL.
If we can let the user select a Legacy HAL in the boot loader after
installing with an ACPI HAL, it is also technically possible to have one
HAL that encompasses both.


- 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] About the bootcd and livecd, and the 1st-stage GUI setup

[Riccardo Paolo Bestetti]

IT guy says +1!

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of David Quintana 
(gigaherz)
Sent: martedì 4 luglio 2017 22:47
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

Oh the "Cancel and boot from hard disk" could be on the main menu I suppose!

On 4 July 2017 at 22:45, David Quintana (gigaherz) 
<gigah...@gmail.com<mailto:gigah...@gmail.com>> wrote:
I feel like the boot menu is going to be far too busy for the end user. I'd go 
with something closer to

blah blah:

  *   Install Now
  *   Try without installing
  *   Show advanced options...
where:

  *   Install now -- boots into the graphical installer (no desktop unless you 
cancel or something)
  *   Try without installing -- boots into livecd desktop (backed by RAM, I 
guess)
  *   Show advanced options... -- opens a second-level menu with

 *   Text-mode installer
 *   Live boot without Ramdisk
 *   etc.


On 4 July 2017 at 21:45, Hermès BÉLUSCA-MAÏTO 
<hermes.belu...@sfr.fr<mailto:hermes.belu...@sfr.fr>> wrote:
Hello everyone,

One of the long-term plan for ReactOS was to have a graphical user-mode 
interface for the 1st-stage setup, similar to e.g. what may be found in newer 
versions of Windows (Vista+), as an alternative to our current 1st-stage setup 
in text-mode
(note that I say “alternative”, not “replacement”, because both of them can 
live together without fundamental changes to either ReactOS or our ISO images, 
both of them can share core functionality, and finally because some people may 
prefer the text-mode either for unattended installations or for low-memory 
conditions).

You can find some information about the 1st-stage GUI setup here: 
https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it can be 
found in base/setup/reactos/ . Currently only most of the screens have been 
implemented, while the core functionality is not present. However this 
functionality can somehow be taken by reusing the source code of USETUP (see my 
branch 
https://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/ ).


Abstract (aka. TL;DR): I explain below the needed changes introduced 
experimentally in the “setup-improvements” branch, revision 75273, to generate 
an all-in-one ReactOS bootcd, that includes both the 1st-stage text-mode setup 
+ 1st-stage GUI setup alternative + live-demo functionality. This is meant to 
replace our currently separated “bootcd” / “livecd” ISOs, where the latter 
currently do not offer the possibility to install ReactOS. Some currently known 
potential problems are evoked.

Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; Proposed 
Boot Menu : http://i.imgur.com/14n5Ryi.png .


Having a 1st-stage GUI setup also means that it’ll also use the 
already-existing functionality that we offer in our “Live-CD” ISOs. Currently, 
the “Live-CD” ISOs we provide only allow for demonstration purposes, while the 
ReactOS installation proper is found in our so-called “Boot-CD” ISOs (which 
currently only contain text-mode setup). Thus, the 1st-stage GUI setup, as an 
alternative to the 1st-stage setup in text-mode, means that both ISOs can be 
merged all in one, and we won’t have to make a distinction between both: they 
will be able to offer both the 1st-stage in text mode AND a graphical mode (à 
la “Live-CD”) where it is possible to choose whether to test ReactOS in demo 
mode, or to install it via the GUI setup.
Such an all-in-one ISO capability was already present in the trunk under the 
name “hybridcd”, but was used only when we built ISO images for the public 
events where ReactOS participated (FOSDEM, CLT, …). But now, having the setup 
process both in text mode and in graphics mode, in addition to the Live-CD 
demonstration capability, really suggests just using the all-in-one ISO and 
stop doing the “Boot-CD” (aka. only setup) vs. “Live-CD” (aka. only demo) 
separation. We would just generate only one type of ISO that contains 
everything.

With that in mind, I have committed in my branch “setup_improvements”, in 
revision 75273 : 
https://svn.reactos.org/svn/reactos?view=revision=75273 such changes 
to be able to only build an ISO that contains everything. These changes are 
minimal, in the sense that I haven’t purposelessly changed the names of the 
build targets just to be fancy. Such changes may be done later, but not now.

The needed changes are the following: First, the build target that will 
generate the all-in-one CD is called “bootcd”, because this also was the main 
build target for ISOs before the change. Second, I completely remove the 
“hybridcd” build target, because its functionality are now absorbed by 
“bootcd”. Third, the build target “livecd” is reduced to its strict minimum. 
For the sake of building a RAMDISK boot drive (see comments after), I continue 
t

Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to support Windows XP or Vista"

[Riccardo Paolo Bestetti]

Hello Colin,
As this definitely wasn't the predominant thinking the last time this same 
discussion took place, Hermès' email scared me a bit. Thank you so much for 
clarifying.

Best regards,
Riccardo Paolo Bestetti

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: giovedì 29 giugno 2017 20:00
To: ros-dev@reactos.org
Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to 
support Windows XP or Vista"

Rest assured, we know that ReactOS won't be of much use if we stay NT5-only. 
Work is underway to provide a seamless support of NT6 applications on top of 
the existing codebase.
Also the majority of developers should be using an NT6 platform themselves, so 
they certainly aim for support for NT6 applications.
Finally, applications compiled by modern versions of Visual Studio are NT6-only 
by default, so supporting this platform is unavoidable.

Just my two cents, as the previous replies could lead you to believe we're 
failing the reality check.

Cheers,

Colin


Am 29.06.2017 um 18:54 schrieb Riccardo Paolo Bestetti:
> I’m just gonna snap in for my yearly IT guy NT6 rant: this mindset is 
> going to kill the project by making it useless whenever it reaches a 
> usable state.
> 
> Windows XP/Server 2003 use is **already** marginal as of today, and 
> it’s only gonna get “worse” as more and more networks get infected by 
> ransomware and institutions all over the world wake up and update (and 
> as time passes of course). It’s not a matter of “fancy”, it is a 
> matter of what people use on their computers. With that argument you 
> may as well advocate for DOS.
> 
>  
> 
> Please don’t be offended, as always this is only intended as a reality 
> check.
> 
>  
> 
> Best regards,
> 
> Riccardo Paolo Bestetti
> 
>  
> 
> *From:*Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of 
> *Hermès BÉLUSCA-MAÏTO
> *Sent:* giovedì 29 giugno 2017 16:09
> *To:* 'ReactOS Development List' <ros-dev@reactos.org>
> *Subject:* Re: [ros-dev] "Note: LibreOffice 5.4 will be the last 
> codeline to support Windows XP or Vista"
> 
>  
> 
> I’m wondering for which useless / fancy features they need Windows 7+ 
> support only….
> 
>  
> 
> H.
> 
>  
> 
>  
> 
> *De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* 
> Javier Agustìn Fernàndez Arroyo *Envoyé :* jeudi 29 juin 2017 15:48 *À 
> :* ReactOS Development List *Objet :* [ros-dev] "Note: LibreOffice 5.4 
> will be the last codeline to support Windows XP or Vista"
> 
>  
> 
> https://wiki.documentfoundation.org/Releases/5.4.0/RC1
> 
>  
> 
>  
> 
> FYI
> 
> 
> 
> ___
> 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] "Note: LibreOffice 5.4 will be the last codeline to support Windows XP or Vista"

[Riccardo Paolo Bestetti]

Sorry, let me clarify: I don’t think ransomware is a reason to target NT6. I 
think ransomware is contributing to wake up big institutions still running NT5 
to switch to NT6, which means more software will be ported to NT6, which means 
(along with other reasons) that NT5 will be even less significant than today.

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: giovedì 29 giugno 2017 19:05
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to 
support Windows XP or Vista"

rasomware is definitely not a reason.

Windows XP may be patched against it. Its not a matter of design, but 
implementation.

On Thu, Jun 29, 2017 at 6:54 PM, Riccardo Paolo Bestetti 
<riccardo.kyo...@live.it<mailto:riccardo.kyo...@live.it>> wrote:
I’m just gonna snap in for my yearly IT guy NT6 rant: this mindset is going to 
kill the project by making it useless whenever it reaches a usable state.
Windows XP/Server 2003 use is *already* marginal as of today, and it’s only 
gonna get “worse” as more and more networks get infected by ransomware and 
institutions all over the world wake up and update (and as time passes of 
course). It’s not a matter of “fancy”, it is a matter of what people use on 
their computers. With that argument you may as well advocate for DOS.

Please don’t be offended, as always this is only intended as a reality check.

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev 
[mailto:ros-dev-boun...@reactos.org<mailto:ros-dev-boun...@reactos.org>] On 
Behalf Of Hermès BÉLUSCA-MAÏTO
Sent: giovedì 29 giugno 2017 16:09
To: 'ReactOS Development List' <ros-dev@reactos.org<mailto:ros-dev@reactos.org>>
Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to 
support Windows XP or Vista"

I’m wondering for which useless / fancy features they need Windows 7+ support 
only….

H.


De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : jeudi 29 juin 2017 15:48
À : ReactOS Development List
Objet : [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to support 
Windows XP or Vista"

https://wiki.documentfoundation.org/Releases/5.4.0/RC1


FYI

___
Ros-dev mailing list
Ros-dev@reactos.org<mailto: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] "Note: LibreOffice 5.4 will be the last codeline to support Windows XP or Vista"

[Riccardo Paolo Bestetti]

I’m just gonna snap in for my yearly IT guy NT6 rant: this mindset is going to 
kill the project by making it useless whenever it reaches a usable state.
Windows XP/Server 2003 use is *already* marginal as of today, and it’s only 
gonna get “worse” as more and more networks get infected by ransomware and 
institutions all over the world wake up and update (and as time passes of 
course). It’s not a matter of “fancy”, it is a matter of what people use on 
their computers. With that argument you may as well advocate for DOS.

Please don’t be offended, as always this is only intended as a reality check.

Best regards,
Riccardo Paolo Bestetti

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès 
BÉLUSCA-MAÏTO
Sent: giovedì 29 giugno 2017 16:09
To: 'ReactOS Development List' <ros-dev@reactos.org>
Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to 
support Windows XP or Vista"

I’m wondering for which useless / fancy features they need Windows 7+ support 
only….

H.


De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : jeudi 29 juin 2017 15:48
À : ReactOS Development List
Objet : [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to support 
Windows XP or Vista"

https://wiki.documentfoundation.org/Releases/5.4.0/RC1


FYI
___
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

[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

[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 
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] "Test WHS" Builder is back!

[Riccardo Paolo Bestetti]

Il 12/09/2016 11:04, Colin Finck ha scritto:
The machine uses DDR2-667 FBDIMM (PC2-5300F) modules. 

Ah, way too old & exotic I'm afraid. It was worth a try.

Regards,
--- /Riccardo Paolo Bestetti/
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] "Test WHS" Builder is back!

[Riccardo Paolo Bestetti]

Il 10/09/2016 16:48, Colin Finck ha scritto:

Hi all,

Back in April, our server farm used for building had to leave its
hosting site (cf.
https://reactos.org/archives/public/ros-dev/2016-April/017775.html). A
single server was set up at the new site and I estimated to have our old
server farm back up by May or June.

Unfortunately, this still hasn't happened. Our server farm is still at
its old location and I cannot give a timeframe when it will finally be
shipped to the new location.

As we cannot wait forever for this to happen, I put up the old Windows
Home Server VM on our single new server and reintegrated it into
BuildBot ("Test WHS" builder).
Its performance won't match the former one for sure. Instead of 4GB of
RAM, it's currently at mere 1GB and it builds on HDD instead of
RAM-Disk. Nevertheless, it should be fully operational at least.

If this works out well, I'll see if I can also get our Win7 builder up
again. This would give us "Build GCCWin_x86", "Build MSVC_x64" and
"Build MSVC_x86".
I cannot resurrect the VMware and VBox testers right now though. This
will definitely need another machine. Will look after this in October.

Maybe we can also get a RAM upgrade for the existing machine to enable
building on RAM Disks again.


Cheers,

Colin
What kind of memory modules does the machine use? I have spares around 
from machines I tore down that I'd be glad to donate to the project.


Regards,
--- /Riccardo Paolo Bestetti/
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 4th scenario

[Riccardo Paolo Bestetti]

Il 22/05/2016 23:14, Love Nystrom ha scritto:

Server 2oo3 might not be used in big corporations anymore, but I think 
it's not uncommon to keep running it in small companies and home 
servers (due to high licensing cost of Windows server versions).

It /is/ pretty uncommon.
I'm in contact with IT administrators from many small companies, at this 
point everyone has either (a) moved to Linux, (b) moved to some kind of 
cloud service or (c) upgraded to Server 2012.

Even my school, which struggles to repaint walls, has done (c), lol.
I don't know if it is any different in other parts of the world, but I 
suspect it is pretty much the same.


Best regards,
--- /Riccardo Paolo Bestetti/
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Actually a GOOD architecture.

[Riccardo Paolo Bestetti]

Il 22/05/2016 14:18, David Quintana (gigaherz) ha scritto:
I believe Riccardo referred to people developing apps for ReactOS/NT5, 
when they can write them for NT6 instead.

That's what I meant.

I also agree with you, Neo, that NT, even version 5, is overall a better 
architecture than Linux.
However, I agree with gigahertz that discussing this isn't all that 
useful: good != not obsolete.


Best regards,
--- /Riccardo Paolo Bestetti

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

Re: [ros-dev] Pale Moon drops ReactOS support

[Riccardo Paolo Bestetti]

Ah, good to know! Looks like I'm even more right :-).

It was about time.

Regards,
--- /Riccardo Paolo Bestetti/


Il 17/05/2016 22:57, Neal Gompa ha scritto:

On Tue, May 17, 2016 at 2:58 PM, Riccardo Paolo Bestetti
<riccardo.kyo...@live.it> wrote:

Windows Server 2003 is definitely supported by Microsoft (which doesn't mean
it is supported by others, and it mostly isn't), but it is almost dead, and
it would only do harm to deny that.

I had to jump in on this, because this is becoming a repeated fact
that isn't true. Microsoft killed Windows Server 2003 support last
July[1]. It is most certainly dead to Microsoft. Please stop
perpetuating the idea that Microsoft supports a variant of a
15-year-old (!!!) operating system.

[1]: https://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

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

Re: [ros-dev] Pale Moon drops ReactOS support

[Riccardo Paolo Bestetti]

Il 17/05/2016 20:23, Magnus Johnsson ha scritto:
I am an utter scrubnub, but has followed this mailing list for.. more 
than a few years. Its not unheard of to get an angry response to a 
commit saying that its an API that is newer than the targeted version.


Being a scrubnub lurker I can't help but think that being somewhat 
agressive on compatibilty modes would be nice, but.. I'll shut up now 
:'). Just wanted the "people are angry when non-targeted versions of 
API's are implemented" thrown in there.

+1 to this, forgot to mention it.


Il 17/05/2016 20:04, Alex Ionescu ha scritto:

The project doesn't have to be hard-coded to NT5. For example, I am
building a UEFI loader/bootmgr based on Windows 10, because 2003
doesn't boot on UEFI systems.

That being said, I don't see any good reason for us not to still
mainly focus on 2003 for the kernel. The kernel is NOT what's
preventing apps from working, or hardware from working. What's
preventing that from working is:

1) Lacking user-mode APIs, and in some cases Rtl APIs (sure, implement
Win 10 ones!)
2) Lacking hardware support for things like UEFI (I'm working on it),
AHCI (we have a student working on it), USB 3 (someone can implement
this...but USB 2 barely works), etc..etc..etc..

Find me a single device driver that *only* works on NT 6... Server
2003 is still a support MS OS, so by definition there's still drivers
for it.
Best regards,
Alex Ionescu

Hello Alex,

You can definitely focus on 2003 for the kernel, however keep in mind 
that you would be re-implementing 14 years that is an advanced state of 
the process of migration towards new software.
Yes, user-mode APIs and lacking hardware support is what prevents apps 
from working now. Lacking kernel support is what will prevent apps from 
working in a few years.


A clear example: most of new Windows application are being written 
against the .NET libraries, and the last version of .NET has already 
dropped Windows XP support. I doubt you can run .NET 4.5 on a 2003 type 
of kernel even if you implement the last user-mode interface (and afaik 
you can't even do that unless you implement some parts of NT6), so this 
is already significant portion of apps that ReactOS will never be able 
to run if you stick to NT5. Unless you want to reverse .NET 4.5 too and 
rewrite the it to run on NT5... The same goes for all other examples of 
this kind, both from Microsoft and from 3rd party vendors.


I've also found an example of a device driver that only works on NT6, 
and in fact I didn't even have to look for it: it was the first device I 
saw on my desk. Elgato Game Capture HD, and that's pretty much the 
entire YouTube and Twitch gaming business (a multi-million dollar 
industry, for those who aren't familiar with it).
Also, some of the newer printers in my father's business, as well as the 
GPS navigation system map update driver for some of his trucks, to give 
some "job industry" examples.


Windows Server 2003 is definitely supported by Microsoft (which doesn't 
mean it is supported by others, and it mostly isn't), but it is almost 
dead, and it would only do harm to deny that.
Implementing NT5 with the "NT6" user-mode API would lead to an Open 
Source Windows Vista, without the "wow Aero looks so cool" factor. 
Please don't waste all the magnificent work you've done so far like this. :)


Best regards,
--- /Riccardo Paolo Bestetti/
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Pale Moon drops ReactOS support

[Riccardo Paolo Bestetti]

Hello Javier,
Thank you for your answer. Here's what I think about what you said.

Quoting myself:

   /Hell, it would probably be easier for a business to switch from NT6
   to GNU/Linux than to go back to NT5./

I was pretty serious. :)
Sorry if it wasn't clear, but by that I meant that developers would 
never go back to an old architecture, even if it's made Open Source.


We are talking about Open Source NT5 (legacy, maintened by a few 
talented developers, likely to be usable in a few years) vs. Open Source 
GNU/Linux (modern, maintened by hundreds of talented developers and 
supported by companies, used today to run the web). There's no game. 
It's not like developers are gonna pick up again an old (and, honestly, 
bad!) architecture just because it is made free, when *here and now* we 
already have a better alternative. This is obviously going to get worse 
as time passes, because that one last NT5 machine I mentioned in my 
previous email will be eventually eliminated too.


The only game ReactOS is likely to be able to compete on is NT6, or 
whatever NT will be mainstream when ReactOS will be ready for the real 
world. People need to be able to build or buy a new PC, load a ReactOS 
image and start working right away with their usual Windows software and 
tools. No one wants to live the whole NT6 migration again, let alone 
living it in reverse. And I'm not only speaking about office workers, 
but also developers.


Best regards and good luck,
--- /Riccardo Paolo Bestetti/

Il 17/05/2016 16:44, Javier Agustìn Fernàndez Arroyo ha scritto:

"companies and such support NT5?"

where "support NT5", i meant "drop support for NT5", sorry

On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo 
<elh...@gmail.com <mailto:elh...@gmail.com>> wrote:


And why does few developers, companies and such support NT5?
Because MS dropped support for those systems. But if ReactOS
revives that support, maybe companies will support us.

On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti
<riccardo.kyo...@live.it <mailto:riccardo.kyo...@live.it>> wrote:

I'd like to drop my two cents, just because I really believe
in this project's filosofy. Since things have gotten pretty
hot in the past, especially when someone who is not a
developer intervened in a discussion, let me apprise you that
my only intention it to bring in the point of view of a
potential user that really wants to see ReactOS happen and
isn't emotionally attached to the work that has been done.

The reality is that very very few manufacturers and developers
still support NT5 and all of them are going to drop support in
the next few years. This is just a fact. NT5 is legacy
software and there's nothing no one can do about that.

I've followed this project and this mailing list for the past
five years and in this time I've upgraded all of the computer
systems of my father's business to Windows 7 and then to
Windows 10, because all the pieces of software they run
dropped support for NT5, one after another. They still have a
single machine in the whole building running Windows XP, for
legacy software, and honestly they don't use it very often. In
my school, pretty much the same. And even if someone, for
whatever reason, intends to run NT5 for 10 more years, why
should (s)he re-setup all the systems again to run ReactOS
instead of keeping Windows XP?

The point is, you can either implement the architecture that
runs all of the computer in building, or the architecture that
runs that one legacy machine. And even that would happen if
and only if you can achieve 100% compatibility with all of NT5
and Windows XP bugs and quirks and give people a really good
reason to reinstall the OS on such machines, and sorry that's
just not gonna happen.

I get why some of you may want to stick to NT5, but you have
to be aware that if you do that ReactOS will never be used in
the real world. No reason to stick to NT5 is good enough,
since no one out there needs or wants NT5. Hell, it would
probably be easier for a business to switch from NT6 to
GNU/Linux than to go back to NT5.

Again, these are just the two cents of a guy that works in the
    field.

Best regards,
--- /Riccardo Paolo Bestetti/

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

Re: [ros-dev] Pale Moon drops ReactOS support

[Riccardo Paolo Bestetti]

I'd like to drop my two cents, just because I really believe in this 
project's filosofy. Since things have gotten pretty hot in the past, 
especially when someone who is not a developer intervened in a 
discussion, let me apprise you that my only intention it to bring in the 
point of view of a potential user that really wants to see ReactOS 
happen and isn't emotionally attached to the work that has been done.


The reality is that very very few manufacturers and developers still 
support NT5 and all of them are going to drop support in the next few 
years. This is just a fact. NT5 is legacy software and there's nothing 
no one can do about that.


I've followed this project and this mailing list for the past five years 
and in this time I've upgraded all of the computer systems of my 
father's business to Windows 7 and then to Windows 10, because all the 
pieces of software they run dropped support for NT5, one after another. 
They still have a single machine in the whole building running Windows 
XP, for legacy software, and honestly they don't use it very often. In 
my school, pretty much the same. And even if someone, for whatever 
reason, intends to run NT5 for 10 more years, why should (s)he re-setup 
all the systems again to run ReactOS instead of keeping Windows XP?


The point is, you can either implement the architecture that runs all of 
the computer in building, or the architecture that runs that one legacy 
machine. And even that would happen if and only if you can achieve 100% 
compatibility with all of NT5 and Windows XP bugs and quirks and give 
people a really good reason to reinstall the OS on such machines, and 
sorry that's just not gonna happen.


I get why some of you may want to stick to NT5, but you have to be aware 
that if you do that ReactOS will never be used in the real world. No 
reason to stick to NT5 is good enough, since no one out there needs or 
wants NT5. Hell, it would probably be easier for a business to switch 
from NT6 to GNU/Linux than to go back to NT5.


Again, these are just the two cents of a guy that works in the field.

Best regards,
--- /Riccardo Paolo Bestetti/


Il 16/05/2016 16:42, Ged Murphy ha scritto:


But you’re missing the point. The problem is that modern software is 
leaving XP behind and focusing on Win7 as a minimum recommended 
requirement.


What use is ReactOS if none of the modern browsers or applications 
will run on it? It limits the OS to being a compatibility solution for 
older software, or a POS device. No one really wants to see that.


I think the best solution to start with is to keep reporting as 5.2 in 
the kernel, but allowing developers to start moving to the NT6 model. 
An mish-mash of NT5 and NT6 can co-exist as long things are done 
sensibly. e.g. adding IO cancelation to our NT5 kernel isn’t going to 
make us incompatible for XP’s drivers, but it allows us to implement 
an NT6 feature which hugely benefits the OS. Other obvious candidates 
are unimplemented areas such as the fltmgr . Why implement the 2k3 
fltmgr when we can implement a later fltmgr model which still loads 
older filter drivers.


Usermode should also still report as win2k3 (at least in the short 
term), but start to add NT6 APIs directly into the codebase instead of 
using a shim. We then maintain a whitelist of processes that don’t run 
on ros due to a minimum requirement issue, and they get a modified 
result from VerifyVersionInfo (and friends) to a later OS version.


The above changes keep things pretty simple to start with, and allow 
us to move forward almost immediately with very little infrastructure 
work.


Ged.

*From:*Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of 
*Javier Agustìn Fernàndez Arroyo

*Sent:* 15 May 2016 22:55
*To:* ReactOS Development List <ros-dev@reactos.org>
*Subject:* Re: [ros-dev] Pale Moon drops ReactOS support

"Being runnable only on old computers"

I think this is a bad understanding of the problem

By such statement, it seems that ReactOS will only work on old 
computers. And thats not true.


ReactOS may work in any computer where there is hardware drivers for. 
And, as such, any software written for XP/2k3/ReactOS will work in 
that computer.


And afaik, manufacturers are still releasing drivers compatible with 
XP :) (nVidia, for example)




___
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