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

2020-12-02 Thread Magnus Johnsson 
Just a question from the outside here. If we look forward instead of
backwards, what work would it take to make *just the command line build
tools* work on reactos for newer versions?
Is that something to strive for? Is there a missing API, is it
fundamentally incompatible in some way, is reactos 'target windows version'
wrong..?

Den ons 2 dec. 2020 kl 11:14 skrev :

> I unfortunately don't get to contribute much anymore due to other
> commitments, so my view has little weight here, however I just wanted to
> throw my support behind Colin here in his effort to move the project
> forward.
>
> Personally, I'd love to see reactos move to more modern standards,
> allowing more emphasis to be placed onto modern C++ and the benefits it
> brings:
> - Support for scoped resources and RAII
> - Better type checking
> - Stronger use of const correctness
> - Range based loops
> - Use of bool and nullptr instead of BOOLEAN/BOOL and NULL
> - Even use of the thing I hate the most ... auto 
> - STL in user mode
> - vectors, lists, etc
> - NATVIS support to make the above easy to debug
> - etc, etc, etc
>
> I'm not advocating that these should be requirements, or to ever try to
> push devs to make use of them, but it would be incredibly useful to give
> developers the option if they prefer, as so many developers no do.
>
> If it were me, I'd be tempted to drop VS2015 support too, only ever
> supporting the last two major toolchains from any compiler.
>
> Ged.
>
>
> -Original Message-
> From: Ros-dev  On Behalf Of Colin Finck
> Sent: 02 December 2020 08:07
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] Status Meeting (November 2020)
>
> > 1. Visual Studio 2010 is the last version that works (or almost works)
> > on ReactOS [...]
> > 2. Dropping useful features is not really a good idea at all.
>
> Oleg, nobody wants to take away any features here. VS2010 will continue
> to run on ReactOS now and in the future. This discussion is merely about
> *compiling ReactOS* with VS2010.
>
> Everyone, please put personal preferences aside and think about the big
> picture:
> We don't have the workforce Microsoft had when creating Windows XP.
> The only way we can ever create a compatible OS is by leveraging modern
> technologies not yet available back then and building on the open-source
> work third parties have already done for us.
> If we however decide to limit us to 10-year-old technologies now, we can
> do neither. Don't expect us to ever get this project into a usable state
> in a lifetime then.
> The future of the project is at stake here!
>
> I don't want to repeat myself, so let me just link to the reasoning I
> already gave:
> * https://reactos.org/archives/public/ros-dev/2020-December/019158.html
> * https://github.com/reactos/reactos/pull/2658#issuecomment-619540076
> * https://github.com/reactos/reactos/pull/2658#issuecomment-629498043
> * https://github.com/reactos/reactos/pull/2658#discussion_r427615924
> * https://github.com/reactos/reactos/pull/2658#issuecomment-631113317
>
>
> Best regards,
>
> Colin Finck
>
>
>
> ___
> 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] sumatraPDF

2020-05-01 Thread Magnus Johnsson 
Essentially the answer is 'patches are welcome'? :')
And anyway, for them to support reactos, would be to support older windows
versions. Then it's reactos's job to support *it*.

Den fre 1 maj 2020 kl 13:14 skrev Javier Agustìn Fernàndez Arroyo <
elh...@gmail.com>:

> check this link guys! :)
>
> (yes, i am the poster) :)
>
> https://forum.sumatrapdfreader.org/t/support-reactos/2921
> ___
> 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] no replies about making reactos accessible for the blind

2018-11-14 Thread Magnus Johnsson 
Interesting! So I was *completely* wrong ;).

How would *you* go about making the installer accessible?

Den ons 14 nov. 2018 kl 19:10 skrev Erkin Alp Güney :

