using with new 20h1 technical preview that has hyper-v / vbs coexistence support about auto-unlocker

[paolo-projects]

I'll run some tests and dig into it

[paolo-projects]

I made copy of unlocker303\backup folder, ran unlocker303\win-uninstall.cmd, ran auto-unlocker11\Unlocker.exe, compared file size and date of "unlocker303\backup - Copy" and and auto-unlocker11\backup files and they were the same.

That won't work because the content of the backup folder is the original vmware files, not the patched ones. And moreover the file size is not at all a good way of comparing files equality, especially because the patch doesn't affect the file size.

Anyway if I recall correctly from other issues this is a constant behavior of the patch, the first time you run it it's not working properly but if you run it again it works. At this point I guess it's related to vmware not initializing some registry entries or something along those lines.

I'll close this issue as it's basically the same behavior of other issues that I'm currently investigating.

[lanzorg]

Isn't this version currently very limited in performance? It seems the debug mode cannot be disabled.

[paolo-projects]

For now it's still a technical preview, but it would be nice to have it supported when it's eventually released. Unfortunately mine is just a C++ port of drdonk's original patch, hence I wouldn't be able to do it on my own. If anyone with the necessary knowledge shows up with a solution I'll be glad to implement it in this tool.

[myusrn]

What's the github repo for drdonk's original patch and i'll open issue there? I searched and only see https://github.com/paolo-projects/unlocker and nothing of this sort any more under https://github.com/drdonk?tab=repositories&q=unlock results. The reason this is big is because it will allow running macOS vm in required vmware player/workstation environment while retaining ability to run hyper-v and the things we have to do there versus having to turn hyper-v hypervisorlaunchtype [ bcdedit /enum ] into auto/on state [ bcdedit /set hypervisorlaunchtype auto ] and off state [ bcdedit /set hypervisorlaunchtype off ] followed by reboots to switch between being able to operate hyper-v and vmware environments.

[paolo-projects]

I can understand, I run android emulators often (they also rely on hyperv apparently) and a couple hyperv machines every now and then and it's a pain to reboot every time just to switch from vmware to a different vm.
Best place to open another issue is in the new maintainer's repo (don't remember the name but you can find it if you go in my forked repo and look at the forked from tag under the repo name) or in some hackintosh forum. I guess we should wait for a proper release though before someone can get to work on it

[myusrn]

https://github.com/paolo-projects/auto-unlocker/tags doesn't have any "forked from" tag, i assume i'm looking in the wrong place. The readme.md mentioned origin repo https://github.com/drdonk/unlocker appears to be gone as it produces 404 not found.

[paolo-projects]

I meant the text under the repo name, I can see it when I go to my repositories... anyway I just checked and the new maintainer should be theJaxon

[myusrn]

Wondering if the text under the repo name is something you see as the owner of repo but visitors do not see. Anyway i visited https://github.com/thejaxon/unlocker and there isn't an issues tab suggesting repo is just keeping final drop of that work.

[paolo-projects]

I just checked with a private navigation session and I can see it. Probably I didn't explain it well, I was talking about my forked unlocker repo, which I created back then from DrDonk repo to patch some broken urls before eventually moving to this one (auto-unlocker) which is the one I maintain.

