PKZIP archive

And on the spec, subjects in which there is a structure
of nested directories are normally unpacked?
They seem to be unpacked, but the directory structure is not saved, right?

KF> And on the spec, subjects in which
KF> have a structure of nested directories are normally unpacked?
Yeah. There, only the file counting is carried out incorrectly and pkunzip sometimes
resets after everything has been unpacked. But it unpacks everything correctly.

KF> They seem to be unpacked, but the directory structure is not
KF> preserved, right?
Naturally. :) There are no directories in tr-dos. :)

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

Sunday 02 December 2001 14:23:48 Kirill Frolov -> All:

KF> And on the spec, subjects in which
KF> have a structure of nested
KF> directories are normally unpacked?
KF> They seem to be unpacked, but the directory structures are not
KF> preserved, so?

It’s definitely not saved under tyr-dos :)

Nikolaj.
[REAL ZX]

On Sunday December 02 2001 Kirill Frolov wrote to All:

KF> structure of nested directories? They seem to be unpacked, but the
KF> directory structure is not saved, right?
Yes. Otherwise, there are no directories in trdos - the best option.

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

04 Dec 01 00:30, Igor Turashev -> Kirill Frolov:

KF>> structure of nested directories? They seem to be unpacked, but
KF>> the directory structure is not saved, right?

IT> Yes. Otherwise, as if there are no directories in trdos - the most optimal option.

^^^^^^^^^^^^^^^^^^^^^^^^Have you seen TRDN?

Stanislav

03 Dec 01 20:28, Sergey Zotov -> Kirill Frolov:

KF>> It seems like they are unpacking, but the directory structures are not
KF>> saved, right?

SZ> Naturally. :) There are no directories in tr-dos. :)

Why not make pkUnZIP for DirSys? No, but still directories in
TR-DOS.

Stanislav

SU> ^^^^^^^^^^^^^^^^^^^^^^^Have you seen TRDN?
Seen it. Is it already a de facto standard? I can come up with my own, and also an arbitrary
length of the name and extension - many people will be happy?

Bye, Stanislav! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

IT>>> optimal
SU>> ^^^^^^^^^^^^^^^^^^^^^^TrDN seen?
IT> Seen. Is it already a de facto standard? I can come up with my own,
IT> also an arbitrary length of the name and extension - a lot of people
IT> will be happy?
Why not DirSys become a standard?
There are already programs with its support (BMPservice, BMPcolor, Disk Trouble, there may be more). TRDN v1.0 will be coming soon

And imho there is no need for long names.

Do you somehow not like DirSys? Do you have any suggestions?

Alexandr

[ZX]

IT> I saw it. Is it already a de facto standard?

Not a standard yet, BUT:
1. I have not seen any worthy alternatives to the directory system under TR-DOS.
2. This directory system is at the very least supported by software (TRDN itself,
bmp-service, bmp-converter, Disk Trouble...)
3. There is a plugin for FAR on the PC that supports this system, so the subject can be unpacked on the PC and written there to a TR-DOS disk, taking into account all
directories.

IT> I can come up with my own, and
IT> arbitrary length of the name and extension - there are a lot of people will you be happy?

From “I can come up with” to “to come up with”, and even more so to “to embody” there is too big
gap...

Stanislav

SU> Not a standard yet, BUT:
SU> 1. I have not seen any worthy alternatives to the directory system under TR-DOS.
I don’t see the point.

SU> 2. This directory system is at the very least supported by software (TRDN itself,
SU> bmp-service, bmp-converter, Disk Trouble...) 3. K FAR on the PC
SU> there is a plugin that supports this system, so the subject can be
SU> unpacked on the PC and written there to a TR-DOS disk, taking into account
SU> all the directories.
What good are directories? Apart from this special software, no one will understand them, and constantly
loading this canoe to read the text is too much.

KF>> directory structure is not preserved, right?
IT> Yes. Otherwise, as if there are no directories in Trdos - the most optimal option.

Then it would be a very good idea to create a file in which it will be written
which files from the archive were in which directories and with what attributes, and
which files on the TR-DOS disk correspond to them.

SZ> Naturally. :) There are no directories in tr-dos. :)

Yes. Can be unpacked to different disks.

On Thursday December 06 2001 Alexandr Khavzin wrote to Igor Turashev:

IT>> will be happy?
AK> Why not DirSys become a standard?
Why do TRDOS have directories at all? The system is not fat/ntfs/anything like that, and
I don’t see any benefit from them other than just being a toy. + non-standard - brought such
garbage to someone, but didn’t write it down to a boy like these progs who understand this and that’s all
bummer? I have a madrom - I already forgot what boot is, and here I constantly download
some kind of garbage that I may not even like. I still agree with RC, but
everything else...

AK> There are already programs that support it (BMPservice, BMPcolor, Disk Trouble,
AK> there may be more). Coming soon TRDN v1.0
If it is actually difficult to live without long files on the spec, then without
directories in trdos I lived and did not die, and I did not feel the need for them. And
the list of software is simply impressive.

AK> And imho there is no need for long names.