> WINE's accessibility stuff is handled by underlying desktop's UI kit,
> not by WINE itself.
>
> 14.11.2018 17:51 tarihinde Magnus Johnsson yazdı:
> > Jumping in here with a quick reply as a *lurker*, not a developer:
> >
> > Don't think anyone would mind if you supplied patches :). You have to
> > understand, with people still working on kernel things, making
> > applications actually work, stop crashing, hardware support...
> >
> > Most that would interface with screenreaders would *probably* be
> > handled by WINE anyway. Is there something specific you have a problem
> > with not working? If so, do file a bug report! But first check that
> > the same fault doesn't pop up with wine under linux.
> >
> > On Wed, 14 Nov 2018, 15:39 Dick mailto:d...@deds.nl>
> wrote:
> >
> > Hi,
> > I did not receive anny replies about my question to make reactos
> > accessible for the blind. I would really suggest to do that while
> > building
> > the os, instead of doign it when the whole system is fully built.
> >
> >
> > ___
> > 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
>
> ___
> 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] no replies about making reactos accessible for the blind

2018-11-14 Thread Magnus Johnsson 
Jumping in here with a quick reply as a *lurker*, not a developer:

Don't think anyone would mind if you supplied patches :). You have to
understand, with people still working on kernel things, making applications
actually work, stop crashing, hardware support...

Most that would interface with screenreaders would *probably* be handled by
WINE anyway. Is there something specific you have a problem with not
working? If so, do file a bug report! But first check that the same fault
doesn't pop up with wine under linux.

On Wed, 14 Nov 2018, 15:39 Dick  Hi,
> I did not receive anny replies about my question to make reactos
> accessible for the blind. I would really suggest to do that while building
> the os, instead of doign it when the whole system is fully built.
>
>
> ___
> 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] Valve support for ReactOS?

2018-08-31 Thread Magnus Johnsson 
Valve supports linux, and develops actively for it because A) it brings
them a small, but noticable, income
and
B) Because they are still fuckin' around with the idea of an valve-console.

Neither of those are relevant for reactos :)

Den tors 30 aug. 2018 kl 09:20 skrev Javier Agustìn Fernàndez Arroyo <
elh...@gmail.com>:

> i was thinking about Valve's Linux support (Steam play) and i was
> wondering about asking them to support ReactOS via development...
>
> Since Windows XP/2k3 are being abandoned, maybe ReactOS could still run
> Steam games... if they support it.
>
> what do you think?
> ___
> 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] Needs DejaVuMathTeXGyre.ttf?

2018-08-01 Thread Magnus Johnsson 
It's the font used to display advanced mathematical equations, part of the
dejavu suit.

If you have run into it other than a font dropdown box, that's probably in
error, otherwise its inclusion is just standard.

On Wed, 1 Aug 2018, 09:37 katahiromz, 
wrote:

> Dear everyone,
>
> I think DejaVuMathTeXGyre.ttf is bad font for normal use. Why do we need
> this font?
>
> Thanks
> ___
> 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] Microsoft acquires GitHub

2018-06-05 Thread Magnus Johnsson 
Plus, like people said, its decentralized. If they suddenly go nuts and
delete everything, you can just, though its a major PITA, just upload a
copy of the repo to a new server and change url's. If you want to be
paranoid about it, have a domain name that just aliases to github and then
if shit hits the fan point it elsewhere.

2018-06-05 19:52 GMT+02:00 David Quintana (gigaherz) :

