Re: [ros-dev] Distinguish between Windows and ReactOS

[Oliver Schneider]

Hi Nick,

On 2018-11-05 18:09, Nick Surfer wrote:
> I am writing a program which needs to know exact environment in which it
> is running. In case of Windows I simply use GetVersionEx and then
> analyze dwMajorVersion + dwMinorVersion which is enough for my case
> (then I know which WIN API calls I should use). But I stuck how to
> recognize that my program runs in ReactOS. I failed to find any docs
> about it. Any help is appreciated. 
For most scenarios this is even wrong for Windows itself. For example in
order to figure out if the ITaskbarList4 COM interface is available you
should NOT check the OS version and then act depending on whatever you
found out. Instead you should attempt to query for the interface and use
it if you succeed. It's trivial to create a shim class that will return
S_FALSE for each method called when the interface could not be queried.

Similarly if you are interested in a function that only exists on, say,
Windows 7, you'd use GetProcAddress() to find if the function you're
interested in exists. If it doesn't you'd use your fallback code path.

Of course if the function you are requesting behaves in a completely
different way than the original you'd be out of luck. But in case of
ReactOS _such_ observation should prompt you to file a ticket for the
defect (unless it's a known one). The point here is that for public and
documented functions there's pretty much a contract, just like for COM
interfaces.

Generally it's a suboptimal idea to use the OS version to conditionally
execute this or that code path. Instead try to check for capabilities
and go by whatever finding that gives you ...

Further reading:


Hope this helps,

Oliver

PS: now if you wanted to tell ReactOS apart from Windows one way would
be to look into the version information resource of one of the
well-known DLLs. kernel32.dll comes to mind. But as I pointed out above,
you likely do NOT want to do this NOR need this for all but a few edge
cases.

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

Re: [ros-dev] GSOC 2016 - SSH Service Project

[Oliver Schneider]

Perhaps have a look at 
which is Microsoft's effort at porting OpenSSH so that it can work with
PowerShell. (They are reusing what NoMachine had done before them.)

AFAIK they culled most of the OpenSSL functions in order to replace it
with Windows crypto, but since the argument of that being proprietary
would not hold in ReactOS, you could possibly use the ReactOS crypto
straight.

Otherwise, from what I know, you can re-enable the use of OpenSSL in it.

// Oliver

On 2016-03-02 17:18, Ged Murphy wrote:
> Why do we want an SSH server in the source?
> 
> If someone wants to run an SSH server, they can download and install one
> as they would do on Windows.
> 
>  
> 
>  
> 
> *From:*Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of
> *Zachary Gorden
> *Sent:* 02 March 2016 16:58
> *To:* ReactOS Development List 
> *Subject:* Re: [ros-dev] GSOC 2016 - SSH Service Project
> 
>  
> 
> Any SSH server developed for ReactOS would need to be written in C/C++
> and be compilable by both GCC and VC++. So while the expectation is that
> a developer would likely need to pull a SSH library from an existing
> source such as OpenSSH, the server itself will almost certainly need to
> be written from scratch if only because there does not exist as far as I
> am aware of a fully open source SSH server that runs natively on Windows
> without hauling around the likes of cygwin. Apache Mina is written in
> Java and therefore would be inappropriate as a starting base for the SSH
> server project.
> 
>  
> 
> On Wed, Mar 2, 2016 at 5:30 AM, Anchit Jain  > wrote:
> 
> Hello everyone,
> 
> I am Anchit Jain, Computer Science undergraduate from BITS PILANI,
> India. 
> I am interested in pursuing SSH Service project.
> 
>  
> 
> I have some experience in Socket Programming and Network Protocol
> development in C. Some of my work could be seen
> at https://github.com/anchitjain1234
> 
> .
> 
> In past, I have implemented some basic network services like TFTP
> protocol and some minor part of FTP client. 
> 
>  
> 
> Regarding the project :- Would this project require a new SSH Server
> to be written from scratch or to be build upon some existing
> codebase like Apache Mina etc.?
> 
>  
> 
> I would request potential mentors to guide me for the same.
> 
>  
> 
>  
> 
> Thanks,
> 
> Anchit Jain
> 
> 
> Image removed by sender.
> 
> 
> ___
> 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] Consideration for migrating from Subversion to Git