AK> Do you somehow not like DirSys? Maybe you have any suggestions?
Stop this bullshit.

Bye, Alexandr! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

SU> Isn’t it too convenient to have 128 small files in your pile and
SU> to look for what you need?
SU> Isn’t it convenient to sort pictures,
SU> music, texts, etc. into catalogs?

I think it’s very convenient. I've been wanting to do these with
musical modules for a long time.

[ skip ]

IT>> Stop worrying about this crap.

SU> ... there are not even words for such a proposal... :(((

Don’t pay attention to it. Finish it quickly, commander.

Nikolaj.
[REAL ZX]

08 Dec 01 01:15, Igor Turashev -> Alexandr Khavzin:

AK>> Why shouldn’t DirSys become a standard?

IT> Why do you need directories in trdos at all?

What, it’s too convenient to have 128 small files in a pile and look for what do you need it? Isn’t it convenient to sort pictures, music, texts and
other things into catalogs?

IT> The system is not fat/ntfs/something
IT> similar,

I don’t see any connection between the presence of catalogs and these systems at all.

IT> and I don’t see any benefit from them, other than just toy. +
IT> non-standard - brought such garbage to someone, but boydy like these programs,
IT> who understand this, did not write it down and that’s it - a bummer?

That’s where it was necessary to start. You have not seen the system, or if you have seen it, then for a few seconds without even delving into the essence. ANY FILE ON THE DISK WILL BE SEEN BY ANY
EXISTING PROGRAM AND LIST AND CAT COMMANDS!

IT> I have a master - I already
IT> forgot what boot is, and here I constantly load some kind of garbage,

Why is there such an attitude towards the program in advance?

IT> which I may not even like. I still agree with RC, but with everything
IT> else...

Well, that means you really don’t need the system...

AK>> There are already programs with its support (BMPservice, BMPcolor, Disk
AK>> Trouble, maybe there are more). Coming soon TRDN v1.0

IT> If you can actually live without long files on the spechard,

?????????? For some reason, I have never had a need for long names specifically
on Spec.

IT> then
IT> without directories in trdos I lived and never died, and I didn’t
IT> feel the need for them.

And I’m the opposite.

IT> And the list of software is simply impressive.

Moscow is not was built right away...

AK>> And imho there is no need for long names.

AK>> Do you somehow not like DirSys? Maybe there are any suggestions?

IT> Stop worrying about this bullshit.

... there are not even words for such a proposal... :(((

Stanislav

SU> ???????? For some reason, I have never had a need for long names
SU> specifically on Spec.

We are not talking about names in this case. This refers to files with a length of >64
kilobytes. It’s not very convenient when they are split into several files.

Well, in general, he drives. ;))

Bye, Stanislav.
WBR, Vivid^Brainwave.

IT> Why do TRDOS have directories at all? The system is not fat/ntfs/something
IT> like that, and I don’t see any benefit from them other than just being a toy. +
IT> non-standard - brought such garbage to someone, but boyd like these progs
IT> who understand this, didn’t write it down and that’s it - a bummer? I have a madrom - I have already
IT> forgotten what boot is, and here I constantly have to download some kind of garbage,
IT> which I may not even like. I still agree with RC, but with everything
IT> else...
You should have sat out with such statements... Nowadays, when everything is so bad with software
it is necessary to support new projects, and not vice versa..

2AK: TRDN - RulezZ!!! You don't need to listen to negative reviews... You don't need to listen to anyone at all. You need to take it and do it. Moreover, make sure that when
they see the result, everyone’s mouths fall to the floor.. Here.

IT>> everything else...
SU> Well, that means you really don’t need the system...
He doesn’t need it. AND I NEED IT, I NEED IT!!! People, this is cool! The first time
I saw trdn, I realized that Real Commander (I have nothing against RC.
On the contrary, he rules) was not lying next to me... Your program is JUST SUPER! And if
there was also support for 512x192... THEN in general...

IT> Why do TRDOS have directories at all? The system is not
IT> fat/ntfs/anything like that, and I don’t see any benefit from them, except

No, why, directories are very convenient.

IT> are like just a toy. + non-standard - brought such garbage to
IT> to someone, but boyd like these progs who understand this, didn't
IT> write it down and that's it - a bummer? I have a madrom - I already forgot that

No, this is the idea: just behind the 9th track, information about directories is written. Tyrdosina still doesn't use these sectors, and all the files hang in the first eight sectors as usual, and if you load software that supports this standard, the directories will overlap transparently on the disk. So in any case, you don’t lose anything.

IT> is boot, but here you constantly have to download some kind of garbage,
IT> which I may not even like. I still agree with RC,
IT> but for everything else...

Well, until you need to quickly find something in the directory tree and
you don’t need to load anything. If you need it, you’ll load it just once. :-)

Sincerely, Dmitriy.

SU> Is it too convenient to have 128 small files in a pile and
SU> look for what you need? Isn't it convenient to sort pictures, music, texts, etc. into catalogs?

What are "pictures, music, texts, etc."? With a disk capacity of 640kb, you don't have to shove it into different directories, but onto different disks! ;-)

Monday December 01 1997 11:10, Dmitriy Nesmachny wrote to Stanislav Udin:

DN> By the way, here’s a bright idea, and I suggested it when
DN> the development of RC2.0 was just beginning: create with Pavel a directory plugin for
DN> RC2.0, it will be an order of magnitude more convenient and will start instantly develop.
DN> IMHO.
I agree. Of course, I am not a supporter of catalogs, because IMHO, they are not needed. But support for DirSys from RC will be a big step forward. Many people use this
commander, and they are simply too lazy to upload anything else.

Best regards, Oleg. [ZX]

09 Dec 01 11:01, Pawel Semenow -> Stanislav Udin:

PS> He doesn’t need it. AND I NEED IT, I NEED IT!!! People, this is cool! The first
PS> time when I saw trdn, I realized that Real Commander (I have
PS> nothing
PS> against RC. On the contrary, he climbed) was not lying nearby... Your program -
PS> JUST SUPER!

Thanks for the words of support :)

PS> And if I could do more support for 512x192... THAT in general...

Eh, there’s not enough memory for anything anymore, much less for this mode :( And no one else has such a mode (I remind you that the program is written exclusively in
real). Although I agree that this mode would not be there interfered.

09 Dec 01 10:47, Pawel Semenow -> Igor Turashev:

AK>>> But long names are not needed imho.

PS> What is stopping them from being supported? Or is it too difficult?

It’s not difficult to do, but why? There is a ready-made DirSys specification without long names, which is already somehow supported. You can enter long names by
reducing the directories, but in my opinion, long names are inappropriate.
Other software will definitely not see these long names. I once came across a boot
that allowed you to set the name of the file to be launched up to 32 characters, and in my opinion this
boot is quite enough for such purposes.

Stanislav

DN> What kind of “pictures, music, texts, etc.”? With a disk capacity of 640kb
DN> you don’t have to shove it into different directories, but onto different disks! ;-)

When there are a bunch of pictures from different parties on one disk - is it convenient? Or a disc with
music? After all, the disk turns out to be not completely full, if you follow your logic. Of course, I understand that not everyone needs these directories in TR-DOS,
but *personally* they do, and judging by the numerous reviews in the soap, I’m not the only one.

DN> By the way, here’s a bright idea, and I suggested it when the development of RC2.0 had just begun
DN>: create a plugin with Pavel directory for
DN> RC2.0,

Pavel wanted to create his own standard, he didn’t like mine, but he didn’t do his own anyway - according to him, there wasn’t enough memory...

DN> it will be an order of magnitude more convenient and will instantly begin to develop.
DN> IMHO.

Of course, it’s convenient, but, alas, there is a problem with memory... After all, you have to keep an entire track on at least one disk all the time, and in my case even two... So such a system should be built into the commander itself and the plugin, IMHO,
it’s not get by...

Stanislav

On Saturday December 08 2001 Kirill Frolov wrote to Igor Turashev:

KF> Then it would be very nice to create a file in which
KF> it will be written which files from the archive were in which directories and with what
KF> attributes, and which files on the TR-DOS disk correspond to them.
A type of unpacking log to create?

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

KF> Yes. You can unpack it onto different disks.

You can... but why the hell is it necessary?

[Wizard Warz] Yurik aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Conceptual Minimalism] \ZX/

PS> But because he is a fool. (Actually, I wanted to call it something else,
PS> but I don’t like to swear..).

well, that’s it... exactly... if new versions of PkUnZip don’t appear, I will know
who contributed to Tiggr giving up on everything... ;(

Here Pawel Semenow writes to Igor Turashev and I don’t mind interfering:

IT>> constantly uploading some kind of garbage that I may also
IT>> not like. I still agree with RC, but with everything else...
PS> I wish you could sit back with such statements... Nowadays, when
PS> everything is bad with software, we need to support new
PS> projects, and not vice versa..

;) Has it ever occurred to you that by abusing such kind
cries, you risk being left without new versions of UnPkZip? ;)))
And in general, without Tiggr's new works?

