Author Topic: The MicroWeb DOS web browser  (Read 35421 times)

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5025
  • Karma: +44/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: The MicroWeb DOS web browser
« Reply #30 on: December 21, 2022, 12:40:29 am »
I'm really looking forward to see if he (mTCP author) can make his sockets library talk to VDOSTCP through those libraries! I'll gladly assist!
Thanks a lot. I'm just wrote the mTCP author so he can check the file.
I will let you know what he replies.

Regards
« Last Edit: January 02, 2023, 03:38:10 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

mbbrutman

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: The MicroWeb DOS web browser
« Reply #31 on: January 09, 2023, 04:03:09 am »
Hi - I'm the author of the mTCP DOS programs that Martin has been conversing with.

I was an early OS/2 user.  I started with version 2.11 on a 486-66 machine and migrated to Warp when it became available.  I used it for programming and getting connected to the Internet on a SLIP connection.  And of course it ran all of my old DOS software too.  I gave up around fixpack 26 or 36 though; by then Windows 98 was tolerable and I had Linux for more technical work.

I see the excitement here about Microweb, and about being able to run new software in general.

mTCP very much assumes a single-tasking DOS environment with control over the hardware.  It assumes that it is talking to a "packet driver", which is a device driver for an Ethernet card with a specific API.  As long as the packet driver has the API it doesn't matter what the actual hardware is.  This allows one to use a variety of Ethernet cards, and even non-Ethernet devices such as SLIP over a serial port or Token Ring.  (As long as the packet driver can make it look like an Ethernet card, it doesn't matter.)

The packet driver in turn wants to talk to the hardware directly.  It expects to just be able to start touching memory addresses and I/O ports for the Ethernet card, like any DOS good program would.  Obviously this presents some problems when using a real operating system with it's own networking support.

Here are some options:
  • Find a magic packet driver that allows DOS software to access whatever Ethernet hardware OS/2 is using.  This is similar to what virtualization environments use when you use their virtual Ethernet devices.  If there is an API in OS/2 that allows software in a VDM to send and receive raw Ethernet frames, then such a thing might exist.  Given that we are 20 years late, I doubt that it does exist or that finding such an API is going to be easy if it exists.
  • There is a software library that can be linked to DOS software running in a VDM that provides basic networking support through OS/2.  Martin has found this software library, and mTCP could be ported to use it instead of using a packet driver.  This is a lot of work and not guaranteed to work for all of the programs.  In theory it would let you use anything built on top of mTCP today, but that's not a large collection of software.
  • Dedicate a COM (serial) port to a DOS VDM, and then use the packet driver that makes SLIP connections look like Ethernet.  This probably works with minimal effort, but it requires another machine running Linux to serve as the router on the other end of the SLIP connection.  You can also use the ESP8266 "WiFi" modem like devices running a SLIP firmware to eliminate the need for the router and get straight onto your WiFi router.
  • Write new, native OS/2 software using the OS/2 networking APIs.  Yes, this is a lot of work, but it also has the most potential and except for having a good compiler and development environment, jumping through strange hoops is not required.  The end result is native to the OS and doesn't have strange memory limitations, like DOS programs have.

For quick results option 3 (SLIP over the serial port) with a WiFi modem or RaspPi doing the routing works.  Longer term, option four is the best option.  OS/2 is a wonderful operating system with real threading, an event manager for GUI work, a full networking stack, etc.  Only native programs can take advantage of that.

I'm here to provide encouragement and technical help.  I haven't run OS/2 in years though, so even if I do get a new install in a virtual machine I'm not going to be ready to develop software for a long time.