Wednesday, October 27, 2010

New FreeDOS install program

Years ago, I wrote the first FreeDOS installer. It was a pretty basic installer, not much more than an install script in DOS exe form. It prompted the user in plain text mode, and scrolled from the bottom of the screen. This installer supported the FreeDOS Beta 1 ("Orlando") release, in 1998. So it's pretty old. In later releases of the FreeDOS "Beta" distributions, rather than re-write the installer into something that was easy to use, I bolted on the sketched outlines of a text-mode user interface. It "worked", but I always intended it as a "placeholder", something I'd eventually re-write as we got closer to the "FreeDOS 1.0" release.

However, as things sometimes go, I never really got around to re-writing the installer. Others picked up my work just prior to "FreeDOS 1.0", and added some prettier elements to the text-mode user interface, but it was still the basic installer that was written so long ago.

This has always been something I've wanted to fix, to completely re-write the installer and make it easy to use, make it "sane". I'm finally doing that.

I'll add some code and screenshots to my personal page soon, but I wanted to talk about it here also.

The new installer asks the user only a few questions: do you want to install everything, and do you want to install source code? From there, the installer takes over and does everything for you. After you answer those two questions, you can walk away and let the installer do its thing. A very obvious progress bar will show you how far along you are in the install process.

No, the installer doesn't even ask you where you are installing from (the "source") or where you are installing to (the "destination".) The install process should hard-code that, since the install CD is the obvious "source", and we can assume a standard default C:\FDOS "destination" now.

My hope is that the new installer will be a step towards a simplified FreeDOS install process. I'm writing the installer, but am looking for someone else to finish the install CDROM. Ideally, a streamlined install process would do the following:

  1. Select language
  2. Check if your hard drive is already partitioned and formatted with a DOS filesystem for C: (and if not, run FDISK and FORMAT for you)
  3. Run the new installer
  4. Execute any post-install setup BAT files
  5. Done!

The whole process, start to finish, should involve a minimum of prompts and menus. We have a lot of menus and options right now. For example, does the CDROM menu really need to have 4 boot options? It should be:

  • Install FreeDOS
  • Exit

And "Exit" should be the same as skipping the CDROM boot, to try the next bootable device - which we already do in "FreeDOS 1.". This is really useful, for example, when the user forgets the CDROM in the tray after installing FreeDOS.

DOS should be simple. Whatever we can do to simplify and streamline the FreeDOS installation process, we should do that.

Monday, October 11, 2010

Women in Open Source

The SD Times ran an article back in August, "Breaking down barriers for women in open source," by David Worthington. It's an interesting read, and you should check it out.

Free and Open Source Software ("FOSS") is built upon a community of users and developers. That community thrives when everyone is able to contribute, each according to his or her ability and interest. But that community will falter if it cannot achieve a "critical mass" of contributors. It is critical, therefore, for a FOSS project to include everyone in its community. That should be by default, but perhaps should also be by design.

From the article: "Barriers include the perception that the FOSS movement is a "boys' club," a shortage of female role models in the community, the feeling that women are being judged at a higher standard than men, feelings of isolation, sexist behavior, and non-coding roles that are often occupied by women being undervalued." These are serious issues that directly affect FOSS development everywhere.

After you read the article, I encourage you to think about the FOSS projects that you contribute to. Consider if the "culture" of the project community is welcoming of new members, especially women. Is your project a "boys' club" too? Remember, if a project is not open to everyone, it's not really "open", is it?

Monday, June 28, 2010

FreeDOS turns 16

The FreeDOS Project turns 16 years old today. Happy birthday!

You probably know the story already: in the 1980s and early 1990s, many people used DOS. I used DOS all the time - especially at university, mostly to write small programs to help me with my physics data analysis. MS-DOS was the operating system of the day, and I was a huge fan. Sure, Microsoft had already tried to introduce (with limited success) the new "Windows" operating system, but this was really just a shell that ran on top of MS-DOS. And Windows wasn't pretty; everything seemed more difficult under Windows.

So you can guess the reaction when Microsoft announced sometime in early 1994 (through tech magazine interviews) that DOS would soon go away, replaced entirely with a new version of Windows.

I'd also installed Linux by this time, and realized that if a small group of developers could replicate something as complicated as a Unix system, certainly we should be able to do the same with DOS? So I decided to create my own version of DOS, which I would make available to the public for free. We called it "PD-DOS" because much of our early work was released in the public domain.

