1. Self Extractor
Does anyone know of a DOS-based extractor for zip files?
Basically, I have a backup program that copies the whole drive to a zip
file, and I need a way to restore it.
The self-extracting tool that came with it is windows-based - very silly.
I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
through the extraction.
Basically, it needs to be DOS based and not munge up long filenames.. is
that possible?
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
2. Re: Self Extractor
mistertrik at hotmail.com wrote:
> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
> through the extraction.
>
> Basically, it needs to be DOS based and not munge up long filenames.. is
> that possible?
DOS mode doesn't allow long filenames (Microsoft would rather you used
the GUI), but there's a tool out there called LFNDos that will give
access to long filenames in DOS mode.
Second, grab a copy of the PKZip 2.5 package as this handles long
filenames when it thinks it sees Windows running (LFNDos fools it
successfully). Alternatively get the freeware DJGPP Unzip32.exe and
cwsdpmi.exe (along with LFNDOS) to do the unzipping.
HTH,
Carl
--
[ Carl R White == aka () = The Domain of Cyrek = ]
[ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
3. Re: Self Extractor
Try Davi Figueiredo's unzip.e library and make your own unzipping program...
http://www16.brinkster.com/davitf/
----- Original Message -----
From: <mistertrik at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Self Extractor
>
>
> Does anyone know of a DOS-based extractor for zip files?
>
> Basically, I have a backup program that copies the whole drive to a zip
> file, and I need a way to restore it.
>
> The self-extracting tool that came with it is windows-based - very silly.
>
> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
> through the extraction.
>
> Basically, it needs to be DOS based and not munge up long filenames.. is
> that possible?
> =====================================================
> .______<-------------------\__
> / _____<--------------------__|===
> ||_ <-------------------/
> \__| Mr Trick
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: Self Extractor
- Posted by gertie at visionsix.com
May 29, 2003
On 29 May 2003, at 9:20, Carl W. wrote:
>
>
> mistertrik at hotmail.com wrote:
>
> > I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
> > everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
> > through
> > the extraction.
> >
> > Basically, it needs to be DOS based and not munge up long filenames.. is
> > that
> > possible?
>
> DOS mode doesn't allow long filenames (Microsoft would rather you used
> the GUI), but there's a tool out there called LFNDos that will give
> access to long filenames in DOS mode.
>
> Second, grab a copy of the PKZip 2.5 package as this handles long
> filenames when it thinks it sees Windows running (LFNDos fools it
> successfully). Alternatively get the freeware DJGPP Unzip32.exe and
> cwsdpmi.exe (along with LFNDOS) to do the unzipping.
<prolly !helpful>
It's my understanding you can do LFN in dos7 without windows running, and
without any other apps, IF the dos program knows how to stuff the cpu
registers for the interrupt call. The ints are the same, just the registers are
used differently. How the filenames in the zip file are handled is a different
story tho. If the self extractor knows dos, it should run fine in win95 or dos7
(with a console version of itself).
Kat
5. Re: Self Extractor
Mr Trick
Have a look at 7-zip at:
http://www.7-zip.org
Freeware, open source. Command line exe comes as part of the full distribution,
called 7za.exe. This module supports zip as well as its own 7z and tar methods.
Issue of long file names remains as it is an operating system constraint. Have
not
tried LFN or similar DOS utilties, but may be worth the effort.
Suggest check out the FreeDOS web site at www.freedos.org. Go to its Links page.
--
David Jarvis
On 29 May 2003 at 16:27, mistertrik at hotmail.com wrote:
>
>
> Does anyone know of a DOS-based extractor for zip files?
>
> Basically, I have a backup program that copies the whole drive to a zip
> file, and I need a way to restore it.
>
> The self-extracting tool that came with it is windows-based - very silly.
>
> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
> through the extraction.
>
> Basically, it needs to be DOS based and not munge up long filenames.. is
> that possible?
> =====================================================
> .______<-------------------\__
> / _____<--------------------__|===
> ||_ <-------------------/
> \__| Mr Trick
>
6. Re: Self Extractor
Hi Kat, you wrote:
> On 29 May 2003, at 9:20, Carl W. wrote:
>
>> mistertrik at hotmail.com wrote:
>>
>>> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
>>> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
>>> through
>>> the extraction.
>>>
>>> Basically, it needs to be DOS based and not munge up long filenames.. is
>>> that
>>> possible?
>>
>> DOS mode doesn't allow long filenames (Microsoft would rather you used
>> the GUI), but there's a tool out there called LFNDos that will give
>> access to long filenames in DOS mode.
>>
>> Second, grab a copy of the PKZip 2.5 package as this handles long
>> filenames when it thinks it sees Windows running (LFNDos fools it
>> successfully). Alternatively get the freeware DJGPP Unzip32.exe and
>> cwsdpmi.exe (along with LFNDOS) to do the unzipping.
>
> <prolly !helpful>
> It's my understanding you can do LFN in dos7 without windows running, and
> without any other apps, IF the dos program knows how to stuff the cpu
> registers for the interrupt call.
Sorry, this understanding is false. There must be an appropriate API for
Long File Names, and this is *not* provided by (any version of) bare
MS-DOS.
Normally, LFN are only available when IFSMgr (i.e. Windows 95+) is
running. Under bare MS-DOS, they only can be accessed by using special
TSR programs, such as
- LFNDOS: http://saturn.spaceports.com/~dosuser/dosutils.htm
- DOSLFN: http://www.tu-chemnitz.de/~heha/hs_freeware/doslfn.zip
That the DOS program knows how to stuff the cpu registers for the
interrupt call, is necessary of course, but it's not sufficient.
a) There must be an API for LFN, *and*
b) the program must call the proper functions of that API.
Point b) is simple for Eu programmers, because they just can use
my lib http://www.rapideuphoria.com/lfn.zip which does the job
automagically. 
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
7. Re: Self Extractor
- Posted by gertie at visionsix.com
May 31, 2003
On 31 May 2003, at 20:25, Juergen Luethje wrote:
>
>
> Hi Kat, you wrote:
>
> > On 29 May 2003, at 9:20, Carl W. wrote:
> >
> >> mistertrik at hotmail.com wrote:
> >>
> >>> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
> >>> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
> >>> through the extraction.
> >>>
> >>> Basically, it needs to be DOS based and not munge up long filenames.. is
> >>> that possible?
> >>
> >> DOS mode doesn't allow long filenames (Microsoft would rather you used
> >> the GUI), but there's a tool out there called LFNDos that will give
> >> access to long filenames in DOS mode.
> >>
> >> Second, grab a copy of the PKZip 2.5 package as this handles long
> >> filenames when it thinks it sees Windows running (LFNDos fools it
> >> successfully). Alternatively get the freeware DJGPP Unzip32.exe and
> >> cwsdpmi.exe (along with LFNDOS) to do the unzipping.
> >
> > <prolly !helpful>
> > It's my understanding you can do LFN in dos7 without windows running, and
> > without any other apps, IF the dos program knows how to stuff the cpu
> > registers for the interrupt call.
>
> Sorry, this understanding is false. There must be an appropriate API for
> Long File Names, and this is *not* provided by (any version of) bare
> MS-DOS.
I took the time to scan in the book Unauthorized Windows a few years ago...
but it's on zip disk and the puter is too full of hds to plug in the zip
drive... but
in the book, open in front of me, it says if not in real mode, you can switch to
a protected mode dos and get the LFN API with dos interrupts if you load the
vxd's provided for that purpose.
> Normally, LFN are only available when IFSMgr (i.e. Windows 95+) is
> running.
*normally*, but you can load the required vxd's without it.
> Under bare MS-DOS, they only can be accessed by using special
> TSR programs, such as
> - LFNDOS: http://saturn.spaceports.com/~dosuser/dosutils.htm
> - DOSLFN: http://www.tu-chemnitz.de/~heha/hs_freeware/doslfn.zip
>
> That the DOS program knows how to stuff the cpu registers for the
> interrupt call, is necessary of course, but it's not sufficient.
> a) There must be an API for LFN, *and*
> b) the program must call the proper functions of that API.
There is an api already. Well, not really, but sorta of, if you know where to
look..... since all the info for the LFN is on disk, you can still get at it
with
bios calls. It's plain visable in disk "hex" editors, like the olde Norton. As
someone who has written tsrs that did bios calls to manipulate the disk and
memory (dos isn't *normally* reintrant), this is easy. The long filename
simply takes up the next space in the FAT, with a byte flag to tell the LFN
driver that the filename it is reading has NOT ended, and to append the
following block to the filename, repeat as needed for whatever filename len is
needed. You can eat up gobs of drive space in filenames alone.
> Point b) is simple for Eu programmers, because they just can use
> my lib http://www.rapideuphoria.com/lfn.zip which does the job
> automagically.
Kool, thanks, Juergen!
Kat
8. Re: Self Extractor
Hi Kat, you wrote:
> On 31 May 2003, at 20:25, Juergen Luethje wrote:
>
>>
>> Hi Kat, you wrote:
>>
>>> On 29 May 2003, at 9:20, Carl W. wrote:
>>>
>>>> mistertrik at hotmail.com wrote:
>>>>
>>>>> I tried using PKUNZIP.EXE, but it can't handle long filenames (truncates
>>>>> everything to 8 chars, ie PROGRAMF), and it borks about 3/4 of the way
>>>>> through the extraction.
>>>>>
>>>>> Basically, it needs to be DOS based and not munge up long filenames.. is
>>>>> that possible?
>>>>
>>>> DOS mode doesn't allow long filenames (Microsoft would rather you used
>>>> the GUI), but there's a tool out there called LFNDos that will give
>>>> access to long filenames in DOS mode.
>>>>
>>>> Second, grab a copy of the PKZip 2.5 package as this handles long
>>>> filenames when it thinks it sees Windows running (LFNDos fools it
>>>> successfully). Alternatively get the freeware DJGPP Unzip32.exe and
>>>> cwsdpmi.exe (along with LFNDOS) to do the unzipping.
>>>
>>> <prolly !helpful>
>>> It's my understanding you can do LFN in dos7 without windows running, and
>>> without any other apps, IF the dos program knows how to stuff the cpu
>>> registers for the interrupt call.
>>
>> Sorry, this understanding is false. There must be an appropriate API for
>> Long File Names, and this is *not* provided by (any version of) bare
>> MS-DOS.
>
> I took the time to scan in the book Unauthorized Windows a few years ago...
> but it's on zip disk and the puter is too full of hds to plug in the zip
> drive... but
> in the book, open in front of me, it says if not in real mode, you can switch
> to
> a protected mode dos and get the LFN API with dos interrupts if you load the
> vxd's provided for that purpose.
>
>> Normally, LFN are only available when IFSMgr (i.e. Windows 95+) is
>> running.
>
> *normally*, but you can load the required vxd's without it.
>
>> Under bare MS-DOS, they only can be accessed by using special
>> TSR programs, such as
>> - LFNDOS: http://saturn.spaceports.com/~dosuser/dosutils.htm
>> - DOSLFN: http://www.tu-chemnitz.de/~heha/hs_freeware/doslfn.zip
>>
>> That the DOS program knows how to stuff the cpu registers for the
>> interrupt call, is necessary of course, but it's not sufficient.
>> a) There must be an API for LFN, *and*
>> b) the program must call the proper functions of that API.
>
> There is an api already. Well, not really, but sorta of, if you know where to
> look.....
Are you saying, that the authors of LFNDOS and DOSLFN only had to write
their programs, because they didn't know where to look?
> since all the info for the LFN is on disk, you can still get at it with
> bios calls. It's plain visable in disk "hex" editors, like the olde Norton. As
> someone who has written tsrs that did bios calls to manipulate the disk and
> memory (dos isn't *normally* reintrant), this is easy. The long filename
> simply takes up the next space in the FAT, with a byte flag to tell the LFN
> driver that the filename it is reading has NOT ended, and to append the
> following block to the filename, repeat as needed for whatever filename len is
> needed. You can eat up gobs of drive space in filenames alone.
Of course, the LFN are somewhere on the disk, and of course they can be
accessed. That's what IFSMgr, LFNDOS and DOSLFN do. When I build the
functionality of say LFNDOS into my own program, then I don't need
LFNDOS any more. But I'm neither interested in, nor have the ability
to do hardware programming.
>> Point b) is simple for Eu programmers, because they just can use
>> my lib http://www.rapideuphoria.com/lfn.zip which does the job
>> automagically.
>
> Kool, thanks, Juergen!
>
> Kat
You're welcome! But this lib ATM needs IFSMgr (or, not yet tested,
LFNDOS or DOSLFN) running in the background. If you can tell me, how
it can access LFN
| in dos7 without windows running, and without any other apps,
just by storing the appropriate values in the appropriate cpu
registers, and then call the appropriate interrupt, then please tell
me these values. No one will be happier than me!
Best regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
9. Re: Self Extractor
- Posted by gertie at visionsix.com
Jun 07, 2003
On 7 Jun 2003, at 19:33, Juergen Luethje wrote:
<snip>
> > There is an api already. Well, not really, but sorta of, if you know where
> > to
> > look.....
>
> Are you saying, that the authors of LFNDOS and DOSLFN only had to write
> their programs, because they didn't know where to look?
Not exactly. What i thought i said was that dos hackers could call bios
functions to get the lfn's off the disk, and not need to go to a 3rd party
application to do it. The LFNDOS and DOSLFN add overhead that may not
be tolerable in some situations.
<snip>
> > Kool, thanks, Juergen!
> >
> > Kat
>
> You're welcome! But this lib ATM needs IFSMgr (or, not yet tested,
> LFNDOS or DOSLFN) running in the background. If you can tell me, how
> it can access LFN
Which means windows, of course.
> | in dos7 without windows running, and without any other apps,
>
> just by storing the appropriate values in the appropriate cpu
> registers, and then call the appropriate interrupt, then please tell
> me these values. No one will be happier than me!
Not quite. Like you said, to make *DOS* calls to get the lfn, you need the
DOS drivers included in windoze, namely the vxds mentioned earlier. M$
renamed the 32bit code "virtual" because their attempt was to emulate 16bit
dos in 32bit code, and add some cool functions they didn't want to put into
plain dos, because that would stall dos users from buying the new OS. In
win95/dos7, there is a lot of calling back and forth between 16bit and 32bit
tsr/vxd code. Dos will ignore anything you put into or get out of the normal
dos non-used registers, only the 32bit vxd's will use the other registers, but
then you aren't technically in dos land anymore, i think. Think of dos as an
api on top of the bios, after all, bios means basic input-output service, and
that includes input/output to the disk drives. The vxd is just another layer on
the bios, sitting beside and slightly above the olde dos code. Making a bios
call is simply bypassing most of the higher level dos/vxd code, even if you
use dos to set up the call. Msdos is just a glorified tsr, after all is said and
done.
That said, the last books i bought on dos internals was for msdos5, ISBN 1-
55615-329-5, and msdos6, ISBN 1-55615-546-8, i recommend them. The v6
book covers Doublespace drives. They are covered in dust here. They are
each about 500 pages of obsfucated M$ doublespeak, but if you can wade
thru winapi code, you can grasp dos code. (Igor and Karl -- they also cover
language support.) Look up the low level functions in dos present since
version 1, or rather the code that superceeds them. You *could* get by
without dropping into the bios. Just open and read the FAT, minding the last
bytes for pointers and such when reading the name,, and be sure to munge
the filename property with writing. A cheap way to write a lfn would be to
write the file with a truncated name, then overwrite the short name in the FAT
with the pointer to the longer name. The FAT is just another file, ya know.
You can see by doing this how the vxd's just keep calling the olde dos 16bit
code. I recommend you use a non-critical drive for this, in case you make
mistakes and overwrite something (which is easy to do if you don't verify the
FAT block is useable before you write to it).
Kat
10. Re: Self Extractor
- Posted by gertie at visionsix.com
Jun 08, 2003
On 7 Jun 2003, at 19:33, Juergen Luethje wrote:
<snip>
> > just by storing the appropriate values in the appropriate cpu
> > registers, and then call the appropriate interrupt, then please tell
> > me these values. No one will be happier than me!
http://216.239.37.100/search?q=3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manu
als/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hl=3Den&ie=3DUTF-8
At least this dos supports lfn directly:
Long Filenames Files used in the ROM-DOS environment, with long filename=
=20
support enabled, can have up to 260 characters including the file extension=
=20
and path. Each long filename also has a standard 8.3 filename associated=
=20
with it. Long filenames can use nearly any character except the following=
=20
symbols: Output redirection > Question mark ? Input redirection < Asterisk =
*=20
Backslash \ Double quotes =93 Forward slash / Pipe | When using a long=20
filename or path that contains spaces, the name and/or path must be=20
surrounded by double quotes. For example: copy =93c:\my directory\my=20
file.doc=94 =93c:\another directory\reference=94 Standard 8.3 Filenames Fil=
es used=20
in the ROM-DOS environment, without long filenames support enabled, have=
=20
two-part names separated by a period. The first part is the filename; the=
=20
second part is the filename extension. For example, the command=20
interpreter file provided with ROM-DOS is named COMMAND.COM, where=20
COMMAND is the filename and .COM is the filename extension. Filenames=20
range from one to eight characters in length and consist of any combination=
=20
of letters, numbers, and the following symbols: underscore _ Ampersand &=
=20
Caret ^ Hyphen - dollar sign $ Braces { } Tilde ~ Parenthesis ( )=20
Kat
11. Re: Self Extractor
Hi Kat, you wrote:
> On 7 Jun 2003, at 19:33, Juergen Luethje wrote:
>
> <snip>
>
>>> just by storing the appropriate values in the appropriate cpu
>>> registers, and then call the appropriate interrupt, then please tell
>>> me these values. No one will be happier than me!
>
> http://216.239.37.100/search?q=3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manu
> als/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hl=3Den&ie=3DUTF-8
>
> At least this dos supports lfn directly:
<snip>
Tank you, that sounds interesting.
But although I tried several times, I cannot access the URL. It calls
Google, and Google says: "Your search [the URL] did not match any
documents." (Of course, I concatenated the two lines.
How can I read that document?
Best regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
12. Re: Self Extractor
- Posted by 1evan at sbcglobal.net
Jun 09, 2003
how about
http://www.rtdusa.com/manuals/romdos_04_11_1387.pdf
Juergen Luethje wrote:
>
>
>Hi Kat, you wrote:
>
>
>> On 7 Jun 2003, at 19:33, Juergen Luethje wrote:
>>
>><snip>
>>
>>
>>>>just by storing the appropriate values in the appropriate cpu
>>>>registers, and then call the appropriate interrupt, then please tell
>>>>me these values. No one will be happier than me!
>>>>
>>>>
>>http://216.239.37.100/search?q=3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manu
>>als/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hl=3Den&ie=3DUTF-8
>>
>>At least this dos supports lfn directly:
>>
>>
><snip>
>
>Tank you, that sounds interesting.
>But although I tried several times, I cannot access the URL. It calls
>Google, and Google says: "Your search [the URL] did not match any
>documents." (Of course, I concatenated the two lines.
>How can I read that document?
>
>Best regards,
> Juergen
>
>
--
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)`-'\_)
13. Re: Self Extractor
On Mon, 09 Jun 2003 15:53:38 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>Hi Kat, you wrote:
>>
>> =
http://216.239.37.100/search?q=3D3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manu
>> als/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hl=3D3Den&ie=3D3DUTF-8
>But although I tried several times, I cannot access the URL. It calls
>Google, and Google says: "Your search [the URL] did not match any
>documents." (Of course, I concatenated the two lines.
>How can I read that document?
It has been mangled by the email a bit. The link works if you replace
"=3D3D"s with "=3D". This one might get through:
http://216.239.37.100/search?q=3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manual=
s/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hlen&ie=3DUTF-8
Pete
14. Re: Self Extractor
Hi "1evan", you wrote:
> how about
> http://www.rtdusa.com/manuals/romdos_04_11_1387.pdf
<snip>
Ahem ... I couldn't see the wood for the trees.
Thanks, and best regards,
Juergen
15. Re: Self Extractor
Hi Pete, you wrote:
> On Mon, 09 Jun 2003 15:53:38 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> Hi Kat, you wrote:
>>>
>>> http://216.239.37.100/search?q=3Dcache:Rj06PJEI5ecJ:www.rtdusa.com/manu
>>> als/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hl=3Den&ie=3DUTF-8
>> But although I tried several times, I cannot access the URL. It calls
>> Google, and Google says: "Your search [the URL] did not match any
>> documents." (Of course, I concatenated the two lines.
>> How can I read that document?
>
> It has been mangled by the email a bit. The link works if you replace
> "=3D"s with "=". This one might get through:
>
> http://216.239.37.100/search?q=cache:Rj06PJEI5ecJ:www.rtdusa.com/manuals/romdos_04_11_1387.pdf+ISBN+1-55615-546-8&hlen&ie=UTF-8
>
> Pete
Huu, is your other name Sherlock Holmes?
Thank you.
Well, the normal text in Kat's mail also was somewhat mangled.
The mail (at least the copy, that arrived at me) is missing the
"Content-Type" and "Content-Transfer-Encoding" header fields. Maybe
that's the reason why?
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