> No one said we don't need a plan B. We had a plan B before moving to
> github.
> In fact, the move to github only happened because people were assured we'd
> always have a plan B.
> Why? Because github's servers are in the US, and many of the dev team
> didn't like the idea to put our sources in US computers.
>
> I will proceed to ignore everything after your first line, because it's
> mindless paranoia.
>
> You do have a point about the issues, except we don't host them on github,
> so only the Pull Requests would remain, and i'm 100% sure if github becomes
> hostile, we'll have plenty time to make a copy of the data.
>
> [I was typing that and the power blinked off long enough to shut down my
> pc ¬¬]
>
> On 5 June 2018 at 19:43, M. Ziggyesque  wrote:
>
>> No, I don't see it as pointless to have a plan B. It's more a question of
>> when, not if, it's desirable, given past practices.
>>
>> Even with no immediate changes, github can no longer be considered
>> vendor-neutral. Down the road, as example, M$ may well try to require every
>> project adopt their code-signing policy or the project gets deleted, so
>> they get their kickbacks on all the certificate fees that would entail. ROS
>> doesn't require code-signing?? DELETE!! They did similar when they bought
>> out sysinternals, bloated all their utilities with certificates, so that's
>> a distinct possibility.
>>
>> While migrating the repo itself is easy, the issues list and other
>> history is less so, plus the hassle of getting links on external pages to
>> redirect to a new home; those would take some lead time so imo is better to
>> have some plan than not.
>>
>> -- Original message--
>> *From: *David Quintana (gigaherz)
>> *Date: *Tue, Jun 5, 2018 4:40 AM
>> *To: *ReactOS Development List;
>> *Cc: *
>> *Subject:*Re: [ros-dev] Microsoft acquires GitHub
>>
>> To elaborate further:
>>
>>1. The deal won't be closed for many months (they expect december)
>>2. Microsoft probably won't change github at first (xcept maybe make
>>the login integrate with a Microsoft Account)
>>3. We don't know what they plan to do with the platform in the long
>>term, so worrying now is pointless.
>>4. We don't know that it will EVER be hostile toward ReactOS, even if
>>they break the platform and make it unusable, so chances are we are good.
>>5. If worst comes to worst, as Thomas said, we just say goodbye to GH
>>and move elsewhere.
>>
>>
>>
>> On 5 June 2018 at 10:36, Javier Agustìn Fernàndez Arroyo <
>> elh...@gmail.com> wrote:
>>
>>> great! :)
>>>
>>> On Tue, Jun 5, 2018 at 10:34 AM, Thomas Faber 
>>> wrote:
>>>
 To elaborate, we're not dependent on GitHub in any significant way. It's
 just convenient. But if it stops being so, it's easy to go elsewhere.
 That's a key part of Git, being a "distributed" VCS.


 On 2018-06-05 10:31, Oleksandr Shaposhnikov wrote:
 > No it may not.
 >
 > 5 черв. 2018 р. 11:24 Javier Agustìn Fernàndez Arroyo <
 elh...@gmail.com> пише:
 >
 >  May this affect ReactOS?
 >
 >  https://blogs.microsoft.com/blog/2018/06/04/microsoft-github
 -empowering-developers/
 


 ___
 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] 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 b

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

Re: [ros-dev] Merging our x86 HALs

2017-12-13 Thread Magnus Johnsson 
(Oh, and, is anyone willing to actually do the work involved and take it
under their wing?)

2017-12-13 13:02 GMT+01:00 Magnus Johnsson <magnus...@gmail.com>:

> (Outsider looking in, again. hello. Ignore me if needed)
>
> It seems to me like you are discussing this from a pretty nebulous sense
> of 'why should we do this' and the same for 'we are scared of doing this'.
> So, concrete question, what sort of issues are you likely to run in to?
> You have had issues now with bugs that pop up only on some HAL's due to
> duplication of code. What are the negative consequences of doing this? What
> could potentially break? Why would really old hardware break, and can it be
> mitigated? And, if shit hits the fan, how hard would it be to backtrack
> again/make a dirty as hell hack at runtime?
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_-3948499177932828522_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2017-12-13 12:49 GMT+01:00 Javier Agustìn Fernàndez Arroyo <
> elh...@gmail.com>:
>
>> "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> 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] *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> 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] *On Behalf Of *Javier
>>> Agustìn Fernàndez Arroyo
>>> *Sent:* martedì 12 dicembre 2017 18:13
>>> *To:* ReactOS Development List <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> 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

Re: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories

2017-09-07 Thread Magnus Johnsson 
Doesn't submodules do what you need? And, all submodules get cloned
automatically if you just add --recursive to the clone command. It all
depends on what you mean by arbitrary location. :).

https://github.com/magnusjjj/gfesys/blob/master/.gitmodules

(I will shut up if you feel this is annoying and shit. Not meant as a
besserwisser-y shit or no-clue-as-to-situation or something, and don't want
to derail the discussion :). Just nerdsniped me since I have been using the
functionality a fair bit and also seen other projects use it for things
that *sound* similar to what you are talking about)


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-09-07 23:50 GMT+02:00 David Quintana (gigaherz) :