[Oliver Schneider]

Hi all,

want to share some thoughts and experiences regarding a VCS migration.

On 2016-02-25 07:49, Neal Gompa wrote:
> The poor usability of Git on non-*nix platforms is one of the reasons
> why I'm still a huge fan of Mercurial. Also, the SVN-like CLI workflow
> means that's it's less disruptive than moving to Git. There's also a
> fantastic guide on how to get started with Mercurial[0].
First of all, I'm also a big fan of Mercurial for the exact same
reasons. And perhaps I'd also add that I find that Git often lives up to
its name (e.g. when I say `git  --help` I do *NOT* want to be
dropped into a man page but rather see a concise description of options).

> That being said, Mercurial and Git can interoperate with each other
> fairly well. If you choose to have a Git server, then Mercurial can
> talk to it through hg-git[1]. If you choose to have a Mercurial
> server, then Git can talk to it through git-remote-hg[2].
In all fairness hg-git broke for me _consistently_ in the past. I would
not consider it reliable or recommend it to anyone for anything but the
simplest/smallest of repositories. Sometimes it was the "connection"
between the two repos that broke or that some idiom of either side was
not understood by the other.

> However, Mercurial has better support for natively working in Windows,
SourceTree (by the makers of Bitbucket) provides a fairly good user
experience on Windows, but you often still need to drop to a command
prompt for certain advanced operations. But I've had this experience for
both Git and Mercurial.

> and tends to handle the differences of platforms a whole lot better
> than Git does. My experience with importing and contributing to SVN
> based projects tends to be better with Mercurial than Git,
Not sure what repos you have imported and by what means and how you
verified that the whole thing was a valid duplicate. However, I can tell
you from my experience that I have not found a single repo exceeding a
few dozen revisions that could be converted without losses using the
import tools provided by Hg _or_ Git communities.

A lot of prerequisites have to be met to allow for a migration to
produce a proper valid duplicate on the other version control system.
For SVN this means usually that the convention(!) of having top-level
folders trunk, branches and tags need to be true for the *whole*
revision range to be converted. So if you started without this
convention and then introduced it - bad luck. Same if you had certain
accidents on the SVN side. Same if you introduced another project as
top-level folder and later merged it.

All these "kinks" in the revision history are bound to throw off these
automated import tools. I do know that some of them employ heuristics to
"take care" of certain accidents. And of course one can opt to ignore
the visible warnings. But most of those instances would really have to
be reviewed by a human and require some kind of decision. So automatic
handling leads to loss of information.

Essentially it depends on how truthful you want your copy to be. If you
can do with something that "just works" -- and "Git from now on, but SVN
if you want to rebuild historic revisions" -- then you can probably use
the import tools provided by the Git community. If you need more, they
just won't cut it.

> simply because the SVN data maps better in Mercurial.
Sorry to say, but this is simply untrue. There are plenty of things in
Subversion that do not at all map to anything in either DVCS. Starting
with the concept of tags and branches as folders. Same for empty
folders. And in my conversions (about a dozen which I saw through to the
end) I have often ended up with cases where Git as the target VCS would
have been a better match than Mercurial. It really depends *if* you want
a high-quality conversion.

I have worked with reposurgeon for nearly three years and it's the only
comprehensive tool, I know of, to achieve lossless copies of a repo in
another version control system. It even comes with a companion tool to
verify the results and best of all it is a maintained FLOSS project
(hosted on a Gitlab instance, btw). I can help if you choose to go this
route to have a high-quality conversion using reposurgeon. And AFAIK ESR
(the author) himself will also happily help out FLOSS projects like
ReactOS when you run into trouble. He did the conversion of Emacs to
Git, btw.

> There are very nice FOSS tools out there for providing an excellent
> development experience, such as Phabricator[4] and GitLab[5] for
> self-hosted environments. If you really want to move to a Git based
> hosted platform, GitLab.com offers free hosting[6], and there's also
> BitBucket[7] for either Mercurial or Git.
Let me add Kallithea, although the aforementioned ones come with many
additional features. In particular Phabricator comes with a code review
platform which is also used by the LLVM project. Here's an example which
shows many of the features Phabricator offers: