• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

ReactOS 0.3.14 Released

Started by miturbide, 2012.02.08, 17:09:45

Previous topic - Next topic

miturbide

(offtopic)

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

I had always found interesting the progress of this open source Windows 32bits clone project.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

Pete

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

miturbide

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.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

Pete

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

BigWarpGuy

I have been watching ReactOS and have been trying them on my older notebook computers.  8)
http://www.reactos.org


It seems to be doing better than OSFree.
http://www.osfree.org/wiki/doku.php

ALT

#5
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/

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.)

Paul Smedley

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/

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.)


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?

Paul Smedley

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."

ALT

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.

ALT

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.)

RobertM

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...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


miturbide

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.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

Blonde Guy

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.
Expert Consulting for OS/2 and eComStation

dryeo

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

Paul Smedley

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...