> Answering to Magnus: In svn it's trivial to checkout a subfolder in an
> arbitrary location and commit and such from that subfolder. This made it
> easy to have separate root folders for rostests, rosapps, etc. Doing this
> in git is non-trivial and even if possible, would require multiple clones,
> which is not wanted.
>
> Answering to Dimitrij: Using mklink in windows requires administrator
> privileges. It's not a valid option. And XP didn't have proper symlinks, it
> had junction points which are not quite the same.
>
> Given to the two reasons above, it's much more effective to permanently
> move the files to inside the modules folder, where the build system already
> expects it, and change the check from "folder exists" to "this
> property/variable is set".
>
> On 7 September 2017 at 22:50, Dimitrij Klingbeil 
> wrote:
>
>> Hi Colin
>>
>> How about using links in the local filesystem? On Windows it's possible
>> to use directory links in a similar way to Linux. Starting from Win7 there
>> is a simple native way to do so (the mklink command), but it has already
>> been possible since WinXP (with linkd.exe from the Windows Server 2003
>> Resource Kit).
>>
>> It should be possible to keep the modules structure, clone the individual
>> repositories into separate directories locally and link the directories
>> into the target directory with one of the linkd / mklink / ln utilities on
>> the development system. The links can be easily deleted with the normal
>> Windows delete functions if need arises to remove them.
>>
>> Regards
>> Dimitrij
>>
>> - Original Message - From: "Colin Finck" 
>> To: "'ReactOS Development List'" 
>> Sent: Thursday, September 07, 2017 7:17 PM
>> Subject: [ros-dev] Git Migration: The documentation, rossubsys and
>> wallpapers directories
>>
>>
>> Hi all!
>>>
>>> As you know, we have to give up our "modules" directory concept when
>>> switching to Git, because Git doesn't support checking out an arbitrary
>>> directory into a subdirectory of a Git clone.
>>> Therefore, the first commit to the migrated repository will make the
>>> "reactos" directory the new root and move "rosapps" and "rostests"
>>> permanently into "modules". We can then introduce an environment
>>> variable/CMake variable/something else to enable or disable building of
>>> them on demand (suggestions are welcome!)
>>>
>>
>>
>> ___
>> 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] Git Migration: The documentation, rossubsys and wallpapers directories

2017-09-07 Thread Magnus Johnsson 
"Git doesn't support checking out an arbitrary directory into a
subdirectory of a Git clone."

What is it that you feel is lacking? Because I have done similar things,
depending on how you frame the issue.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-09-07 19:26 GMT+02:00 David Quintana (gigaherz) :

