Vfat on TurboVision

VFAT to 8.3: The Shortname Rules Behind the Curtain

Tue, 10 Mar 2026 00:00:00 +0000

The second story begins with a floppy label that looked harmless:

RELEASE_NOTES_FINAL_REALLY_FINAL.TXT

By itself, that filename is only mildly annoying. Inside a mixed DOS/Windows pipeline in 1990s tooling, it can become a release blocker.

Our fictional team learned this in one long weekend. The packager ran on a VFAT-capable machine. The installer verifier ran in a strict DOS context. The build ledger expected 8.3 aliases. Nobody had documented the shortname translation rules completely. Everybody thought they “basically knew” them.

“Basically” lasted until the audit script flagged twelve mismatches that were all technically valid and operationally catastrophic.

This article is the deep dive we wish we had then: how long names become 8.3 aliases, how collisions are resolved, and how to build deterministic tooling around those rules.

First principle: translate per path component

The most important rule is easy to miss:

Translation happens per single path component, not on the full path string.

That means each directory name and final file name is handled independently. If you normalize the entire path in one pass, you will eventually generate aliases that cannot exist in real directory contexts.

In practical terms:

C:\SRC\Very Long Directory\My Program Source.pas
is translated component-by-component, each with its own collision scope

That “collision scope” phrase matters. Uniqueness is enforced within a directory, not globally across the volume.

Fast path: already legal 8.3 names stay as-is

If the input is already a legal short name after OEM uppercase normalization, use that 8.3 form directly (uppercase).

This avoids unnecessary alias churn and preserves operator expectations. A file named CONFIG.SYS should not become something novel just because your algorithm always builds FIRST6~1.

Teams that skip this rule create avoidable incompatibilities.

When alias generation is required

If the name is not already legal 8.3, generate alias candidates using strict steps.

The baseline candidate pattern is:

FIRST6~1.EXT

Where:

FIRST6 is normalized/truncated basename prefix
~1 is initial numeric tail
.EXT is extension if one exists, truncated to max 3

No extension? Then no trailing dot/extension segment.

Dot handling is where most bugs hide

Real filenames can contain multiple dots, trailing dots, and decorative punctuation. The rules must be explicit:

skip leading . characters
allow only one basename/extension separator in 8.3
prefer the last dot that has valid non-space characters after it
if name ends with a dot, ignore that trailing dot and use a previous valid dot if present

This is the difference between deterministic behavior and parser folklore.

Example intuition:

report.final.v3.txt -> extension source is last meaningful dot before txt
archive. -> trailing dot is ignored; extension may end up empty

Character legality and normalization

Normalization from the spec includes:

remove spaces and extra dots
uppercase letters using active OEM code page semantics
drop characters that are not representable/legal for short names

Disallowed characters include control chars and:

" * + , / : ; < = > ? [ \ ] |

A critical note from the rules:

Microsoft-documented NT behavior: [ ] + = , : ; are replaced with _ during short-name generation
other illegal/superfluous characters are removed

If your toolchain mixes “replace” and “remove” without policy, you will drift from expected aliases.

Collision handling is an algorithm, not a guess

The collision rule set is precise:

try ~1
if occupied, try ~2, ~3, …
as tail digits grow, shrink basename prefix so total basename+tail stays within 8 chars
continue until unique in the directory

That means ~10 and ~100 are not formatting quirks. They force basename compaction decisions.

A common implementation failure is forgetting to shrink prefix when suffix width grows. The result is invalid aliases or silent truncation.

A deterministic translator skeleton

The following Pascal-style pseudocode keeps policy explicit:

function MakeShortAlias(const LongName: string; const Existing: TStringSet): string;
var
  BaseRaw, ExtRaw, BaseNorm, ExtNorm: string;
  Tail, PrefixLen: Integer;
  Candidate: string;
begin
  SplitUsingDotRules(LongName, BaseRaw, ExtRaw);   { skip leading dots, last valid dot logic }
  BaseNorm := NormalizeBase(BaseRaw);              { remove spaces/extra dots, uppercase, legality policy }
  ExtNorm  := NormalizeExt(ExtRaw);                { uppercase, legality policy, truncate to 3 }

  if IsLegal83(BaseNorm, ExtNorm) and (not Existing.Contains(Compose83(BaseNorm, ExtNorm))) then
  begin
    MakeShortAlias := Compose83(BaseNorm, ExtNorm);
    Exit;
  end;

  Tail := 1;
  repeat
    PrefixLen := 8 - (1 + Length(IntToStr(Tail))); { room for "~" + digits }
    if PrefixLen < 1 then PrefixLen := 1;
    Candidate := Copy(BaseNorm, 1, PrefixLen) + '~' + IntToStr(Tail);
    Candidate := Compose83(Candidate, ExtNorm);
    Inc(Tail);
  until not Existing.Contains(Candidate);

  MakeShortAlias := Candidate;
