Re: [ros-dev] FOSDEM 2017 - It's happening!

[hermes . belusca]

We use FreeLDR for the RAM booting, which loads in RAM an ISO (not a HDD image 
yet).
For the LiveCD for example, the following lines can be added into 
freeldr.ini:

[Operating Systems]
...
LiveCD_RamDisk="LiveCD in RAM"
...

[LiveCD_RamDisk]
BootType=Windows2003
SystemPath=ramdisk(0)\reactos
Options=/MININT /RDPATH=livecd\livecd.iso /RDEXPORTASCD

FreeLdr will load the "livecd\livecd.iso" file from the boot drive (a USB key 
for example...) (the switch '/RDEXPORTASCD' explicitely specifies that the file 
is loaded as an ISO image, with read-only access, etc...).
Then, "ramdisk(0)\reactos" specifies that the kernel etc... will be loaded from 
the "reactos" directory inside the root directory constituted by the ramdisk, 
once the ramdisk is loaded.


Regards,
Hermès___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS Repository migrated to GitHub

[hermes . belusca]

Ahah!! 
Correct, you've a watchful eye!
Thank you very much!

Hermès.‌

De : 
magnus...@gmail.com
A : ros-dev@reactos.org
Envoyé: mardi 3 octobre 2017 20:09
Objet : Re: [ros-dev] ReactOS Repository migrated to GitHub
 

Are they not under the branches dropdown? Top left, three 
columns down? There is a handy drop down there. There are at least all the 
gsoc's, and a ton of other branches there? :). Check it out?

 



https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon";
 target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif";>
Virus-free. https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link";
 target="_blank">www.avast.com





 
2017-10-03 19:45 GMT+02:00 Hermès BÉLUSCA-MAÏTO hermes.belu...@sfr.fr>:

Thank you very much Colin !! \o/ \o/ \o/ \o/

A little question, although: Where are our (experimental) branches now? :P

Hermès