PD-DOS was announced to the world on June 28, 1994. To cement my ideas, I created a PD-DOS Manifesto. By July 24, 1994, the name of the project had officially changed to "Free-DOS", though the name actually switched around July 16, 1994 (the revision date on the manifesto).

FreeDOS has accomplished a lot since then. We've had many releases of our official distribution, including "1.0" a few years ago, and others have made their own versions of DOS based on the FreeDOS kernel. PC manufacturers now include FreeDOS as an option on some of the systems they sell - including such big names as HP and Dell.

Here's looking to another year of FreeDOS!

Friday, June 11, 2010

I'm moving soon

I thought you'd be interested to know: I've accepted a new position at work. I am the new Director of Information Technology/CIO for the University of Minnesota, Morris. I start in mid-July.

Morris is about 3 hours away, so my wife and I are moving to a new home. Expect that I'll be out of communication starting around June 12 until about July 18.

Saturday, May 29, 2010

Developing the web site

When considering how to develop the web site, I have two questions:

  1. What do people look for when they visit the FreeDOS web site?
  2. What do we want the FreeDOS web site to be?

Note that these questions are not necessarily tied.

We don't have tracking tools to know what searches people are using on Google, Bing, etc to find information on our website. But even without data, the first question is probably straightforward: people are looking for information about FreeDOS.

  • For the new user: what is this "FreeDOS" thing, what does it do / can I run Windows programs with FreeDOS, can I install FreeDOS on my computer, how can I install FreeDOS on my computer, ... how do I fix this problem I found after installing FreeDOS, etc.
  • For the experienced user: when is the next distro coming out, what updates have happened since I last looked, etc.
  • For the interested developer: how can I contribute to the next version of FreeDOS, what else can I do, etc.

The second question is much harder to answer, and really gets at the heart of a web "strategy" for FreeDOS. Our current web site has a lot of varied content on it. There's no single vision behind it.

I believe we need to focus the web site to be a kind of "one stop" site for everyone interested in FreeDOS. Extraneous content should be archived, important content should be highlighted. That will mean some serious pruning.

At my work (University of Minnesota) we have a "OneStop" web site that all students use as a "front door" to check email, register for classes, plan their degree program, etc. The web site is (when you get down to it) just a portal to other web applications at the U of M, even those not hosted at the "OneStop" site. Even though students can easily bookmark the places they need to go (and many do) I hear from students that it's often easier just to bookmark the "OneStop" web site, and get to where you're going from there.

There are also content areas for staff and faculty. Often, links are replicated in each focus area.

That could apply to the FreeDOS web site, if that's where we wanted to take the web site. We already have a "New Users" and "Developers" list of links down the left-hand side of the front page. But to turn the FreeDOS web site into a "one stop" site we could change our tabs at the top of the page to "new users", "experienced users", and "developers" - or whatever labels work best. Those tab links would point you to different "focus" areas on the web site. Maybe the front page is for "new users", and we have tab links for "experienced users" and "developers".

The focus areas would have links to download the latest release, to our Wiki at SF, our source code at SF, stuff at CafePress, our bug tracker at SF, our mailing lists, chat sites, SF project info, RSS feed, Facebook, Twitter, etc. Note that things may point off the site, which is okay. Some links might be replicated in the different focus areas, but that would help users from having to dig around the web site to find whatever they are looking for. Each page should still have a "Search" box on it.

We'd still keep some pages as-is on the site, like the software list, web images, etc. And we'd link to these from each of the focus areas. The locations (for some) might need to change so everything makes sense and is easily locatable.

For example, we use "/freedos" as the prefix for most pages only because we used to have a "web site mirror" affiliate program, to distribute the load when FreeDOS was very popular. Mirror sites has their own copy of "/freedos". But we don't support web mirrors anymore, so "/freedos" no longer makes sense. That's why the software list moved from "/freedos/software" to "/software".

I'm not suggesting changing the web design again - just re-arranging the content so things are easier to find, using the current web design.

What are your thoughts?

Sunday, May 9, 2010

Web images cleanup

Yesterday, I started to do some cleanup work in the FreeDOS images space. So far, I've updated the presentation so the page looks better, and separated the "official" logos from the "unofficial" logos.

