It's taken me much longer than I would have liked, but I've finally got Starcraft working in a Mac OSX VM on my Windows 7 box.

I'll post all the steps/resources I used to achieve this:
1. Log in to battle.net and download the OSX client for Starcraft. Note that this is a mac downloader program, but if you dig around you can find a torrent file which will work with any torrent client. When you install the game you'll need a CD Key - this turned out to be the Game Key stored on my battle.net account which was lucky because my original box is buried somewhere hard to get to.
2. Download the 1.16.1 mac patch also on battle.net (somewhere)
3. Download or buy Mac OS X.
5. Download virtual box: https://www.virtualbox.org/wiki/Downloads
6. Download mac 10.6.8 update: http://support.apple.com/kb/DL1399
7. Download iBoot: http://www.tonymacx86.com/viewforum.php?f=125 (use my dud forum login: Somedood / somedood)
8. Download multibeast 3.9.1 from above
9. Follow page 1 of the instructions here http://www.orderingdisorder.com/2010/10/21/creating-a-mac-osx-vm-on-a-windows-7-host-part-1/. You do NOT need to download the Empire EFI because we're using iBoot instead (empire didn't work for me). Note that the latest version of virtualbox does not look quite the same as the screenshots, but the functionality is all similar. Also where it talks about finding your empire efi .iso, although I followed these instructions you can substitute this with your iBoot iso, or skip the step entirely and manually add iBoot later (which is what I did because I had empireefi added).
10. On page 2 at the above site, read the first few sections up until the OSX install screen and get familiar with the concept of changing the CD/DVD using the Devices menu. We'll be using iBoot instead of empire efi.
11. Now follow the instructions from this site from step 2 onwards http://tonymacx86.blogspot.com/2010/04/iboot-multibeast-install-mac-os-x-on.html You can check step 1 if you like but hopefully you won't need to meddle with those things. When it says to burn iBoot to a physical disc, we don't need to do that - we will use the Devices menu in virtualbox to point to our iBoot image on the hard drive, same with the retail DVD image. Once osx is installed you can skip the various registration and online account steps.
12. Because you've downloaded SC, the mac update and multibeast onto your windows box, we'll need to transfer them into the mac one. To do this we need to create a shared folder on your windows host that we can access from osx and place your files inside it: http://www.onecomputerguy.com/windows7/windows7_sharing.htm
13. Follow step 3 inside osx to get access to the shared folder you just made: http://www.sysprobs.com/mac-os-guest-virtualbox-326-snow-leopard-1064-windows-7-32-bit
14. Copy multibeast to your osx virtual drive to unzip it. You'll need to copy the SC patch there to unzip it as well.
15. Install SC by running the installer. I found the gamekey was on my battle.net account, as noted earlier.
16. Unzip the 1.16.1 patch and simply copy and paste the files on top of your starcraft installation, which is located in \Applications\Starcraft by default
17. You can now run starcraft!

The VM runs quite sluggish for me, probably because it doesn't have correct video drivers or some-such. I really wouldn't want to use it for any serious purposes. But I can get sound and starcraft to work, as well as the internet, so that's all I'm really concerned with.

Tomorrow and over the weekend I hope to use the CheatEngine program that jjf28 has linked to for harvesting EUDs: http://www.staredit.net/311764/

I've done a quick test and it's possible to set up a LAN UDP game between the OSX VM and my W7 host computer, so I'll be able to test the same map on both systems at once to ensure EUD compatibility, which will be nice. The VM is really really sluggish though - takes about 3 seconds for the initial 50 minerals you get to be fully accounted for, instead of the half second or so it takes normally. I'm going to check if I need to enable virtualisation support in my bios or something, because this is going to be frustratingly slow.

Post has been edited 5 time(s), last time on Oct 21 2011, 1:26 am by Roy. Reason: Don't post links to illegal downloads

Great Work

For quick referance here is the RAM reading program i've seen the most success with thusfar:
The Cheat

Alternate Mac Ram Reader: (my "guinea pigs" saw more trouble with this):
Bit Slicer

Will get it runnin myself soon.

Here were the addresses previously requested in shoutbox:

-Energy
-Health
-Upgrade Levels
-Selection Detection
-Text Detection
-Keypress Detection

Did you have trouble connecting to the internet through the VM OS? (was downloading the patch separately neccessary)?

Edit: the link in step 11 is broken, remove the period from the end.

Post has been edited 1 time(s), last time on Oct 20 2011, 3:57 pm by jjf28.

Link fixed.

