@sis65 NO NEED to apologize as I understand completely abt it being confusing as sometimes it is confusing for me to post a problem–it is also confusing for most of us as we’ve never experienced this–so it’s hard for us to wrap our heads around what is going on.
I used FTM for many years and don’t know abt now as I left almost 8 yrs ago but back then you could open a gedcom as a temp file and as a permanent file. As for your gedcom and your Ancestry file in RM, they can coexist in RM but NOT as a gedcom versus database file especially if they have the same name- what happens when you open a gedcom is that RM turns it into a database file-- so when you hit save
and the gedcom and ancestry have the same name , it saves it to the ancestry file.
So if you want the gedcom file and the Ancestry file both then slightly change the name of database made by the gedcom such as add ged to the name and you will now have 2 database files both saved in the same place–if you still want to keep the original gedcom ( just in case), either figure out where it is saved or move it to where you want it saved
For now I’ll stick with the ancestry file and see how that goes. Hopefully I’ve got it figured out with all of you helping me out! I really appreciate it!
RM isn’t ported to anything. Porting means that Windows code is rewritten and compiled to run on a Mac. That is not the way things are done any more, and haven’t been done for a long time now. Now days the code is written once and compiled to the target platform. There is an allowance for platform specific code to be added to the codebase which is only used when compiling to the the specific platform. By platform specific code, I mean things like checking memory and other platform specific housekeeping, not the entire codebase.
Cross-platform virtualization Since the software runs on a virtualized equivalent of the original computer, it does not require recompilation or porting, thus saving time and development resources. However, the processing overhead of binary translation and call mapping imposes a performance penalty, when compared to natively-compiled software. For this reason, cross-platform virtualization may be used as a temporary solution until resources are available to port the software. Alternatively, cross-platform virtualization may be used to support legacy code, which running on a newer and faster machine still maintains adequate performance even with virtualization overhead.
I believe that what Rooty means, but has not expressed clearly is that RootsMagic (8-10) isn’t compiled to run natively on an ‘M’ Series (ARM64/aarch64) Mac and that is correct. ‘M’ Series Macs identify RootsMagic (8-10) as an Intel (not Windows) application and therefore has to use its ‘software translation’ capability each time software starts so that it can run on the ARM64 hardware platform.
Most current macOS software is now released as either:
‘Universal’ applications, where the installer contains both native Intel and ARM64 code and adapts to run natively (without requiring translation) on whichever hardware platform it is installed on (Legacy Intel or ARM64); or
separate platform specific installers for ‘Intel’ and ‘Apple Silicon’ Macs
At present RootsMagic for Mac is only provided as an ‘Intel’ application, so remains dependent on Apple’s ARM translation capability to run on the ARM64 platform. The same dilemma will increasingly impact in the Windows world if the ARM64 (Qualcomm Snapdragon) and Windows for ARM platform continues to gain a firm foothold in the market.
Intel only code is part of the problem but easy to resolve if RM does what all other mac programs have by now. RM also ignores many mac OS conventions and scatters folders with .xml files around. I am impressed that it is able to bypass what I thought were required behaviors.
Windows users can certainly expect Microsoft and others to switch to the superior AMD style chips and coding to achieve performance comparable to M series chips. Intel is so far behind it does not seem reasonable that they can catch up.