> -Message d'origine-
> De : Ros-dev [mailto:mailto:ros-dev-boun...@reactos.org";>ros-dev-bounces@reactos.org] 
De la part de Colin Finck
> Envoyé : mardi 3 octobre 2017 19:40
> À : mailto:ros-annou...@reactos.org";>ros-annou...@reactos.org; mailto:ros-gene...@reactos.org";>ros-gene...@reactos.org; 'ReactOS
> Development List'
> Objet : [ros-dev] ReactOS Repository migrated to GitHub

>
> Today, the ReactOS Source Code has been migrated from a central 
Subversion
> instance to a decentralized Git repository. Together with that, ReactOS 
joins the
> list of projects using the popular GitHub service for developing 
software:
> https://github.com/reactos/reactos"; target="_blank" 
rel="noreferrer">https://github.com/reactos/reactos
> We expect that this move greatly improves the way we collaborate on 
ReactOS
> development and reduces the barriers for newcomers. Just fork our 
repository
> on GitHub, commit your changes and send us a Pull Request!
>
> Migrating a source code history of more than 20 years that had seen 
multiple
> version control systems was not a straightforward task.
> Deciding on a decentralized version control system has not been either.
> First discussions already started back in 2009, when neither Git nor 
Mercurial
> were able to fully convert a large SVN repository like ours and Git’s 
Windows
> support was still neglected. Things improved massively over the years, 
with
> GitHub and Git for Windows emerging as reliable tools for software
> development. But the ReactOS Project still took advantage of some 
Subversion
> features, so only a smooth migration using a two-way SVN-Git mirror was
> attempted in 2016. This failed miserably, however important lessons 
were
> learned for a future complete migration to Git. The tipping point was 
reached
> in early 2017 when a majority of ReactOS developers spoke out in favor 
of
> moving to Git. Finally, the ReactOS Hackfest in August offered a forum to 
try
> out things and discuss every little detail of the planned migration. And 
this is
> what got us here today!
>
> The development documentation is still in the process of being rewritten 
to
> account for the Git migration. You may currently find outdated 
information
> here and there. However, most of that is on the Wiki, so you are more 
than
> welcome to help us!
> The SVN Repository has been turned read-only and will be kept online for 
a
> while at the last revision r76032. Our Git mirror now mirrors the 
GitHub
> repository. If you have already been using our old Git mirror, please note 
that
> you have to do a fresh clone of our new repository (from either GitHub or 
the
> mirror) as the old and new ones are incompatible.
> JIRA continues to be used for bug tracking, BuildBot for continuous 
integration,
> and FishEye as a code browser.
>
> I would like to thank all the people who have helped with this migration, 
be it
> on IRC, the mailing lists or at the Hackfest! Special thanks also go to 
the KDE
> Project for their excellent svn-all-fast-export tool that was used for 
the
> conversion. If you are ever in a similar situation, have a look at my 
conversion
> scripts as well as the Git helpers for our infrastructure.
>
>
> Colin Finck
>
> ___
> Ros-dev mailing list
> mailto:Ros-dev@reactos.org";>Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev"; target="_blank" 
rel="noreferrer">http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
mailto:Ros-dev@reactos.org";>Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev"; target="_blank" 
rel="noreferrer">http://www.reactos.org/mailman/listinfo/ros-dev







___
Ros-dev mailing list
R

Re: [ros-dev] GitHub Newbie Question

[hermes . belusca]

Oops yeah 
sorry, it was about "author name", not committer name. But you've understood my 
point.
Thanks!
 
De : 
gigah...@gmail.com
A : hermes.belu...@sfr.fr,ros-dev@reactos.org
Envoyé: mardi 10 octobre 2017 12:06
Objet : Re: [ros-dev] GitHub Newbie Question
 
Open the commit URL, such as 
https://github.com/reactos/reactos/commit/44060c284194546703805453f3985ed2bb140e6b,
 but with .patch appended to the end. This shows the author name as part of the 
"From:" line. The commiter doens't matter since it will be set to whoever 
presses the merge button. On 10 October 2017 at 11:56, Hermès BÉLUSCA - MAÏTO 
wrote: > ‌Hi all, > > I've a newbie question related to GitHub pull 
requests: How can one see > whether commits pertaining to a pull request 
have both a valid full > committer name and email set? So far I can only see 
the nicknames. > > Cheers, > Hermes > 
___ > 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] [ros-diffs] [reactos] 01/01: CID 1206831 Dereference after null check

[hermes . belusca]

Certainly 
not a "feature", but just that (certainly because it is only for user-mode AND 
the out pointer is not optional) the MS dev who introduced these functions 
didn't want to (or just more simply forgot to) not check for such NULL 
pointer.
And thus, 
if you pass NULL, it's just your fault if your app crashes.
And of 
course, since ReactOS also want to behave similarly... we don't check for NULL 
either!

H.


De : 
A : ros-dev@reactos.org
Envoyé: mardi 31 octobre 2017 16:10
Objet : Re: [ros-dev] [ros-diffs] [reactos] 01/01: CID 1206831 Dereference 
after null check
 

Seems like this API has a 'feature' where by it throws 
exceptions if BytesRead is 
null?

 
On Sun, Oct 29, 2017 at 8:02 AM, Jerome Gardou jerome.gar...@reactos.org> wrote:

HI,

that doesn't look good, as shown by https://reactos.org/testman/compare.php?ids=56275,56276"; rel="noreferrer" 
target="_blank">https://reactos.org/testman/compare.php?ids=56275,56276

Jérôme


Le 29/10/2017 à 11:17, Samuel Serapion a écrit :
https://git.reactos.org/?p=reactos.git;a=commitdiff;h=b3b2a23f05e5188dc1475961fcd7f036f0046d25";
 rel="noreferrer" 
target="_blank">https://git.reactos.org/?p=reactos.git;a=commitdiff;h=b3b2a23f05e5188dc1475961fcd7f036f0046d25

