Re: Objective-C selector names in disassembly

[Martin Wierschin via Cocoa-dev]

I'm running my app's project in Xcode as normal, so that's a debug version. But 
I'm interested in selector names for system frameworks, which are naturally 
final release versions that are part of macOS.

~Martin

> On Apr 3, 2022, at 3:24 PM, Alex Zavatone  wrote:
> 
> Yes.  Are you disassembling a release version or a debug version?
> 
>> On Apr 3, 2022, at 2:36 PM, Martin Wierschin via Cocoa-dev 
>>  wrote:
>> 
>> Hi everyone,
>> 
>> I have a question that's been an irritating me for a long time. Is there any 
>> way to get Xcode (or other tools) to show Objective-C selector names in 
>> disassembled framework's code?
>> 
>> Back in the good old days viewing assembly for any Obj-C method in Xcode 
>> would automatically give you this information. Xcode would always show you 
>> each selector's name (as a C string) alongside the SEL value in the assembly 
>> listing, usually right before each call to objc_msgSend. This was incredibly 
>> useful when you had to workaround Apple bugs, or just to poke around to see 
>> how things were implemented.
>> 
>> I forget when this changed. I know it was triggered by optimizations to the 
>> Obj-C runtime. But not being able to see selector names is like being 
>> blindfolded. Is there a good way to discover this information in the modern 
>> runtime / toolchains?
>> 
>> Thanks for any tips!
>> 
>> ~Martin Wierschin 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Objective-C selector names in disassembly

[Martin Wierschin via Cocoa-dev]

Thank you for the suggestion. It looks like Hopper does display selector names 
correctly. 

Initially I was confused as to what I should have Hopper load. It looks like 
framework bundles (e.g. AppKit) don't have a binary file on disk like in former 
times. This post help explain things:

https://mjtsai.com/blog/2020/06/26/reverse-engineering-macos-11-0/ 
<https://mjtsai.com/blog/2020/06/26/reverse-engineering-macos-11-0/>

I pointed Hopper at the dyld shared cache, which seems to lump in all 
frameworks now, and the info I needed was parsed out. It's a shame Xcode can't 
bother to do this during debugging. Oh well.

Thanks again!

~Martin Wierschin

> On Apr 3, 2022, at 1:55 PM, dev.iceberg  wrote:
> 
> Hopper Disassembler ?
> 
> Envoyé de mon iPhone
> 
>> Le 3 avr. 2022 à 21:36, Martin Wierschin via Cocoa-dev 
>>  a écrit :
>> 
>> Hi everyone,
>> 
>> I have a question that's been an irritating me for a long time. Is there any 
>> way to get Xcode (or other tools) to show Objective-C selector names in 
>> disassembled framework's code?
>> 
>> Back in the good old days viewing assembly for any Obj-C method in Xcode 
>> would automatically give you this information. Xcode would always show you 
>> each selector's name (as a C string) alongside the SEL value in the assembly 
>> listing, usually right before each call to objc_msgSend. This was incredibly 
>> useful when you had to workaround Apple bugs, or just to poke around to see 
>> how things were implemented.
>> 
>> I forget when this changed. I know it was triggered by optimizations to the 
>> Obj-C runtime. But not being able to see selector names is like being 
>> blindfolded. Is there a good way to discover this information in the modern 
>> runtime / toolchains?
>> 
>> Thanks for any tips!
>> 
>> ~Martin Wierschin 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Objective-C selector names in disassembly

[Martin Wierschin via Cocoa-dev]

Hi everyone,

I have a question that's been an irritating me for a long time. Is there any 
way to get Xcode (or other tools) to show Objective-C selector names in 
disassembled framework's code?

Back in the good old days viewing assembly for any Obj-C method in Xcode would 
automatically give you this information. Xcode would always show you each 
selector's name (as a C string) alongside the SEL value in the assembly 
listing, usually right before each call to objc_msgSend. This was incredibly 
useful when you had to workaround Apple bugs, or just to poke around to see how 
things were implemented.

I forget when this changed. I know it was triggered by optimizations to the 
Obj-C runtime. But not being able to see selector names is like being 
blindfolded. Is there a good way to discover this information in the modern 
runtime / toolchains?

Thanks for any tips!

~Martin Wierschin 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Several different NSUserDefaults in the same app?

[Martin Wierschin via Cocoa-dev]

This topic of default defaults (aka initial, hardcoded, or fallback values) 
came up recently on this developer blog:

https://mjtsai.com/blog/2021/04/02/foil-userdefaults-property-wrapper/ 