Next, I plan to rename the official "FreeDOS fish" logos so they are named in a consistent way. Probably something like "fdfish_color_text.*" and "fdfish_bw_url.*", etc. That way, it's easy to pick out an official FreeDOS logo asset via its filename, and know what's inside it.

Looks like we don't have any pages on the site that refer to these files directly (we use copies of the assets for the stylesheets.) But I'm mentioning it in case someone out there notices the change. I don't know if anyone out there is referencing a logo directly from the FreeDOS web site, and obviously those references will break when I am done.
Update: The cleanup is done. If you need to know how the official logos were renamed, I've created a list for you at renamed.txt.

Tuesday, April 20, 2010

10 years since Phil Katz

Did you know that last week was the 10th anniversary of the death of Phil Katz? For those who don't know, Phil invented the ZIP file format, including the popular PKZIP and PKUNZIP toolset. Perhaps his greatest contribution is that Phil released the ZIP file format as an open standard, which meant anyone could write their own tools to put data in ZIP files. FreeDOS uses InfoZip to manage ZIP files, for example.

Phil battled alcoholism for much of his life, and on April 14 2000, Phil was found dead in his hotel room due to complications related to alcoholism. A pity it all turned out badly for Phil. We'll miss him.

La Stampa posted an article (in Italian, see Google's translation) describing a bit of Phil's life. You can also read more at Wikipedia.

Friday, April 2, 2010

Where FreeDOS came from

FreeDOS was previously known as "Free-DOS" and originally as "PD-DOS." For a little trip down memory lane: In 1994, I was a physics student at the University of Wisconsin-River Falls. Most of my work for school had been done using DOS - writing programs, dialing up to the university computer, network, analysing lab data, etc. I really loved DOS; I did everything with it. I had a '386 desktop system in my dorm room and an XT laptop that I would carry around with me to do work "on the go".

I liked the simplicity that DOS offered. As a DOS user, you have the equivalent of 'root' access on your computer. Anything that you want to do on the PC is possible. Nothing is really stopping you, other than hardware limitations. I found that this additional degree of freedom was nice to have, although since I worked in both environments (UNIX and DOS) I tended to write programs that stuck to "safe areas" that worked on both platforms. DOS was great.

But that year, there was an announcement that Microsoft would stop support for DOS, that a new version of Windows was going to be released that completely removed DOS from the picture. Of course, this was Windows 95, and it still did have DOS, but at that time we all had the vision that Microsoft was trying to kill our favorite operating system. Everyone was pretty shocked. We didn't want to be forced to use Windows, which completely removes the command line. In DOS, everything is done on the command line, and a true command line "guru" can do amazing things there. In Windows, you are stuck with the mouse, and if the menus don't let you do something, it pretty much can't be done. So things were looking pretty bleak. We were all very upset about Microsoft's decision to ditch the DOS platform.

Then, I saw a discussion thread on the DOS groups asking "hey, why doesn't someone write their own free version of DOS?" Remember, this was about three years after Linus Torvalds announced his work on the Linux kernel, and by 1993 Linux had shown that free software can achieve incredible results. So in 1994, the suggestion that we could write our own free version of DOS, and give it away with the source code so others could work with it and improve it, really didn't sound all that far-fetched.

Unfortunately, no one seemed to pick up the ball. The idea sort of sat there, waiting. So I sat down one weekend and hacked out code for a bunch of DOS file utilities. I posted what I had done to the DOS newsgroups, and announced that I intended to form a group on the Internet to write our own free version of DOS.

I took the opportunity to fix some things. There are some things about what Microsoft did with DOS that do irk me. The biggest is that MS-DOS commands lack options, not that there are lots of MS-DOS commands anyway. I wanted to have more powerful tools than what MS-DOS provided me with. So I hacked some of my own. (I wasn't a strong C programmer at the time, so this wasn't very beautiful code.) There were several "beta" pre-release packages of my stuff:
contained a few basic utilities, just to get the easy ones out of the way: clear (like Cls), echo, more, rem, type, ver, wait (like Pause)

added date, test (some do-nothing test program), time

added choose

fixes and some cleanup

added tee (like UNIX 'tee(1)')

added bgc (sets background color), fgc (sets foreground color), man (like UNIX 'man(1)') …

clear replaced by cls, man replaced by help, wait replaced by pause, bgc and fgc moved into cls. Added del, find, reboot, unix2dos.
After I'd written over a dozen utilities that replaced MS-DOS commands, and found some public domain source that implemented other functionality, I realized that you could reproduce what MS-DOS does and make it a free software project. So I decided to go for it.

PD-DOS was announced to the world on June 28, 1994. To cement my ideas, I created a PD-DOS Manifesto. By July 24, 1994, the name of the project had officially changed to "Free-DOS", though the name actually switched around July 16, 1994 (the revision date on the manifesto).

It immediately became a popular idea. Within a few weeks, I had several coders from various parts who contacted me, wanted to take on this or that part of the new Free-DOS. Weeks after that, the number had doubled. Within months, I was contacted by Pat Villani, who had already written a functional DOS kernel called DOS/NT, and who was willing to release it under the GNU GPL for us to use! Tim Norman also started work on his version of the Free-DOS, which is the heart of the DOS command line interface. I think the fact that, early on, we had access to a working DOS kernel and really helped get the Free-DOS project in motion.

I can't pinpoint exactly when "Free-DOS" became "FreeDOS," but we have called ourselves "FreeDOS" (without the dash) since sometime in early 1996. The name change has become a bit of a FreeDOS myth: Free-DOS had become so popular, that R+D Books agreed to publish a book about Pat Villani's DOS kernel, entitled The FreeDOS Kernel. Popular belief is that Pat's editor thought the dash wouldn't look right on a book cover, so he dropped it! I stopped using the dash between January 31, 1998 and February 15, 1998.

On September 3, 2006, FreeDOS reached the "1.0" milestone.

DOS will be around for quite some time yet. DOS remains a great environment to work in if you are building an embedded system, for example. The operating system is light, so it will run well in a device that doesn't have a lot of memory. You can burn it into ROM, boot from a floppy, or a small micro-drive. There aren't many operating systems that you can find these days that will boot from a floppy, yet still leave you enough room on the disk for your embedded program and maybe some room for data files.

Saturday, March 6, 2010

Old software list

As promised, it's been a week, so I have replaced the old software list with a friendly message that redirects you to the new software list. Now, if you try to visit the old (lsm.cgi) software list, you'll just get a message that the software list has moved, and a URL to the new page you were looking for.

For the last week, the old software list has worked, but had a note added to it, letting you know that it was the old version. This was so program maintainers could compare the new software list with the old software list, and verify for themselves that all the data was correctly imported.

If you still want to validate the data in the new software list against the old data, you will need to use the old LSM files directly. The old LSM files are still there, but I haven't linked to them so web search engines can't find them (these files were never meant to be indexed or views directly, but rather through the software list web interface.) But you can still get there if you know where to look.

Let's say you want to compare entries in the "Base" disk set. The LSM files from the old software list are still on the web server. Go to and you'll see a list of files ending with ".lsm". Those are the original LSM files. Just put that at the end of the "" URL.

Monday, March 1, 2010

The Software List as XML

When I wrote the new FreeDOS software list, one of the "targets" was to provide a method for the FDUPDATE program to get a list of packages that it needed to update. An easy way to do this is to query the database, and format the output in an XML file that the FDUPDATE program can read.

I've already shared this with Mateusz, but in case anyone else wants to write their own program to check FreeDOS program information via an XML file, here's how to export the software list as XML.

You start here:

Without any parameters, the fdupdate.cgi program returns an unformatted list of "categories" (also called "disk sets") in the software list. When you installed your distribution of FreeDOS, you may only have installed the "Base" disk set. But others may have installed the "Full" distribution, and might have chosen to include things like "Devel" and "Edit". The FDUPDATE program knows what disk sets you installed, so it also knows what disk sets it needs to update. It does the right magic in the background to fetch the right category lists.

Let's say you wanted to get the data for just the "Base" category. You just give fdupdate.cgi the "cat=" parameter:

That will give you an XML list of all the packages (and their version numbers) in the "Base" category. The FDUPDATE program can easily parse this to figure out which programs need updating.

Since the software list was only recently converted to a database, obviously the FDUPDATE program doesn't support the new fdupdate.cgi method yet. That's probably a good thing for right now, since the database doesn't contain any information (yet) about the specific package zip file names. We haven't entered that into the database yet, but we will.

So this is sort of a "coming soon" feature of the software list. But I wanted to share this with you now, so you can see the flexibility that a database back-end gives us.

Sunday, February 28, 2010

Exporting an LSM

I recently posted about the new software list, how it uses a database back-end to store the data. An important thing to remember is that maintainers will still use LSM files to provide information (author, maintainer, URL, etc) about your program. The new software list just makes it easier for us to keep the information organized.

But you may ask, "if the database is tracking all the information, how do I edit an LSM file?" Maintainers have two options: You can still edit the LSM file that you already have. Or, you can export your program's information from the database as an LSM file, and work from that. Let me walk you through the process.

To export an LSM file from the database, use this CGI:

Without any parameters, this CGI will simply list all the program "categories" that are available. Categories are what later become "disk sets" in the full distribution. To see the programs listed for a particular category, use the "cat=" parameter. For example, for the "Base" disk set:

This lists all the programs that are part of that category. To view the LSM file for a specific program, give the "prog=" parameter. For example, for the FreeDOS Kernel:

And that's it. Easy!

Note that when you have a new LSM file (for example, when you make a new release of your program, or if you need to update the URL, etc) you still need to email that file to one of the FreeDOS admins. There's an LSM "import" process that the admins can use to put your LSM file into the database.

Saturday, February 27, 2010

I know about the broken forum link

In case you are wondering: yes, I know that the link to the forums (from the news items) is broken. That seems to be something that SourceForge did. I can't fix it for them, but I can at least modify the links to point to the news archive at SF. I'll fix this soon.
Update: It's fixed. Thanks.

New FreeDOS Software List

For years, we have used "LSM" (or, Linux Software Map) data files to describe the packages contained in FreeDOS. We still do, and we will continue to use them.

To make it easy for people to see what packages we included in FreeDOS, I wrote (long ago) a simple perl CGI that parsed the LSM files and displayed them as part of a web page. That worked well, for what it did. But it wasn't very flexible. Also, there was no way to ensure that the LSM files were filled in correctly. This only made things worse for the CGI.

For a while now, I've wanted to re-write the software list to use a database back-end. I have finally done this, and the new list is now available at:

Having the program information contained in a database allows us to do several things. We can still display the software list as a set of web pages. But we can now export that data as (correctly formatted) LSM files. Or as an XML file that the FDUPDATE program can use. I'll post something in a few days about how to get data out of the system.

A database also makes it easier for us to keep the software list up to date. In the old method, a webmaster had to upload an updated LSM file to a specific directory, using a particular name. With a database back-end, we can assign a few people to be "software list administrators" (for lack of a better term) that can import LSM files into the database, or edit fields directly.

I hope the new software list makes it easier for the FreeDOS Project to keep our program information updated. That will, in turn, make it easier for users to find our stuff.
Update: I forgot to mention that yes, I will update the old software list (lsm.cgi) to redirect users to the new software list. My intention was to leave the old pages as-is for about a week, so program maintainers could validate the data in the new list against the old list.

This weekend (3/6?) I'll edit the old lsm.cgi to redirect users to the corresponding page in the new software list. It probably will not be a "silent" redirection - I'll print a message so that users know to update their bookmarks, etc.

However, I'll leave the old LSM files in place (in /freedos/software) for a while, so maintainers can still compare against the old data if they like.

Thursday, February 25, 2010

What motivates F/OSS?

The Harvard Business Review's IdeaCast recently interviewed Dan Pink about his book, Drive, The Surprising Truth About What Motivates Us. (Amazon)

In the interview, Dan gave Free/Open Source Software as an example of motivation. What motivates F/OSS developers? Largely, it isn't about the money. According to Dan, we're driven primarily by the creative need, the urge to create something that's immediately useful.

I think Dan hit the nail on the head, there. I've worked with a lot of F/OSS developers, spoken about F/OSS at a lot of conferences, and what we all seem to share is a drive to create new things. At first, Free / Open Source Software tends to "scratch our own itch" by solving a problem for ourselves, but often this grows to support others. When I wrote the first FreeDOS utilities in 1993, it was to create DOS tools that functioned better than MS-DOS. It wasn't until 1994 that I made these tools available to a wider audience in the form of FreeDOS.

Dan also commented that, contrary to conventional wisdom in business, paying a F/OSS developer doesn't actually provide additional motivation. Sure, we appreciate that we're being paid to write Free . Open Source software, but in the end that doesn't motivate us to create more software, or bigger software, or software in support of a particular thing. F/OSS developers work on things that are interesting to them, not to a corporate entity.

Paying a F/OSS developer to work on a project may actually de-motivate the developer, rather than actually motivate them. Instead, if a corporation wants to fund F/OSS development for something, you have to find other ways to motivate your developers. Dan talked about building community. And I've often discussed that building a healthy community is key for any F/OSS project. I thought this was very insightful.

Monday, February 15, 2010

New software list coming soon

Just a quick note that I've finished coding the new software list. All that's left now is importing the current LSMs into the database, and that's going to be a very manual process. I've imported all of the "Base" programs into the new software list. That means I'm about 40% complete (62 in base, 143 remaining.) I expect to finish them this week, so look for an announcement on the main page soon!

Sunday, January 31, 2010

Update on new Software List

Well, I now have the "import" working on the new Software List, and I've cleaned up the code and moved common functions to a separate file. I'll leave any further changes until next weekend, but in the meantime I've released this to a few folks for testing. We're finally getting there!

Later, I'm going to add some fields to the database, to keep the name of the binary package (on ibiblio) and the corresponding source package. This won't show up in the Software List, and it will be optional to add them, but (if present) they'll get sent to FDUPDATE automagically.

Also later, I'll add some fields for the URL (on for the license, and an indicator for whether or not the FSF considers this a "Free" license. These won't be used by the Software List, so they won't normally be visible, but whoever puts together the next FreeDOS distribution can use these for reporting.

As part of the above, I intend to write a report utility to check for errors in the data, and otherwise show some useful statistics.

Some answers to questions you may already have:

Q: Why make the Software List into a database?

A: Using a database (with a web front end) means we can automatically make sure things get entered in a consistent way. This will make the Software List better for everyone. This also means we can export the data in any number of ways. For example, FDUPDATE can get a list of all programs in XML format. End users see the normal html version of the Software List. Developers can export an LSM version of program information.

Q: Who updates the data?

A: We can set up "Software List administrators" (for lack of a better term) who can import and edit data. These people do not (necessarily) need to be web site admins, or news admins. It's a different role.

Q: How will it get backed up?

A: I plan to create an automated job that will export all the data (probably weekly) into LSM format, and keep that copy on ibiblio as a backup of the data. If the worst happens, at least we'll still have the program data.

Q: What happens if we lose the data in the database?

A: If the database just gets deleted (or corrupted) then a "Software List admin" can import all the LSM files from ibiblio. It's a slow way to do it, but it works for disaster recovery. We can also make some sort of remote backup using mysqldump, so you can just re-import that file.

Monday, January 18, 2010

What I'm working on now

Back in February 2009, I had announced that I was taking an absence from the FreeDOS Project to focus on a Masters program in Management of Technology (MOT). Over the next few months, I transferred my roles in FreeDOS (webmaster, SourceForge admin, ibiblio admin, etc) and finally stepped aside in May 2009, with Pat Villani now acting as the new FreeDOS Project Coordinator.

Since then, some very positive opportunities have come my way, and I have decided to defer entering the MOT program—at least for now.

So what have I been doing, if I haven't been busy in MOT?

You've probably noticed that I've been making updates to the FreeDOS web site. Some changes are very visible (the web site redesign, for example) and others not so visible. One of those "behind the scenes" projects that I'm working on at the moment is building a new version of the FreeDOS Software List.

The current Software List is a set of simple perl CGIs that act on a set of regular LSM files, displaying them in various tables. It was an easy solution for how to quickly and easily display details about the programs we include in the FreeDOS distributions. To manage the Software List, a webmaster just uploads an LSM into a particular directory, and the CGIs do the rest.

I once wanted to write a set of CGIs that would allow "Software List administrators" (for lack of a better term) to update software list info via a web form, and keep all the data in a database, so not have to upload files anymore. The idea was that an "admin" should be able to edit fields directly, or upload an LSM and let the system parse the LSM appropriately before importing fields into the database. And be able to display the data via web pages (like we do now), or as XML (useful for FDUPDATE), or as a correctly-formatted LSM file (for the FreeDOS Install program.)

That's what I'm working on now. The "Software List" part is working great, and looks very nice. (Sorry, I don't plan to share the URL until this is closer to "live", so no one gets confused when they look at "test" data.) The "Editor" function seems to be solid. Right now, I'm trying to finish up the "Import" process.

Once that's done, I plan to do some code optimization, identify duplicate code and move those into functions, that sort of thing. Later, I'll write a "Report" function that generates a status of the Software List, useful in finding/fixing missing or bad data.