commit b3b2a23f05e5188dc1475961fcd7f036f0046d25
Author: Samuel Serapion samcha...@hotmail.com>
AuthorDate: Fri Oct 20 14:00:32 2017 -0400

     CID 1206831 Dereference after null check
          BytesRead is an optional out parameter and 
must be checked before being written to.
---
  sdk/lib/rtl/memstream.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sdk/lib/rtl/memstream.c b/sdk/lib/rtl/memstream.c
index 0549424ca4..8fe4169fb1 100644
--- a/sdk/lib/rtl/memstream.c
+++ b/sdk/lib/rtl/memstream.c
@@ -185,7 +185,8 @@ RtlReadMemoryStream(
        Stream->Current = (PUCHAR)Stream->Current + 
CopyLength;
  -    *BytesRead = CopyLength;
+    if (BytesRead)
+        *BytesRead = CopyLength;
        return S_OK;
  }
 


___
Ros-dev mailing list
mailto:Ros-dev@reactos.org"; target="_blank">Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev"; rel="noreferrer" 
target="_blank">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] RAPPS Database now maintained in https://github.com/reactos/rapps-db

[hermes . belusca]

Talking of 
which, what's the status of Victor's website for RAPPS submissions?

H.‌

De : 
gigah...@gmail.com
A : ros-dev@reactos.org
Envoyé: lundi 8 janvier 2018 18:28
Objet : Re: [ros-dev] RAPPS Database now maintained in 
https://github.com/reactos/rapps-db
 


\o/ awesome!
 
It would be more awesome to have a crowdsourced (moderated) compatibility 
database to generate these from, but until that's done, this is a really good 
addition.

 
On 8 January 2018 at 18:15, Colin Finck co...@reactos.org> wrote:

Hi all!

We all wanted the RAPPS Database to leave the main source tree for a
long time. When Alexander Shaposhnikov asked me today if it was possible
to regenerate the rappmgr.cab on every commit, I took the opportunity
and split off the /media/rapps folder (including all history) into its
own repository: https://github.com/reactos/rapps-db"; rel="noreferrer" 
target="_blank">https://github.com/reactos/rapps-db

As a bonus, the public database at
https://svn.reactos.org/packages/rappmgr.cab"; rel="noreferrer" 
target="_blank">https://svn.reactos.org/packages/rappmgr.cab is now 
automatically
updated with every commit to that repository.

I hope you'll like that change :)


Cheers,

Colin

___
Ros-dev mailing list
mailto:Ros-dev@reactos.org";>Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev"; rel="noreferrer" 
target="_blank">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] Status Meeting (May 2018)

[hermes . belusca]

Hi!

To that I see one solution, that has actually already been proposed in the 
PR:
we make an external package (a la Wine gecko) that one can download during 
installation, or later through RAPPS.
Then this package (possibly together with other heavy core ones?) could be 
hosted in some GitHub sub-repo or elsewhere...
Closing the PR now would definitely not be the right solution.

Best,
H.‌

De : "Colin 
Finck"
A : ros-dev@reactos.org
Envoyé: mercredi 30 mai 2018 18:21
Objet : Re: [ros-dev] Status Meeting (May 2018)
 
Am 30.05.2018 um 13:26 schrieb Ged Murphy:
> Potential problems are:
> 4) something else?

I've been struggling with e.g. https://github.com/reactos/reactos/pull/276

On the one hand, we definitely need official support for Chinese,
Korean, and Japanese character sets.
On the other hand, this must not bloat up ReactOS by default, and just
dropping a 12 MB font into the repository definitely does.
So what is the ideal solution? I don't even know myself.

- I could leave the PR open and hope that the submitter addresses my
comments and comes up with a better solution. That hasn't happened in
the last months.

- I could close the PR right away. That would give the submitter no
chance to address my comments and may even look disrespectful. And the
original problem tends to be forgotten.

