OS2World OLD-STATIC-BACKUP Forum

Public Discussions => Off Topic discussions => Topic started by: miturbide on 2012.02.08, 17:09:45

Title: ReactOS 0.3.14 Released
Post by: miturbide on 2012.02.08, 17:09:45
(offtopic)

Check ReactOS announcement
http://www.reactos.org/en/news_page_70.html (http://www.reactos.org/en/news_page_70.html)

I had always found interesting the progress of this open source Windows 32bits clone project.
Title: Re: ReactOS 0.3.14 Released
Post by: Pete on 2012.02.08, 18:11:51
Hi Martin

Guess I'll give it a try - although none of the reactos releases have worked so far here.

OTOH: As the webpage goes on forever with no content maybe I won't bother - if these guys cannot even put a webpage together what chance they can build an operating system that works?  :-)


Regards

Pete
Title: Re: ReactOS 0.3.14 Released
Post by: miturbide on 2012.02.08, 22:01:39
Hi Pete

I had tried older ReactOS in Virtual Machines. I consider their effort pretty good considering that they are not Microsoft, IBM, Apple, RedHat or Oracle.

Sure, it is not stable or production ready, but I'm amazed to see how much they had advanced without a regular income or a business case to profit from the project.

The web site is working fine at my side.
Title: Re: ReactOS 0.3.14 Released
Post by: Pete on 2012.02.09, 02:19:16
Hi Martin

I've yet to get any release to boot and install in VirtualPC - however, it does not mean that I do not appreciate their efforts and intentions.

Just revisited http://www.reactos.org/en/news_page_70.html and the page is loading fine now. Maybe it was a glitch with Seamonkey or something not quite right with the webpage code that has now been fixed but on my previous visit the page required lots of scrolling to get to the bottom; Miles of blank space between the last of the pages' text and the "ReactOS is a registered trademark or a trademark of ReactOS Foundation in the United States and other countries. " line.


Regards