I've always used this same approach in my own code. You can extend 
NSUserDefaults to add methods that provide a fallback value without first 
registering the values separately via a plist file.

~Martin Wierschin

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught in try statement

[Martin Wierschin via Cocoa-dev]

Breaking the RTFD loading process down into subtasks is a good idea. It might 
be worth trying to sidestep the issue using NSAttributedString. You can try 
loading the data yourself as Mike suggested and then use initWithRTFD or 
initWithRTFDFileWrapper. Once you have the text in an attributed string you can 
swap its content into your NSTextView/NSTextStorage using 
-replaceCharactersInRange:withAttributedString:

However, I suspect the problem will remain. The exception is coming from 
Apple's internal NSRTFReader class, which we can be reasonably certain is 
utilized by all RTF/RTFD loading code paths. To really fix this you're probably 
going to be stuck with ugly code that either:

1. Preprocess the RTFD to remove the data that Apple's code can't handle, eg: 
strip tab stops as someone else suggested.
2. Use method swizzling to patch Apple's buggy methods at runtime, eg: replace 
-[NSRTFReader defaultParagraphStyle] to avert the conditions that lead to the 
exception, before it gets thrown in the first place.

One other potential debugging aid: NSExceptionHandler. You can register your 
own handler, perhaps in a way that prevents AppKit from killing your app 
outright when an exception occurs (this used to be possible but I don't know 
the current behavior). But as Mike said, this isn't a real solution for 
shipping software. Generally speaking once an app has thrown an exception its 
state can't be relied upon. So you should only use this for testing to gather 
additional debug information.

~Martin Wierschin

> On Mar 26, 2021, at 11:22 AM, Mike Abdullah via Cocoa-dev 
>  wrote:
> 
> This does seem quite surprising. However, here’s the thing: this code is very 
> strange approach to take.
> 
> Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism 
> except where explicitly stated and supported. You’re trying to use them, 
> which is asking for trouble. The system doesn’t guarantee proper handling of 
> memory if an exception does throw.
> 
> Number 2: Your error handling approach is back-to-front. You’re trying an 
> operation, seeing if it fails, then attempting to guess from the current 
> state (which might have changed in the meantime) why it might have failed.
> 
> Instead, use the proper error APIs and approach:
> 
> 1. Load the data from disk, e.g. +[NSData 
> dataWithContentsOfURL:options:error:]
> 
> If that fails you can introspect the error to your heart’s content to find 
> out what went wrong
> 
> 2. Load the data into your text view. I’m not sure if there’s an API to do 
> that in a single step or not, dunno.
> 
> I also note that your code explicitly is trying to read an RTFD which if 
> memory serves can be a document *bundle* format, so perhaps at step 1 you’d 
> have to go with a file wrapper. But the path you specify is .rtf so I’m 
> guessing you really do have a basic file and can load it as data.
> 
> Mike.
> 
>> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev 
>>  wrote:
>> 
>> Hi folks,
>> 
>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>> to gain additional diagnostics from a user, I wrapped the affected line in a 
>> try/catch block.  For two users it resolve the crash, but for a third, it's 
>> still crashing at the same point!
>> 
>> The crash occurs when a user attempts to open the "About" window from my 
>> app's main menu item. I'm not using the standard about panel as there's a 
>> few additional items I need to display, one of which is an NSTextView which 
>> I populate with the contents of an RTF file from within the app bundle.
>> 
>> I've symbolicated the crash log to find it's happening when populating that 
>> TextView. The line in question now reads as follows:
>> 
>>  @try {
>>  [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]];
>>  } @catch (NSException *exception) {
>>  NSLog(@"Error loading the contents of the text file for the 
>> About Box. %@", exception);
>>  //Check we have a file at the expected path 
>>  if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>>  NSLog(@"Yes. Found the RTF credits file");
>>  // check the attributes in case somehow there's no 
>> permission to read the file
>>  NSDictionary *fileAttributes = [[NSFileManager 
>> defaultManager] attributesOfItemAtPath:[[NSBundle mainBundle] 
>> pathForResource:@"Credits" ofType:@"rtf"] error:nil];
>>  NSLog(@"RTF file has following attributes %@", 
>> fileAttributes);
>>  }
>>  else {
>>  NSLog(@"Nope, file not found");
>>  }
>>  }
>> 
>> This is the crash log from the newest build (with the try/catch around that 
>> line):
>> 
>>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540

Re: Cocoa dylib access by C program

[Martin Wierschin via Cocoa-dev]