- I could close the PR and open a JIRA issue describing the problem.
If we decide on that as a general rule, we would put another burden on
every reviewer. Additionally, such general JIRA issues tend to rot in
our database as well.

I think we often have this situation where the submitted PR is wrong,
but we don't know the right solution either, and therefore keep the PR
open. If we can better deal with these cases, the number of open PRs may
decrease significantly.


- 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

Re: [ros-dev] Status Meeting (November 2018)

[hermes . belusca]

Hello,

I may not be available as it's the day when I'm going somewhere for a 
conference; it just depends at which time I arrive at destination.

For the meeting we may talk about the best way we can move to delivering 
all-in-one ReactOS ISOs (containing livecd + installation in both text and GUI 
modes), and which changes this could imply for our infrastructure 
(buildbots/website...).

Best regards,
Hermes
De : "Javier 
Agustìn Fernàndez Arroyo"
A : "ReactOS Development List"
Envoyé: samedi 24 novembre 2018 22:06
Objet : Re: [ros-dev] Status Meeting (November 2018)
 

I'm at work but I will do my best to attend!
 


El sáb., 24 nov. 2018 21:38, Colin Finck co...@reactos.org> escribió:

Hi all!

Let me invite you to the November 2018 meeting, taking place next
Thursday, November 29, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.

This will be the first meeting since August and I hope we get some more
topics than just the obligatory Status Reports. Please send your
proposals by replying to this mail.


Best regards,

Colin

___
Ros-dev mailing list
mailto:Ros-dev@reactos.org"; rel="noreferrer" 
target="_blank">Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev"; rel="noreferrer 
noreferrer" 
target="_blank">http://reactos.org/mailman/listinfo/ros-dev




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

 

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

Re: [ros-dev] Status Meeting (November 2018)

[hermes . belusca]

‌Hi!

Usually when we talk about ReactOS 0.5, we implicitly think that it will enter 
beta state there.
So unless you consider this to not completely hold anymore, we can look at what 
remains to be done/fixed (importantly) so that we may qualify as going into 
beta state.
(And yes, USB and storage sound strongly as prerequisites for 0.5 in my 
opinion).

Best,
Hermes
De : "Ged 
Murphy"
A : "'ReactOS Development List'"
Envoyé: mercredi 28 novembre 2018 17:42
Objet : Re: [ros-dev] Status Meeting (November 2018)
 





Some potential 
talking points:

 


Selecting a new 
coordinator
Version bump to 0.5
USB / Storage (perhaps linked to 
a 0.5 release)
Mattermost
New website progress


 

 

From: Ros-dev  On Behalf Of 
Mark Jansen
Sent: Wednesday, 28 November 2018 16:13
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 
2018)

 



We can discuss this if you are present, but I don't see 

Re: [ros-dev] iso.reactos.org migrated to new server

[hermes . belusca]

‌Hi,

In case this happens to be indeed a problem, the additional stuff to add to the 
build scripts would be to upload these bootcdregtest ISOs to iso.reactos.org, 
while using now the local copy on the build machine network.

Best,
Hermes
De : "Colin 
Finck"
A : "'ReactOS Development List'"
Envoyé: mercredi 5 décembre 2018 20:01
Objet : [ros-dev] iso.reactos.org migrated to new server
 
Hi all!

iso.reactos.org, the file server used by our build machines and the
source for https://reactos.org/getbuilds, has been migrated to new
hardware at a different location today.

You should experience better transfer rates due to the increased
bandwidth, and a higher availability. The new hardware also offers more
disk space and redundancy to keep our precious ISOs absolutely safe :)

Unfortunately, the new iso.reactos.org is no longer right next to the
build machines. This has several consequences: If I had left the build
scripts as-is, the build machines would have uploaded the bootcdregtest
ISOs to iso.reactos.org, just to download them multiple times for each
Testbot a minute later. This would be an excessive waste of ISP
bandwidth and would have delayed the entire testing process.
Therefore, I changed the build scripts to keep the bootcdregtest ISOs
within the local build machine network. However, the downside is that
bootcdregtest ISOs are no longer available via iso.reactos.org.