> Suggestion for modules: cmake properties (and default value):
> DISABLE_ROSTESTS:bool=false ENABLE_ROSAPPS:bool=false
>
> Since we can call cmake with -DENABLE_ROSAPPS:bool=true in the
> commandline, to override the default, it's easy to toggle.
>
> As for other modules:
>
>- Documentation deserves its own repository, at github.com/reactos/
>documentation, where people can more easily contribute documentation
>separately from code.
>- Rossubsys: I'd extract them into some git repository at like
>git.reactos.org/rossubsys.git, for anyone who wants to access them
>historically, but I wouldn't bother making a github repository for them.
>- Wallpapers: Would be nice to have a community website where people
>can submit wallpapers, themes, cursors, icons, ... and the "staff picks"
>can get copied into modules/wallpapers and included in releases.
>
>
>
>
>
> On 7 September 2017 at 19:17, Colin Finck  wrote:
>
>> Hi all!
>>
>> As you know, we have to give up our "modules" directory concept when
>> switching to Git, because Git doesn't support checking out an arbitrary
>> directory into a subdirectory of a Git clone.
>> Therefore, the first commit to the migrated repository will make the
>> "reactos" directory the new root and move "rosapps" and "rostests"
>> permanently into "modules". We can then introduce an environment
>> variable/CMake variable/something else to enable or disable building of
>> them on demand (suggestions are welcome!)
>>
>> But what will happen to the remaining directories in /trunk, namely
>> "documentation", "rossubsys", and "wallpapers"?
>>
>> * Commits to "documentation" never had a relation to "reactos" commits,
>> so nothing is lost if we put that directory into a separate repo
>> "documentation.git" and remove all traces to it from the history of
>> "reactos.git". I'd go this way if there are no objections.
>>
>> * I don't get the idea of that "rossubsys" directory created in 2014..
>> These subsystems are all stubs, never built with modern ReactOS, and no
>> work has happened since "reviving" them. I would just go and remove them
>> again. You can always find them in our repository history.
>>
>> * The "wallpapers" directory is a harder candidate.
>> On the one hand, we don't want to bloat our ReactOS builds by including
>> wallpapers in every build. Also the number of wallpapers may increase in
>> the future, which could bloat the "reactos.git" repo even more.
>> On the other hand, the wallpapers have always accompanied our release
>> branches, so there is a value of having them tracked next to our code.
>>
>> I could put them in a separate repository "wallpapers.git" now and remove
>> all traces to them in the "reactos.git" repo. But then again, how are they
>> picked up by the build process in the future if we can't check them out
>> into a subdirectory of "modules"?
>> Another alternative is moving them to "modules/wallpapers_disabled". Then
>> they are not picked up by the build process until they are renamed to
>> "modules/wallpapers" for releases.
>>
>> What are your opinions on this?
>>
>>
>> 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] undelate

2017-08-21 Thread Magnus Johnsson 
   1. Send a mail to the list unsubscribe address, which will be of the
   form LISTNAME-leave@DOMAIN. The subject and body of this message will be
   ignored, so it doesn't matter what you put there.

not sure if you found out this yet. Quick google for mailman, which seems
to be what is used :)

2017-08-20 19:39 GMT+02:00 gmusume :

>
> hi I want undelate of the group
> thank
>
>
> Enviado desde mi smartphone Samsung Galaxy.
>
> ___
> 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] Opening up #reactos-dev to the public

2017-03-24 Thread Magnus Johnsson 
Then again, just saying here, is that there is such a thing as 'Premature
optimization'. This is a change that is literally one command to roll back
:). Just tell the dev's that its an experiment for a while and to submit
feedback if they see anything wonky. Communication is a good thing.

2017-03-24 16:13 GMT+01:00 Hermès BÉLUSCA-MAÏTO :

> I don’t approve the idea. The fact is that if the devs quit originally
> #reactos, it’s because it was generally too noisy, etc… . If we remove the
> moderation irc bit in #reactos-dev, you may expect the same phenomenon to
> occur in #reactos-dev too.
>
>
>
> *De :* Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* David
> Quintana (gigaherz)
> *Envoyé :* vendredi 24 mars 2017 11:35
> *À :* ReactOS Development List
> *Objet :* Re: [ros-dev] Opening up #reactos-dev to the public
>
>
>
> I approve the idea.
>
>
>
> On 24 March 2017 at 11:21, Colin Finck  wrote:
>
> Hi all!
>
> As you all know, our #reactos-dev IRC channel has been a moderated IRC
> channel for decades, and only operators (devs) and voiced people can
> talk. While we always tried to keep discussions dev-related there, no
> topic has ever been enforced on #reactos. The result is that I see a
> notable number of developers only on #reactos-dev these days.
>
> This is a pretty bad situation! Emerging developers hardly have a way to
> interact with all existing devs on IRC. Often enough, legitimate
> questions from them remain unanswered on #reactos. Moreover, we don't
> maintain the list of voiced people thoroughly, so even some contributors
> have to ask for temporary voice on #reactos-dev.
>
> Keep in mind that we're currently in the GSoC phase where students shall
> submit their proposals and get in touch with the developers.
> How are they going to do this on IRC if #reactos-dev continues to be an
> exclusive club?
>
> Because of these reasons, I'm proposing to remove the moderation bit on
> #reactos-dev and let everybody talk there.
> Its development topic should be enforced though! As soon as people get
> too off-topic, they should be directed to #reactos and kicked if nothing
> else helps. Given that all devs are already operators on #reactos-dev,
> it's fully in their hands.
>
>
> 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] Microsoft switched to Git