PS> 2AK: TRDN - RulezZ!!!

Would I limit myself to this, why call me names?

Or having praised one thing, you absolutely have to criticize another?

Pawel, Puck! WbW, i┌i└/4D.

06 Dec 01 00:14, Alexandr Khavzin wrote to Igor Turashev:

AK> And long names imho are not needed.

A real cool hacker does not need names longer than 6 HEX characters.

IT> Why do trdos have directories at all?

Correct. TR-DOS must die.

SU> ???????? For some reason, I have never had a need for long
SU> names specifically on Spec.

And I know why - there is an unspoken standard for the name of Spectrum
programs:

THREE LETTERS
SYMBOL "_"
VERSION NUMBER

Like "MMD_4.41".

There is one drawback - it is completely impossible to name the program understand
its
purpose. It is also impossible to remember the name.

SU> Eh, there’s not enough memory for anything anymore, especially for this mode :(

Overlays. Swap to disk. Dynamic memory allocation.

None of this is PRACTICALLY USED on the spec, but allows
to really save a lot of memory.

09 Dec 01 10:47, Pawel Semenow wrote to Igor Turashev:

IT>> madrom - I already forgot what boot is, and here I constantly load
IT>> some kind of garbage that I may not even like. I still
IT>> agree with RC, but with everything else...
PS> You should go to jail with such statements... Nowadays, when so

PS> @TID: ParToss 1.10/DOS
PS> @PID: GED+W32 1.1.5-20010807

Well, well....

PS> that’s all with the software it sucks, you need to support new projects on the contrary, and not
PS> the other way around..

Write something yourself.

IT>> I lived and never died without directories in trdos, and I didn’t feel the need for them
IT>>. And the list of software is simply impressive.
PS> Yes! Well, it’s very cool when there are 10-20-30 files in the root... It’s just crazy
PS> you can...

I have ~700 in /usr/bin and for some reason this doesn’t bother me at all.

PS> Just because you lived and didn’t die doesn’t mean it should be like that. You didn't
PS> die, but I, for example, am sick of such a mess. Here in is-dos...
PS> Here everything is done more or less “on the shelves”...

In iS-DOS you can run a program by name, but here you need to crawl
the cursor
through the list - that’s the whole problem.

SU> It’s not difficult to do, but why?

Download a file from a PC.

SU> There is a ready-made DirSys specification without long names, which
SU> is already somehow supported.

It definitely needs to be completely changed.

SU> You can introduce long names by reducing the directories, but in my
SU> opinion they are long names are inappropriate. Other software will definitely not see these long names
SU>. I once came across a boot that allowed you to specify
SU> the name of the file to be launched up to 32 characters, and in my opinion this boot for
SU> is quite enough for such purposes.

Count how many RUNNING FILES in your PC have names longer than 8
characters?
Minimum number.

And the disadvantages DirSys are as follows:

1. Information about the placement of files in directories can be destroyed by anything
(both through various manipulations of the disk directory and overwriting
service
sectors)
2. It is impossible to export it without using your commander.
(when copying files, including to hobeta/scl, during transfer via
modem...)
3. There is no possibility for expansion (I would really like to have time
creation
and file modification, support for long >64kb files distributed
in
several tr-dos files).

What prevents you from storing information aboutdirectories in the file? The fact that the disk capacity
kilobytes will decrease by 2%, and the number of stored files by 1%?

IV> ;) Has it ever occurred to you that by abusing such kind
IV> shouts, you risk being left without new versions of UnPkZip? ;)))
Author, such a vulnerable person? ;)

