Update: I take the previous statement above back. I just tried the windows update and it worked fine, and Windows 7 still shows it is activated.
Windows 7 works like a charm via bootcamp on my Mac mini and iMac. I think Snow Leopard will make the difference about speed. It'll be released within a few months. We shall see.
iMac early 2009 working with windows 7 ultimate 32 bit, activated, but with the 40 second delay. Whats the general opinion 32bit or 64bit version of windows 7 for the newer intel macs?
i am using the 1° version of hazar loader.. its have textboot but boot more fast... i hope someone can fix this longgggboot
Yes. When i startup my iMac (24" - 2.66GHZ - 4GB ram - 640GB HD - NVIDIA GeForce 9400 - early 2009) or my older Mac mini (2.00 GHZ - 2GB ram - 120GB HD - Intel 945 Express Chipset - 2007), installed the Hazard lo*der, i have a delay from 40 seconds. This is what i saw when i used the first Hazar lo*der with text on both systems. Warning: Unrecognized partition table for drive 80. Please rebuild it using a Microsoft-compatable FDISK tool(err=4). Current C/H/S=266305/255/63 Starting cmain() ... Warning: Unrecognized partition table for drive 80. Please rebuild it using a Microsoft-compatable FDISK tool(err=4). Current C/H/S=266305/255/63 So it has something to do with my Mac partition. That's where it hangs for 40 seconds. What can we do about it? Still hope there will be a solution for this problem but i doubt about it.
I have a feeling it expects to see a certain drive designation that us Mac users don't have. I believe it finally times out looking for that drive designation and then we boot up. Of course, this is just pure speculation on my part. Well need a Mac hacker to take a look to see how to manipulate these lo*ders so we no longer see this problem.
Well just found an older post of hazar. Here is what he said in response to the boot delay on Mac's (bold type) That's just to do with bootcamp because the lo*der temporarily hangs on a non ntfs partition I would think someone could patch the lo*der to not hang on a non ntfs partition.
I got it working. I started from scratch and wiped out Partition 3 and 4 and just made it one partition.
All this does is re-write the boot sector of the partition (removing the crack loader). We need to just modify the source of the loader and set the timeout to 0. Hopefully it's that easy
I asked hazar about this, even sent him a PM here, but he never replied to either. I don't think he knows how to do it.
I spent a couple of hours trying to get around this myself, but ended up giving up because I couldn't find enough information about how the SLIC table is loaded, and because I'll have a legitimate key through MSDN shortly. What I propose is to use grub compiled for 32-bit EFI. It's possible to do so very easily using the latest svn sources and gcc with certain compilation flags. The grub binary can then be loaded through rEFIt (or even without rEFIt) in order to load Windows. I just don't know how the SLIC table itself gets loaded without any source code from the other lo*ders or other real specific information, such as grub command line flags or whatever else is used in loading it into the ACPI table. If such information were provided, it's possible I could conjure up something. My programming skills aren't fantastic, but I believe they're at an acceptable level. Grub4dos uses the antiquated grub base which isn't really worth patching to work since we have an EFI solution that would not only be more streamlined, it would also be undetectable to Windows since grub and associated files could reside on the OS X HFS partition, completely undetectable by Windows. If anyone knows the specifics, feel free to enlighten me.