2017-02-16 Thread Magnus Johnsson 
You could enforce it via.. uh.. communication? :) (not trying to be snarky,
just thinking out loud)

Like, maintainers are the only ones getting push access to the master,
right? So you make sure anyone getting access to push things to the master
has that option used. Anyone not having access to it can only submit pull
requests, and you can easily see in the pull request if it will pollute the
history? It feels about right.
On github you have a setting on a repo, that lets you set a template for
pull request descriptions. In it, you can ask people to verify that they
have rebased. :).
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

2017-02-15 Thread Magnus Johnsson 
Zachary, that is some seriously valuable input :). I was going to write a
longer answer, with super simple answers, but I found that the super simple
solutions to these are all the top results on google, stackoverflow. Seems
like the situation has cleared up to be a *lot* simpler these days, like 2
to 3 commands copy paste, with helpfull comments on the what and why's :).
Check it out?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

2017-02-15 Thread Magnus Johnsson 
Wierd, any clue as to why?

There are some tools with git though that makes it operate with svn. Like,
as in that developers can use all the functions in git locally, but still
push/pull to SVN. Might be worth faffing about with and writing a guide? If
it works well and doesn't cause major headaches maybe people can use both.

I know the dual repositories are a bitch to maintain and not exactly bug
free, but it might be possible for people to use whichever tool fits them
best locally?
Actually, now I am itching to try it :).

I just feel like it would lower the entry point significantly for super
simple patches and maintenance. But then, I am not a reactos developer ;).

2017-02-15 11:47 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>:

> There was a talk last year, about the possibility of switching. At least
> one long-time member said if we fully switched, they'd leave the project in
> bad terms.
>
> On 15 February 2017 at 11:41, Magnus Johnsson <magnus...@gmail.com> wrote:
>
>> Sure, but, do you know that its a fact? Has anyone checked recently? We
>> are talking vehemently against it here, right, not 'minor annoyance'?
>> Not calling anyone out here, would just love to hear some input on what
>> they want from the repository system. No pooflinging, promise.
>>
>> 2017-02-15 11:35 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>
>> :
>>
>>> The number doesn't matter. The ReactOS project can't afford to lost any
>>> long-time members. Git would be a benefit for all of us, but it has to be a
>>> benefit for ALL of us. SVN works well enough meanwhile, even if passing
>>> patch files around is rather 1990s.
>>>
>>> On 15 February 2017 at 11:30, Magnus Johnsson <magnus...@gmail.com>
>>> wrote:
>>>
>>>> How many developers are we talking about here? :)
>>>>
>>>> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>>>>
>>>>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>>>>> the same, pushing all new projects to use tfs git, and give existing
>>>>> projects using vsts the option to convert if they wish.
>>>>>
>>>>> Git is far better at managing developers working in remote locations,
>>>>> and as most of the software industry has already moved towards devs 
>>>>> working
>>>>> remotely, it makes sense. There are very few big companies no longer using
>>>>> a distributed system such as git or mercurial.
>>>>>
>>>>>
>>>>>
>>>>> That fact that open source projects, which are inherently built on
>>>>> devs being remote, are still reluctant to move from a centralized to a
>>>>> distributed system seems archaic and self-detrimental. It’s a shame to 
>>>>> hold
>>>>> the project back because a few devs are unwilling to move forward.
>>>>>
>>>>>
>>>>>
>>>>> A distributed system can do everything a centralized system can do if
>>>>> you decide to model it in that way, and so much more if you decide to 
>>>>> model
>>>>> it in other ways.
>>>>>
>>>>>
>>>>>
>>>>> Ged.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>>>>> Quintana (gigaherz)
>>>>> *Sent:* 15 February 2017 09:57
>>>>> *To:* ReactOS Development List <ros-dev@reactos.org>
>>>>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>>>>
>>>>>
>>>>>
>>>>> Unlike us, Microsoft probably doesn't care if a few of the developers
>>>>> would rather quit than switch. ;P
>>>>>
>>>>>
>>>>>
>>>>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>>>>
>>>>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>>>>> it-and-some-back-story/
>>>>>
>>>>> I didn't expect Microsoft to switch to Git sooner than us..
>>>>>
>>>>> ___
>>>>> 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
>>
>
>
> ___
> 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] Pale Moon drops ReactOS support

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