IV> And generally no new works by Tiggr?
AAAAAAAAA!!! Not this! :)))

IV> well, that's it... exactly... if new versions of PkUnZip do not appear, I will
IV> know who contributed to Tiggr giving up on everything... ;(
Yes, I have nothing against pkunzip... I just don’t want projects to die
so to speak “in the bud”...

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

On Tuesday December 11 2001 Ilya Vinogradov wrote to Pawel Semenow:

IV> well, that’s it... exactly... if new versions of PkUnZip don’t appear, I will
IV> know who contributed to Tiggr giving up on everything... ;(
Don’t be afraid, I’m still going to resurrect unzip, because scl is still there need to
insert, otherwise I'm Alx.... and not only him :) And to be offended by everyone - I'd
die :)

IV> damn it, why call me names, Pawel?
This is fashionable, yo!

p.s. Where have you disappeared from the soap again?

Bye, Ilya! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

Oleg Groskow ==========> Dmitriy Nesmachny:

DN>> By the way, here’s a bright idea, and when I just started
DN>> the development of RC2.0 suggested: create with Pavel a directory plugin for
DN>> RC2.0, it will be an order of magnitude more convenient and will immediately begin to develop.
DN>> IMHO.
OG> I agree. Of course, I am not a supporter of catalogs, because IMHO, they are not needed. But
OG> support for DirSys from RC will be a big step forward. A lot of
OG> people use this command, and they’re just too lazy to upload something else.

Theoretically, creating a DirSys support module is quite possible,
and for this you won’t have to rewrite the copying/compaction procedures.
In general, if there is anyone willing to write such a module, write.

Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]

