Jump to content


  • Content count

  • Joined

  • Last visited

About Ubaid

  • Rank
    InsanelyMac Protégé
  • Birthday 08/14/1988

Contact Methods

  • Website URL

Profile Information

  • Location
    Long Island, NY
  1. Making Good Progress for Windows XP

    I'm not saying that a competitive contest is not inhibiting progress, for it most certainly is. However, the issue is also with closed source software. In order to deal with bios calls in propietary software, you need to hex edit files, and hack away at disassembled binaries that are harder to decipher than common assembly language. With linux, mostly, everything is binary, and the programmers can see (and change) whats going on under the hood. Linux was easy by comparison, yes. I don't think we'll see XP running natively on the macs unless a lot of work is put into it. Whats more likely to be seen soon is Windows running on a light emulation client sitting on top of the EFI, as a sort of psuedo-CSM.
  2. Maxxuss ~ XP on MacTel?

    Well, I don't think the guy that is doing it (from windowsxp.onmac.net) is allowed to. I agree that it's a splendid idea, and would probably be the most productive use of the money. Maxxuss knows what he's doing, and has gotten the furthest in his efforts. If only we could have this money go to him. Personally, I see no use for XP as an operating system, but some people I know need xp for the applications, namely MS Virtual PC, and I would see a use for it being a gaming platform for native Counter-Strike as Darwine doesn't support OpenGL yet.
  3. Wine+X11 Update

    The goal (of WINE) is not to emulate a session of windows or run a windows box on your MacIntel. Wine just allows windows executables to use Windows APIs on other platforms, without the bulk of windows that you need to run an emulation environment with vmware. Its true, vmware will probably make apps work similarly to how they work on windows computers, but WINE won't eat up your resources or harddrive space, and you won't have to run windows on your mac. These are two seperate solutions, WINE aims at allowing windows programs to run on Macs, whereas VMware aims at having windows run inside an emulation environment running on OS X, with programs running in that sandbox of an emulation environment. I don't mean to be condescending, just trying to make it clear. I personally would love to see WINE work on OS X intel. For those that have access to a macintel, a promising program is "Newsbin" available at newsbin.com. It rivals Unison, and is a great usenet tool. Since it behaves as a self-contained app for the most part, accessing internet-access dlls as it may, it seems as though it would work on the WINE build that you have constructed. Since I am on a windows box, I would be glad to donate any DLLs that you need for testing, PM me if you would like draken. For the openGL stuff, would the video card require specific openGL drivers? I'm not too familiar with the specifics of openGL, but would it be possible to use NSopenGL (cocoa) to output video as then the core code would run in a windows executable, but would be rendered native to OS X, with native windowing support (not x11) and with native rendering with proper video card drivers? This is not a hypothesis, nor a supposition, I'm simply asking a question. I don't know about OS X, I'm planning on making the switch, I've only developed in Windows and Linux so far.
  4. Yes, Dells and gateways do use EFI, but the problem is that these EFI implementations are with backward compatible BIOS settings. Unfortunately the Apple implementation, from what we know does not offer backward compatible BIOS as they do not need it. Thus, on the gateway and the dell, XP is installed normally, and none of the bios calls are converted by software, they are handled by the EFI chip on the motherboard which treats these calls as bios would treat them. The question is, whether it is possible to have backward compatibility on the iMac by installing or enabling this feature on the EFI. Sorry, I thought the same before I read up on it.
  5. EFI booting thread

    Salam Guru, Are you suggesting that everytime windows interfaces with the BIOS, it goes through the ntldr? To abstract that and derive a solution based upon it, you'd have to prove that fact. If that were true, I'd think the ntldr file would be locked, and I've modded it while windows was running, so it seems unlikely that windows only interfaces through that one file. If it works this way, than it would be a lot easier than what I thought. I'm sorry you're receiving so much criticism, but I just need to be sure about this. If I can delete the NTLDR file and have programs read my CPU and play with voltages, even rewrite BIOS firmware without windows locking the NTLDR file, it seems unlikely that this would be the case. However, you may have a point if the NTLDR is loaded into ram and then everything is put through the RAM address of the NTLDR, this would make sense. I don't know how to prove or disprove it, but I think you should go about figuring that out. Don't worry about the partitions, worst comes to worst, you partition a disk using a windows computer and plug it in, the issue is the proof of concept. Once it can be proved that windows can work with an EFI, people will write the software to resize or format the OS X partition. However, it would be a lot simpler if you have a blank disk, and you partition it just to get that out of the way for now. As for what partitions can be read from the EFI module on the Apple computer, that has to be checked and verified as well. The way I thought it worked was that Windows interfaces directly with the BIOS through some low-level calls. In this case, Windows would have to be run on what I would term a BIOS emulation or BIOS sandbox environment, in which bios calls would be converted to the EFI equivalents, and EFI return statements converted to bios equivalents.
  6. EFI booting thread

    As for getting any OS on the iMac/Macbook, it seems as though its not only the issue of booting it. We know that EFI booting is supported by Vista Beta, but what we don't know is if EFI compatibility is completed on Vista. All bios calls in the OS have to be modularized so that when the OS wants to request 'bios' information, it can get information from the EFI thing. Reaching towards $7g prize money for XP: Frankly, I know I'm not winning it anyways, so heres for anyone who is trying: Windows XP will not operate on an EFI without the bios compatibility set. The best method of attacking this is by running it in a sandbox or emulation environment, in which the bios calls by windows are converted into EFI calls and responses similarly converted. Yes: its a pain in the neck, but seems like its necessary. If the vista EFI loader works, and supports launching executables after its loaded, it can be hacked to load any windows executable file, namely, a bios software compatibility layer to launch the windows executables. Please tell me I'm not crazy, and correct me if I'm wrong, thanks.