I wasn't sure if I'd have internet access through the VM once it was fully configured; another guide I read suggested to disable internet access to prevent phoning-home to apple etc. But I didn't see any indications of that happening and was able to skip all the registration stuff at the start without any apparent issues. So you should be able to download the update, as well as SC, the patch and multibeast from within the OSX VM if you wanted to. Seems easier just to do it in windows and move them over later since the whole setup process takes at least 40 minutes, so you can be downloading the files in your windows host while you get everything set up. You'll need a way to move map files over to the OSX VM anyway so you'll need steps 12 and 13 at some point. It's highly likely there's a better and easier way to get access to the host hard drive from the VM but this was simple and it works well enough for our purposes.

Right, so I ended up making a new virtual machine from scratch, trying to solve the slow performance issue. I have HW virtualisation enabled at every level so that ruled out the main contender.

I made use of the Snapshot feature which lets you back up the state of the VM at any given time, and then roll back to it later seamlessly. I installed SC before I installed the 10.6.8 upgrade and multibeast thing, and it is is very responsive - not as fast as native windows, but much better than previous VM. After I installed the 10.6.8 update and multibeast, my VM never seems to reboot cleanly and the VM crashes and I have to start it up again (as in power it on again). After that SC was running sludgy again. So rolling back to my pre-upgrade snapshot and it's back to a useful performance level again.

I don't think I actually need the upgrade, since I'm not really using this for any real tasks. The main feature of multibeast is so you don't need to use the iBoot bootloader to get into OSX, as well as install sound drivers etc. But since it's a VM I can just Pause it and resume it later, so I don't need to reboot (and using iBoot isn't a big deal anyway). This does mean I don't have any sound since the sound drivers aren't installed, but that's not really a big deal.

So I'd recommend making a snapshot before you do the upgrade and multibeast install, just incase they make performance significantly worse, then you can easily rollback to pre-upgrade without having to create a new machine from scratch.

Also to run Starcraft in windowed mode, press command-M. If you're using a windows keyboard, the windows logo key stands in for command. It's a bit annoying to use because if you move your mouse outside the game window, it drags the cursor to the side of the screen and therefore starts scrolling everywhere, so you wouldn't really want to try and play the game like that I don't think.

Post has been edited 1 time(s), last time on Oct 21 2011, 10:55 am by Lanthanide.

(Triple post. Sue me. This post has quite different content from the above 2).

Right, I have now started using Cheat Engine to grab some addresses. It's not quite as easy to use as I'd like - after you click 'Add variable' so you can edit it and change the values ingame, it seems you have to 'close' the window by clicking the red circle, and then recall the main window from the dock (Right click - Show). Kinda annoying.

So I've found the addresses for the SC1 vanilla upgrades. I got Farty to PM me the reference for the upgrades since his EUDDB is offline since he's in the process of moving house. This makes me think the content should really be backed up somewhere else on the internet - if Farty got hit by a bus tomorrow, we'd lose his database.

The SC1 upgrades appear to have the same memory layout as the windows version, that is 46 bytes per player. I'm assuming it goes player 1 to 12, although so far I've only confirmed Player 1 and the first address for Player 2.

So:
Player 1:
Terran Infantry armor 0x005A3660
Terran vehicle plating 0x005A3661
Zerg flier carapace 0x005A3664
Defiler energy up 0x005A3680
Arbiter energy up 0x005A368C

Player 2:
Terran infantry armor 0x005A368E

Now the very interesting thing I have found, which jjf28 may already have known, as well as anyone else who has done much with mac memory (which is I suspect not many people). The OSX version of Starcraft was written for Power PC, and therefore needs Rosetta to run on the intel-compatible versions of OSX. This also means that all of the memory is big-endian instead of little-endian like a native intel application is. Incidentally the latest versions of OSX, 10.7.x Lion has removed support for PPC applications, and so Starcraft will no longer work on newer macs that come with lion installed or anyone who upgrades to Lion. We can therefore expect to see declining numbers of mac players on battle.net over time, as I doubt Blizzard will be interested in releasing a new intel-native version for OSX.

Because we must operate with 32 bit unsigned integers, in windows to check if a player had 1 level of terran infantry upgrade we would check if the 32 bit integer had a value of 1. But because SC on OSX is big-endian, to make the same check we must check for the value 16,777,216. Similarly in windows if we want to check Zerg Carapace is level 6 in windows we must check for value 100,663,296, but in OSX we need only check for 6.

This means supporting OSX and windows in a single map is not going to require just making a copy of EUD triggers and using new memory addresses, but we're going to have to re-write all of the actual integer values as well.

Roy: This will make your EUD tutorial more complicated
Farty: This would really be a useful switch to include in your EUD calculator program, a flag for windows/OSX that swaps the value we're checking for.

Post has been edited 1 time(s), last time on Oct 21 2011, 10:56 am by Lanthanide.

My tutorial is specifically for PC. The only thing that's different for Macs is that you have to swap the multiplier to accommodate for big-endian memory, and of course the addresses themselves are different. Calculating the value of text is probably the most notable difference here.

Could you check the value of address 0x4FF900 for me? Let me know what the value is and if it appears constant or not.

