#26
Posted 28 June 2020 - 09:02 AM
#27
Posted 01 July 2020 - 05:08 PM
Well, I can confirm that the "magically" unplethoric winsxs folder mentioned a few posts above works perfectly on version 19041.329 as well.
#28
Posted 04 July 2020 - 08:27 PM
#29
Posted 05 July 2020 - 07:43 PM
So, what do you suggest I do after deleting what is not required at boot?
#30
Posted 06 July 2020 - 04:14 PM
for the time being, here is my new winsxs (70megs), after cdob's suggestions. In order to integrate cdob's idea (faster ramloading), I would like to say that even for normal loading would I like to have as small a vhd as possible; not only would I be happy to see my system startup, but I would also like it to perform the same operations as when the winsxs folder size was 90megs. I use windows as a "shell"; for the rest I rely on as many portables (standalone no-install executables) as possible. I would place the juctions cdob hinted at in his last post, if only I knew what to link to what.
#31
Posted 06 July 2020 - 04:14 PM
for the time being, here is my new winsxs (70megs), after cdob's suggestions. In order to integrate cdob's idea (faster ramloading), I would like to say that even for normal loading would I like to have as small a vhd as possible; not only would I be happy to see my system startup, but I would also like it to perform the same operations as when the winsxs folder size was 90megs. I use windows as a "shell"; for the rest I rely on as many portables (standalone no-install executables) as possible. I would place the juctions cdob hinted at in his last post, if only I knew what to link to what.
#32
Posted 06 July 2020 - 04:14 PM
for the time being, here is my new winsxs (70megs), after cdob's suggestions. In order to integrate cdob's idea (faster ramloading), I would like to say that even for normal loading would I like to have as small a vhd as possible; not only would I be happy to see my system startup, but I would also like it to perform the same operations as when the winsxs folder size was 90megs. I use windows as a "shell"; for the rest I rely on as many portables (standalone no-install executables) as possible. I would place the juctions cdob hinted at in his last post, if only I knew what to link to what.
#33
Posted 06 July 2020 - 04:15 PM
for the time being, here is my new winsxs (70megs), after cdob's suggestions. In order to integrate cdob's idea (faster ramloading), I would like to say that even for normal loading would I like to have as small a vhd as possible; not only would I be happy to see my system startup, but I would also like it to perform the same operations as when the winsxs folder size was 90megs. I use windows as a "shell"; for the rest I rely on as many portables (standalone no-install executables) as possible. I would place the juctions cdob hinted at in his last post, if only I knew what to link to what. winsxsdir.txt 1.17MB 7 downloads Capture.PNG 932.38KB 2 downloads
#34
Posted 06 July 2020 - 04:24 PM
sorry about the triple posting, but I had some trouble sending it and thought I had not sent it in the first place.
#35
Posted 06 July 2020 - 04:25 PM
sorry about the double posting, but I had some trouble sending it and thought I had not sent it in the first place.
cleaned up
#36
Posted 06 July 2020 - 05:30 PM
So, what do I suggest I do after deleting what is not required at boot?
What's the request? Do you like a small WinSxS to boot only? Do you like a small WinSxS with addional funcitons?
To boot only: gdiplus and VC* are not required. They can be deleted.
However, if you launch a program after boot, then gdiplus.dll may be required.
Addional Junctions should work after boot, junctions to gdiplus and VC*
To boot only, keep the folders
WinSxS\amd64_microsoft.windows.c..-controls.resources_*_en-us_*\ WinSxS\amd64_microsoft.windows.common-controls_*\ WinSxS\amd64_microsoft.windows.i..utomation.proxystub_*\ WinSxS\amd64_microsoft.windows.isolationautomation_*\ WinSxS\Manifests\
Be aware: a hard link is not junction, this are different cases.
#37
Posted 06 July 2020 - 07:44 PM
So, is there anything I can do to hardlink gdiplus.dll, vc* and/or whatever to make everything work after boot? I have hardlinkshellextension - does that help?
#38
Posted 06 July 2020 - 08:04 PM
My dear cdob,
Of course I do want quick boots, provided they were of no hindrance to my normal everyday operation. as u were saying, for booting only those folders are needed, but then, exes dont work.
BTW
WinSxS\amd64_microsoft.windows.i..utomation.proxystub_*\
WinSxS\amd64_microsoft.windows.isolationautomation_*\
are not on my list,
at least to the best of my vision.
u mentioned junctions to gdiplus* and vc* to make everything else work after boot. - how do I link or junction or hardlink or do anything that wants doing to them?
#39
Posted 07 July 2020 - 04:32 AM
If you use the files at normal everyday operation, then keep gdiplus at WinSxS, hardlink to system32
Do you use VC* dll normal everyday operation?
Another question: do you use 32 bit programs at normal everyday operation?
#40
Posted 07 July 2020 - 02:02 PM
As for the hardlinks, shall I use hardlinkshellexrension or will u suggest a cmd string?
#41
Posted 07 July 2020 - 04:13 PM
the winsxs to system32 or system32 to winsxs? which is the link source?
#42
Posted 07 July 2020 - 05:20 PM
the winsxs to system32 or system32 to winsxs? which is the link source?
It is a hardlink, i.e. the link is hard , "original" and "copy(ies)" are ALL the SAME file.
If you prefer, any file, as seen in a DIR command or in Explorer is already a sort of hardlink to self, and any "additional" hardlink have the same "relevance" and "dignity", see:
http://www.flexhex.c...phtml#hardlinks
https://docs.microso...loads/findlinks
Wonko
#43
Posted 07 July 2020 - 06:07 PM
so, my humble question was "do I have to go to system32 and hardlink it to winsxs, do I have to go to winsxs and hardlink it to system32, or do I have to do nothing because each directory will take care of itself by itself?"
to give u a clue of my limits, I only junctioned directories and files. hardlinkshellextension offers the following options: symbolic link, junction, smart mirror, delorean copy, hardlink clone, symbolic link clone. before cdob's suggestions, I only used the first 2, the second for directories and the first for files (this one was the only option, so I did not even choose this one).
#44
Posted 07 July 2020 - 07:20 PM
or will u suggest a cmd string?
Yes, I'll suggest a cmd batch in future.
've to make some educated guesses to work it on most cases. AMD64/X86 comctl v5, comtcl v6 and gdiplus work different. Some patience please.
#45
Posted 07 July 2020 - 08:21 PM
of course, u have all the patience it takes from me. As a computer-half-illiterate visionary, I envisage an enlightened and enlightening databank as to a scheme whereby one can see what to safely delete and what not. I am sure not all we have on c:\ (vhd.vhd) is really needed for boot and normal everyday operations. me I will post a list of the little I have installed, I guess it will not reach the end of a page. the rest on my system is managed thru portables.
Attached Files
#46
Posted 08 July 2020 - 07:22 AM
so, my humble question was "do I have to go to system32 and hardlink it to winsxs, do I have to go to winsxs and hardlink it to system32, or do I have to do nothing because each directory will take care of itself by itself?"
to give u a clue of my limits, I only junctioned directories and files. hardlinkshellextension offers the following options: symbolic link, junction, smart mirror, delorean copy, hardlink clone, symbolic link clone. before cdob's suggestions, I only used the first 2, the second for directories and the first for files (this one was the only option, so I did not even choose this one).
Yep, you miss some concepts, hence I provided you a couple links to study, those are not "limits" or however you can go easily beyond them, see also this:
https://web.archive....at-are-they-for
And the Italian Wijipedia page:
https://it.wikipedia...egamento_fisico
A hardlink is ONLY for single files.
The file does NOT exist in system32 AND it does NOT exist in winsxs, it exists ONLY on one or more extents on disk that is/are addressed by the filesystem structures (basically the $MFT) as EITHER \...\System32\<file> OR by \...\Winsxs\<file>, etc..
This addressing is ALREADY a sort of hardlink, let's call it hardlink 0, when you see a file in a DIR or in Explorer, like \...\System32\ gdiplus.dll you are seeing what essentially is a representation of the corresponding $MFT record, let's say $MFT#1234, you can think of it as:
\...\System32\ gdiplus.dll=$MFT#1234
nothing prevents you from adding one or more other hardlinks, with different paths and also different names, this hardlinks table will look *like*:
\...\System32\ gdiplus.dll=$MFT#1234
\...\Winsxs\ gdiplus.dll=$MFT#1234
\..\pippo.xxx=$MFT#1234
\..\pluto.yyy=$MFT#1234
If you prefer, hardlinks are (multiple) definitions of the same physical data.
And these definitions have all the same "dignity" as an example, as long as one of such definitions exist, the physical data is not deleted.
You can have a file that you can initially access as:
\...\System32\ gdiplus.dll
to which you make a hardlink as:
\...\Winsxs\ gdiplus.dll
or a file that you can initially access as:
\...\Winsxs\ gdiplus.dll
to which you make a hardlink as:
\...\System32\ gdiplus.dll
it makes no difference in practice.
A junction or symbolic link is instead more something "added" to an existing path or "around it", think of it as it being an alias, if you make a symbolic link to \...\System32\ gdiplus.dll (remember junctions are for directories/folders only, symbolic links can be for either file or directory/folder), in \\.\WinSxs\gdiplus.dll it is liike it was an "outer" container, you can think of it as:
\...\WinSxs\ gdiplus.dll=(\...\System32\ gdiplus.dll)
If you prefer, junctions or symbolic links are (multiple) redirections to the same address of the given physical data.
I hope it is more clear now.
Wonko
#47
Posted 08 July 2020 - 08:55 AM
#48
Posted 08 July 2020 - 12:29 PM
I have just finished reading the documents u linked for me, wonko, but, as I was saying, it still remains obscure to me why one should create a hardlink to something which is already there. Of course I have no problem undestanding the other links, which link files or directories which are ELSEWHERE, a.k.a. NOT HERE:
#49
Posted 08 July 2020 - 12:56 PM
I have just finished reading the documents u linked for me, wonko, but, as I was saying, it still remains obscure to me why one should create a hardlink to something which is already there. Of course I have no problem undestanding the other links, which link files or directories which are ELSEWHERE, a.k.a. NOT HERE:
By elsewhere you probably mean on another volume, but junctions/symbolic links can also be on the same volume.
Imagine that some service/windows/routine/etc. wants (needs/checks/etc.) a file gdiplus.dll in \\.\WinSxs and that another program/windows/routine, etc.wants a file gdiplus.dll in \..\System32.
On a FAT fileystem[1] you have no choice but to have two copies of the file, one in \\.\WinSxs and one in \..\System32, on a NTFS you have one copy of the file and two hardlinks to it.
In practice, in certain situations, as an example in the early stages of booting, a soft link address may not (yet) be resolvable whilst an hardlink already works (basically because there is nothing to resolve).
Wonko
[1] actually it is possible - but out of specs - to define a same extent twice or more in FATs
#50
Posted 08 July 2020 - 01:49 PM
I see it more clearly now. well, do u not think registryfirstaid will do the job by pointing routines to the same one and only lonely location of the file? if it will, I run it on a weekly basis and it changes a lot of stuff direction-wise, so in ur example, it would point the second routine or process to the system32 file location, if I am not mistaken.
ps, by elsewhere yes I did actually mean anyplace other than c:\
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users