- FastCommander is an easy to use native Cocoa application with dual panel interface, support for all operations on files, keyboard shortcuts and themes.
- Jul 23, 2017 FastCommander is an easy-to-use native Cocoa application with a dual-pane interface, support for all file operations, keyboard shortcuts, and themes. It was created with a strong focus on user experience, a responsive utility with a clear interface. FastCommander was created with a Cocoa OS X framework, written in Objective-C.
FastCommander v1.7 Mac OS X 1.5 MB FastCommander is an easy to use native Cocoa application with dual panel interface, support for all operations on files, keyboard shortcuts and themes. Application is designed to be natural enhancement for workflow of creative users. Administrators, developers, designers and advanced users — they constantly need to handle large amounts of files each day. FastCommander Alternatives. FastCommander is described as 'Fast, lightweight, elegant file manager for Mac OS X' and is an app in the File Management category. There are more than 25 alternatives to FastCommander for a variety of platforms, including Windows, Mac, Linux, BSD and PortableApps.com.
Fastcommander Mac
Today I’ve discovered a very strange bug in my software: after using an internal viewer in Files with PkgInfo in app package, Files crashes randomly and alerting on memory corruption.Something like this:
Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)
or this:
Files(85331,0x7fff7e8cc310) malloc: *** error for object 0x600000018a70: Heap corruption detected, free list canary is damaged
*** set a breakpoint in malloc_error_break to debug
A following story is below.
It was funny, since this viewer can easily handle a gigabyte-scale files. So I blamed the last refactoring and checked previous releases. They crash too, with the same symptoms.
Ok, I started investigations.
PkgInfo is 8-bytes file with text APPL????.
Copied this file to another place (some system-level locks maybe?) and viewed it. Crash.
Renamed file. Crash.
Created another 8-byte file with content 01234567 and tried it. Crash.
Created 7-byte and 9-byte files and tried them. Worked like a charm. Hmm…
It was something definitely related with alignment logic somewhere in low-level modules.
My suspicions fall onto data analysis module, which answers the questions like “what is the likely encoding for this bulk of data?” or “is this bulk of data binary or text?”.
Turned off this module and tried 8-byte file again. Crash.
Things becoming worse since sometimes viewer crashed even before it’s logic (layout, render, navigation etc) get to work.
Desperately I start tracking everything down from the very beginning of viewer’s initialization and came to my string decoders. At least it was a place where memory can become corrupted and I’ve changed encoding to Western (Mac OS Roman) from UTF-8 to see any difference. Worked like a charm. Hmm…
A few minutes later I finally stopped on relatively old UTF-8 conversion function:
void InterpretUTF8BufferAsIndexedUniChar(
const unsigned char* _input,
size_t _input_size,
unsigned short *_output_buf, // should be at least _input_size 16b words long
uint32_t *_indexes_buf, // should be at least _input_size 32b words long
size_t *_output_sz, // size of an output
unsigned short _bad_symb // something like ‘?’ or U+FFFD
)
*_output_buf = 0;
Fast Commands On Windows 10
m_DecodeBuffer = (UniChar*) calloc(m_FileWindow->WindowSize(), sizeof(UniChar));
Fastcommander Mac