Microsoft

Stories about Microsoft, Windows, Office and so on

New computers – Windows 7 – compatibility (3) – Epson (and hardware in general?)

Having gotten some of the software and XP Mode problems out of the way, I now need to install some of the old (and some new) hardware to the new desktop.

The HP LaserJet P1005 installed just fine as soon as it was plugged in.

I suspected that the Epson Stylus CX6400 wasn’t going to be quite so simple, since I recalled having to run the install software before I connected it the last time.  And, yes, sure enough, the installation software (once I found the old CD and instructions) didn’t run under Windows 7.

So, off to Epson.  I checked under Drivers and Support, specified my “All-in-One” (it’s get a printer, a scanner, and some memory card readers), and asked for Windows 64-bit drivers.

Now out of Epson EasyPrint v3.10, ICM Color Profile Module Update v1.20, TWAIN Driver and EPSON Scan Utility v3.04A, TWAIN Driver and EPSON Scan Utility v2.68A, and Printer Driver v5.5aAs which would you pick?  Yeah, I didn’t know either, and the descriptions weren’t an awful lot of help.  But I knew (from the dim and distant past) that TWAIN (we used to say that it stood for “Technology Without An Interesting Name) had something to do with scanners, and the v2.68A was listed for 64-bit only, so I chose that.

It ran.  After a while I got the scanner part of the Windows Fax and Scan program.  It didn’t have many options.  Epson Scan had been installed, but it insisted that it couldn’t run, and Epson Scan Settings insisted the scanner wasn’t installed.  I used the troubleshooter (seemingly provided by Epson) but it was no help.  I rebooted the computer: that was no help.  I tried help and searching on the Epson site: you guessed it, no help.

I did some Google searching.  Found a mention of device drivers, and having to uninstall the Microsoft brand, and install the proper Epson driver.

Well, thought I, I installed this with installation and setup stuff from Epson: surely Microsoft wouldn’t have messed it up in that short time.  But I had a look at Device Manager anyway.

And, lo and behold, the driver that was installed was signed by Microsoft.  Uninstalled that, searched the disk for related drivers, found two.  One was for CX6300/CX6400, and one just for the CX6400, so I installed the latter, on the theory that the more specific was more likely to be from Epson.

And now Epson Scan is happy to run.

(I also installed the original XP software from the CD within XP Mode.  That didn’t work …)

New computers – Windows 7 – XP Mode fixes

I think I may finally be getting the hang of this XP Mode thing.  (I may also be fooling myself …)

As previously noted, XP Mode doesn’t access the “real” drive, but a virtual drive which is contained in one large file.  (Actually, seemingly a minimum of three, but only one appears to contain the drive “contents.”)  XP Mode does provide you with links to the real drives on the computer, but, while accessible from most Windows programs, since they are not mapped to drive letters, you cannot do anything with DOS programs, even though such programs run under XP Mode.

I figured I would have to create the directories, with files I wanted to work on, within the “virtual” drive, and, each time I made any modifications, remember to copy the new versions back to the “real” disk so they could be used under Win7.  Not only is this a nuisance, but it wastes disk space.  XP Mode takes up enough space as it is: starting at about 1.5 gig, by the time you get it up to speed with Windows updates, it has ballooned to 6 or 7 gig.  Any programs or file space you want come on top of that.  (And, since I no longer trust XP Mode to stay stable, I have been making backup copies as I have been doing the updating and adjusting of the virtual machine, wasting even more disk space.)  An annoyance, to say the least.

I can’t remember where I found it, but somehow I noted a reference to the actual description, within XP Mode, of the links to the real drives.  It looks just like a network reference to a shared resource.  So I tried mapping that format and creating a DOS “lettered” drive mapping (from within XP Mode).  So far it seems to work fine.

For those who’d like to try, the “network” name of the real computer seems to be TSCLIENT.  So, in order to create a link to the C: drive on the real computer, map to \\TSCLIENT\C .  (It does not seem to matter what your real machine’s name is, that name does not seem to be used in the reference.)

The MSRC – now and then

It’s amazing to compare how the Microsoft Security Response Center handles vulnerability disclosures versus how things were just 10 or 12 short years ago.

Here’s a typical disclosure process 10 years ago (based on a very true story):

Us: (sending an email to secure@microsoft.com) we’ve discovered a vulnerability in an office product. Here are the technical details. Can you confirm the issue and let us know when it’s patched?
Microsoft: Thanks for reporting, bla bla, we’ll get back to you soon

