Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/19/2020 in all areas

  1. I made a custom Windows Vista Image called Windows Vienna (Named after Windows 7's codename) I gave it it's own kind of look anyway i'm kinda off topic. I used a program called gimagex which is very useful. all you have to do is extract install.wim from the .ISO file and mount it but be sure to select the 'read and write' check box. you can directly replace the modified kernel32.dll file in the Windows directory without any permission issues. once done, check 'commit changes' and then select unmount. here's what i achieved whith gimagex: this took me 2 years to develop btw.
    2 points
  2. Update on x86 extension: I have refined the implementation of SetThreadErrorMode, (Rtl)TryAcquireSRWLockExclusive and (Rtl)TryAcquireSRWLockShared. On the x64 side, I've got SetThreadErrorMode and its dependency BaseSetLastNTError. x86 SetThreadErrorMode is based on Windows 2000 extended kernel code, though all others are based on Windows 7 code. Next up is GetCurrentProcessorNumberEx (needed by Pale Moon 28.10.0) and the entire K32* series of functions (there are about 25 of them). And then a few stragglers in user32 and shell32 will be added. The manual patching instructions will be updated once kernel32.dll is filled out with all of the planned functions. On another note, I have found a limitation of the DLL redirection scheme. While it works wonderfully for say, kernel32.dll where the program will call the local version, and even other system dlls (not located in the local directory) would refer back to the local version, it appears that ntdll.dll is exempt from it. Mind you I haven't applied the reg key mentioned in the article yet that would allow system-wide DLL redirection. And as it stands, all program execution (as in GIMP 2.10.8 and a recent version of oCam) using my x86 kernel32/ntdll combo fails ATM. Yes, I did try renaming the local ntdll to ntdl1 then adjusting kernel32's import table accordingly. That still didn't work out as a fault occurred in the main ntdll at 0x77E0F7B3 (RtlInitializeNtUserPfn). I will keep investigating. update: x86 ntdll is unbootable, but x64 kernel32 still boots to a stable system, now with K32GetProcessMemoryInfo implemented.
    2 points
  3. It is better to live one day as a lion than 100 days as sheep. ... but maybe 50 as a teddy bear would do ... jaclaz
    1 point
  4. Yup, this is fine. If it seems stuck try to hold the motherboard side part in place, so you don't pull both connectors out. Just for better contact. That's the standard, but you can never be 100% sure. I've seen many cables (not battery yet, though) with swapped colours. Check the old battery just in case.
    1 point
  5. Actually, 2.10.0 x64 runs on Vista. Download gimp-2.10.0-x64-setup.exe from https://download.gimp.org/mirror/pub/gimp/v2.10/windows/ and you will notice that the installer doesn't block Vista like those for later 2.10 releases. The module that calls SetThreadErrorMode in later releases doesn't call it in this one. huh? 404? what a shame since 2.10.2's installer blocks Vista!
    1 point
×
×
  • Create New...