Please let me know if this is a problem for you and needs a solution.
In the past, bootcdregtest ISOs were only available for a week and not
accessible via GetBuilds either, so I have no idea how popular they are.


Cheers,

Colin

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

 

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

Re: [ros-dev] [ros-diffs] 07/18: [WIN32K:NTUSER] Get rid of the cached window station Name member, and instead just use the name stored in the NT Object's header. CORE-11933 and PR #621.

[hermes . belusca]

Hello Timo,

Let's make a deal: while I fix this in win32k, you may try to find a way to fix 
that one too in the SAC driver line 1192:

https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/sac/driver/util.c;hb=d0c8636d1b41e07f67546c7f4f07df6ddbedb2a1#l1167

I used the object macros because I didn't want to have the (huge) overhead of 
calling ObQueryNameString() together with allocating memory buffers just to 
retrieve the necessary names that already exist somewhere. (Also we note that 
WinStation objects, by their nature, really wrap closely around the NT objects 
and that's why I didn't see any inconvenience in using the helper macros for 
retrieving said information).

Best,
Hermes‌

De : "Timo 
Kreuzer"
A : ros-dev@reactos.org,"Hermès Bélusca-Maïto"
Envoyé: lundi 10 décembre 2018 01:44
Objet : Re: [ros-diffs] 07/18: [WIN32K:NTUSER] Get rid of the cached window 
station Name member, and instead just use the name stored in the NT Object's 
header. CORE-11933 and PR #621.
 

Why did you remove an abstraction and create additional dependencies on
internal implementation details?

Win32k is not supposed to directly access internal kernel structures!
The headers and macros shouldn't even be in NDK.

Please revert or fix this. And while you are at it, put an "#ifdef
_NTOSKRNL_" around the stuff in NDK to prevent people from using it.

Thanks,
Timo