SU>> mode :(

KF> Overlays. Swap to disk. Dynamic allocation
KF> of memory.

KF> None of this is PRACTICALLY USED on the spec, but
KF> allows
KF> to really save a lot of memory.
I absolutely agree, but I don’t think anyone will implement it on in practice.
The following trend is taking place - almost all software (for now) works on 128k
computers, and all extensions (plugins, for example) are made for expanded memory.
This, it seems to me, is quite justified for games due to the dynamism, but system
programs could well use swap But the fact is that the computers of the authors
of such programs usually have >128kb of brains. and it would never even occur to them to engage in such nonsense as swap. And for those few who have only 128kb, it would never occur to them to engage in such global projects.
Sorry if I offended anyone...

JseveN from the 4th Dimension...

KF> And the disadvantages of DirSys are as follows:

KF> 1. Information about the placement of files in directories
KF> can be destroyed by anything.
KF> (both through various manipulations of the
KF> directory of the disk, and overwriting service
KF> sectors)
in holedos versions 5.12 and derivatives Sector 15 (I think) of the road
ramdisk is used for swap, i.e. with the local ramdisk dirsys will fail

KF> 2. It is impossible to export it without using
KF> your commander.
KF> (when copying files, including to hobeta/scl,
KF> when transferring via modem...)
I don’t remember who came up with the “cropped” trd files, but this is not the best idea, although
due to the fact that took root...

KF> 3. There is no possibility for expansion (I would really
KF> like to have time for creating
KF> and file modification, support for long >64kb
KF> files distributed in
KF> several tr-dos files).
time in trdos is hardly possible, but long files can be made - the same
satellites, just show the name of the 1st file and
the sum of its pieces

KF> What prevents you from storing information about directories in a file? That
KF> that the capacity of the disk
KF> will decrease by 2% per kilobyte, and the number of stored files will decrease by
KF> 1%?
this idea is implemented in boot'e DeathMoroz'a (GreenMan'a), its capabilities:
- creating directories (names can be Russian);
- moving/deleting files to/from directories;
- reading texts, listening to music, launching basic files
All information is stored in a separate file.

JseveN from 4th Measurements...

PS>> you can go crazy...
KF> I have ~700 in /usr/bin and for some reason this doesn’t bother me.
So it doesn’t bother you... ;)

PS>> You’re not dead, but I, for example, am sick of such a mess. Here
PS>> in is-dos... Here everything is done more or less “on the shelves”...
KF> In iS-DOS you can run a program by name, but here you need
KF> to crawl with the cursor through the list - that’s the whole problem.
What’s stopping you from eliminating this problem?

WBR, Pawel.

KF>> Then it would be a very good idea to create a file in which
KF>> it will be written which files from the archive were in which directories and with what
KF>> attributes, and which files were on the TR-DOS disk

KF>>>> They seem to be unpacked, but the directory structure is not
KF>>>> preserved, right?
SZ>>> Naturally. :) There are no directories in tr-dos. :)
KF>> Yes. Can be unpacked to different disks.

DN>> You need to push 640kb not into different directories, but onto different drives
DN>>! ;-)
SU> When there are a bunch of pictures from different parties on one disk - is it convenient?

Or for different luggage, or there are also iS-DOS disks...
Anyway, the tracker does not distinguish between directories - what's the point then?

SU> Of course, it's convenient, but, alas, there's a problem with memory... After all, you have to do it all
SU> all the time keep an entire track of at least one disk, and in my case
SU> even two...

If the disk is not removed, there is no need.

SU> So such a system should be embedded in the
SU> commander itself and the plugin, IMHO, this is not possible...

First of all, it should be embedded in programs that contain the contents
of the disk will work. The commander takes last place here.

SU>> I saw it for a few seconds without even delving into the essence. ANY FILE ON THE
SU>> DISK WILL BE SEEN BY ANY EXISTING PROGRAM AND THE LIST
SU>> AND CAT COMMANDS!

KF> And will randomly move through different directories?

You yourself know that it won’t, but every single file will see.

Stanislav

KF> Overlays. Swap to disk. Dynamic memory allocation.

KF> None of this is PRACTICALLY USED on the spec, but it allows
KF> to really save a lot of memory.

Users will beat you up for swapping to disk and will not use the program, no matter how wonderful it is was...

Stanislav

11 Dec 01 02:52, Kirill Frolov -> Stanislav Udin:

KF> And the disadvantages of DirSys are:

KF> 1. Information about the placement of files in directories can be
KF> destroyed by anything.
KF> (like various manipulations over disk directory, and
KF> rewriting service
KF> sectors)

Many have a completely zero track and are wasted in vain. Well, so what? It is not
supposed to keep the system on 100% disks, but only where it is really
needed.

KF> 2. It is impossible to export it without using your
KF> commander.
KF> (when copying files, including in hobeta/scl, when transmission
KF> via modem...)

Hey, this is no longer for me. Perhaps someone who likes DirSys will make
support...

KF> 3. There is no possibility for expansion (I would really like to have
KF> time for creating
KF> and file modification,

I’ve only heard such wishes from you. There is IS-DOS for this, for example. You
said yourself that TR-DOS must die, and DirSys is at least some attempt to improve something with minimal loss of compatibility.

KF> support for long >64kb files
KF> distributed in
KF> several tr-dos files).

This can actually be done, but again at the level commander.

KF> What's stopping you?store directory information in a file? The fact that
KF> the disk capacity will decrease by 2% per kilobyte, and the number of stored files
KF> by 1%?

In principle, nothing interferes and, perhaps, the next version of DirSys will live both
on the zero track and in the file, this is not so difficult to do. However, in order
to save space, it is worth making a file with a system size of 2 sectors, which
will provide “only” 22 directories.

Stanislav

12 Dec 01 00:29, Vassili Klimov -> Kirill Frolov:

KF>> What prevents you from storing information about directories in a file? That
KF>> that the capacity of the disk
KF>> kilobytes will decrease by 2%, and the number of stored files by
KF>> 1%?