Pete
Title: Re: ReactOS 0.3.14 Released
Post by: BigWarpGuy on 2012.02.09, 04:49:02
I have been watching ReactOS and have been trying them on my older notebook computers.  8)
http://www.reactos.org (http://www.reactos.org)
(http://www.reactos.org/history/10y/pictures/ros_logo_08.jpg)

It seems to be doing better than OSFree.
http://www.osfree.org/wiki/doku.php (http://www.osfree.org/wiki/doku.php)
(http://www.osfree.org/wiki/lib/tpl/osfree/images/osfree.png)
Title: Re: ReactOS 0.3.14 Released
Post by: ALT on 2012.02.11, 05:09:53
I was interested to notice the TCP/IP stack they're using (lwip), which is supposedly small, efficient, self-contained and highly portable.  And open source under the BSD-license.  http://www.sics.se/~adam/lwip/ (http://www.sics.se/~adam/lwip/)

It's unclear whether it supports IPv6, but it if does, it might not be a bad candidate for porting to OS/2 as a replacement for our current TCP/IP stack.

One of the nice things about MPTS is that protocol drivers are essentially plugins, so as long as the interface is maintained it should be eminently possible to replace the TCP/IP stack by itself.  AFAIK it's basically contained in the driver AFINETK.SYS (with two alternate versions provided, AFINET.SYS and AFLEAN.SYS, for various specialized purposes) plus the API DLLs TCP32DLL.DLL and TCPIP32.DLL (not sure what the distinction is).

MPTS protocol drivers apparently follow the NDIS 2.0.1 LAN Manager interface, which unfortunately I cannot find any extant SDK for (the DDK doesn't seem to have it), but evidently such a thing did exist at one point...  

I did find an interesting technical paper where somebody documented his experience in porting an open source TCP/IP stack to OS/2 back around 1991.  Basically the 'engine' was simply retained intact from the cross-platform code, and all he really had to do was implement the NDIS interface to LAN Manager on one side, and the API interface to applications on the other.  (PDF file here.) (http://ir.library.oregonstate.edu/xmlui/bitstream/handle/1957/21863/PillayHarish1990.pdf)
Title: Re: ReactOS 0.3.14 Released
Post by: Paul Smedley on 2012.02.11, 22:45:04
Hi Alex,

Quote from: ALT on 2012.02.11, 05:09:53
I was interested to notice the TCP/IP stack they're using (lwip), which is supposedly small, efficient, self-contained and highly portable.  And open source under the BSD-license.  http://www.sics.se/~adam/lwip/ (http://www.sics.se/~adam/lwip/)

It's unclear whether it supports IPv6, but it if does, it might not be a bad candidate for porting to OS/2 as a replacement for our current TCP/IP stack.

One of the nice things about MPTS is that protocol drivers are essentially plugins, so as long as the interface is maintained it should be eminently possible to replace the TCP/IP stack by itself.  AFAIK it's basically contained in the driver AFINETK.SYS (with two alternate versions provided, AFINET.SYS and AFLEAN.SYS, for various specialized purposes) plus the API DLLs TCP32DLL.DLL and TCPIP32.DLL (not sure what the distinction is).

MPTS protocol drivers apparently follow the NDIS 2.0.1 LAN Manager interface, which unfortunately I cannot find any extant SDK for (the DDK doesn't seem to have it), but evidently such a thing did exist at one point...  

I did find an interesting technical paper where somebody documented his experience in porting an open source TCP/IP stack to OS/2 back around 1991.  Basically the 'engine' was simply retained intact from the cross-platform code, and all he really had to do was implement the NDIS interface to LAN Manager on one side, and the API interface to applications on the other.  (PDF file here.) (http://ir.library.oregonstate.edu/xmlui/bitstream/handle/1957/21863/PillayHarish1990.pdf)


VERY interesting article.  I know IPv4 is going to around in some forms for ages, but without IPv6, eCS looks even more unattractive....

Where do the protocol drivers come into it - ie the bindings to tcpip.nif in protocol.ini?
Title: Re: ReactOS 0.3.14 Released
Post by: Paul Smedley on 2012.02.11, 22:47:38
http://lwip.wikia.com/wiki/LwIP_IPv4/IPv6_stacks

"Support for IPv6 is currently being added to LwIP. An experimental version can be downloaded from git."
Title: Re: ReactOS 0.3.14 Released
Post by: ALT on 2012.02.12, 06:20:51
Quote from: Paul Smedley on 2012.02.11, 22:45:04
Where do the protocol drivers come into it - ie the bindings to tcpip.nif in protocol.ini?

The protocol driver interface to PROTMAN is defined by MPTS and, AIUI, follows the NDIS 2.0.1 spec.  How much is part of NDIS itself and how much is MPTS's own stuff I'm not too clear.  It's very hard to find detailed information, although that thesis is probably a good place to start. 

AFAIK the MPTS we have today is a pretty close descendent of MS LAN Manager from OS/2 1.x.  It's quite likely the driver model is basically the same, so if Microsoft's LAN Manager docs could be hunted down they'd probably be quite informative.
Title: Re: ReactOS 0.3.14 Released
Post by: ALT on 2012.02.12, 06:24:49
Keep in mind this is really all just thinking aloud, I don't pretend to know a great deal about this stuff.

One question that arises is: would a new IPv6 stack replace the IPv4 stack or exist alongside it?  Specifically, would it have to perfectly implement the TCP/IP API in TCP32DLL etc.?  Or could it implement its own separate IPv6 API and require programs to be modified specifically to use that?  (The latter would probably be a lot easier than trying to reverse engineer and clone TCP32DLL/TCPIP32/SO32DLL/etc.)
Title: Re: ReactOS 0.3.14 Released
Post by: RobertM on 2012.02.14, 08:50:45
Quote from: ALT on 2012.02.12, 06:24:49
Keep in mind this is really all just thinking aloud, I don't pretend to know a great deal about this stuff.

One question that arises is: would a new IPv6 stack replace the IPv4 stack or exist alongside it?  Specifically, would it have to perfectly implement the TCP/IP API in TCP32DLL etc.?  Or could it implement its own separate IPv6 API and require programs to be modified specifically to use that?  (The latter would probably be a lot easier than trying to reverse engineer and clone TCP32DLL/TCPIP32/SO32DLL/etc.)


Can it just do a "hand-off" for IPv4 stuff, like object method/class replacements for OS/2 can do? That may be easiest of all...
Title: Re: ReactOS 0.3.14 Released
Post by: miturbide on 2012.02.14, 14:58:25
About OSFree.

I connect to the #OSFree channel on IRC (efnet) from time to time and talk to valeriusN.
The project need more help and developers to help on.

I'm currently testing some Forward DLL's they produced to replace the OS/2 ones. But the bigger components FreepPM, WPS, SOM, require more work.

Since I'm not a developer or system architect, I can not say what is the best approach to make an open source OS/2 clone, but I think that producing any open component that replaces close source code on OS/2 it is an step forward to reach that goal.
Title: Re: ReactOS 0.3.14 Released
Post by: Blonde Guy on 2012.02.14, 19:00:30
Quote from: ALT on 2012.02.12, 06:24:49

One question that arises is: would a new IPv6 stack replace the IPv4 stack or exist alongside it?  Specifically, would it have to perfectly implement the TCP/IP API in TCP32DLL etc.?  Or could it implement its own separate IPv6 API and require programs to be modified specifically to use that?  (The latter would probably be a lot easier than trying to reverse engineer and clone TCP32DLL/TCPIP32/SO32DLL/etc.)


Either approach would work. Windows XP uses two stacks. Windows 7 uses a dual-mode stack. No matter which is used, there is a well-defined (RFC 4038) way to support IPv4 programs that link to TCP32DLL, etc. New programs have to use new parameters and new constants in the same old Berkeley sockets interface, so any interface we currently use needs to be enhanced for IPv6. The enhancements at the application program level aren't that difficult, so making the additions to the appropriate header files should not be difficult. On the other hand, this has already been done for GCC and OpenWatcom for other platforms, so perhaps we'd just take that and leave our OS/2 toolkit files alone.

How about supporting IPv6 in 16-bit programs with os2tk45\h\stack16\...? I guess it could be done, but yuck.
Title: Re: ReactOS 0.3.14 Released
Post by: dryeo on 2012.02.15, 07:50:29
As I understand it (and I'm no expert) none of our programming interfaces even support getaddrinfo() which is the POSIX function to seamlessly use either IPv4 or IPv6 so the first step would be adding this to our libc and compiling programs to use it. The easiest way might be to rip the BSD licensed one from rsync. Without this step our programs only know how to interface with IPv4.
http://en.wikipedia.org/wiki/Getaddrinfo
http://pubs.opengroup.org/onlinepubs/009604499/functions/getaddrinfo.html
Title: Re: ReactOS 0.3.14 Released
Post by: Paul Smedley on 2012.02.16, 08:58:12
Quote from: dryeo on 2012.02.15, 07:50:29
As I understand it (and I'm no expert) none of our programming interfaces even support getaddrinfo() which is the POSIX function to seamlessly use either IPv4 or IPv6 so the first step would be adding this to our libc and compiling programs to use it. The easiest way might be to rip the BSD licensed one from rsync. Without this step our programs only know how to interface with IPv4.
http://en.wikipedia.org/wiki/Getaddrinfo
http://pubs.opengroup.org/onlinepubs/009604499/functions/getaddrinfo.html

I use a different implementation than the rsync one, but agree - it should be added to libc...
Title: Re: ReactOS 0.3.14 Released
Post by: Paul Smedley on 2012.02.16, 09:02:00
Quote from: ALT on 2012.02.12, 06:24:49
Keep in mind this is really all just thinking aloud, I don't pretend to know a great deal about this stuff.

One question that arises is: would a new IPv6 stack replace the IPv4 stack or exist alongside it?  Specifically, would it have to perfectly implement the TCP/IP API in TCP32DLL etc.?  Or could it implement its own separate IPv6 API and require programs to be modified specifically to use that?  (The latter would probably be a lot easier than trying to reverse engineer and clone TCP32DLL/TCPIP32/SO32DLL/etc.)


I would have thought a dual-stack approach would be the best option.  Apps seem to link to either TCP32DLL or SO32DLL, and the functions present in those DLLs are fairly BSD compliant (except for select())