Am 19.08.2018 um 22:16 schrieb Hermès Bélusca-Maïto:
> 
https://git.reactos.org/?p=reactos.git;a=commitdiff;h=43e2ab208a2d3d50b12b4689347f57ca83568dd9
>
> commit 43e2ab208a2d3d50b12b4689347f57ca83568dd9
> Author: Hermès Bélusca-Maïto
> AuthorDate: Sun Jun 17 19:40:32 2018 +0200
> Commit: Hermès Bélusca-Maïto
> CommitDate: Sun Aug 19 22:18:32 2018 +0200
>
> [WIN32K:NTUSER] Get rid of the cached window station Name member, and 
instead just use the name stored in the NT Object's header.
> CORE-11933 and PR #621.
>
> - Remove the related hack-FIXMEs;
> - Adjust NtUserGetObjectInformation() in accordance.
> - Retrieve the window-station/desktop object type string in 
NtUserGetObjectInformation()
> also from the NT Object's header.
>
> Also simplify the UOI_FLAGS case of NtUserGetObjectInformation() by 
reading
> the handle inheritance information directly from the 
OBJECT_HANDLE_INFORMATION
> structure returned by ObReferenceObjectByHandle().
> ---
> win32ss/user/ntuser/sysparams.c | 3 +-
> win32ss/user/ntuser/winsta.c | 106 
+++-
> win32ss/user/ntuser/winsta.h | 1 -
> 3 files changed, 51 insertions(+), 59 deletions(-)
>
> diff --git a/win32ss/user/ntuser/sysparams.c 
b/win32ss/user/ntuser/sysparams.c
> index 7eedc028de..d0badba00e 100644
> --- a/win32ss/user/ntuser/sysparams.c
> +++ b/win32ss/user/ntuser/sysparams.c
> @@ -33,7 +33,8 @@ BOOL g_PaintDesktopVersion = FALSE;
> } \
> else \
> { \
> - ERR("NtUserSystemParametersInfo requires interactive window station 
(current is %wZ)\n", &GetW32ProcessInfo()->prpwinsta->Name); \
> + ERR("NtUserSystemParametersInfo requires interactive window station 
(current is %wZ)\n", \
> + 
&(OBJECT_HEADER_TO_NAME_INFO(OBJECT_TO_OBJECT_HEADER(GetW32ProcessInfo()->prpwinsta))->Name));
 \
> } \
> EngSetLastError(err); \
> return 0; \
> diff --git a/win32ss/user/ntuser/winsta.c 
b/win32ss/user/ntuser/winsta.c
> index f373b1cedf..ba1b1eb57d 100644
> --- a/win32ss/user/ntuser/winsta.c
> +++ b/win32ss/user/ntuser/winsta.c
> @@ -114,8 +114,6 @@ IntWinStaObjectDelete(
>
> RtlDestroyAtomTable(WinSta->AtomTable);
>
> - RtlFreeUnicodeString(&WinSta->Name);
> -
> return STATUS_SUCCESS;
> }
>
> @@ -449,8 +447,6 @@ IntCreateWindowStation(
> RtlZeroMemory(WindowStationObject, sizeof(WINSTATION_OBJECT));
>
> InitializeListHead(&WindowStationObject->DesktopListHead);
> - WindowStationObject->Name = *ObjectAttributes->ObjectName;
> - ObjectAttributes->ObjectName = NULL; // FIXME! (see 
NtUserCreateWindowStation())
> WindowStationObject->dwSessionId = NtCurrentPeb()->SessionId;
> Status = RtlCreateAtomTable(37, 
&WindowStationObject->AtomTable);
> if (!NT_SUCCESS(Status))
> @@ -491,7 +487,7 @@ IntCreateWindowStation(
> }
>
> TRACE("IntCreateWindowStation created object 0x%p with name %wZ handle 
0x%p\n",
> - WindowStationObject, &WindowStationObject->Name, 
WindowStation);
> + WindowStationObject, ObjectAttributes->ObjectName, WindowStation);
>
> *phWinSta = WindowStation;
> return STATUS_SUCCESS;
> @@ -582,23 +578,7 @@ NtUserCreateWindowStation(
> return NULL;
> }
>
> - WindowStationName.Length = wcslen(ServiceWinStaName) * sizeof(WCHAR);
> - WindowStationName.MaximumLength =
> - WindowStationName.Length + sizeof(UNICODE_NULL);
> - WindowStationName.Buffer =
> - ExAllocatePoolWithTag(PagedPool,
> - WindowStationName.MaximumLength,
> - TAG_STRING);
> - if (!WindowStationName.Buffer)
> - {
> - Status = STATUS_NO_MEMORY;
> - ERR("Impossible to build a valid window station name, Status 0x%08lx\n", 
Status);
> - SetLastNtError(Status);
> - return NULL;
> - }
> - RtlStringCbCopyW(WindowStationName.Buffer,
> - WindowS

Re: [ros-dev] CORE-15467 - 1st stage setup freezes when the expected file is missing

[hermes . belusca]

‌Hi,

There is in principle (almost) all the infrastructure to implement the 
Retry/Skip/Abort dialog in usetup.
The freezing you encounter is however a bug I should investigate.

Cheers,
Hermes
De : "Javier 
Agustìn Fernàndez Arroyo"
A : "ReactOS Development List"
Envoyé: mercredi 19 décembre 2018 20:17
Objet : [ros-dev] CORE-15467 - 1st stage setup freezes when the expected file 
is missing
 

An idea,
 

I don´t think its a good idea to "skip" a file during 1st stage, specially 
core files (in 2nd stage it might be acceptable for some device drivers, for 
example)

 

So, if "cloning" the Win2k3 behavior, i would set only 2 options: retry or 
abort installation and reboot.

 

what do you guys think?




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

 

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