So now that I’ve played around with this for a few days, I have to say that
“windows containers” appear to be a moving target on WIn10. Building the
container on a current release works, building on an insider build is a
nightmare of inconsistent results. Once the container is built and
validated I think it is good to go on any supported platform, regardless of
where it was originally generated, but I haven’t verified that.
Of course I could do all of this on S2016 instead, but then I’d have to
deal with nested hyper-visors and that is another nightmare of what works
and what doesn’t…
Mark Roddy
On Fri, Jun 29, 2018 at 3:23 PM Mark Roddy wrote:
> Oh that is just the ticket. The container works great. Greatest container
> ever. Now I have to go convince it to build our stuff.
>
> Thanks Jakob!
>
> Mark Roddy
>
>
> On Wed, Jun 27, 2018 at 2:26 PM Mark Roddy wrote:
>
>> And I should read the thread to the bottom :-). That docker script looks
>> great. Will hack away at it.
>> Mark Roddy
>>
>>
>> On Wed, Jun 27, 2018 at 2:20 PM Mark Roddy wrote:
>>
>>> I looked at the EWDK as a starting point for a containerized build
>>> solution and gave up because it was just too huge to be a viable container
>>> image and there appears to be no reasonable way to get docker containers to
>>> use network share mount points. A msft supported docker image for each
>>> released wdk with reasonable size would be a huge win from my perspective.
>>>
>>> Mark Roddy
>>>
>>>
>>> On Thu, Jun 21, 2018 at 10:15 AM xxxxx@osr.com
>>> wrote:
>>>
>>>> (For those who may not be familiar with Mr. Lichtenberg… he’s the dev
>>>> lead for the WDK and related tools, and a LONG time friend of the driver
>>>> development community).
>>>>
>>>> Thank you, Mr. Lichtenberg, for jumping into the conversation. Your
>>>> help and insight is always appreciated.
>>>>
>>>>
>>>>
>>>> Honestly… the problem is that it’s very hard to narrow down. “Back
>>>> in the day” we might have had a driver and a (native) C/C++ test app in one
>>>> solution and that’s it. THESE days, that test app MIGHT be C/C++, or it
>>>> might equally be written in C#, or there could be a service in the Solution
>>>> (in C/C++ or C#), or it might be some UWP management app (OK, not really
>>>> the last of those… but someday, maybe).
>>>>
>>>> We could be convinced to build the user-mode parts separately (as a
>>>> separate Solution)… but we still have to build both parts (the driver
>>>> Solution and the UM Solution) as part of our CI process. So, bottom line,
>>>> we need to have a full-blown VS (to accommodate the various user-mode
>>>> options) and the driver part.
>>>>
>>>>
>>>>
>>>> That’s good news.
>>>>
>>>> One approach might be to (a) ship along with the WDK the pieces/parts
>>>> that are needed to ensure that tools work on Windows Server, (b) provide a
>>>> container with VS Community and the WDK pre-installed. Extra points for
>>>> having such a container on Docker Hub. How cool would THAT be??
>>>>
>>>> ANYhow… We still plan to give this a try, and see how it works.
>>>>
>>>> AND I hope there are others in the community who have tried this, and
>>>> can share the details of their experiences.
>>>>
>>>> Regardless, as I said, we’ll write-up whatever we come up with to help
>>>> those who come after us.
>>>>
>>>> Peter
>>>> OSR
>>>> @OSRDrivers
>>>>
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list online at: <
>>>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>>>
>>>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>>> software drivers!
>>>> Details at http:
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at <
>>>> http://www.osronline.com/page.cfm?name=ListServer>
>>>>
>>></http:>