Nom, dlaczego nie chce podzielić dysku 30 MB na 15 MB APT (przecież się zmieści) i 15 MB FAT32 (przecież "da się")?

No załóżmy, w takim razie, że się da itd. (m$ nie musi się stosować do własnych doców, w rzczy samej), to dlaczego u pinokia nie chce to działać?

Nie to, żebym się czepiał, ale Pinokio ma rację.

Doce m$ stanowią, że, cytuję: "There is no such thing as a FAT32 volume that has less than 65,525 clusters." A zatem najmniejszy rozmiar dysku dla FAT32 to 65526 klastrów po 512 bajtów, czyli 31,995 MB. Jeśli użyteczny obszar dysku jest mniejszy niż te niecałe 32 MB, to po co FDISK proponuje założenie partycji FAT32?

SV2010 było w dniach 10-12 grudnia. Może to i Independence Day, tylko że nie nasz :P

No, ładne kwiatki ... :) Fajne demko. Nawet kol. bezrobotny dostał gretsy ... za SDX :P

@Pin: udało mi się to odtworzyć, nie wiem tylko, czy się coś z tym sensownego zrobi, bo tak na oko przyczyną może być za długa ścieżka dostępu. Popatrzę, może da się to jakoś obejść.

@w1k: SDX has ARC archiver built-in, so I can't see how such an archive may be difficult to unpack.

Zobacz zatem, czy to działa (bo SOA#1). Z nowości tylko aktualizacja "KB free" podczas kopiowania.

EDIT: archiwum uaktualnione (wymieniłem SC.COM).

Z tego, co widzę, nieprawdą jest, jakoby :P Żeby tak było, jak piszesz, uruchomiony program musi zrobić reset - to wyłącza 80-kolumnową konsolę.

Albo może powiedz bliżej, jakie czynności mam wykonać, żeby odtworzyć ten efekt u mnie.

SC stara się utrzymać ustawienia konsoli takie, jakie były przy pierwszym uruchomieniu.

Powinno wystarczyć, jeśli dorzucisz do niego CON.SYS.

A ty myślisz, że różne rodzaje ramek, jakie były wpisane w dystrybucyjny SC.INI, czym innym zrobiłem, jak nie ED-em? :P

Sprawdziłem na szybko, u mnie działa. Upewnij się, że plików źródłowych nie ma aby w katalogu docelowym - jeśli są, zostaną pominięte.

To chyba nie spowoduje dużej straty czasu, zobaczę.

No to już nie jest takie trywialne, bo oznacza rekursywny skan katalogu. Pomyślę.

Wszystko w swoim czasie :P

In fact, the screen redraws are nearly 2,5 times faster with S_VBXE than with RC_GR8.

Let's assume that "256" looks vaguely familiar and I can imagine where it was picked from :P The question was different: if already such a number of files per directory is to be handled, why not one more? There is no such limit in SpartaDOS, so why the user has to keep a cautious eye on not copying certain numberof files to a directory, especially if a much greater number is allowed? And if he does copy a 257th file, what then?

A file manager's purpose is to facilitate maintaining of the file system. Large directories are most difficult to handle, yet I have to deprive an user of this assistance just to amuse him with sorted directories? Well, I don't think so.

So let's assume that. But this is a scroll, so one place must be filled with new entry. This involves reading it from the disk - and not necessarily the one, which physically is immediately following the last displayed entry - then formatting it, then displaying. So, it of course will always consume more CPU time than simple cursor movement, without a scroll.

As for the scrolling speed, for starters I would suggest to compare not with the NC running on a 486, but with ICD's MENU - which, by the way, has only 10 lines to scroll, not 20.

When writing such a file manager for 8-bit compromises must be done between speed, limits imposed on the file system, and the amount of remaining free memory for operations such as copy. I choose not to impose arbitrary limits on directory length (256 files? Ok, why not 257?) and make as much memory free for copying buffer as possible. And I am not so sure that I've done this at speed compromise. Of course, with VBXE the blitter can be used to copy the screen contents (and this is planned), which will probably add some speed to the scrolling, but I suspect that it won't add as much as some of you  (Candle) might expect, because scrolling up/down the actual screen contents is not the only thing involved in the process.