[Pascal] Lange bestandsnamen uitlezen onder DOS *

[Verwijderd]

Ik ben een programmaatje aan het schrijven in Turbo Pascal 5.5 (maar het geldt voor elke DOS-taal) dat onder andere dirlists moet maken... Natuurlijk kan ik wel de 8.3 namen krijgen, maar ik wil van al deze bestanden de lange (Windows-)bestandsnaam te weten komen. Iemand enig idee hoe ik dit doe?

[Microkid]

Lastig. Ten tijde van TP5.5 waren er nog geen lange bestandsnamen. Wellicht is er een unit plugin die het ondersteund.

[Verwijderd]

Hier heb je vast wel wat aan:


Voor een "Quick-and-Dirty" oplossing:
http://www.odi.ch/prog/lfn/index.php

Eigen implementatie schrijven:
http://www.cybertrails.com/~fys/longfile.htm

[Verwijderd]

Verwijderd schreef op 13 maart 2004 @ 22:39:
Hier heb je vast wel wat aan:


Voor een "Quick-and-Dirty" oplossing:
http://www.odi.ch/prog/lfn/index.php

Eigen implementatie schrijven:
http://www.cybertrails.com/~fys/longfile.htm

Hmm... ik denk er inderdaad wel wat aan te hebben, alleen werkt de ASM implementatie in TP 5.5 nogal beroerd... d.w.z. ik kan geen ASM toevoegen, alleen de CPU-codes (en het is mogelijk een of twee bytes te vervangen door de naam van een variabele, dat maakt ie ook nog goed )

*gaat ermee prutsen* Iig bedankt

/edit: maar gelukkig kan ik zo te zien overal de MsDos functie voor gebruiken, dat scheelt me weer een middag werk

[ Voor 10% gewijzigd door Verwijderd op 13-03-2004 23:09 ]

[LordLarry]

Waarom stap je niet over naar een andere pascal compiler die wel voor deze tijd geschikt is. FreePascal bijvoorbeeld.

[Verwijderd]

LordLarry schreef op 14 maart 2004 @ 18:35:
Waarom stap je niet over naar een andere pascal compiler die wel voor deze tijd geschikt is. FreePascal bijvoorbeeld.

Is die compatibel met oudere DOS versies?

[LordLarry]

Volgens de website wel.

[BoomSmurf]

Ik meende hier ooit iets voor gemaakt te hebben en jawel, na mn backup disk erin geduwd te hebben heb ik het volgende gevonden: Win95U.PAS . Ik weet niet of het gaat werken, de executable gaf bij mij een error onder XP en ik had weinig zin om BP te gaan zoeken om het te testen, maar misschien heb je er wat aan.

[Verwijderd]

BoomSmurf schreef op 15 maart 2004 @ 00:52:
Ik meende hier ooit iets voor gemaakt te hebben en jawel, na mn backup disk erin geduwd te hebben heb ik het volgende gevonden: Win95U.PAS . Ik weet niet of het gaat werken, de executable gaf bij mij een error onder XP en ik had weinig zin om BP te gaan zoeken om het te testen, maar misschien heb je er wat aan.

Dit is niet in TP 5.5 geschreven zo te zien? een unit Strings kent ie niet, en type PChar ook niet (en ik weet niet wat dat zijn, dus ik kan ze moeilijk zelf gaan schrijven...)

Ik heb de code even bekenen, en op zich lijkt ie wel handig (ik zal proberen iets te vinden voor die unit en dat type ) maar wat moet ik als argument geven, alleen de bestandsnaam of mag ik het hele pad er ook voor plakken? Dan is 127 bytes wel erg weinig, want de rest van mn progsel houdt rekening met 32 dirs diep, met een naam van elk 127 tekens max En geeft ie het hele pad terug of alleen de naam?

/edit: Ik heb hem even herschreven en hem getest met het volledige pad, dat doetie (alleen vervangt ie de driveletter door een vaag tekentje ) (ah, en ik krijg dus het volledige pad terug, maar wat als die langer is dan 254 tekens?)
/edit: dat vage tekentje was mijn fout

[ Voor 17% gewijzigd door Verwijderd op 17-03-2004 18:31 ]

[BoomSmurf]

Verwijderd schreef op 17 maart 2004 @ 17:08:

Dit is niet in TP 5.5 geschreven zo te zien? een unit Strings kent ie niet, en type PChar ook niet (en ik weet niet wat dat zijn, dus ik kan ze moeilijk zelf gaan schrijven...)

Is idd niet TP 5.5 maar BP 7.0 (ofwel TP 7.0 met Protected Mode ondersteuning). De Strings unit bevat conversie en cut/cat procedures voor Strings en PChars als ik het me goed herinner.

Een PChar is een soort pointer naar een string. Op de locatie waar de pointer naar wijst staan gewoon een hoop karakters achter elkaar in het geheugen, eindigend met #0 (zo weet je waar de string ophoudt zeg maar)

Met een beetje pointer en array geklungel vallen die functies uit de strings unit zo te herschrijven. Een makkelijk manier als je de maximale lengte weet:

code:

type
    TMyPChar: Array[0..MaxLen] of Char;
    PMyPChar: ^TMyPChar;

procedure InitMyPChar(PC: TMyPChar);
var i: Integer;
begin
    for i := 0 to MaxLen do PC[i] := #0;