I had to use BitSlicer to look at specific memory addresses. I found that with The Cheat and BitSlicer you can add your own custom variables (use the top menu bar), but it doesn't really refresh them very frequently so it's a useless approach for viewing specific addresses.

In BitSlicer however there's an option for View Memory under the Memory menu. This lets you type in an address (must start with 0x) and the number of bytes to view, and this appears to be updated in real-time with the program, which is nice.

So I had a look at the 512 bytes starting at 0x004FF800, which includes your address Roy. This block of memory always appeared to be 0, in the main menu, when playing a custom single player game, when playing the first protoss BW level and when starting a UDP network game with no other players.

If you gave me an idea of what you think that memory address might be for, it'd help with testing.

Using this View Memory approach, I looked at the 552 bytes starting at 0x005A3660, which appears to be the SC upgrades. Using my map with edited default values for terran infantry armor and protoss arbiter energy upgrades (first and 2nd last upgrade per player), I can confirm that the mac version uses the same memory layout: 46 bytes * 12 players. The info in my previous post indicates that the order of the upgrades within the block is the same.

I went and read your EUD tutorial and see that the address you wanted me to look up is the one you used as the example for a PC-specific switch setting.

Using this, I made a map with the following triggers, and I can confirm that there is no desync between the PC player and the mac player. PC is P1, mac is P2. The marine-creation triggers are testing if Player 1 has exactly 1 upgrade of terran infantry armor, which is performed by the PC player.





It seems that as long as these two triggers have exactly the same conditions, occur in the same relative order compared to other triggers being run by that player and the actions are identical, then the triggers won't cause any desync.

Seeing that this works, it means that the upgrade memory block is the same relative distance after the death table as in the PC version. We probably just need to check a few of the other more exotic parts of memory and we may discover that all of the relative memory offsets are the same. If so, this would make mac EUD triggers fairly straightforward - just need to turn little-endian checks into big-endian where required and slap in a Switch check to turn one or the other off.

Incidentally, I was only able to do this because Roy had posted the address for the infantry upgrade in the other thread. Since Farty's in the middle of shifting houses the EUDDB is inaccessible, unless there's some other resource that has all the addresses in it we're kinda screwed. Maybe that excel sheet Roy was working on has the addresses? I haven't looked at it myself.

I was working on an excel sheet? Are you talking about http://www.staredit.net/topic/14408/? It has some of the common converted address values in it. I'll quickly pull some addresses for you.



I rushed through that, but it should be accurate.

Oh, and thanks for checking that address. In Windows, it's the beginning of the area in memory that the string "Last Replay.rep" is stored. I just wanted to make sure the Mac address wouldn't fluctuate, so it would indeed be a good address to check the OS of the players at the beginning of the game.

Definitely some interesting research here...as a Mac user with a Windows VM, I might be able to help out a bit, though I've had very little free time lately and it doesn't look like that's likely to change anytime soon.

Quote from Roy

Oh, and thanks for checking that address. In Windows, it's the beginning of the area in memory that the string "Last Replay.rep" is stored. I just wanted to make sure the Mac address wouldn't fluctuate, so it would indeed be a good address to check the OS of the players at the beginning of the game.

Does this remain constant across different language-versions of SC?

Oh, I didn't think about that; probably not.

So the mac version doesn't support replays at all?

If the mac version is always 0, then that's your check right there: is memory address at least 1 = PC, exactly 0 = mac.

Edit: Mac does of course support replays. I'm downloading cheatengine now so I can see how this address works on PC.

Post has been edited 1 time(s), last time on Oct 22 2011, 1:52 am by Lanthanide.

Where did you hear this? I've never had any problems making or watching replays on OSX (or OS9, for that matter...or OS8...I've not tried SC under OS7, but replays probably work there, too).

No, the Mac and PC addresses for this string will of course be different, though, and it appears as though the Mac address for where it is stored for the PC is always 0, meaning it won't cause a false-positive in the OS detection.

I spoke with someone with a Spanish version of the game, and the replay is still saved as "Last Replay.rep"; unless someone with another language can say otherwise, it may be universal across different languages.

Ok, I think I know what's going on here.

The mac addresses are all quite a bit after the PC addresses: 0x5A3660 for 1st upgrade vs 0x58D2B0 in PC for example. What Roy asked me for was an absolute address based on the PC version which is very early in the PC memory space. In the mac case, this absolute memory address is actually outside the memory of Starcraft itself and is so being used by the OS for some other purpose. Thus when the cheat engine tries to read that memory through SC, it's always returning a value of 0 (similarly attempts to write to it would fail). If I go to the same relative address in the mac memory, 0x515CB0 I get some block of program memory that doesn't have nice english strings, so no idea what it's really being used for. At the moment sitting in the single player selection screen it's got a value of 5,177,562, so my triggers above would always work as long as this value didn't change to the big-endian equivalent of 1,953,718,604. Looking at the values around it, I think this is unlikely, but it's not really a consistent controlled test.