Re: [ros-dev] ReactOS versioning

2015-03-09 Thread Magnus Johnsson 
A thought occurs to me. Is there a way to add descriptors to DLL functions?
It would be a neat way to handle having multiple versions. In Python you
can tag functions like @TargetVersionWindowsXP. If you could transparently
hide and rename symbols in the DLL's kernel-side on load time, then you
could have all the functions in the same file without losing sanity points.

2015-03-09 11:27 GMT+01:00 Colin Finck co...@reactos.org:

 Am 09.03.2015 um 09:59 schrieb Aleksey Bragin:
  I suppose if the API changes (and it means, it improves, and usually
  without breaking backward compatibility), then there is no reason to
  provide old, broken or incomplete implementation. I doubt there is any
  popular app which relies on some bugs in old API implementation which
  can justify that.

 My favourite for subtle changes inside Win32: SetTimer :)
 MSDN has removed many of the details now, so I quote from the old
 version of the page:

 ===
 uElapse
 [in] Specifies the time-out value, in milliseconds.
 Windows NT/2000/XP: If uElapse is greater than USER_TIMER_MAXIMUM, the
 timeout is set to 1.

 Windows 2000/XP: If uElapse is less than USER_TIMER_MINIMUM, the timeout
 is set to USER_TIMER_MINIMUM.

 Windows Server 2003: If uElapse is greater than USER_TIMER_MAXIMUM, the
 timeout is set to USER_TIMER_MAXIMUM.

 Windows XP SP2/Windows Server 2003 SP1: If uElapse is less than
 USER_TIMER_MINIMUM, the timeout is set to USER_TIMER_MINIMUM. If uElapse
 is greater than USER_TIMER_MAXIMUM, the timeout is set to
 USER_TIMER_MAXIMUM.
 ===

 Reference e.g. http://www.jliforum.de/board/viewtopic.php?p=61375#61375


 This has broken at least our third-party imported Matrix screensaver
 (see fix in r28955). Due to the widespread usage of the SetTimer API,
 there are probably more examples.
 Of course, given that we're targetting Windows Server 2003 SP1 or newer,
 the behaviour for us is clear. But if such changes occur in recent
 Windows versions as well, I believe we need different implementations of
 an API for each Windows version we try to emulate.

 Maybe someone can give an example of such a change in more recent
 Windows versions as well.


 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

Re: [ros-dev] GSoC :: application rejected

2015-03-03 Thread Magnus Johnsson 
Its probably on the lines of 'you have no users, don't plan to have any
users, and the last time you were in SOC nothing came of it' :P.

