So atreyu's patch is for slic and will not work with SLP1 (XP mode in virtualbox), correct? Is there an update for FreeSlayer's SLP1 x64 vboxdd2.dll patch for VB 4.0.0 (last made for 3.2.10)? -- One other thing that's confused me; is it possible for SLP1 to make XML changes to the Extra data to get xp mode to activate (without other changes)? I tried several and none worked, such as: <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" value="Supermicro"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion" value="A12"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/ReleaseData" value="02/22/2010"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/ReleaseMajor" value="2"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/ReleaseMinor" value="3"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/FirmwareMajor" value="2"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/FirmwareMinor" value="3"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" value="Supermicro"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" value="X7SBL"/> <ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiSystemVersion" value="A12"/> which others claimed to have worked for them. The only thing that worked was FreeSlayer's DLL patch.
@bizarro, setting the 'Windows_Virtual_XP_F9161D8E7FCC11DDBFAA369856D89593' SLP string with XML using the ExtraDataItem directives won't work, the string is too long for DMI entry and besides that the 'Windows_Virtual_XP_F9161D8E7FCC11DDBFAA369856D89593' SLP string requires to be at a specific location. The XML ExtraDataItem directive works fine in conjunction with for example the Hewlett-Packard and Medion oembios sets as these look for the SLP string inside a larger BIOS memory range including the DMI area. Update for VirtualBox v4.0.x (x64 tested, x32 tested): If you search and replace the following hex values in VBoxDD2.dll you are able to use the XP Mode Mode vhd in VirtualBox without having to swap oembios files original Code: C406B8430250FF76FEE8DC7483C40430E4508B460A4050FF7604E8F17483C406B8440250FF76FEE8BE7483C40430E4508B460A replacement (ASCII = Windows_Virtual_XP_F9161D8E7FCC11DDBFAA369856D89593) Code: 57696E646F77735F5669727475616C5F58505F4639313631443845374643433131444442464141333639383536443839353933
MICROSOFT (OEMBIOS.CAT CRC32=B4FFCA38) F000,908A,,Windows_Virtual_XP_F9161D8E7FCC11DDBFAA369856D89593 Easy to check what is there and replace sebus
Thanks, but since VB is open source, is there any way to make changes to the source code so you don't have to manually provide a patch for each release? I'd assume we could just rebuild this one DLL.
That would also require to be done for each version, so no real benefit here over the patch (as FS said, it takes only a moment, way less then rebuild would take) sebus
Yeah, unless he joins the peace core, gets abducted by the greys, or otherwise leaves the forum! Teach a man to fish and all that...
Who said it is not possible? I am sure it is, just that nobody was discussing the Linux platform in this thread so far sebus
Ok, maybe it is possible but where is the problem? Does it need some tester or is it on Linux a different thing to get Slic in it? Thanks for your answer.
(running 4 my 20 posts...) Hi terrafaux Linux is not a completely different thing when you look inside an executable. Where you have a .dll in windows, there may be a .so in linux; made of the same matter. However there are two constraints: - linux has a different culture built around open source; you don't patch, you change the source and publish the code. Yeah, I know, VBox is a bitch to get compiled; and there are more and more linux users that just want to get their things done. That's why there are VBox binaries for Linux, but looking at it there is another problem: - there are MANY binaries for *nix! ( something is wrong here, imho, but that's another story ). While a windows patch covers, what, more than 80% of the "market", for *nix one would have a lot of work just testing the thing! However, if you feel like it worth, I begin with a question: are all VBoxDD.so binaries equal, byte by byte?
Atreyu thx for your explanation, now i have a better understandment and i think it is not worth to start " The Neverending Story" ;-) Have a nice day.
Are you patching executable code or just data? Sounds like it's just data. If it's just data, the same data is probably verbatim in the Linux library file, so the same patch could possibly be applied to the Linux library. I don't know if I'd consider this a constraint. It maybe a different way of doing things, but certainly wouldn't be a constraint. Many people such as myself could utilize it. Have you thought about submitting your changes back to the VirtualBox people so your changes can be permanently part of VB? If it's a .so, it might be. I can install VBox 4.0 later today on Ubuntu Server 10.10 X64 and post the MD5 of any .so file you need. But if you are just searching/replacing constant strings, it might not matter, as they maybe the same for any compile.
If there is people interested in a nix solution I can take a deeper look at that. What I will do: - change and test the code path; code change is almost done in sdk, I have to install a real nix box because vm inside vm is more troubles in the way, if feasible. - check the patch path with Ubuntu 10.10 Virtual, some quick answers, I'm in a hurry: - the patch is in code, each case is a case, patterns die fast - vbox people will never accept a "slic" addition; however a complete BIOS replacement would be interesting, IMO
The hope proudly presents..... ..... ........ ATREYU ........ ..... I will support this project if i can