A nice way to do this is to have a bridge header file that only declares C 
functions. The corresponding .m source code file will have C functions that 
natively call Objective-C methods. This same header can be included in .c files 
without any trouble, letting them have access to Obj-C code via the bridge's C 
functions.

Basically structure your files something like this:

 MyBridge.h
extern void DoObjectiveCStuff();

 MyBridge.m
#import 

void DoObjectiveCStuff()
{
NSLog(@"Hooray, calling Obj-C methods...");
[NSArray arrayWithCapacity:32];
}

 pure.c
#include "MyBridge.h"

void RegularFunction()
{
DoObjectiveCStuff();
}

I hope that helps!

~Martin Wierschin


> On Nov 13, 2020, at 11:16 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I have built an ObjC/Cocoa/Foundation library.dylib; it works well when 
> linked with ObjC apps. 
> 
> But now I need to link a C program against that library. How do I invoke the 
> ObjC library methods from a C program? (I know I can add C function entry 
> points to the library, but how do they invoke the internal ObjC library 
> methods?)
> 
> -Carl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSView draws unwanted "seams" for certain zoom factors

[Martin Wierschin via Cocoa-dev]

I have a large custom NSView subclass that's set as an NSScrollView's 
documentView. This view achieves zooming in the standard AppKit way, by having 
a zoom factor between the frame and bounds sizes, eg: frame.size.width = 
bounds.size.width * 2.0. This has worked just fine for years.

The problem is that on modern versions of macOS, for certain zoom factors, 
there are "seams" that show up during drawing. The seams are fine lines that 
show some view's background color (or stale content from a prior drawing pass). 
The seams are always aligned in neat rectangular patterns, which tipped me off 
that macOS is doing some kind of tiling.

After poking around I see that my view is assigned a CALayer, despite never 
opting-in via setWantsLayer or anything like that. This implicit layer backing 
seems to be expected on current versions of macOS, but it's definitely the 
cause of my problem. I can see that my view is assigned a layer like:

_NSViewBackingLayer → sublayers: _NSTiledLayer

If I increase the tileSize property of this automatically generated layer (eg: 
from 512x512 to 2048x2048), I can decrease the visual frequency of the problem. 
But this is naturally a hack, and not a complete solution. The seams still 
occur, just less often.

Can I somehow opt my view out of implicit layer backing? Is there a modern way 
to implement zoom now that everything is using layers? Thanks for any help!

~Martin Wierschin

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Localization under Catalina

[Martin Wierschin via Cocoa-dev]

> Auto layout (not auto-resizing) is independent of localization.  You don’t 
> need to switch to auto layout to support Base localization

It's true that autolayout has many benefits aside from localization. But I'd 
say it's only partially true that you can switch to Base.lproj for localization 
without converting to autolayout. 

Without autolayout the translated text from your strings files probably won't 
look very good injected into your Base UI. You might be able to finagle it if 
you use certain control placements, or make your controls really wide so longer 
translated text doesn't overlap adjacent controls and that kind of thing, but 
it's going to be awkward and finicky. Autolayout is really the key to making a 
single set of source xibs from Base.lproj work for all localizations.

~Martin Wierschin
Nisus Software / Developer
Solana Beach ☀️ California

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Localization under Catalina

[Martin Wierschin via Cocoa-dev]

I remember AppleGlot. I also remember how terrible it was, at least way back 
when it was first around. In the intervening years I preferred loc-suite. As 
Georg said, it's a very good tool. But all that's obsolete now.

You ultimately should convert your nibs to Base.lproj. The current Xcode 
localization process is way better than the bad old days where you had to keep 
endless translated nibs in sync. The conversion job is a good amount of busy 
work, and autolayout may give you pain initially, but ultimately using 
Base.lproj + autolayout + translated .strings files is much cleaner.

~Martin Wierschin
Nisus Software / Developer
Solana Beach ☀️ California

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [OT] NSTimer +timerWithTimeInterval:

[Martin Wierschin via Cocoa-dev]

Sandor is correct. Using "new" in a method name is not forbidden. That method 
just has to return an object with a +1 retain count. The relevant docs are here:

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994-BAJHFBGH
 


The static analyzer in Xcode will detect any methods that fail to follow these 
rules– at least, most of the time.

The "newData" selector name used for Carl's timer callback won't cause any 
problems. That method doesn't return an object, so calling code can't leak or 
overrelease any objects because the memory management conventions were 
disregarded. The static analyzer ignores this method because there's no return 
value to misuse.

