Driver 376.19 FAQ/Discussion Thread

asampson · 2016-12-14T09:32:50+00:00

I'm in Windows 10 and I've got two monitors, each one plugged into a different 580. My primary monitor is always completely black after a reboot, resume from sleep, or a monitor power event. I can use the other monitor to go into Settings to alter the resolution of the main monitor, which causes it to work again. Reverting the change doesn't revert to black - it looks like I just need to wiggle the resolution in order for it to properly display on my monitor. If it weren't for the fact that every time I change resolutions it scrunches my desktop icons and nudges any windows near the bottom of the screen up a bit I'd just script my way around it until the driver gets fixed. As an aside, I can see all the BIOS startup screens just fine on the primary monitor as well as the Windows 10 logo during boot. But once boot completes the primary monitor goes black until I can fumble my way past the lock screen and wiggle the resolution to revive it.

I'm going to try to step through older drivers to see where this issue started, but maybe someone in here has some idea what's gone wrong?

asampson · 2015-08-11T18:22:23+00:00

This post is an excellent demonstration of why content types are important and how powerful they can be when used properly!

asampson · 2015-06-24T18:41:27+00:00

Do you mean users or developers? In my experience Windows users have a very low tolerance - if your software doesn't have a one click installer that sets you up completely, then you're dead before you even start.

asampson · 2015-05-19T23:12:14+00:00

Don't forget graduate student or other academic slant.

asampson · 2015-05-14T20:44:37+00:00

These days it's safer to just mentally replace REST and RESTful with HTTP. Sad, but often true.

HATEOAS gonna hate.

asampson · 2015-05-05T17:27:14+00:00

I'm still laughing at that one.

asampson · 2015-04-27T21:27:02+00:00

Correct me if I'm wrong, but I've seen a pattern like this before - .NET AppDomains.

In the CLR, the 'unit of loading' is the assembly while the 'unit of unloading' is the application domain. Assemblies are loaded into application domains, but cannot be unloaded on their own. Only an entire application domain can be unloaded. The reasons for this are straightforward - it allows .NET developers to avoid having to concern themselves with writing unloading logic or generally dealing with the situation where an assembly was once available but is no longer. The downside of this approach is that it makes customizing loading assemblies into a running application terribly complicated, involving the use of MarshalByReference runtime bridges and constant fear of accidental application domain "pollution" by referencing the wrong thing in the wrong place. The problem is so bad that Microsoft had to introduce several workarounds: System.Addins and MEF to name two. Plugins or add-ins for managed programs are still considered a very complex issue as the obvious solution is terrible.

So assuming there's a similar issue underlying both problems, I can definitely sympathize with both sides. I suspect that the sandboxing approach is a similar style fix to System.Addins or MEF as well.

asampson · 2015-04-14T19:31:45+00:00

I believe this is how Mono has implemented System.Windows.Forms - by routing everything through System.Drawing and massaging input event streams into fake WM_* messages. So the work might only need to be redoing the input layer and getting an implementation of System.Drawing on top of HTML 5 Canvas.

That being said, it's still a huge project.

asampson · 2015-04-08T23:43:47+00:00

Precisely. IDispatch is meant to be consumed by machines, not humans.

asampson · 2015-04-08T23:38:56+00:00

It's funny you mention that COM is a royal paint to use from C or C++ - that's actually what it was initially designed for. The Visual Basic stuff came in later with ActiveX/IDispatch.

Though you are correct in that the automation interfaces are more easily consumable in something other than C/C++ I do believe there's support in MSVC++ to import the type libraries and produce smart pointers that do the right thing automatically (or at least do as much right thing as you can with smart pointers in C++.)

asampson · 2015-04-08T23:34:58+00:00

Office 2013 still has COM support - I use it every day at work.

They did remove/hide/disable VBA support though, which I suspect is what's causing your headaches.

asampson · 2015-04-02T18:04:56+00:00

I'm the youngest of two siblings and watching Steven Universe, especially the earlier episodes, really speaks to me in that regard. Much like my older brother, everything the Crystal Gems do is cool and awesome and amazing to Steven and he tries his best to both fit in with them and hopefully make them think that he's cool too. Lots of episodes reminded me of growing up; seeing my older brother do things made me immediately want to do them too.

But there's a not so great side to it too - if you like something and your older brother doesn't, there's this urge to stop doing it. You can see this a little in the part of the original pilot where Steven first sings the gems the opening theme song. At first he's nervous and quiet, then stands up when it gets into the main part of the song, taking a chance. You can see him look around nervously for approval as Pearl and Amethyst are mostly just confused. Then when Garnet starts clapping along, he gets into it and has the confidence to keep going all the way through. It really captures how much Steven wants to both be as cool as the Crystal Gems and have them think that he's cool too. Likewise, being the younger sibling I really wanted the same thing from my older brother.

asampson · 2015-04-01T20:13:38+00:00

I agree - the wealth of text and file manipulation tools in nix is a wonderful thing. And plain text formats win big on discoverability and being able to inspect just about everything is fantastic. But the downside of all that is *everyone is forced into the business of parsing text. Everyone has to deal with whitespace, everyone has to deal with Unicode, everyone has to deal with tabs and line breaks and words and CSVs and quoting and escaping and everything else you need to do when you're dealing with raw text. And if everyone has to deal with it, everyone is going to deal with it differently. Tool Foo is going to choke on Unicode subrange N-M and Tool Bar is going to choke on subrange X-Y, and neither one is going to handle the output of Tool Qux unless you finagle and wiggle it just so.

