DOS ain't dead

> I think Int21.71A0 should work well. Do "stc" before the "int" opcode,
> because DOSes without any Int21.71 functions will leave CF unchanged and
> set al to 0. If the flags are NC, test the returned bx's bit 14 (4000h).
> If it's 1, LFNs should be supported.

I found this code from the Free Pascal RTL (system.pp). And I think, it's buggy, because it assumes, that LFNs on other drives are available too, if drive C: already supports these?!

function CheckLFN:boolean;
var
  regs     : TRealRegs;
  RootName : pchar;
begin
{ Check LFN API on drive c:\ }
  RootName:='C:\';
  syscopytodos(longint(RootName),strlen(RootName)+1);
{ Call 'Get Volume Information' ($71A0) }
  regs.realeax:=$71a0;
  regs.reales:=tb_segment;
  regs.realedi:=tb_offset;
  regs.realecx:=32;
  regs.realds:=tb_segment;
  regs.realedx:=tb_offset;
  regs.realflags:=carryflag;
  sysrealintr($21,regs);
{ If carryflag=0 and LFN API bit in ebx is set then use Long file names }
  CheckLFN:=(regs.realflags and carryflag=0) and (regs.realebx and $4000=$4000);
end;

---
Forum admin

> > Yes, and I'm already doing this for some parts of the source code.
> > What's a safe way to detect, if LFNs are available?
>
> FPC's way (system unit)

[snip]

see my previous message

---
Forum admin

> Yes, but at least two DOSes (RxDOS, ROM DOS) support LFNs natively, right?

You're better saying "at least one DOS". RxDOS's current LFN code doesn't really work and supports only some of the Int21.71 functions (and some of these supported functions are not very well written). And that just besides all the other RxDOS bugs. Don't consider using it for anything serious right now.

> Even DR-DOS (at one time) had a beta FAT32 LFN driver of some sort
> (probably recalled due to patent worries, bah).

I think there was one DRFAT32 driver and another DRLFN driver. (All versions I know are betas.) They however had a special interface so if used together, DRLFN provided LFNs on DRFAT32 partitions as well.

> > But I don't want to work around your buggy Linux. Why not use DOS?
>
> That's not a bug.

Probably the bug isn't in that Linux driver, but rather in the other NTFS driver. It should translate LFNs without SFNs "on the fly", that is, if anyone requests SFNs (applications inside NTVDM or whatever), create them "virtually".

---
l

> > > planning on migrating URLs anytime soon? Didn't think so.
> >
> > Sorry, I don't understand.
>
> Is your site changing addresses anytime soon? I hope not!

No.

> > UPXINFO was made for DOS, where SFNs always exist.
>
> Yes, but at least two DOSes (RxDOS, ROM DOS) support LFNs natively, right?

Yes, but there still is a SFN for every LFN.

> > > a file to NTFS from some Linux distro recently, and while most modern
> > > distros support NTFS r/w fine, this one didn't create a SFN alias, so
> I
> > > had to ZIP/UNZIP it just to create one). And yes, I'm aware that TP55
> >
> > But I don't want to work around your buggy Linux. Why not use DOS?
>
> That's not a bug.

Depends on your point of view.

> As mentioned, I think DJGPP's libs use int 21h,71A0h in various places. So
> I'd assume that's a good way. Take a look at
> IO95
> (written for C) if you want a second opinion.

Thanks for the URL! It's a pitty Steffen left FreeDOS.

---
Forum admin

> > > I already knew that unit and I don't like it very much.
> >
> > Why not? If it works, it works.
>
> It doesn't work (always).

Does Win2k have LFN bugs in that regard? I've heard something like that. Maybe NTLFN helps?? (Dunno.) Anyways, it's not THAT important.

> Or will I convert UPXINFO to NASM completely? I don't know...

Does TP have a way to output .ASM or do you have to manually disassemble it? I was actually (half-jokingly) going to suggest to make it portable to be able to be compiled in the new FreePascal, which supports LFN natively (as all DJGPP-ish programs do). And that can output .ASM, albeit 386+, which may or may not be what you want. Granted, it won't be a 4 kb .EXE anymore, but you could (drum roll please) ... UPX it!!

DOSferatu wrote:

(nothing yet)

Rugxulo wrote:

> Some people violate the UPX license by making the resulting .EXE
> not unpackable. DOS386 apparently wants you to be able to
> heuristically find such .EXEs and make 'em unpackable again.

Incredible: someone did understand my post

> Irony: it's basically an article against the need for UPX re: FreePascal,
> but your tool is written in FreePascal to identify UPX'd binaries.

To identify the evil

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***