This one, however, is just a convenience C++ port of that one, made to allow one-click install on every machine (actually the one click thing is true just for windows, but most of the linux users don't like one click things anyway lol).

Wondering if the text under the repo name is something you see as the owner of repo but visitors do not see. Anyway i visited https://github.com/thejaxon/unlocker and there isn't an issues tab suggesting repo is just keeping final drop of that work.

Well, I guess you're right, he probably won't be releasing patches for new versions. The only hope at this point is to wait for someone with experience in that field to come around.

Edit: I've pinned this issue to give it more visibility.

[myusrn]

Note that I retested removing all presence of vmware player/workstation 15.x and new 16.x technical preview and then did another clean install of 16.x player+workstation technical preview. I then ran "auto-unlocker11\Unlocker.exe [ --install ]" against that install which succeeds fine but when you then use vmplayer.exe or vmware.exe console to create a new virtual machine the "Guest operating system" dialog doesn't present a MacOS 10.x set of options so appears a different file has to be patched for things to work.

[myusrn]

I tested patching the vmware 20h1 technical preview using unlocker 3.0.3 [ https://github.com/paolo-projects/unlocker ] and it works. When i create a new vm i see the "Apple Mac OS X" guest operating system option and version selections, that include 10.15 and 10.16. Booting a macOS 10.15.4 installer iso succeeds as does booting an existing macOS 10.15.4 vmware setup i had in place before upgrading to this new hyper-v / vbs co-existence capable vmware 20h1 technical preview.

It would seem autounlocker 1.1 [ https://github.com/paolo-projects/auto-unlocker ] perhaps needs an update to do whatever the current version of unlocker 3.0.3 is doing in order to function properly against these new 20h1 technical preview installs. Alternatively i could have done something different that i'm overlooking when i applied the unlocker 3.0.3 but not sure what that would be since in each case i just ran "auto-unlocker11l\Unlocker [ --install ]" and "unlocker303\win-install.cmd".

[paolo-projects]

I just checked on a clean vmware player 15 install: I ran the python tool first, uninstalled the patch, ran the c++ tool and then compared the results with a hash tool:

Filename	MD5	SHA1	CRC32	SHA-256	SHA-512	SHA-384	Full Path	Modified Time	Created Time	Entry Modified Time	File Size	File Version	Product Version	Identical	Extension	File Attributes
vmware-vmx.exe	18b47f8f1575ed0ff1d6eb8489a9c47a	4cdc2690f831730e2adcb2af4e1783bda6b5372b	c695d31c	f5a09140bc7e4d945cb44f5f450b119573ff9cd733daf3ebdb7947c8563c2ed1	963ad28dc076ab32b01267101fb2a5ce43ed246733310f7fe3c394210edf74e713a9de226ca53fcd566ef8f6126e6515bbd055c4976ffa591775ae66b9e83518	4bd862f6e337435cb103771baca8508844643139aa3bb262929f660e47921732e9c753b3652d9842a79d96d5e38662d8	D:\auto-unlocker\testing\good\vmware-vmx.exe	07/04/2020 16:55:19	07/04/2020 16:57:01	07/04/2020 16:55:19	16.764.376	15.5.2 build-15785246	15.5.2 build-15785246	1	exe	A
vmware-vmx-debug.exe	cfab05e9b1bd4596f54dd682cba68d5e	3701628840b4167b1969d1f60af995cc0b0c7034	d8876ee6	cf3551659b977063c69ed9499143a7f6b0ccb591720e47b65eca52f628da9b69	fd3786bd748ff02409a4b8d8257db6ab6e4854170ccf16ead94bbb0ae37db1d9a0c765c24aa8fa149318aff978f81b7180af8f4f6a1e21789f8c9a80fec02802	99e6e6ed4596c97f36891555c089a1fc7fc7aa2d9dbd903d3328ab0bae8192d5afc55aa464c4e29cb6e8c5ee471e072d	D:\auto-unlocker\testing\good\vmware-vmx-debug.exe	07/04/2020 16:55:19	07/04/2020 16:57:01	07/04/2020 16:55:19	22.104.536	15.5.2 build-15785246	15.5.2 build-15785246	2	exe	A
vmwarebase.dll	e8bf8ca0bb7e6f1b929ebd2777f33a22	87818a402b871670f568889c8acadbf731a6ecff	f73f2fcc	cead472605eddca069f39157b6812c5cfd5a22e5aad04f905779981c0dfca552	05f57a26d9bcc5172686693123f7199416891bc4b7de17304afd96309506712bc1ca88dc8253201545d8098d9f8484cdb967c3629057a1d8ae795922890ee653	1f8bed5cc1b49df8ad2db514a34314b93644eb20d3aac4f9d1950263f3907f67e39ea9342a09f1c7c58bbbdb5f7d35c4	D:\auto-unlocker\testing\good\vmwarebase.dll	07/04/2020 16:55:19	07/04/2020 16:57:08	07/04/2020 16:55:19	7.037.912	15.5.2 build-15785246	15.5.2 build-15785246	3	dll	A
vmware-vmx.exe	18b47f8f1575ed0ff1d6eb8489a9c47a	4cdc2690f831730e2adcb2af4e1783bda6b5372b	c695d31c	f5a09140bc7e4d945cb44f5f450b119573ff9cd733daf3ebdb7947c8563c2ed1	963ad28dc076ab32b01267101fb2a5ce43ed246733310f7fe3c394210edf74e713a9de226ca53fcd566ef8f6126e6515bbd055c4976ffa591775ae66b9e83518	4bd862f6e337435cb103771baca8508844643139aa3bb262929f660e47921732e9c753b3652d9842a79d96d5e38662d8	C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe	07/04/2020 17:50:10	07/03/2020 11:17:04	07/04/2020 17:50:10	16.764.376	15.5.2 build-15785246	15.5.2 build-15785246	1	exe	A
vmware-vmx-debug.exe	cfab05e9b1bd4596f54dd682cba68d5e	3701628840b4167b1969d1f60af995cc0b0c7034	d8876ee6	cf3551659b977063c69ed9499143a7f6b0ccb591720e47b65eca52f628da9b69	fd3786bd748ff02409a4b8d8257db6ab6e4854170ccf16ead94bbb0ae37db1d9a0c765c24aa8fa149318aff978f81b7180af8f4f6a1e21789f8c9a80fec02802	99e6e6ed4596c97f36891555c089a1fc7fc7aa2d9dbd903d3328ab0bae8192d5afc55aa464c4e29cb6e8c5ee471e072d	C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx-debug.exe	07/04/2020 17:50:10	07/03/2020 11:17:00	07/04/2020 17:50:10	22.104.536	15.5.2 build-15785246	15.5.2 build-15785246	2	exe	A
vmwarebase.dll	e8bf8ca0bb7e6f1b929ebd2777f33a22	87818a402b871670f568889c8acadbf731a6ecff	f73f2fcc	cead472605eddca069f39157b6812c5cfd5a22e5aad04f905779981c0dfca552	05f57a26d9bcc5172686693123f7199416891bc4b7de17304afd96309506712bc1ca88dc8253201545d8098d9f8484cdb967c3629057a1d8ae795922890ee653	1f8bed5cc1b49df8ad2db514a34314b93644eb20d3aac4f9d1950263f3907f67e39ea9342a09f1c7c58bbbdb5f7d35c4	C:\Program Files (x86)\VMware\VMware Player\vmwarebase.dll	07/04/2020 17:50:10	07/03/2020 11:06:18	07/04/2020 17:50:10	7.037.912	15.5.2 build-15785246	15.5.2 build-15785246	3	dll	A

The files produced by python and c++ tools are identical, so at least in my case that's not the issue.

If you could remember what kind of procedure you followed before running the working patch it would be useful to identify the problem.

You can also run the test yourself to give it a bit of reproducibility: copy the python patched files from your install dir (/vmwarebase.dll, /x64/vmware-vmx.exe, /x64/vmware-vmx-debug.exe), uninstall the patch, run the patch with c++ tool and do the same thing, then compare the hashes with some tool (I use this one) and post the results here.

Edit: VMWare Player 15.5

[myusrn]

I made copy of unlocker303\backup folder, ran unlocker303\win-uninstall.cmd which removed unlocker303\backup folder, ran auto-unlocker11\Unlocker.exe, and compared file size and dates of "unlocker303\backup - Copy" and and auto-unlocker11\backup files and they were the same.

I opened vmware 20h1 tech preview 16.0.0 player app and created a new vm and the select a guest operating systems dialog had an "Apple Mac OS X" entry with 10.16 and 10.15 entries in drop down list.

I booted an macOS vm configuration using macOS 10.15.4 installer.iso and that successfully launched me into macOS installer. I booted an existing macOS vm configuration with macOS 10.15.4 completed installation and it launched and allowed me to login just fine.

Conclusion, issue does not repro. I must have had some machine specific state in place when i first tested where complete uninstall of existing vmware bits and reinstall clean of new 20h1 tech preview 16.0.0 release then cleared the slate and allowed the auto-unlocker 1.1 to work as expected. Looking at tech preview release notes it says i should have removed my existing vmware 15.x.x install first before trying 20h1 tech preview install. Also my 15.5.2 had the auto-unlocker 1.1 patches installed before i did the inplace upgrade to 20h1 tech preview so that could have messed up initial test results.

Apologies for the false alarm. You can close this issue.