2015-03-03 15:20 GMT+01:00 Javier Agustìn Fernàndez Arroyo elh...@gmail.com
:

 yeah, well.. the politically correct answer

 But i doubt it`s the actual answer

 On Tue, Mar 3, 2015 at 2:48 PM, Pierre Schweitzer pie...@reactos.org
 wrote:

 The ReactOS Foundation application got officially rejected because of
 the numbers of slots available and the high # of terrific applications.

 On 03/03/2015 02:08 PM, Hermès BÉLUSCA - MAÏTO wrote:
  We've been yet again rejected for the same reasons as before (i.e. no
 apparent reasons)?
 
  Cheers,
  Hermès.
 
  -Message d'origine-
  De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre
 Schweitzer
  Envoyé : lundi 2 mars 2015 22:23
  À : ReactOS Development List
  Objet : [ros-dev] GSoC :: application rejected
 
  Dear all,
 
  The ReactOS Foundation application to GSoC has been rejected this year
 again. Statistics are not reliable after all.
 
  In any case, keep up the good work. We don't need Google to be the
 bests at what we do.
 
  Cheers,
  --
  Pierre Schweitzer pierre at reactos.org System  Network
 Administrator Senior Kernel Developer ReactOS Deutschland e.V.
 
 
  ___
  Ros-dev mailing list
  Ros-dev@reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev
 


 --
 Pierre Schweitzer pie...@reactos.org
 System  Network Administrator
 Senior Kernel Developer
 ReactOS Deutschland e.V.


 ___
 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] Ram/hdd

2012-02-18 Thread Magnus Johnsson 
Dude. Your mailserver claims that the time you sent the email was
2008-05-24, which flags your mail as spam.
Go check your settings, Aleksey was merely joking :).

2008/5/24 Mikey developer...@gmail.com:
 1. Time machines have not been invented so that's impossible.

 2. I don't live in the past so that was stupid

 3. I have my date/time done perfectly fine.

 So next time don't say that to someone  knows what they are talking about

 ___
 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] HDD Geometry switch

2011-11-28 Thread Magnus Johnsson 
No drama please! - Aleksey Bragin


2011/11/28 Ged Murphy gedmurphy.mailli...@gmail.com:
 Do you have to work at being this rude and disrespectful or does it just
 come naturally to you?
 This is the a great example of why the reactos forums are such a nasty place
 to visit.
 You must be quite proud.


 -Original Message-
 From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
 Behalf Of cae...@myopera.com
 Sent: 27 November 2011 23:07
 To: ReactOS Development List
 Subject: Re: [ros-dev] HDD Geometry switch

 Also, knowing the consequences, did you bother to issue any message to our
 community, to inform them about this?? Not every ReactOS user is subsribed
 to ros-dev.

 Ah wait... you ignored that as well. You will let others handle the problem
 as usual.

 I have 5 sets for testing, 2 real hardware and 3 vm. Each one with two
 partitions, one for ros and other for all the installers and drivers.

 So now, whenever i cross the border of this change, i will have to wipe all,
 recreate the partitions and copy the stuff back? It will take no less than
 half an hour for VM. On real hardware, just the copying can take up to 1
 hour.

 Do you value your time available to spend on ReactOS? Then perhaps you could
 also think about others as well?

 On Sunday, November 27, 2011 4:48 PM, Eric Kohl eric.k...@t-online.de
 wrote:
 cae...@myopera.com wrote:
  Is the new geometry backward-compatible? If i recreate the partitions,
 will they be visible when i regress test revisions before 54511?
 

 This is a one-way road. If you want to test older revisions, you must
 delete and re-create partitions again.


 Regards
 Eric

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



 --
 With best regards
 Caemyr

 ___
 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] Kernel Question

2010-05-23 Thread magnus johnsson 
I think he meant the reverse. He wants to use Reactos DLL's in windows.

2010/5/23 Andrew Faulds ajf...@googlemail.com

 If I understand you correctly, you want to replace ReactOS dlls with
 Windows dlls?
 Well, it's illegal under the Microsoft Windows EULA, but if that doesn't
 stop you, bare in mind it probably won't work, as ReactOS does not directly
 clone Windows in all areas and in some areas things are implemented in
 completely different ways.

 On 23 May 2010 20:25, ahmet alper parker aapar...@gmail.com wrote:

 Hi all,
 I am new to this mail group and have a question that probably needs
 your kind of technical knowledge to answer. I want to use reactos,
 however, up to its completion, can I use some libraries on windows to
 replace them? In example, wine libraries can be superseded by original
 windows libraries if you own them. I want to make the inverse of this
 simply for security reasons to use a kernel fully opensource and which
 have a documented api. So can I use ntkrnlos.exe and hal.dll or
 similar in original windows installations to replace propriety kernel
 and libraries for security reasons? If yes, which of them should I
 use, and are they complete to replace them?
 Also a second question may arise as the priority of reactos
 development can be focused on firstly these parts of the project or
 not?...
 Best Regards...
 Ahmet Alper Parker

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




 --
 Andrew Faulds (AJF)
 http://ajf.me/


 ___
 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