Making old hardware work with new software and vice-versa has always felt like the true "hacker spirit"; more so when source code isn't even needed, contrary to what many FOSS advocates think. Much like how you don't need the original design drawings and such to fix physical machines, but just need to understand what's wrong and how to correct it. This is also near right-to-repair.
It's also worth noting that "ezloader" USB interface was later acquired by Cypress and became the infamous FX2/FX2LP MCUs that popularised a lot of USB devices, including logic analysers.
(I usually do more of the latter, but the same skills are used.)
Good point about the Cypress acquisition. While I was investigating part of the driver code recently, I realized it was based on FX2 sample code. The development kit that I got, on the other hand, was pre-FX2. The article notes that Cypress acquired Anchor Chips, the original creator of EZ-USB, in 1999, which would seem to line up perfectly with the time frame in which the Pakon scanners were developed.
Oddly, there are files on the CDs that are dated after the date on the packing slip - several months after, in fact. So I'm not quite sure exactly how old my kit is...
> more so when source code isn't even needed, contrary to what many FOSS advocates think
Source code isn’t always needed, it just makes the process simpler and quicker. There’s way more old devices that people would like to continue to use than there are hackers with the time and skills to reverse engineer them! For example, I’ve been lurking on the Magic Lantern forums (alternative firmware for canon dslrs) and the time it takes to port the software to a new camera model is counted in years…
To reduce e-waste I think companies should be obliged to release the source code to their devices when they stop supporting them (and if they’re afraid of releasing trade secrets—they’ll just have to keep supporting them longer!).
Our company used to build 35mm film scanners, called Northlights, for film post-production.
Originally they were driven by SGI Octanes. Then x86 Linux machines. Biggest problem these days would be the interface cards. I believe we were stuck with PCI-X cards for a long time, requiring host machines capable of accepting them.
We still support them, as there are many still in active use on both new films and restoration/archival jobs.
TIL about PCI-X. Northlight looks like a pretty cool piece of hardware! It's cool to see what other obscure stuff is out there - that's why I like Hacker News :-)
Patched versions of the original drivers will be released, along with the new drivers. I'm not sure if I'll release the source code yet because of the legal gray area around this sort of work, but it's still something I'm considering.
I think it's less about "level of expertise" than it is about having a willingness to explore, learn, and analyse. IMHO working in ring0 isn't a huge change in difficulty than ring3, despite the different environment. Device drivers are mainly libraries that translate between interfaces.
> First and foremost, for reasons that are unclear to me, ObfDereferenceObject is exposed to driver developers through a macro3 called ObDereferenceObject. I don’t understand what the point of this even is, but in any case, we can find the documentation for the macro here.
Emphasis mine. The reason why this is done in big projects is adding just one more level of abstraction to be able to preserve how userland interacts with your library, but still allowing you to make underlying structural changes to the code.
Kai, could the author please share your port of the 64 bits driver? I happen to own a F135. Thanks in advance.
Great article, it brings back some memories.
The custom drivers will be released soon :-) If you're not in the Pakon Facebook group, I recommend requesting to join it, since there's a lot of useful information there.
This is pretty cool. Would you consider releasing the reverse engineered source code? I imagine that could be pretty helpful for anyone dealing with future OS changes (perhaps trying to make this work on Windows ARM for example, or even linux), and while it's probably technically against the license agreement, I can't imagine anyone would care much about such old software that's no longer maintained.
Like steve_austin said, releasing the code is in a grey area. Realistically, it's highly unlikely that anyone would actually be upset about it, so it may happen in the future.
Linux support is a completely different beast. There is a lot of code that I didn't talk about, including the absolutely massive image post-processing/color-correction library that we only have a Windows version of (and no source code for, obviously.) The Pakon's added complexity (especially automatically finding frame boundaries) makes a cross-platform, source-code-less port extremely unlikely to succeed in a remotely reasonable amount of time.
Perhaps share the code privately with someone in another jurisdiction that is more suitable (reverse engineering laws, copyright, whatever), and that person can take the legal liability? Perhaps someone who owns a scanner like user yesimahuman in this thread?
In theory it's unnecessary. The problem is that one of the main selling points of the Pakon is its convenience - then again, if somebody wants to do things the hard way, who am I to stop them?
I don't have any plans to develop a cross-platform client, but I will be publishing more technical information about the scanner so people aren't left wondering what I know.
It seems like a grey area. Especially given that the driver is a mash-up of sample code from a third-party hardware SDK and a Microsoft book, would Kodak/Pakon really care?
I would think the only part of the software that still might retain trade secrets would be the color management code, and that's not in the driver.
Maybe there's a way to distribute dissembler hints and patches where you need the original driver files to get the source code. I assume the MS code has a reasonable license since it was published as sample code
> trade secrets would be the color management code
Are trade secrets even protected? If there's a patent, yes, but that's expired. The implementation is protected by copyright, but the know-how isn't.
Kodak sold a lot of their patents to other companies as a result, IIRC, of their bankruptcy. I'd have to look at the patents for this particular system again, because I can't remember if they were ever reassigned or if they were simply allowed to expire.
I don't think reassignment changes the duration of the patent. Looks like the early versions of the devices came out in 2004, so it's getting really close to when they'd expire.
IANAL, but my concern would be distributing either the original drivers or 64-bit drivers, but in practice, no one is going to care. It's not worth an hour of a lawyer's time to send a cease and desist letter for distributing driver source for an 18-year-old device.
It would be awesome to have the scanner supported with an open source driver in SANE, which now has an IPP module, so this would enable doing film scans from a smartphone :)
Very cool! I own a Pakon F135+ and using it through a VM has worked well enough for me, but I’ve always wanted someone to modernize the tooling so that wasn’t necessary. Thanks for putting in the work here!
By popular demand, the article now has a picture of the scanner I have access to - an F135 Plus - with a bit more information about how it's used. For those who wish to see an F235 and/or F335, I recommend Google Images, since I'm not going to use someone else's pictures without their permission.
>In the course of this article, the Pakon film scanners went from being a user’s nightmare to being totally usable with modern versions of Windows.
Right, but I think it's still nightmare because Windows require driver signature verification by default. But why there's dedicated kernel driver at all? I wonder how feasible would be transplating decompiled driver code into userspace shim that uses WinUSB.
>I think it's still nightmare because Windows require driver signature verification by default
I've taken care of that already :) My custom drivers are properly signed and basically ready to release once I tidy up some loose ends.
I'm not entirely sure if this really needs to run at the kernel level. In the future I might investigate converting it to a user-mode driver, but for now I think a signed kernel-mode driver will suffice.
I had help, but yes. I think it's worth the cost to give people peace of mind that they won't have to disable some of the most important security features available to them in order to use a scanner.
I own Nikon CoolScan 9000, which I picked up for cheap without film adapters/holders. It takes me more than year to find 120 film adapter on EBay and it cost me as good flat-bed scanner alone.
But, boy, quality of scans of good 120 slide film! I never liked colour negatives, but MF Velvia 100F is a magic!
The service manual recommends hitting the film channel with compressed air every couple of weeks. If you do that and keep it covered when not in use dust is not an issue.
The way the scanner deals with dust is by complaining that there's dust :-) (It doesn't have a special dust error, AFAIK, but it does do some checks that will end up failing if too much dust has accumulated.)
The way to avoid dust accumulation is to keep it covered when it's not being used. That works nicely and is a reasonable thing to do anyway.
And please walkthrough the process so I may see whether to get one. Well last time I read about Paton around 2000 I presume : https://www.dantestella.com/technical/f235plus.html only 6Mpix but for quick and good scan great. He scanned 12,000 of his.
I don't plan on doing a walkthrough - the only reason I even touched a Pakon scanner was for development/testing purposes - but there's an abundance of information online that I'd encourage you to seek out if you're interested.
I've addressed this a couple of times in response to others, but the main problem is that there are multiple models that look quite different from each other. I could pick one, but that wouldn't be telling the whole story, or I could show them all and add extra clutter to the page.
That being said, I'll probably just pick a model and add a picture to the article. Google Images is good for finding the others.
I had never even heard the name "Walter Oney" before I started researching this thing. I was pleasantly surprised by how well his 20 year old code held up, though.
Indeed it does. I was born a few years later :-) That's what I love about "digital archaeology" like this - it's so much fun to find and explore things from a time you can't possibly imagine on your own.
Huh, I guess I should tell everyone I know that I don't exist ;)
In all seriousness, I like learning about things that were before my time, and that's why I use the term "archaeology." It's not really archaeology, since I know plenty of people who were alive at the time, but it still appeals to my inner curiosity.
And touch type. Or that while the internet is great, it should be viewed with a distance and skepticism.
Probably the biggest thing I wish I could share though is general civics and history knowledge. A lot got cut from education since then in the US. Plus what 90s America felt like-freedom before “terrorism.” (Quotes because there are many great books on all this that I’m not able to even point at right now.)
Apologies for jumping into code - this is "Hacker" News, after all. The feedback is still appreciated. I actually meant to include pictures but forgot :/
The practical results can best be described as 36 super high-quality TIFFs (if you scan a full 35mm roll) obtained in just a couple of minutes. You can find more information by looking at other online sources - one I'd recommend reading, if you're interested, is https://www.dantestella.com/technical/f235plus.html.
I'm not surprised that it's relatively unknown - after all, digital photography has mostly taken over, and even those people who benefited from drug-store film development/scanning probably wouldn't have cared too much about what hardware was in use.
It's also worth noting that "ezloader" USB interface was later acquired by Cypress and became the infamous FX2/FX2LP MCUs that popularised a lot of USB devices, including logic analysers.
(I usually do more of the latter, but the same skills are used.)