end;

Je zou ook FillChar kunnen gebruiken maar ik weet niet of die in TP 5.5 al beschikbaar is. Misschien dat een array van char's en een string al compatible zijn in TP 5.5 je moet alleen oppassen voor die #0 daar worden strings af en toe niet helemaal vrolijk van

Ik heb de code even bekenen, en op zich lijkt ie wel handig (ik zal proberen iets te vinden voor die unit en dat type ) maar wat moet ik als argument geven, alleen de bestandsnaam of mag ik het hele pad er ook voor plakken? Dan is 127 bytes wel erg weinig, want de rest van mn progsel houdt rekening met 32 dirs diep, met een naam van elk 127 tekens max En geeft ie het hele pad terug of alleen de naam?

32 dirs met een naam van elk 127 tekens, lol! Zelfs Windows XP understeund nog maar max 1024 tekens in het totaal

Een bestand zelf mag max 127 tekens zijn, dus zo naar de unit kijken zal ie niet het volledige pad nodig hebben. 'T is allemaal jaren geleden dat ik het ooit geschreven heb dus ik weet het niet meer zo precies Je zult het gewoon effe uit moeten proberen heh.

/edit: Ik heb hem even herschreven en hem getest met het volledige pad, dat doetie (alleen vervangt ie de driveletter door een vaag tekentje ) (ah, en ik krijg dus het volledige pad terug, maar wat als die langer is dan 254 tekens?)

Dan heb je een probleem, want strings mogen maar 255 bytes lang zijn. Ik weet ook niet of de interrupts die aangeroepen worden wel meer dan dat teruggeven. Allicht dat als je zo'n soort 'nep' PChar constructie gebruikt zoals ik een stuk terug aangaf dat je langere namen kan gebruiken, maar is niet echt handig

[Verwijderd]

BoomSmurf schreef op 17 maart 2004 @ 18:34:
[...]


Is idd niet TP 5.5 maar BP 7.0 (ofwel TP 7.0 met Protected Mode ondersteuning). De Strings unit bevat conversie en cut/cat procedures voor Strings en PChars als ik het me goed herinner.

Een PChar is een soort pointer naar een string. Op de locatie waar de pointer naar wijst staan gewoon een hoop karakters achter elkaar in het geheugen, eindigend met #0 (zo weet je waar de string ophoudt zeg maar)

Met een beetje pointer en array geklungel vallen die functies uit de strings unit zo te herschrijven. Een makkelijk manier als je de maximale lengte weet:

code:

type
    TMyPChar: Array[0..MaxLen] of Char;
    PMyPChar: ^TMyPChar;

procedure InitMyPChar(PC: TMyPChar);
var i: Integer;
begin
    for i := 0 to MaxLen do PC[i] := #0;
end;

Je zou ook FillChar kunnen gebruiken maar ik weet niet of die in TP 5.5 al beschikbaar is. Misschien dat een array van char's en een string al compatible zijn in TP 5.5 je moet alleen oppassen voor die #0 daar worden strings af en toe niet helemaal vrolijk van

Ik had er zelf al wat op gevonden, namelijk for count := 0 To 254 do tempstr[count+1] := asciz[count] met var tempstr : string

BoomSmurf schreef op 17 maart 2004 @ 18:34:
[...]


32 dirs met een naam van elk 127 tekens, lol! Zelfs Windows XP understeund nog maar max 1024 tekens in het totaal

Een bestand zelf mag max 127 tekens zijn, dus zo naar de unit kijken zal ie niet het volledige pad nodig hebben. 'T is allemaal jaren geleden dat ik het ooit geschreven heb dus ik weet het niet meer zo precies Je zult het gewoon effe uit moeten proberen heh.

Ik rekende ook niet op dat ooit de volledige 32*128=4K gebruikt zou worden daarvoor, maar 32 dirs en max 127 chars leken me wel realistisch (aangezien ik zelf vaak een gigantisch diepe tree heb )

BoomSmurf schreef op 17 maart 2004 @ 18:34:
[...]

Dan heb je een probleem, want strings mogen maar 255 bytes lang zijn. Ik weet ook niet of de interrupts die aangeroepen worden wel meer dan dat teruggeven. Allicht dat als je zo'n soort 'nep' PChar constructie gebruikt zoals ik een stuk terug aangaf dat je langere namen kan gebruiken, maar is niet echt handig

Daarvoor had ik dat hele geklungel met 32*127 juist bedacht, om die strings te slim af te zijn Kzal dr es wat mee gaan klooien

[Tomatoman]

BoomSmurf schreef op 17 maart 2004 @ 18:34:
[...]
32 dirs met een naam van elk 127 tekens, lol! Zelfs Windows XP understeund nog maar max 1024 tekens in het totaal

Windows NT/2000/XP/Server 2003 ondersteunt unicode-bestandsfuncties met maximaal 65535 tekens in een volledig gekwalificeerde bestandsnaam.

[BoomSmurf]

tomatoman schreef op 17 maart 2004 @ 19:36:
[...]
Windows NT/2000/XP/Server 2003 ondersteunt unicode-bestandsfuncties met maximaal 65535 tekens in een volledig gekwalificeerde bestandsnaam.

Nu FAT32 en NTFS nog