I'm developing an app on a 64-bit machine with Lion and Xcode 4.2. I'm not doing anything special with the 64bit environment or lion specifically and would like this app to run on 32bit Snow Leopard machines. Can I do this? If so, what specifically do I set in the build settings?
I've looked all over the internet and cannot find a simple "yes, here's how..." or a "no, it isn't possible"
Thanks
The simple answer to the situation above: NO
Because the program was using ARC and that is limited to 64 bit releases only.
Related
We are moving from CefSharp to WebView2. Because of certain requirements, we are thinking of going ahead with the fixed version where the updates can be controlled by us. Now, on Microsoft's official distribution page we have 3 options available - x86, x64 and ARM64. We have users who use different combinations of OS and CPU architecture. One example is 32 bit Windows 10 Pro running on a 64 bit Intel processor. Here is where I am confused. Which one to ship to agents depending on their combinations of OS and CPU architecture. Can anybody help here? Here are the combinations -
I have not tried out and hence may be a blunt question - can x86 distributable be a safe bait for all these combinations? If yes, then what are the trade-offs?
I think x86 distribution is safe. If 32-bit OS is running, the entire system acts as purely 32-bit. It's impossible to use any 64-bit piece of code, so 64-bit applications won't work. You can also check this thread: If you want to run 64-bit app on 32-bit OS, you have to install a VM or something. I think that's not what you want.
In conclusion, I think you should choose the WebView2 Fixed Version according to the OS version.
I'm trying to find a solution to allow me to compile C code to a DOS executable from Windows 7 64-bit. I recently updated from XP 32-bit to Win7 64-bit, and now my Borland C++ 5.0 compiler won't work. I get an error when it tries to call tlink.exe 16-bit. I'm trying to avoid bringing over another computer with XP but that will have to be my course of action if I can't figure something else out soon.
My target is an embedded x86 running FreeDOS. As much as I'd like to transition to Linux I can't afford the time that would transition would take. Aside from the learning curve of never having used Linux, much of my code is DOS-dependent and would have to be re-written.
I'm hoping there's a windows setting I can just change but my research so far leads me to believe I need a more drastic change to my process. I've sniffed around at Turbo C 2.01, DJGPP, DOSbox... not really too confident to go down any of those alleys without some outside input
Run Virtual XP or VirtualBox and install Borland C++ inside. BTW, there is version 5.02 with some fixes (in case your version is exactly 5.0).
If you can find an old Microsoft Compiler, like 16 bit C / C++ 1.52 (which is included on the 32 bit C / C++ 4.1 cd-rom), or C 8.00 or earlier, it runs using a dos extender or in a 32 bit dos console window.
Why can't you run the Borland compiler using FreeDOS?
You could try to create a virtual machine with MSDOS on it, but you'd have to find a way to install MSDOS 6.22 on the virtual machine. At Microsoft's support site, they have links to a bootable ISO file for MSDOS 6.22. I still have the original floppies and started with those on an old system that has a floppy drive. It's a bit awkward to import / export files to / from the virtual machine.
This is the config.sys that I use that seems to work with Win 7 virtual machine. I had to increase buffers, stacks, and files to avoid a stack overflow problem with this setup.
dos=high,umb
buffers=40,0
files=60
lastdrive=e
shell=c:\command.com c:\ /e:1024 /p
stacks=64,512
switches=/f
device=c:\dos\himem.sys /numhandles:64 /testmem:off
device:c:\dos\emm683.exe ram i=b100-b7ff i=c600-c7ff i=cc00-cfff i=e600-efff frame=d000 a=32 d=128 notr
devicehigh=c:vmadd\cdrom.sys /d:mscd001
This is the autoexec.bat that I use (smartdrv is a bit pointless in this case so I commented it out with "rem" prefix) .
c:\dos\emm386 auto
lh c:\dos\mscdex.exe /d:mscd001 /m:7
rem lh c:\dos\smartdrv.exe
lh c:\vmadd\mouse.com
set path=c:\dos
set blaster=a220 i5 d1 h5 p330 t6
prompt $p$g
As for a compiler, Open Watcom seems to me to be the best choice in your situation. FrameworkPascal (written in the old version of Watcom) provides a 32 bit extender. Regarding the creation of a FreeDOS virtual machines, pickup the tools from Microsoft SysInteral. They include a tool that create a VHD. Once you get a FreeDOS running in a VM you can simply SYS the VHD and start it anywhere. There are plenty ready to run ISO images for FreeDOS, one worth mentioning is Seagate Seatools for DOS which is being distributed with the FreeDOS kernel.
Your best (but not only) solution for running all that is probably XPMode on Windows 7 Pro. It runs Windows XP 32 which of course provide 100 percent transparent compatibility via its NTVDM with DOS 16 bit real mode, 16 bits protected (Windows 3.1), and DOS 32 bit extenders.
NTVDM by the way is a feature that can be activated on Windows 10 Pro but it yet to be seen what exactly can be done with it there.
XPMode is a free downnload from Microsoft that installs a free version of Windows XP 32 bit in a virtual machine on Windows 7 Pro with full sharing of the cutpaste/copy buffer, USB, drives, screen and network card (web access). It can be toggled between a Window and full screen. The installation of XPMode is automated (after activation of the Windows 7 Pro VM). Microsoft provide various downloadable hot fixes that update the registry to activate the VM. There is an MS support downloadable hot fix that has to be run to allow the installation on the AMD Bulldozer architecture. XPMode hibernate its desktop and virtual hard drives making it a much more productive environment than a hardware based system.
With a little extra work Windows XP 32 bits can be installed on any virtual machine including Microsoft Virtual Machine on Windows XP 64 bits as well as Oracle Box and VMWare. XPMode however is probably the smoothest solution since some installations such as MS Virtual Machine for Windows XP 64 bits do not utilized the full physical display in full screen (only about 90 percent of it). If you install your browser and email in XPMode you can live in the full screen and forget about new versions of Windows.
By now all Mac App Store developers know that all apps must have the new OSX Lion Sandboxing enabled going forward. For existing apps, we must enable it in XCode 4.2 and set in place the data migration plist.
So my existing Mac App Store app has a build target of OSX 10.6.8 Snow Leopard. Not only that, but it does access the webcam and also synchronizes stuff to iCal via CalendarStore API and AppleScript. I'm expecting most of my app to break when I enable the Sandbox, but when I get that working in the Sandbox I'm wondering if a Sandboxed app can run in Snow Leopard.
Does anybody have experience in migrating to the Mac App Sandbox? I would like to know if enabling this would break Snow Leopard compatibility, and what I am up against given the entitlements my app will require.
Snow Leopard is an awesome OS and I'd like to support it as long as reasonably possible, for those users who have a Mac not quite new enough to run Lion.
After enabling entitlements and sandbox while still keeping the build target as 10.6, I was able to get my app up to speed so it operates within the sandbox in Lion. E.g. file access, calendar access, webcam access.
Once I had that taken care of, I built a .pkg file and installed it on my old Mac Mini running Snow Leopard. It seems to run in Snow Leopard just as it did before. Unlike Lion, it won't migrate your config and plist-defined folders as it seems the sandbox stuff that is compiled in is completely ignored when run under Snow Leopard (which makes sense since the Lion kernel is probably doing all the work).
So there you have it, the short answer for backwards compatibility is "Yes". Although who is to say Apple won't restrict 10.6 targeted builds from being uploaded to the Mac App Store once March 1st hits? Probably not, but it will happen eventually. I'm not trying to start a rumor or anything, it's just a thought.
Anyways, I hope Apple continues to let us support Snow Leopard users, as I imagine they are still the majority of the Mac users out there. Take this article with a grain of salt, but still...
http://www.theverge.com/2011/11/11/2554009/mac-os-x-lion-adoption-slowing
I am developing a 64 bit application. Is it possible to run the 64 bit application on a 32 bit OS?
Please note that the question is generic and not specific to Windows OS. Infact the application in itself is portable across OS.
(We'll assuming your talking about AMD64 (== EM64T == x86_64) and x86 for 64-bit and 32-bit respectively)
You can run AMD64 code on x86 processors only by emulation (e.g. qemu), or some kinds of virtualisation (I believe VMWare might support 64bit guest OS on 32bit host OS on 64
bit capable CPU). However this means running a 64-bit OS as a guest on emulation or virtualisation I believe.
As you're developing the application, it shouldn't be too hard to develop both 32-bit and 64-bit builds of your code.
For Mac you can ship a single binary that has both types of code in it, or Mac OSX can run your 64-bit binary on a 32-bit kernel (only on a x86_64 capable processor though). For Windows and Linux, you'll either have to ship separate installers, or ship some smart installer, that selects the correct binaries at install time. For Linux there is a project for add the ability to run AMD64 code on x86 kernel on AMD64 processor - http://linuxpae64.sourceforge.net/ - but it doesn't look like it's got very far into the mainline kernel.
Is there a particular reason you only want to produce 64-bit binaries?
If it's to access extra memory, then the 32-bit OS wouldn't be able to give you extra memory anyway.
If it's to avoid have to test 2 different versions, then just produce the 32-bit version, it'll work on Windows AMD64, and most Linux AMD64 distributions without problems.
On windows, only using a virtual machine.
On OS X, 64Bit apps run natively (thanks Stephen)
The other way around is fine, bit I dont think you can run a 64bit app on a 32bit OS, you may be able to using a virtual machine or some kind of virtualisation.
There's an easier solution than trying to run a 64-bit program on a 32-bit OS (including executing through an emulated or virtual 64-bit platform on top of the 32-bit OS): recompile it for the 32-bit OS.
When you said it's portable across different OSes, did you also mean non-64-bit OSes? I could not call something portable without qualifying "only 64-bit" if that was the case, and I think many (maybe even most?) programmers also expect that qualification, at least currently.
it is possible using qemu in soft emulation mode
No.
See Microsoft FAQ:
The terms 32-bit and 64-bit refer to
the way a computer's processor (also
called a CPU), handles information.
The 64-bit version of Windows handles
large amounts of random access memory
(RAM) more effectively than a 32-bit
system. For more details, go to A
description of the differences between
32-bit versions of Windows Vista and
64-bit versions of Windows Vista
online.
Understand the difference between 32-bit and 64-bit and you will see why it's not possible.
See this (assuming you're running Windows):
If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)
Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.
On Windows, no. On OS X, yes. I don't know what the state of affairs is on Linux.
In fact, Snow Leopard boots into a 32-bit kernel, but compiles applications 64-bit by default, so this is quite common on OS X.
A 64 bit application does not run on a 32 bit processor period
A 64 bit application uses a 64 bit wide register. It just plain won't fit.
I have 3rd party libraries for my mac applications which used to link nicely to my application with the previous version of Mac OS X.
I have upgraded to Snow Leopard and now g++ linker complains:
ld: warning: in /Users/paul/Projects/3rdPath/NHUI/Lib/mac32/libNHUI.a, file is not of required architecture
The link also fails to locate functions from this library.
Do I need Snow Leopard versions of each 3rd party library or can I provide some compiler/link switch which could allow me to build like I did in the previous Mac OS X version.
Thank you,
Paul
I don't even own a Mac so feel free to disregard this, but your path has "mac32" in it, which suggests to me that it's a 32 bit library. "architecture" in computers usually refers to 32/64 bit CPU architectures, and I've heard that Snow Leopard has a big emphasis on migrating to 64 bit apps. As such, my first blush impression is that you are using a 32 bit library which Snow Leopard is warning you away from.
Hope that helps you get going in the right direction!
My guess is you're compiling 32/64-bit Universal, but the library itself is only 32-bit. While ideally you should get a 64-bit version of the library, for the time being you should just turn off 64-bit compilation of your application.