VK> this idea is implemented in the boot of DeathMoroz (GreenMan), its
VK> capabilities: - creating directories (names can be Russian); -
VK> moving/deleting files to/from directories; - reading texts,
VK> listening to music, launching basic files All information is stored in
VK> a separate file.

Can this be booted directly, or directly here?

Stanislav

KF>> files by 1% ?
SU> In principle, nothing interferes and, perhaps, the next version of DirSys
SU> will live both on the zero track and in the file, this is not so difficult to do.
SU> However, in order to save space

2% ?

SU> it is worth making a file with a system of 2 sectors in size, which will provide
SU> “only” 22 directories.

It should be ~8kb. And store file names in symbolic form.
And at the same time, everyone should think about how to find out that the information in the directory
refers to this particular file, or whether the file has already been overwritten by another
program. This is unreal.

VK>> is stored in
VK>> a separate file.

SU> Is it possible to boot this into soap, or directly here?
I’ll ask the author for the latest version and upload it. By the way, it's called Tomberboot, maybe you've seen it?

JseveN from the 4th Dimension...

KF> Well, it’s more likely not a log, but a list of files in the archive.
Combine business with pleasure - a list of files + the status of unpacked or not.

Bye, Kirill! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

SU>> mode :(

KF> Overlays.

It is necessary to always keep the system disk at hand (if not in the drive)

KF> Swap to disk.

It is imperative to back up a junk file on the disk using this swap,
making sure that the disk is not accidentally replaced inadvertently.

KF> Dynamic memory allocation.

It will not particularly solve the problem, although by the way it is quite successfully used.

KF> None of this is PRACTICALLY USED on the spec, except

Because it is very inconvenient. If
there was a screw, then there are no problems, but so... :-(

KF> allows
KF> to really save a lot of memory.

Regards, Dmitriy.

Yes, I’m for TR-DOS... in general, I don’t know what I’ll do to you for this, but
probably something terrible :)

You. actually, I realized what I blurted out?
“Watch yourself, be careful...” - V.R. Tsoi.

Isdosniki - cool special trumists, shout at every corner “isdos is a steering wheel,
and trdos is a Mazda,” but when a fresh
Insanity or ZX-Guide comes to them, without stopping, they press RESET and turn on the same TR-DOS.

All the best,
Sergey Moskalev.

Somehow Wednesday December 12, 2001 at 01:22:40, Kirill and Yuri were arguing about PKZIP
archive

KF>>> Yes. Can be unpacked to different disks.

[Wizard Warz] Yurik aka Jerri / Alien Factory /I \
[No RAR allowed] [SoHm] [Conceptual Minimalism] \ZX/

(11 Dec 01 23:38) Igor Turashev wrote a letter to Kirill Frolov

KF>> Write something yourself.
IT> There is no time - we need to support new projects, and this means having an active
IT> lifestyle and smelling biomax at night instead of sleep, to start the day with
IT> feeling the energy of the freshness of the deodorant Adidas and eat it with Chibo coffee
IT> baked in a frying pan Tefal in a Moulinex kettle in a washing machine
IT> Samsung using calgon.
And what do you mean by this?

PS> Yes, I have nothing against pkunzip... I just don’t want projects
PS> to die, so to speak, “in the bud”...

I doubt that Tigrr will touch the writing of pkzip. Now he's got a job, his Pentagon isn't fussing again, but the offtopic is fussing...
I think the best thing you can do is to give the source codes for free
distribution.

IT> I forgot multitasking just in case.

I really forgot - while reading a floppy disk, about 30%
of the time
the processor is free. 400ms reads two sides of the track and then waits 200ms for
the heads to move
and for the desired sector to appear (which will not be earlier than 200ms,
if the disk
is not formatted with a sector offset).

12 Dec 01 00:35, Pawel Semenow wrote to Kirill Frolov:

KF>> Write something yourself.
PS> What?

zip

PS> There’s no point in provoking...

hmm... but if I say, information about the carefree existence of
hippos in South Africa provokes me to trip up old ladies in
public transport, will you believe me? ;)))

PS> I didn’t understand what exactly of my words offended you. Explain, plz...

probably a willingness to swear for a private opinion...

"PS>(Actually, I wanted to call it something else, but I don’t like swearing..)."

but in general, the incident is over ;) Continuation of DirSys and PkUnZip - rules. You turned out to be kinder than you seemed, peace-work-may and never mind ;)))

Pawel, Paka! WbW, i┌i└/4D.

IT>> died, oddly enough, although this is the first thing that came to hand.
PS> Now let's talk about who has more files where...
Come on. Your option:

Bye, Pawel! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

SU> CD with music? After all, the disk turns out to be not completely full, if
SU> you follow your logic. I, of course, understand that not everyone needs these
SU> directories in TR-DOS, but *personally* they do, and judging by the
SU> numerous reviews in the soap, I’m not the only one.
DN>> By the way, here’s a bright idea, and I proposed it when the development of RC2.0 was just beginning
DN>>: create with Pavel a directory plugin for
DN>> RC2.0,
SU> Pavel wanted to come up with his own standard, he didn’t like mine, but he didn’t do his own anyway - according to him, there wasn’t enough memory...