[about a week passes]

Us: Hi MSRC, any news about our office vulnerability?
[no reply]
[Sending a personal email to an MSRC friend to speed things up]
Microsoft: Oh, thanks for reminding us. We’ll check with the office team

[another few days pass]

Us: Hello? Anybody there?
Microsoft: Oh, yes. That vulnerability thing. Here’s what we decided: (a) It’s not a vulnerability. (b) it’s not a problem with the office product but with the world (or the RFC) (c) The office team can’t recreate it (d) even if the vulnerability was real, it wouldn’t be exploited in real world scenarios
Us: are you kidding us? Did you actually look at the sample code we gave you?
[a few days pass. We are pondering if to go complete full disclosure or give them time to digest]

Microsoft: Ok, this time we actually read your advisory and yes, it seems to work. But it’s just a denial of service. Nobody will ever exploit it because of … [something that heap spraying/DEP bypass/code mutation made look ridiculous about a year later]
Us: [starting the get mad] look guys. We sent you PoC code. You actually want us to write an exploit code for you?
Microsoft: yes, that would help convince our developers

[Us, spending time writing code so that Microsoft is convinced to fix their own products based on free information while wasting our precious time]

Us: here it is
Microsoft: oh, wow, it really does run code. Ok, we’ll fix it in the next release cycle which should be right after the democratic primaries of 2012.

Us: Ok, forget it. We’re going full disclosure

Microsoft: no, wait wait wait. We found your name on the world wide web and now realize you’re legit. Ok, we’ll fix it. Happy now? We might even mention your name in our advisory if/when that happens.

If it sounds familiar, that means you were disclosing vulnerabilities to vendors in the early 2000’s or late 1990’s. If you think I’m exaggerating, it’s only because you didn’t.

But here’s the amazing thing. Just a few years later, some radical changes started to happen. The big dysfunctional dinosaur that was MSRC became an efficient, friendly and if I didn’t know it, I would think it’s a different company altogether. Here’s a real recent discussion:

Us: Hello MSRC, here’s information about an office vulnerability
Microsoft: Hi, thanks for reporting. I checked the information, went over the sample code and have some technical questions [some intelligent questions here, basically they are doubting the findings but being really careful to check all the angles first]

[technical discussion continues for a couple of days with questions and answers going back and forth]

Microsoft: Ok, we get the picture now. Thanks for reporting. Here’s the guy that is going to be responsible for your case.
[a few days pass]
Microsoft: Ok, we now know it’s a […] vulnerability and not a […] one. We’ll pass it to the relevant team, just wanted to keep you posted
[further proactive updates and niceties continue until disclosure time. Credits, the end.]

What could have possibly caused this radical change that made MSRC focus on the technical side instead of the PR, not to mention being so research-friendly? New team? New procedures? Full disclosure forced them to see the truth? Too many beers at defcon finally showed them the light? Whatever they are taking, I wish they could spread some around. Most of the other vendors could use that. Yes, I’m looking at you Google.

New computers and old network problems

Well, I don’t know if this is a continuation in the “new computers” series, or just rehashing an old problem.

I’ve noted before the problem of the complexity of trying to establish an ad-hoc network under Windows.  And, I’m trying various things with the new Mac.  So, in a situation, right now, where I have one network cable, and two computers downstairs, I decided to see what an ad hoc network was like with a Mac.

I remembered to do the bridging thing on Windows, and I’ve set up an ad hoc network with a pre-shared key.  (At least, I think I have.  That seemed to be the way it worked, and the Mac connected with a password, but, on the Windows machine, when I go back and look at it, it says it’s open.)  The Mac wouldn’t show the network when I looked at the list, but, when I gave it the name and password it seemed to connect just fine.

I got a Web site correctly on the Mac.  Then I went to connect to the Windows machines as servers, and that worked out fine.  Then I went to do some work on the Web, and … nothing.  The Mac wasn’t able to get onto the Internet.  I was still connected to the Windows servers, but couldn’t get a Web page.

And, then, suddenly, I could, again.  And then I couldn’t.  (At the moment, I can’t.)  (Sorry, started working again just before I finished this entry.)
I’ll have to give it a shot with the Mac connected to the cable, and see if I can set up an ad hoc wireless connection that the Windows netbook can use, but, at the moment, Mac networking is not working any better than Windows in the ad hoc environment.

Roll on PopulistNet.