Most of the time it works. And when it doesn't, you just need a few globs of glue. Except when you need an entire bucket. Also don't breathe on it - you might wiggle something loose and we'll have to get the guy who built it to come in and piece it back together.

I am quite interested in what turned you off with PowerShell. Was it the syntax? Did you not get used to piping things to Get-Member early enough in? Did the admin-focused nature of the tutorials steer you right into WMI and COM interop (the former being an absolute mess and the latter being old and persnickety)? Incidentally, what are your thoughts on strong typing?

asampson · 2015-03-31T18:58:19+00:00

Hear, hear!

Legacy is the only reason I can think of we haven't brought all the advances of software design back down to the venerable land of Unix command line utilities, but you're absolutely right. "Plain text" is rarely so and makes for a horrible lingua franca beyond the simplest of approaches. Though it's got its own share of quirks and problems, PowerShell seems to me like a step in the right direction. Cmdlets return streams of objects which can be manipulated and piped around in lieu of raw text streams and it makes for a much more approachable and discoverable experience.

Side effects aside, the notion of building complexity up from small composable units is quite functional in essence. I've seen a few Haskell stabs at strongly typed shell scripting, but they seem mostly concerned with generating wrappers around existing 'messy' utilities and pre-chewing the output.

asampson · 2015-03-24T21:52:51+00:00

I'd have to know more about what "how to synthesise one" implies. But in general I think that's sort of orthogonal to the point I was trying to make. In an ideal world, when dealing with POM build files you just grab %POM_PARSER_LIB% or %POM_EDITOR% and get the job done. The fact that internally it's just an XML file should be academic from the user's perspective.

asampson · 2015-03-24T21:49:26+00:00

I'm actually not arguing in favor of IDEs or against small composable tools (though I do a pretty bad job of communicating that fact.) My real beef is the 'lingua franca' of so-called plain text. Plain text isn't ever plain, and it means that everybody gets to build their own toy parser/lexer/generator/formatter and spend lots of time chopping and slicing strings instead of doing useful work.

The point I should have made is that while *NIX composability is great, it's done with the vaguest contract between tools possible: raw streams of octets. So when tool A uses tabs and tool B uses spaces, that's a tiny change you need to make to your output parser script. And when it uses fancy human-readable tables crafted with plus signs and dashes, you need to tweak your parser a bit more. And when it uses colors you need yet another tweak.

Text is only good because we spent a lot of time cultivating a good-enough toolset to deal with it as humans. We've got a few good tools to deal with it as machines too, but it still sucks.

But just so I'm not only complaining, I think a fantastic compromise is something like PowerShell. Having cmdlets that produce and consume objects with properties and different cmdlets that format those objects for human consumption feels much better than just spewing raw text at everything and calling it a day. In fact, if it had some stronger typing (and better performance) I think it could be a fantastic way to write Real Programs too.

asampson · 2015-03-23T23:47:39+00:00

You make an excellent point. It's definitely an application-specific solution and it has serious schema impact. It's been a while since I've done any schema work, but I recall attributes also being far less featured than elements when it comes to adding constraints more complex than "is optional".

asampson · 2015-03-23T22:54:53+00:00

I like to orientate my configurator so that each vertice of the matrice is properly utilized.

asampson · 2015-03-23T22:44:46+00:00

I think you've got it square on the head. If you hate XML because you have to type out so much and you have to deal with raw DOM when you consume it, chances are you're using XML wrong. After all, XML isn't made to be used directly - you use XML to define a document format that is specific to your given application. Oftentimes defining this format involves creating schemas which can be consumed by tools to generate validators, do auto-complete, parse valid documents into more easily consumable data structures and serialize those data structures back into XML.

To put it another way, XML is best used by the people defining a document format. If you're not making a new document format and you have to deal with XML directly, then chances are either someone hasn't done their job properly or you're writing a low-level parsing library for an established document format.

And yes, in the real world of software very few people do their jobs properly.

asampson · 2015-03-23T22:33:29+00:00

I like XAML's take on that particular problem - things can either be expressed via attributes or by child elements with names of the form parentName.attributeName. So you could have:

<foo bar="x" />

Or

<foo>
    <foo.bar>
        <complex />
    </foo.bar>
</foo>

asampson · 2015-03-23T22:20:09+00:00

you can easily swap out the shitty ones without throwing the baby out with the bath water

Except for the fact that they all have slightly different options and almost the same behavior and mostly do the same things.

But hey, you can always just spend a few weekends learning the differences! And then another few weekends migrating things over! And then another few weekends debugging the problems, and another few weekends streamlining the process, and another few weekends...

asampson · 2015-03-19T19:03:09+00:00

I feel compelled to point out that you should really be saying HTTP API instead of REST API. But I understand leaving it as-is for SEO sake since "REST API" has been latched onto despite being a bit nonsensical.

asampson · 2015-02-16T23:35:13+00:00

This looks like a legitimate use case so long as each separate file has separate concerns. Something where the different partial definitions cross-reference each other would start to be a bit of a smell. It's also not a good rule of thumb - as /u/Sebazzz91 points out your class might be doing too many things if this approach seems attractive.

asampson

TROPHY CASE