Let me clarify - there wasn’t enough memory in version 1.9x and not RAM, but ROM 16k for
rom-version or for installation in 16k Shadow RAM.

DN>> it will be an order of magnitude more convenient and will instantly begin to develop.
DN>> IMHO.

KF> 1. Information about the placement of files in directories can be
KF> ruined by anything. (both through various manipulations of the
KF> directory of the disk, and overwriting service sectors)

I somehow wanted to make my own standard directories in Real Commander,
in the system sector of the TR-DOS disk there is a ton of free space,
we only need 128 bytes, one byte per file, each byte will
indicate to which directory the corresponding
file in the directory belongs. The directory will be specified, for example, by a zero-length file
with the DIR extension (the directory can also refer to some
directory). You can make sure that files written to disk
by other programs end up in the desired directory. That was the
idea, the advantages over DirSys are that it does not require
additional space on the disk and in the commander's memory, the probability
of damage to directories can be compared with the probability of damage to the directory itself.
The disadvantages are the same as those of DirSys, when compacting a disk with a program
that does not support a directory, the entire system will be disrupted. To exclude
such a possibility, you would also have to store the CRC of file names.

KF> 2. It is impossible to export it without using your
KF> commander. (when copying files, including to hobeta/scl, when
KF> transferring via modem...)

How do you imagine exporting directories toformats
that never supported them? Even if the directory system
is stored in a file, it will still be possible to transfer
only the entire directory system of a specific disk.

KF> 3. There is no possibility for expansion (I would really like to have
KF> file creation and modification time, support for long >64kb files
KF> distributed in several tr-dos files).

Real Commander supports long files anyway ;). The file
can occupy at least all the free disk space. Remember
Spectrofon in which there were not a bunch of files of 255 sectors, but two,
the first boot was a couple of sectors in size and the second was 1800 sectors in size,
then came the application files. In order for RC to work with files
of such length, you must enable "File size from: Calc.". True
this system collapses just as easily as DirSys when compacted
by another commander that does not support this feature (besides RC
only Conver Commander supports long files).

You can figure out how to make long file names and creation times,
but they will certainly require creating a system file for themselves.

KF> What prevents you from storing information about directories in a file? The fact that
KF> the disk capacity will decrease by 2% per kilobyte, and the number of stored files
KF> by 1%?

This is of course not significant, but no one is being forced
if you want to use it,like it or not. And in RC, I also think that all these bells and whistles should be in the form of external modules, otherwise problems may arise again with placement in rom. For now, you can
use RCGEN to generate a rom with one of the modules -
TView, Doctor, PT3Play, and there is still some space left.

YP> What is it? Thank you very much :)
How about this :)

Bye, Yuri! >>.. tigr...@mail.ru >>.. http://brainwave.dax.ru

YP> why? There is also a tape recorder :)

There is BASIC. And it can even load from a CD, unlike all sorts of tr-dos.

PK> This, of course, is not significant, but no one is forced to use it
PK> whether you want to use it or not. And in RC, I also think that all these
PK> bells and whistles should be in the form of external modules, otherwise problems may arise again
PK> with placement in rom. Now it is possible
PK> using RCGEN to generate rom with one of the modules -
PK> TView, Doctor, PT3Play, and there is still some space left.
why not use 2 banks of rom for RC+Modules?

JseveN from the 4th Dimension...

KF>>>> Yes. You can unpack it onto different disks.
YP>>> you can... but why the hell is it necessary?
KF>> So that later you can understand which file from the archive
KF>> belongs to what.

KF> There is BASIC. And it can even load from a CD, unlike any
KF> tr-dos there.
Come on, educate the public. And how is it that we wandered in the dark for so many years and couldn’t play a CD.

Sincerely, Oleg. [ZX]

OG> Come on, educate the public. And how come we wandered in the dark
OG> for so many years and couldn’t play a CD.
Read the press, sir! Miracle #3, for example. And in general, it seems like there was a branded set-top box for connecting a CD (something with a Kempston port) - mentioned in some ZX News and the latest Insanity. In short, one CD ROM will replace you with
70 minutes of cassette and no Tape loading errors.

JseveN from the 4th Dimension...

Somehow Sunday December 16, 2001 at 21:28:38, Kirill and Yuri were arguing about the topic
PKZIP archive

KF>>> So that later you could understand which file from the archive
KF>>> to

OG>> they wandered in the dark and couldn’t play the CD.
VK> read the press, sir! Miracle #3, for example. And in general, it seems like there was a
VK> branded
VK> set-top box for connecting a CD (something with a Kempston port) -
VK> is mentioned in some ZX News and the latest Insanity. In short
VK> one CD ROM will replace you with 70 minutes of cassette and no Tape loading
VK> errors.
It’s like using the fourth stump to play minesweeper ;)

Sincerely, BopoH.",0
Ld Hl,10072: Ld Sp,(23613): Exx: Ret

Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]

DN> It is necessary to always keep at hand (if not in the drive) the system
DN> disk

There is a lot of page memory.