Even if the timer's callback selector were expected to return an object with a 
neutral retain count (eg: an autoreleased object), the timer implementation 
wouldn't figure out that you'd incorrectly given it a selector whose name 
includes "new". There's no runtime introspection that would change the behavior 
of the timer; the naming conventions ensure properly balanced retains/releases 
during compilation. At runtime the timer would happily call your method and 
simply fail to release the return value. If you wrote your "new" method 
properly to return a +1 retain count object you'd have a leak, not a crash or 
change in timer behavior. If you wrote your "new" method incorrectly and 
returned an autoreleased object there would be no leaks or runtime 
implications, at least not from the timer's side of things.

All that said, the "newData" method name is best changed so as not to confuse 
anyone who does know the correct naming conventions.

~Martin Wierschin


> On Apr 29, 2020, at 3:55 PM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> Sandor, it’s somewhere in the naming guide for the Objectice-C fundamental 
> docs.  I could be confusing things though.
> 
>> On Apr 29, 2020, at 5:27 PM, Sandor Szatmari  
>> wrote:
>> 
>> Alex,
>> 
>>> On Apr 29, 2020, at 17:12, Alex Zavatone via Cocoa-dev 
>>>  wrote:
>>> 
>>> Not sure about this, but in Objective-C, you’re not supposed to start 
>>> methods with new.
>> 
>> I’ve always operated under the premise that using a reserved prefix, such as 
>> new, was not verboten.  Rather, if one chose the prefix new one must ensure 
>> that the method followed memory management conventions, and would return an 
>> object with a +1 retain count.  Am I mistaken about this?
>> 
>> Sandor
>> 
>>> 
> On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
>>> NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0  // should be 
>>> 1/sec



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What is the preferred way to set NSTextView content from NSAttributedString?

[Martin Wierschin via Cocoa-dev]

Yes, working through the NSTextStorage is the way to go. To replace its entire 
contents you can use -replaceCharactersInRange:withAttributedString: 

 with a range that encompasses all current text.

You should not need to manually call -setNeedsDisplay: on the NSTextView as was 
suggested earlier. If you're working with the right NSTextStorage then its view 
should observe the changes and automatically mark any redisplay as needed.

~Martin Wierschin


> On Feb 02, 2020, at 3:01 PM, Jonathan Prescott via Cocoa-dev 
>  wrote:
> 
> Looking at the documentation for NSTextView, it is highly recommended that 
> you manipulate the NSTextStorage associated with the view.  NSTextStorage is 
> a sub-class of NSMutableAttributedtString, so you have all of those 
> capabilities as well.
> 
> I’m just getting into this as well for my console application related to my 
> expert system interface.
> 
> Jonathan
> 
>> On Feb 2, 2020, at 3:37 PM, Jeff Younker  wrote:
>> 
>> Yes, I've set needsDisplay = true in my attempts to so far. Also needsLayout 
>> = true.
>> 
>> The question I've got though is what is the recommended way of setting the 
>> value to T2. There is no attributedString variable, just an accessor method, 
>> so I've been trying a variety of insert methods.
>> 
>> -jeff
>> 
>> On Sun, Feb 2, 2020 at 12:19 PM Jonathan Prescott > > wrote:
>> Did you tell V that it needs to re-load it’s display?  There is a method on 
>> NSView (from which NSTextView is derived) called “needsDisplay(sic)” which 
>> sets a flag on the view so that the view will re-draw its content the next 
>> display cycle.  So, after you set the content to T2, you need to call 
>> “V.needsDisplay()” so that the next display cycle the view gets refreshed.  
>> Need to check the spelling of the method.
>> 
>> Jonathan
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/martin%40nisus.com
> 
> This email sent to mar...@nisus.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Difficulties with recovering NSAttributedString attachments from saved RTFD

[Martin Wierschin via Cocoa-dev]

> let savedRtfd = originalString.rtfd(from:NSRange(0.. recoveredAttachment.contents is still nil.


Your core problem is RTF/RTFD encoding. There's simply no guarantee those 
formats will preserve everything that's supported by the Apple text system, 
including NSTextAttachment data. Even features that are officially supported by 
RTF/RTFD might not be roundtripped if Apple didn't add support for it. 

A quick example: images in RTF data are discarded when loaded by 
NSAttributedString. That's despite the fact that images are completely 
supported by the RTF spec, NSTextAttachment, and even Apple's RTFD. It's just 
that Apple didn't bother with RTF.

Maybe there's another data format where Apple better handles attachment 
serialization? I don't know. But if I needed to reliably serialize all kinds of 
attachments I'd probably do it myself to be sure, since I don't recall seeing 
it mentioned explicitly.

~Martin Wierschin


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com