That's pretty close to GML (precursor to SGML)

    :h1.Chapter 1:  Introduction
    :p.GML supported hierarchical containers, such as
    :ol.
    :li.Ordered lists (like this one),

https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Languag...

>but most of us had no idea how to write a parser, let alone deal with the complexities of HTML and JavaScript.

>a search engine

how did that search engine work?

Pretty much all the apps were written in PHP on shared hosting. Since the system had support for a simple kind of forms (using GET requests), it was possible to accept queries for the various web apps. The search engine crawled the pages that existed looking for links from a few "start" pages, and built a primitive index.

> most of us had no idea how to write a parser, let alone deal with the complexities of HTML and JavaScript.

Nice. But couldn't you just use pure well-formed XHTML and make similarly simple pages? Isn't there an XML library for DOS?

Since none of us knew how to write a parser, dealing with the arbitrarily nested nature of XHTML was pretty intimidating (now that I know how to do it it's not too bad, but in 9th grade I made very little progress). To my knowledge there is no XML parsing library for QBasic; it fell out of favor for "serious work" about 10 years before XML was invented.

How did you do networking from QBasic? (And especially when running under NTVDM?)

Can't speak for the original author but if I had to guess: Files on a world writable shared network volume, as this was a "classic" in school settings ;-)

No matter the decade, allow some pupils a shared network volume somewhere, they'll soon or later write a chat app with whatever programming language they can get their fingers on in that network, at least that was my experience. I did it, heard from other schools were the same happened.

Can confirm that it was still happening as late as 2019.

Wow this got a lot of interest.

For that we cheated - someone wrote a xommand-line Windows program called GetWeb (I think) that took in a URL, fetched it, and wrote the result to a particular filename. I believe most of the clients used that, but some (especially those written in FreeBASIC) may have done their own thing.

This is interesting as an example of something that can be done on NTVDM but generally not other DOS emulation solutions such as DOSBox. A DOS program running in NTVDM can have a Windows console application as a subprocess; other DOS emulation solutions such as DOSBox generally don't support that. So a QBASIC program running under NTVDM can use the SHELL statement to run a Windows console program.

Part of how this works is that NTVDM uses the Windows console to host DOS applications. By contrast, DOSBox shows them in a Windows GUI window, not a console window. In principle, DOSBox could display them in a console window too; that works fine for text mode applications, but it can't support graphics. But, actually, NTVDM can run graphical applications in a Windows console window – how? Well, the legacy Windows console subsystem actually supports two different kinds of console buffers – text and graphics – but only the former is documented. NTVDM creates a graphics buffer for graphical DOS applications using an undocumented CONSOLE_GRAPHICS_BUFFER flag to the CreateConsoleScreenBuffer API – http://blog.airesoft.co.uk/2012/10/things-ms-can-do-that-the... – regrettably, creating a console graphics buffer is broken on 64-bit Windows. Another method that would still work on 64-bit Windows is GetConsoleWindow to get HWND of the console Window and draw on it manually. But Microsoft is discouraging console APIs such as CreateConsoleScreenBuffer and GetConsoleWindow since they don't work with pseudoconsoles (Windows 10 equivalent to Unix ptys) – and it actually looks like in more recent Windows code the CONSOLE_GRAPHICS_BUFFER API flag is gone – see https://github.com/microsoft/terminal/blob/fb597ed304ec6eef2... and https://github.com/microsoft/terminal/issues/246

Using serial or parallel ports, or communicating over modem was done in QBasic. It's possible they did something like that.

NTVDM has an interface called VDD you can use to write virtual device drivers. Basically a Windows DLL loaded into NTVDM.EXE and you can call the DLL from DOS by executing illegal instructions. Often a VDD would have an associated TSR which would provide a more normal interface to DOS programs (based on software interrupts not illegal instructions.)

Microsoft provides some, and third party vendors and open source provides others (the interface is documented in the Windows DDK, or at least it used to be). In particular, Microsoft had one called REDIR which included a bridge between the DOS and Windows NETBIOS APIs. Microsoft used to ship their own Netware client with old versions of Windows and that included another, VWIPXSPX, which similarly bridges the IPX/SPX API from DOS to Windows. Novel’s Netware client for Windows had an equivalent VDD called IPXVDD - https://support.novell.com/techcenter/articles/ana19970501.h...

And see http://netfoss.com/ for a VDD which connects the DOS FOSSIL API (de facto standard for DOS BBS to talk to multiport serial cards) to TCP/IP.

QBASIC doesn’t support any of these APIs, but it can call code written in assembler, and assembler can.

Another option would be to use a virtual serial port driver which makes a TCP/IP port appear as a serial port. QBASIC has built-in support for talking to serial ports. There are a bunch of these, for example https://pcmicro.com/netserial/ or http://com0com.sourceforge.net/ - it can be done either as a Windows kernel driver (so all Windows apps can access it) or as a VDD (only usable by DOS programs running under NTVDM but a pure user mode solution). Actually, if one uses DOSBox instead of NTVDM it has a serial-to-telnet gateway built in.

So there are lots of ways they could have solved it. Still wondering what they actually did.

That would indeed have been pretty cool and I remember reading up on ideas like that. What we actually did (as I mentioned in a recent reply) was use a helper program written by someone who knew a language other than QBasic that fetched files given a URL on the command line. I don't think there was a client that ran in actual DOS.

Please share the code! That project should be in the Internet Archive!

It looks like at least one example page is online: http://brandoncornell.com/index.qml