Windows 7 (7057) on Acer Aspire One

I'm running Windows 7 build 7057 (appears to be RC1) on my $299 Acer AsipreOne netbook from Costco and it works great! Win7 even found the built in Webcam! The latest install went just fine, booted off my USB key and did an upgrade from the earlier version of Windows 7 I was running (build 7000). Only problem was there were 4 devices listed as "Base System Device" in device manager on the machine -- they'd been unknown in build 7000 too.

In device manager these devices were listed as Vendor 197B and device 2381, 2382, 2383 and 2384. For those googling, this would be device IDs (as an aside, anyone know of a centralized list of these?):

  • PCI\VEN_197B&DEV_2381
  • PCI\VEN_197B&DEV_2382
  • PCI\VEN_197B&DEV_2383
  • PCI\VEN_197B&DEV_2384
Everything seemed to work, so I wasn't that worried about it, but I hate having unknown devices. So after some digging I determined that Vendor 197B was JMicron so I guessed these had to do with the card readers on the netbook. This was odd since the card reader was recognized by Win7, but then again, I'd tried to use an SD card for ReadyBoost, and while Windows found the device, and tried to create a ReadyBoost file on it, Windows would always then pull the file off, saying there had been an IO error.

A little hunting led me to an FTP site for JMicron's drivers, specifically ftp://driver.jmicron.com.tw where, within the /jmb38x/XP_Vista folder there are a list of drivers for the missing devices. Odd, since these are WHQL certified drivers, I would have thought that the centralized Microsoft repositoy in the sky would have found them. Maybe because they're certified for XP and Vista but not Win7?

I downloaded the JMB38X_WinDrv_R1.00.26_WHQL.zip driver and installed it. Worked like a champ! I now have four JMicron devices listed under the "Memory Technology Driver" branch on the device tree, and readyboost now seems to like my SD card too!

Added 15 Oct 09 I'm upgrading my netbook to the RTM version of Win7 and I see that JMicron now has version 34 of the drivers out, and they are Win7 certified now. Available at the same download location.

LISUG iSeries Debugging Presentation

Gee, an attempt at LiveBlogging! I'm sitting at the March LISUG meeting at the Fox Hollow listening to Charles Guarino's presentation on debugging applications on the IBM i.

The first thing that dawns on me is the relative ignorance of the user base with regard to the options for developing applications on the i with a rich IDE like RDi, as opposed to something like the old tired SEU. RDi and it's predecessor, WDSC, have been available for years, and provide a much richer development experience than SEU. Face it folks, this is the 21st century (has been for a while) and we should all be using 21st century tools. The second thing that amazes me is that it's a big deal that the new RDi runs on machines with 512M of memory. Folks (I like that word today) go read Joel Spolsky's blog about writing better code, especially #8 and #9.(and he puts his money where is mouth is). 512M? I think I have that on my video card!

Into the actual presentation... First part is an overview of the RDi tool. RDi is based on Eclipse and as such has all the features of Eclipse; this includes perspectives, GUI interface, drag/drop, keyboard shortcuts, etc. Again, the fact that this is cool and needs to be highlighted shows the current state of development tooling in the i community. For those of us in the Microsoft community using Visual Studio, or for many Java developers, having to highlight these capabilities is like having to highlight that the room you're sitting in today includes gravity and oxygen -- "like, no d'uh"as my kids would say.

Important step, you've got to start the "debug server" on the i. Since RDi is running on your PC, and the PC (obviously) can't run IBM i programs (RPG, Cobol, etc.) the program must run on the i; and there must be some sort of interface between the program being debugged on the i and the debugger running on the PC. The Debug Server is this interface. One Debug Server can handle all the programmers on the machine, so it only needs to be started once. It can be started from the command prompt too (STRDBGSVR), so you might as well just put it in QSTRUP and forget about it, at least on partitions that have active development.

OK, now we're getting to the meat of the presentation, an example program that Charlie will be debugging from within RDi. We're going to debug a SAX XML parser written in freeform RPG (so much for simplicity :-)) . The program seems to read a table to find the list of files in the IFS to parse, and then for each file found, parse it, and do something. To debug a program you simply right-click on the program and select debug. You need to have compiled the program with DBGOPT(*SOURCE), but that should be your default compile setting anyway. You set a service entry point and then click ok. This then connects to the debug server on the i and starts your debug session. A nice feature here is you can actively debug multiple jobs at the same time, remember you're limited to one STRSRVJOB at a time on the i. When you started the debug session you specified a user profile; this user profile tells the i what job(s) to debug. The i will debug the next call to the specified program by the specified user. This is how RDi, the debug server, and the green screen are all linked together.

From w/in RDi you now have access to the program in debug mode. We can do the typical things we would expect to do in a debugger. We will see the variables and the source. We can step though the code with F6 (was F10 in STRDBG) and jump out with F8 (F12 in STRDBG). A nice feature here is that you can click on the "blue dot"on the right side of the screen, and the editor will jump to the current line. Also on the right side are a number of icons that will show you different views, like breakpoint view, or variable view. Of course, being Eclipse based, I'm sure you can rearrange these windows any way you want. RDi also includes the ability to hover over a variable and see the current value. Typical rich IDE debug stuff, but a nice addition to the tools a typical i developer is used to.

This is where things start to go wrong for Charlie -- and while it wasn't my fault it's kind of funny that it goes wrong after I asked him change the value of a date field to '2009-02-30' using the debugger. Actually, until now he's been using a Verizon aircard to connect to his machine in his office so he could show us the use of RDi live. Unfortunately the Verizon coverage around the Fox just isn't up to par and the connection dropped several times. So off to the slides now. Thankfully Charlie is prepared enough to have slides to show. But a nice addition would be to actually record a debugging session with Camtasia and then we could have seen it in action, even w/out a connection. This is also when my netbook's battery died, so the rest is from memory; and I've got poor memory. :-) From slides Charlie does show several steps in the debugging process, but he really needed that connection.

Overall, RDi does provide a much richer interface for debugging (and coding) applications for the i, and everyone should be running it. It's a shame that companies aren't willing to spend the $800 for the tool, and the $500 for the machine to run it. After all they're spending 80 to 100K on each of the developers writing the code, and that's a yearly expense, where the tooling and hardware would be amortized over several years.

In conclusion, great job Charlie. Just wish Verizon had behaved more!