end;

This intentionally leaves NormalizeBase, NormalizeExt, and SplitUsingDotRules as separate units so policy stays testable.

Table-driven tests beat intuition

Our fictional team fixed its pipeline by building a test corpus, not by debating memory:

Input Component                         Expected Shape
--------------------------------------  ------------------------
README.TXT                              README.TXT
very long filename.txt                  VERYLO~1.TXT
archive.final.build.log                 ARCHIV~1.LOG
...hiddenprofile                        HIDDEN~1
name with spaces.and.dots...cfg         NAMEWI~1.CFG

The exact alias strings can vary with existing collisions and code-page/legality policy details, but the algorithmic behavior should not vary.

Why this matters in operational pipelines

Shortname translation touches many workflows:

installer scripts that reference legacy names
backup/restore verification against manifests
cross-tool compatibility between VFAT-aware and strict 8.3 utilities
reproducible release artifacts

If alias generation is non-deterministic, two developers can build “same version” media with different effective filenames.

That is a release-management nightmare.

The fictional incident response

In our story, the break happened during a Friday packaging run. By Saturday morning, three teams had three conflicting explanations:

“the verifier is wrong”
“Windows generated weird aliases”
“someone copied files manually”

By Saturday afternoon, a tiny deterministic translator plus collision-aware tests cut through all three theories. The verifier was correct, alias generation differed between tools, and manual copies had introduced namespace collisions in one directory.

Nobody needed blame. We needed rules.

Subtle rule: legality depends on OEM code page

One more important caveat from the spec:

Uppercasing and character validity are evaluated in active OEM code page context.

That means “works on my machine” can still fail if code-page assumptions differ. For strict reproducibility, pin the environment and test corpus together.

Practical implementation checklist

For a robust translator:

process one path component at a time
implement legal-8.3 fast path first
codify dot-selection/trailing-dot behavior exactly
separate remove-vs-replace character policy clearly
enforce extension max length 3
implement collision tail growth with dynamic prefix shrink
ship fixture tests with occupied-directory scenarios

That last point is non-negotiable. Most alias bugs only appear under collision pressure.

Closing scene

Our weekend story ends around 01:03 on Sunday. The final verification pass prints green across every directory. The whiteboard still looks chaotic. The room still smells like old plastic and instant coffee. But now the behavior is explainable.

Long names can still be expressive. Short names can still be strict. The bridge between them does not need magic. It needs documented rules and testable translation.

In DOS-era engineering, that is usually the whole game: reduce mystery, increase repeatability, and let simple tools carry serious work.

My First Linux Router: SuSE 5.3, Teles ISDN and the Blinking DSL Modem

Sat, 03 Oct 1998 00:00:00 +0000

I wanted to start with Linux already earlier, but I did not. One reason was VFAT. I had too much DOS and Windows stuff on the disk and I did not want to make a big break just for trying Linux. Now SuSE 5.3 comes with kernel 2.0.35 and VFAT support is there in a way that feels usable for me, so now I finally do it.

Also I have enough curiosity to break my evenings with this, and enough little money to make bad hardware decisions and then keep them running because there is no budget for the nice version.

The machine for the router is a Cyrix Cx133. Not a fancy box. Right now it has 8 MB RAM and a 1.2 GB IDE disk. The case looks like every beige case looks. For a router it is enough. It boots. It stays on. It has one job. If I find cheap RAM later I will put it in, but first I want the basic thing working.

For ISDN I do not buy AVM because I simply cannot. Everybody says AVM is the good stuff and the drivers are nice and all is more easy. Fine. I buy a cheap Teles 16.3 PnP card. It is not the card of dreams, but it is my card and I can pay it. So the project now is not “what is best”, it is “what can be made to work with Teles and a bit stubbornness”.

At the same time there is already the whole T-DSL story from Telekom. This is maybe the funny part: I already subscribe to the DSL package together with T-Online, but the line is not switched yet. They give us the hardware. The DSL modem is there. The splitter is there. Everything is there. I can look at the modem and I can connect it and the LED is blinking and blinking and blinking. But there is no real DSL sync yet. It is like the future is already on the desk, only the exchange in the street does not care.

