Tag Archives: dosbox

retro

Getting Windows 3.1 connected to the internet (in DOSBox of course)

What if, for historical reasons, you wanted to test early Windows internet software?

You would do well to run up DOSBox. Better still, the Megabuild version which includes an emulated NE2000 network card.

Then you install DOS and Windows 3.x. Not too difficult if you can find copies of the software.

What next? This is where I wasted a certain amount of time. I found this information:

Run ne2000.com 0x65 3 0x300 and winpkt 0x65 before starting Windows

I found ne2000.com from the above link, but where was winpkt? Eventually I found it in many-other-drivers.zip on crynwr.com.

I still was not up and running. Then it dawned on me that I needed WinPcap on the host PC for the NE2000 emulation to work.

Next, I took a look at the DOSBox configuration file, which for this build is dosbox-SVN_MB6.conf. Nothing will work until you edit this file, since you need to specify which real NIC DOSBox should use. By default it is set to “list”, which means you get a list of candidates when you start up DOSBox.

I use Windows 8 with Hyper-V virtual networking installed, which complicates matters. It was not obvious which NIC to use, since three of mine are distinguished in the list only by GUIDs. I got it right on the second attempt.

Now I was getting somewhere. I had already added the driver initialisation into autoexec.bat. I installed Trumpet winsock which is still for sale though you get 30 days trial.  You just have to configure it. No DHCP but not too difficult:

image

Note that the values here are examples; yours will be different.

IP address: a valid, unused IP address on your internal network

DNS server: the same as used by the host PC

Domain suffix: optional, your internal domain

Vector: this must match the first argument you gave to ne2000.com, without the 0x

Netmask: same as you use on the host PC

Gateway: same as you use on the host PC

The other values I left at the default. Then you can try a ping to check that it works:

image

Happy retro computing!

development, gaming, google, open source, professional, qt, software development

Google Native Client: browser apps unleashed, or misconceived and likely to fail?

6 Comments

Last week Google integrated Native Client into the beta of Chrome 14. Native client lets you compile C/C++ code to run in the browser. It depends on a new plug-in API called Pepper. These are open source projects sponsored by Google and implemented in the Chrome browser, and therefore also likely to turn up in Chrome OS which is an operating system in which all apps run in the browser.

Native Client is cool. For example, NaCLBox lets you run old DOS games in the browser by porting DOSBox to Native Client.

image

Another project is Qt for Google Native Client, a project currently in development. Qt is an excellent and popular GUI and application framework which would speed development of Native Client apps as well as enabling many existing applications to be ported.

It is also worth mentioning that Native Client provides another way to run .NET code in the browser, via Mono with NaCl support.

Why Native Client? Google’s vision, or at least the part of it that focuses on Chrome OS rather than Android, is that everything runs on the Internet and in the browser, making the local operating system unimportant and easily replaced. Native Client removes any performance compromises in managed languages such as JavaScript, ActionScript or Java, as well as easing migration for businesses with existing C/C++ code.

Writing native code for the browser is nothing new. Both Microsoft’s ActiveX and the NPAPI plug-in API used by non-Microsoft browsers let you extend the browser with native code. However Native Client is seamless for the user; you do not have to install any additional plug-in. The main limitation is that Native Client applets do not have access to the local operating system, for security reasons.

It is also worth noting that Native Client apps are not altogether cross-platform. They must be recompiled for different CPU instruction sets, with the current implementation supporting x86 and ARM though you have to compile two binaries. Google says it will support LLVM output to enable cross-platform binaries though this will impact performance.

But is Native Client secure? That is an open question. Google was aware of the security challenge from the beginning of the project. Unlike the plug-in mechanisms which rely mainly on trust in developer competence and signed code to verify the origin of the plug-in or ActiveX control, Native Client inspects the actual code for unsafe instructions before allowing it to run. There is also an “outer sandbox” which intercepts system calls.

However, adding any new way for code to run makes the browser less secure. Google ran a Native Client Security Contest to help identify vulnerabilities, and the contestants did not have any problem finding security flaws. Of course all of these discovered flaws will have been fixed, but there may be others and likely will be.

And is Native Client necessary? The latest JIT-compiled JavaScript engines are fast enough to enable most types of application to run at a satisfactory speed. This is not just about performance though; it is about reusing existing skills, libraries and applications. There is no doubt that Native Client is nice to have; whether its benefits outweigh the risks is harder to judge.

The last question, which may prove the most significant, is political. Google has forged ahead on its own with Native Client, saying as vendors always do that it hopes it will become a web standard. In the early days of the project, it looked like a Native Client plug-in might enable the feature in other browsers, but abandoning NPAPI for Pepper makes this difficult. Will other browser vendors support Native Client?

Here is a comment from Google’s Ian NI-Lewis that I find remarkable:

As you probably know, the rule in Web standards is "implementation wins." So we’re concentrating on getting a good quality implementation out the door. We’re doing that in Chrome. That doesn’t mean that NaCl is intended to be "Chrome only," just that we have to start somewhere.

So Native Client is non-standard, and therefore less interesting than HTML 5 until either Google has a Microsoft-Office-like de facto monopoly of web browsers, or it persuades Mozilla, Microsoft and Apple to support it.

That said, you can think of Chrome as an installable runtime in the same way as the Java Virtual Machine or Adobe Flash, just a potentially more intrusive one. Here is our app, you have to install the free Chrome browser to use it. If this happens to any great extent, I can foresee other browser makers hastening to support it.