KF>> Swap to disk.
DN> It is imperative to back up a junk file on the disk using this
DN> swap, making sure that the disk is not accidentally replaced inadvertently.
And if the user accidentally loses power will it turn off or press RESET?

KF>> Dynamic memory allocation.
DN> Doesn’t particularly solve the problem, although by the way
DN> is used quite successfully.

How?

PK> What?
usually a 64kb ROM:
0 bank - all sorts of crap (all sorts of tests for pros...)
1 bank - trdos
2 bank - basic128
3 bank - basic48
Accordingly, you can use banks 0 and 2 instead. The only problem is
that the computer starts from bank 0 and when leaving it (as well as from trdos) it can no longer be enabled. Instead of 128bas, it is better to flash RC, then if the program goes to
128bas, then RC will always start, and if the user presses reset, then
the modules will first be written to the banks and only then jp 0 will work in the 1st bank.
By the way, Shalaev has support for user rom, but I
didn’t understand how to start from it - apparently only modules can access it.

JseveN from the 4th Dimension...

Somehow Sunday December 9, 2001 at 10:47:54 lil
Pawel Semenow to Igor Turashev on the topic of PKZIP archive

AK>>> And long names imho are not needed.
PS> And what prevents them from being supported? Or is it too complicated?
By and large, nothing interferes, you can make their support at the
commander level and not change anything at all in DirSys.
Are long names really needed?

Alexandr

[ZX]

Somehow Sunday December 9, 2001 at 11:01:28 lil
Pawel Semenow to Stanislav Udin on the topic PKZIP archive

IT>>> which I may not like yet. I still agree with
IT>>> RC, but with everything else...
SU>> Well, that means you really don’t need the system...
PS> He doesn’t need it. AND I NEED IT, I NEED IT!!! People, this is cool!
PS> The first time I saw trdn, I realized that Real
PS> is a commander (I have nothing against RC. On the contrary, he rules)
PS> was not lying around... Your program is JUST SUPER! And if
PS> we also made support for 512x192... THAT in general...
Thanks for the support.
As for 512*192, the main problem is lack of memory, although it can be solved. This
mode is implemented on my Pentagon, and I use KAI.

Alexandr

[ZX]

Somehow Tuesday December 11, 2001 at 02:28:48 soap
Kirill Frolov to Igor Turashev on the topic of PKZIP archive

AK>>> Why not DirSys become a standard?
IT>> Why are there directories in trdos at all?

KF> Overlays. Swap to disk. Dynamic allocation
KF> of memory.
Swap to disk is available on a screw or on a RAM. And even then not always. And with a floppy disk it will be slow.

Alexandr

[ZX]

VK>>> why not use 2 banks of rom for RC+Modules?
PK>> Which ones?
VK> usually costs 64kb ROM:
VK> 0 bank - all sorts of garbage (all sorts of tests for pros...)
VK> 1 bank - trdos
VK> 2 bank - basic128
VK> 3 bank - basic48
VK>, respectively, you can use banks 0 and 2 instead. The only problem with
VK> is that the computer starts from bank 0 and when leaving it (as well as from
VK> trdos) it can no longer be turned on. Instead of 128bas, it is better to flash RC,
VK> then if the program goes to 128bas, then RC will always start, and
VK> if the user presses reset, then the modules will first be written to the banks and
VK> only then jp 0 will work in 1 bank.

I passed ;)

PK> I gave up ;)
Well, I don’t know then...
Until recently, I used rc1.97, since I sewed it up a couple of years ago,
then I learned how to sew flash (people, maybe someone needs it?) and decided to switch to a more
modern version: 1.96 or 2.1. The following arguments were considered:
Firstly, on account of $2 - this is not a problem at all, we can send more,
it’s just breaking (not only me...) to go to the post office and delve into their problems with
translation. Secondly, and this is the most important thing, RC2.x does not have a text viewer and a disk doctor, which easily fit into the same jar (and even with the Mouzon player) along with RC1.96. I won’t complain about the bloat of the code, etc. - it’s not my
business;), and probably the right too.
In short, you need RC2.x with at least a doctor and a viewer hardwired into the pocket
(I suggested one of the options above), before that you will have to use the previous
version.

PS: this is not an ultimatum;), so please don’t spit and shout: “Nobody
needs anything” and give up on the project.

JseveN from the 4th Dimension...

AK> Swap to disk is relevant on a screw or on a RAM. And even then not always. And with an
AK> floppy disk it will be slow.

It’s time for everyone to install screws, like they once installed disk drives.

AK> Wrong. TR-DOS doesn't owe anyone anything.
AK> On Spec, 99% of the software is for TR-DOS, do you offer it to be thrown into the trash?

Yes. You need a normal axis and a TR-DOS emulator in it.
The PC also once had 99% of software for MS-DOS, and where is this DOS now?

On Monday December 24, 2001 Alexandr Khavzin wrote to Kirill Frolov:

AK> Here it is 99% successful - that TR-DOS, it doesn't matter what it is - that помойку?
It's okay. Thanks for reading.

Bye, Alexandr! >>.. tigr...@mail.ru >>..

From Vadim Chumachenko → To All 29 December 2001