Designing a new Finder

[OS923]

Here's the prototype:

Code: [Select]

#define DESKHOOK (*(void (**)())(0xA6C))But what does it mean?

[nanopico]

It looks like a call to get a handle to an A trap system call.

[ProfileName]

This is an interesting project. Curiosity:
What program do you use to create this app?
You mention the features of your app, what is the main idea?
Here's my suggestion: NextFinder

[OS923]

I write it with CodeWarrior Pro 5.3 without PowerPlant.
The main idea is that the old Mac OS was designed in a time that memory was very expensive, so they sacrificed speed for memory.
I want to sacrifice memory for speed.
I also want to solve some technical problems like long Unicode filenames.
For example, if you have a long filename, then it will be displayed like "abc#A14.txt".
The number A14 will change when you copy the file to a different volume, which is hilarious.
This may also change the order of the files, which can cause problems if you want to compare files and folders.
So if you copy files with a long name, then it will warn you.
It will warn you about possible problems.
For example, if the Finder flags say that the resource is locked, but there's no resource fork, then it may not be possible to unlock the file.
There are many of these problems which my Finder will see, warn for and/or repair.
Another example: if you copy pictures from a Windows computer, then you may also copy invisible locked files with the name "Thumbs.db". These files also cause trouble on OS 9.

[OS923]

i am no a native coder but seperate threads sound logical.

otoh, from what iknow, the most speed gain could be archieved by first finding the space where to write, then write in chunks as big as possible. that is about what OSX does...

I tried it and it works well for large files, but not for small files.
Synchronous IO with large files and large blocks was 3x faster than Finder.
Synchronous IO with small files and large blocks was slower than Finder.
Asynchronous IO with large files and large blocks was 1.5x faster than Finder.
See the results here:
http://os923.gangstalkingwiki.com/DesignNewFinder.htm

I also improved the WDEF.
As you can see, I can use Windows Unicode fonts.
(Noto was converted to Mac TrueType.)

[OS923]

FastCopy has the solution:
https://ipmsg.org/tools/fastcopy.html.en

It automatically selects different methods according to whether Source and DestDir are in the same or different HDD(or SSD).

• Diff HDD: Reading and writing are processed respectively in parallel by separate threads.
• Same HDD: Reading is processed until the big buffer fills. When the big buffer is filled, writing is started and processed in bulk.

Reading/Writing are processed with no OS cache, as such other applications do not become slow.

And... it's open source.

[IIO]

I tried it and it works well for large files, but not for small files.

you could get the file length first and when the file is longer then 20 mb you use method B.

[OS923]

For example, if the Finder flags say that the resource is locked, but there's no resource fork, then it may not be possible to unlock the file.
There are many of these problems which my Finder will see, warn for and/or repair.
Another example: if you copy pictures from a Windows computer, then you may also copy invisible locked files with the name "Thumbs.db". These files also cause trouble on OS 9.

That's not accurate.
Thumbs.db files are invisible, but not locked.
But I have experienced trouble with invisible locked files.
I think they were icon files.
The problem with locked files that couldn't be unlocked occurred like this:
the "Has been inited" flag is set but there's no resource fork.

[OS923]

I wrote a program which can copy asynchronously between 2 disks, where write can get behind on read. In debug it can get behind and then there's a marginal benefit. In release it doesn’t get behind because the reads and writes are perfectly alternating so there’s no benefit.

Thus the FastCopy solution which is fast on Windows won't be fast on a Macintosh.

Then the solution is probably: copy small files asynchronously with blocks of 16 K and copy large files synchronously with blocks of 64 MB. Now the question is: what is small?

I tried a HD with a buffer of 2 MB and one with 8 MB. The second was 20% faster.

Is here someone who uses OS 9 with a HD with a buffer of 16 MB? How fast is it? Can you measure that with the hard disk toolkit?

[IIO]

in a realtime situation you might use the HD´s buffer for more than one task at a time.

btw, copying many files at once compared to one by one is slightly faster on mavericks, about the same speed on 10.4.11 but much slower on OS9.

i even managed to chrash the OS9 finder sometimes with folders of 3000+ files, with both, copying and unstuffing.

[OS923]

That type of crash is prevented by my "Flush within a second" extension.

[IIO]

The problem with locked files that couldn't be unlocked occurred like this:
the "Has been inited" flag is set but there's no resource fork.

why should this cause trouble?

[OS923]

What I do not understand is the point 4 of your aims: " Trashed files will not automatically be renamed, so you can put them back exactly like they were." When does the orioginal Finder rename trashed fies??

It doesn't, but Sherlock 2 does and in my program Finder and Sherlock 2 will be one and the same program.
Some of my tools will be integrated too, like calculating CRC's.

That's not accurate.
I mean if you move several files with the same name to the trash, then Finder will refuse, but if you try this with Sherlock 2 then it will rename them.
If you move a file to the trash with the Finder, but there's something in the trash with the same name then that item will be renamed.
So it's not the trashed item which is renamed, but the older item with the same name.

[OS923]

Now that I know how Finder uses AppleScript I decided that the new Finder will support only open app, open doc and quit.

You will be able to install your own plugins in the new Finder, for example if you want something else than list view and icon view.

The things that are usually done by FKEYs, contextual menu extensions, scripting additions, control strip modules or even extensions should be done by plugins in PPC code.

I had also these ideas:

• sending an Apple event which contains a complete script to the new Finder is much faster than sending numerous Apple events which contain one command.
• merge DrScheme into the new Finder.

[OS923]

It's possible to replace AppleScript with Scheme if the new Finder and a Scheme extension are linked to the same shared library with a shared data section. Then you can write scripts for Finder that work at the speed of a C program instead of the speed of AppleScript.

Then there's one major problem left: drawing on the desktop.

[OS923]

I wrote an extension to find out how Finder draws on the desktop.
It covers the desktop with a window which doesn't draw a white background.
It's a 'normal' window.
That's why Finder comes to the foreground when you click in the desktop.
First it draws the background pattern, then it draws icons in its special window, which are painted on the background pattern.
That's why it's a bit flashy.
The special window is drawn between BeginUpdate and EndUpdate.
When you move an icon, then it's drawn outside BeginUpdate and EndUpdate.
When you quit Finder, then the special window continues to exist, but it's only updated when you click in the background.
When you restart Finder, then it makes a new special window.
The content of the special window matches GrayRgn.
The visRgn of the special window is GrayRgn - the sum of the other windows, regardless of the window order.
So if I make my own special window, then the content of Finder's special window will be the empty region and it will draw nothing.
Then the 2 Finders can be running at the same time.
Just a theory.
I didn't try it yet.

[Protools5LEGuy]

Better Finder
Die Hard Finder
Dream Finder
Ersatz Finder
Finder King
Finder Not Dead
Finder to the max
Finder255
Long Unicode Finder
Real Finder
Surrogate
Undead Finder

I'm in favor of "Long Unicode Finder" because it describes best what it does.

What about "Findr" instead of anything longer? I think most of us are interested in displaying more options, gaining some space loosing the "e" from "Finder". "Find" could be fine too, but "Findr" seem easy to recognize versus Apple's Finder and MacTron´s Finder

[OS923]

At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

[MacTron]

... and MacTron´s Finder

¿?
 

[IIO]

At this moment it's called UniFinder because this is practical.
All Unicode classes start with Uni (UniString, UniWDEF and so on).

like