00:35:44  * auroraeosrosequit (Quit: Leaving.)
01:01:32  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:30:48  * sungami_joined
01:30:48  * sungami_quit (Changing host)
01:30:48  * sungami_joined
01:31:46  * sungamiquit (Read error: Connection reset by peer)
01:41:38  * jgmdevquit (Remote host closed the connection)
05:33:30  * madewokherdquit (Ping timeout: 252 seconds)
06:08:55  * Jonny5joined
06:08:55  * Jonny5quit (Changing host)
06:08:55  * Jonny5joined
06:10:56  * TReKiEquit (Read error: Connection reset by peer)
06:13:11  * TReKiEjoined
06:18:44  * sungami_quit (Remote host closed the connection)
06:54:47  * sungamijoined
06:54:47  * sungamiquit (Changing host)
06:54:47  * sungamijoined
06:55:23  * ender`joined
08:16:28  * Jonny5quit (Quit: Leaving.)
09:43:23  * cH40z-Lordquit (Read error: Connection reset by peer)
09:44:08  * cH40z-Lordjoined
11:03:15  * [[zzz]]joined
11:06:36  * [[zz]]quit (Ping timeout: 246 seconds)
11:14:10  * piscisaureus_joined
11:49:03  * sungamiquit (Remote host closed the connection)
11:49:53  * piscisaureus_quit (Ping timeout: 240 seconds)
12:08:31  * sungamijoined
12:08:31  * sungamiquit (Changing host)
12:08:31  * sungamijoined
12:47:09  * TReKiEquit (*.net *.split)
12:48:59  * TReKiEjoined
14:05:49  * [[zzz]]changed nick to [[zz]]
14:09:49  * piscisaureus_joined
14:19:51  * vpovirkjoined
15:08:29  * virmitiojoined
15:39:55  <vpovirk>man, the more I think about reinventing sxs, the more terrible an idea it seems :/
15:52:54  <virmitio>vpovirk: reasoning? (I'm not disagreeing, just wondering how you're getting there.)
15:53:50  <vpovirk>well, currently I'm worrying about interaction with the real sxs
15:54:43  <vpovirk>and I'm just not sure there's a good place to hook the loader
15:56:03  <vpovirk>at least on Wine, ntdll doesn't call LdrLoadDll recursively for dependencies; I believe it calls some internal function for deps instead
15:59:38  <vpovirk>I think the need for that has to do with calling DllMain/PROCESS_ATTACH in the correct order..
16:25:25  <Dark-Star>why would anyone want to reinvent sxs?
16:26:56  <vpovirk>we want to use it to do things it wasn't designed for
16:27:16  <virmitio>case example: publisher forwarding
16:28:15  <virmitio>person A who has been building and publishing assembly "foo" for years is no longer maintaining it, but trusts person B to continue the work
16:28:59  <vpovirk>I had no idea that was a concern
16:29:08  <virmitio>under current SxS, the only way for old-"foo" assemblies to forward reference new-"foo" assemblies would be for A to give their private signing key to B
16:29:19  <virmitio>that would be bad
16:29:49  <virmitio>another case example: extention awareness
16:29:57  <virmitio>*extension
16:30:29  * piscisaureus_quit (Ping timeout: 246 seconds)
16:30:58  <virmitio>I have two separate installs of PHP (for example) on a machine, both of the same version
16:31:57  <virmitio>if there's a module I want both to use that is in SxS, both installs need to be made explicitly aware of the extension
16:33:09  <virmitio>installing a new module assembly to SxS would not make it visible or discoverable from any program which was not already manifested to find that specific extension beforehand
16:34:42  <virmitio>now suppose that I've manifested up both of those installs to use module A in SxS. If I build a new version of that module myself (cannot strong name with identical keys as the original), neither install will be able to locate and use the version that I just build myself
16:40:14  <virmitio>building an enhanced style of SxS (we're calling it SxS+ at the moment) will make thes trivial problems instead of "you can't do that" problems
16:53:52  <Dark-Star>these sound like tricky problems to solve...
16:54:05  <virmitio>true
16:54:42  <virmitio>but at present they would need to be solved in a haphazard manner, on an individual and case-by-case basis
16:55:02  <Dark-Star>so you're building atop SxS? or can you replace/re-create it in usermode? or will this be a pure source-code solution (i.e. needs source patches to work)?
16:55:08  <virmitio>and at that they would still be very clumsy and partially functional work-arounds
16:59:12  <virmitio>the present plan as I'm aware of it is that it will be a separate mechanism located elsewhere on the system. It will not conflict with existing SxS assemblies and storage, and would operate by two available mechanisms: 1) source-side include to replace loadlibrary calls with our SxS+ lookup, or 2) a runtime redirection of such calls to our lookup.
16:59:43  <virmitio>lookups to SxS+ would fail over to SxS and local file system locations to locate the specified library
17:00:38  <virmitio>(I'm a little fuzzy on the exact lookup order because this was discussed with me last week and I haven't looked at my notes since then.)
17:01:23  <Dark-Star>if you do 2), wouldn't there be no need for 1) at all? also, I'm curious how Windows Defender etc. react when someone hijacks LoadLibrary() through a DLL injection (or is there any other, legal, mechanism for such things?)
17:05:01  <virmitio>Dark-Star: Excellent questions. I'm sorry you asked. I know that these have been asked before but I cannot recall the answers that were found, and the two individuals who are most familiar with those methods are missing from the channel at the moment.
17:05:15  <Dark-Star>also I see problems with the source code approach, in that you probably can't mix SxS+-aware apps with (say) non-SxS+-aware DLLs/extensions...
17:05:46  <virmitio>why not?
17:05:51  <Dark-Star>yeah, no problem, I think I'm probably (hopefully ;-) not the first one to have these questions in his mind :)
17:06:56  <Dark-Star>non-sxs+-aware apps would bypass the SxS+ code path and thus end up with different builds of a common library (say, libz.dll, or something) so you have 1 lib in 2 different versions (and probably different compilation flags, calling conventions, etc.) in memory
17:07:21  <Dark-Star>I'm not sure if there's indeed any problem, that's just what came to my mind while thinking about it :)
17:08:08  <virmitio>seems a reasonable concern
17:09:14  <virmitio>I'll see what can be done to thoroughly test a setup of that sort once we've got a functional prototype
17:09:30  <Dark-Star>I see the calling conventions as the biggest problem, there are some projects out there that use _fastcall for everything, and they bring their own DLLs. If step 2) would then inject a "matching" DLL the program would simply crash
17:10:29  <Dark-Star>in the past, OpenTTD would have been a reasonably weird testcase for that, although I don't know if they switched to stdcall by now
17:12:01  <Dark-Star>the good thing is that stdcall vs. fastcall can at least be detected on DLL load time because the name mangling is different. Debug-vs-retail, however, cannot
17:13:28  <Dark-Star>brb, windows updates
17:13:57  * Dark-Starquit
17:19:04  * FearTheCowboyjoined
18:46:10  * ender`quit (Quit: Religion is like a blind man looking in a black room for a black cat that isn't there and finding it! -- Oscar Wilde)
19:14:58  <FearTheCowboy>Pity that Darkstar didn't come back.
19:15:13  <FearTheCowboy>I'm thinking that we're not going to replace SxS with SxS+, but more offer both.
19:15:55  <FearTheCowboy>There's nothing terribly wrong with SxS for shared libraries, it just doesn't support the extension/plugin model, and it's literally just as much work to add that to replace it.
19:16:02  <FearTheCowboy>(actually more to add, than to replace)
19:17:10  <FearTheCowboy>so I think that our shared library assemblies will both register into SxS and register in the SxS+ system (which will track where that library is in the real filesystem, so that we can locate it later.)
19:17:42  <FearTheCowboy>Although supporting old-fashioned SxS is gonna be tricky on offline systems.
19:18:34  <vpovirk>so, no linking using sxs+ without explicitly calling loadlibrary?
19:19:41  <FearTheCowboy>Not initially; but we can solve that problem too, but it's not as high a priority.
19:20:12  <vpovirk>what about xcopy deployment?
19:21:09  <vpovirk>currently we don't have any code in our native library packages that would care, but that can change
19:21:24  <FearTheCowboy>I've been working on a model that allows that too. I think we can leverage the existing search order for local SxS for that
19:21:24  <vpovirk>(and is mostly because sxs+ doesn't exist yet)
19:22:22  <FearTheCowboy>Well, SxS+ (perhaps I should call that SxS& :) ... is a lot different that I was originally (months back) thinking... and, yeah, it's gonna take a few months to get there
19:22:46  <FearTheCowboy>on the up side, I've gotten the Nuget folks to agree to supporting native libraries for C/C++ correctly
19:23:08  <vpovirk>cool
19:23:10  <FearTheCowboy>And in a way that's actually supported by Visual Studio
19:23:32  <vpovirk>how is "sxs&" pronounced?
19:23:39  <FearTheCowboy>side-by-side-and ?
19:23:40  <FearTheCowboy>lol
19:23:41  <vpovirk>"side by side ref"?
19:24:14  <FearTheCowboy>I talked with the Chocolatey guy.
19:24:32  <FearTheCowboy>Think we're just gonna provide a way his crap can be tolerated in the Unified model, but his code is for shit.
19:24:52  <FearTheCowboy>it's all powershell scripts, and not very appropriate anyway.
19:25:19  <FearTheCowboy>but, we should be able to use that for 'faux-packages' in the nearer term, which is flexible, if a tad dirty.
19:26:17  <FearTheCowboy>And I've spent the last couple days working with Rob Mensching (WiX) and I think that we're coming up on a better integration with what they are doing.
19:52:36  * FearTheCowboyquit (Ping timeout: 244 seconds)
20:22:29  * FearTheCowboyjoined
20:55:35  * piscisaureus_joined
21:47:59  * vpovirkquit (Remote host closed the connection)
22:15:47  * Gunniquit (Quit: now entering real-life...)
22:16:58  * Gunnijoined
22:17:03  * Gunnipart
22:19:14  * madewokherdjoined
22:42:11  * Dark-Starjoined
23:43:56  * virmitioquit (Quit: Leaving.)