So we could use 0x4FF900 as our memory address for detecting PC vs mac, but it's risky attempting to read memory outside the executables address space as the OS might kill the program for illegal memory access, or any other number of things outside our control might happen.

What we need is ideally 1, but most likely 2 addresses that correspond to fixed strings in each compiled program that we can easily distinguish between the OS. Eg mem 1 on windows says "Win32" and mem 2 has random data, whereas on OSX mem 1 has random data and mem 2 has "OSX" then we can use the combination of the memory addresses to definitively identify each OS with incredibly tiny risk of error.

I'm trying to find a better memory viewer so I can look around the OSX SC memory more easily than the limited ability that BitSlicer provides.

Haven't gotten OS X to work yet, tried iboot, Rebel EFI, and emperor EFI, will look into it more tuesdayish (brothers wedding's tommorow =) )

Two quick questions...
what ISO creator did you use?
what name is the Mac Install CD supposed to have?

As far as different Ram Readers go you can try IHaxGamez and this may also interest you... http://forum.cheatengine.org/viewtopic.php?t=221190&postdays=0&postorder=asc&start=0

Edit: Oh, and here's my personal EUDDB backup (caught some stuff from googles catche when it went down b4, think it's missing some pages)

Attachments:

I didn't need any iso creator. The latest version of virtualbox is capable of loading .dmg files directly, which is the format the torrent I linked to comes in.

No idea what the CD is supposed to be called and it shouldn't matter anyway?

I've tried the cheat engine from that forum post, it sort of works but is quite buggy. It also doesn't recognise Starcraft natively, but instead identifies the process as "LaunchCFMApp" which is apparently because Starcraft for mac is a Carbon application, meaning it was originally programmed for OSX9 and so has to run with a shim layer thing to work in OSX 10+. Then we're running OSX10.6 which further requires Rosetta to translate the PPC calls into x86 calls, so it's layers on top of layers. It's somewhat amazing that Starcraft runs at all. Anyway, because the cheat engine port to mac is very half-hearted, I suspect it doesn't properly work with Starcraft because it's a carbon app - I can view the memory, but when I do so it doesn't start at the beginning of SC's actually memory block, which is what I really wanted. Also using it to search for the terran infantry armor upgrade failed no matter how I tried to search for it. Also going to 0x005A3660 was close, but not exactly on, the SC upgrades, which appeared about 40 bytes or so later.

So all in all, stay away from Cheat Engine when on the mac.

I tried iHax but its a very basic editor and doesn't have any sort of memory viewer.

Googling around the net, there really are very few decent disassemblers/debuggers for mac. This field seems to be dominated by a program called Ida Pro, which does not have a free mac version and I can't find the full mac version on any torrent sites to download.

Post has been edited 1 time(s), last time on Oct 22 2011, 5:20 am by Lanthanide.

Wassat?!

Actually, SC was originally designed to work with systems as old as Mac OS 7, which makes OS9 look positively modern by comparison. In fact, I don't believe OS9 was even out yet when SC was released. I played for a long time under 8.5, myself.

Anyway, I've been playing around with The Cheat a little...so far I haven't managed anything more interesting than changing some strings (in the 16E8Cxxx area), but I haven't transferred over any dedicated testing maps from my Windows partition yet. If I have time later, I'll dig around a bit and see if I can get anything more interesting...

Post has been edited 1 time(s), last time on Oct 22 2011, 9:44 pm by FoxWolf1.

I did a little more work on this. I tried the cheatengine port again, using View Memory it takes me to memory starting at 0x00400000 which there's a little bit of text followed by 1 meg of empty memory. The 4FF900 address falls right towards the end of this block, only a few hundred bytes before what looks like the start of SC proper.

In my discussion above, I mentioned that SC is using Carbon, and Cheatengine registers it with a funny name in the process list because of that. I think that this 1 meg of empty memory at the start of program execution is part of the carbon wrapper around the program. This means that using address 4FF900 to detect the OS is valid: this is actually part of the process' memory, its just the carbon wrapper part rather than SC proper. Until such time as Blizzard re-write it as an x86-native binary (likely never) or the Carbon wrapper system is changed (given that Apple have dropped it in 10.7.x, likely never) this should be an ok address to use.

For testing purposes I made a map that attempts to access memory at approximately 0x003FFFF0 or so. OSX seems to handle this ok without any issues, but Windows kills the process when it sees this memory access.

As Heinermann mentioned to me before, the Windows range for static memory is between 0x00401000 and 0x006DD694. I imagine Macs have a similar range.

Post has been edited 1 time(s), last time on Oct 23 2011, 2:29 am by Roy.