The good thing in this package is: I can already use ISDN with the same flatrate model through T-Online until DSL is finally active. That changes everything. If I had to pay every minute like in the older ISDN situation, I would maybe not do such experiments so relaxed. But with this package I can prepare the whole router now, use it now, put the DSL hardware already in place, and then just wait until someday the blinking LED becomes stable.

This is maybe a bit absurd, but also very german somehow: contract ready, hardware ready, paperwork ready, technology almost ready, and then the actual line activation takes forever.

Why I want a real router box

I do not want one Windows machine doing the internet and all other machines depending on that. I also do not want manual dial each time. I want a separate machine which is just there and does the gateway work. If it works good, nobody sees it. If it breaks, everybody sees it. This is exactly the kind of thing I like.

Also I want to learn Linux not only as desktop. Desktop is nice, but for me the interesting thing is always when one machine does a service for other machines. Then it gets serious. Then configuration is not decoration anymore.

The first setup is simple:

Cyrix Cx133 as the router
Teles 16.3 for ISDN
one NE2000 compatible network card for local LAN
SuSE 5.3
T-Online account
DSL hardware already connected, but DSL itself still sleeping somewhere in Telekom land

The LAN side is eth0. The ISDN side I will configure through the i4l tools once the login part is really clean.

Installing SuSE 5.3

SuSE installation feels big for a student machine because there are so many packages and YaST wants to help everywhere. But I must say, for this use case it is really practical. I do not want to compile every tiny thing right now. I want the machine up and then I want to start reading config files.

The nice thing is that SuSE 5.3 already has what I need for this direction:

kernel 2.0.35
VFAT support, finally good enough for me to jump in
isdn4linux pieces
YaST for basic setup
normal network tools and PPP stuff

The first days are not so elegant. I reinstall once because I partition stupidly. Then I configure the network wrong and wonder why nothing routes. Then I realize that reading the docs before midnight is much more productive than changing random options after midnight.

Still, the feeling is strong: this is possible. The machine is not powerful. The card is not luxury. But Linux is not laughing about the hardware. It takes the hardware seriously and tries to use it.

The Teles card and the small pain around it

The Teles 16.3 works, but not like a nice toy. It works like something you need to deserve first.

PnP is not really my friend here. Auto-detection is sometimes correct and sometimes not. I get into the usual dance with IRQ and I/O settings, and because the NE2000 clone is also not exactly a model citizen, I must be careful there are no collisions. When it finally stabilizes, I write down the values because I know I will forget them if I do not.

The card sits on S0 bus with a passive NT. That setup is physically very small. Short cable is important. At first I use a longer cable because it is just the cable I have on the desk. Then I get strange effects. D-channel sync comes, then some weird instability. I shorten the cable and suddenly the whole thing becomes much less dramatic. From this I learn again the old rule: with communication stuff, physical layer problems are always more stupid than the software problems.

When the ISDN side starts to work the feeling is really good. No modem noise. No analog nonsense. Digital and clean. I know 64 kbit/s is not much in the abstract, but compared to normal modem life it feels fast enough that one can do real things.

The strange situation with the DSL modem

The modem is already on the desk and it is maybe the best symbol for this whole phase. I already have the new thing. I can touch it. I can cable it. I can power it. But it is not mine yet in the practical sense, because the line in the exchange is not enabled.

So what happens is: I install the splitter, I connect the modem, I look at the LED, and it blinks. Every day it blinks. It is almost funny. It is like the house has a small promise lamp.

Because we already have the package, I can connect with ISDN under the same general tariff model and prepare everything. This is really useful. It means the whole router is not a waiting project. It is a live project from day one. The DSL modem is there as a future device, but the machine is already useful now through ISDN.

This also changes my mood when building it. I am not making a theoretical future router. I am making a real working box. If Telekom ever finishes the outside part, then maybe the uplink can change without rebuilding the whole idea from zero.

What I have running now

At this moment I keep it simple. I am still mostly happy that Linux is on the box and the basic line can come up. The stack is not fancy yet. It is more like this:

SuSE 5.3
isdn4linux
T-Online login
local Ethernet
a lot of notes on paper

I already know I want these things later:

dial on demand
IP masquerading for the LAN
maybe DNS cache
maybe Squid if memory allows it
and if DSL finally comes, then PPPoE and the same box continues

I do not know yet which part will be the most annoying. Right now I guess the Teles card. Maybe later I will say PPP is worse. Maybe both.

For now I am just happy that Linux finally starts for me with a version where VFAT is not a blocker anymore, the cheap ISDN hardware is usable, and the blinking DSL modem already stands on the desk like a small challenge.

Maybe next I write more when the dial-on-demand part is not so ugly anymore.