Someone I used to work for emailed me out of the blue and said they want me to update a VB3 (!!!) program I wrote for them because customers are reporting having problems running it under Windows 7. They have lost the source code (natch). Is there a decompiler for VB3?
For decompiling VB "DoDi VB3 decompiler" is the best tool available. The results are pretty good.
However the original is anno 1997. VB3 is 16 bit code only + still some bugs + no source code. These makes that tool hard to get running on windows beyond Windows XP and limits it's use.
DoDi's VBDIS3 it self is also written in VB3 - so about 10 years later just for fun I cracked it to make the decompiler to decompile it self.
... and ported it to VB6!
So now you've the source code !!! :D
... and it's 32 Bit code + some bugfixes and improvements to the original:
DoDi's Visual Basic 3 Decompiler [Reloaded]:
http://vbdis4.angelfire.com
Screenshoot:
in case that website get lost Google for
'VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z'
or try the internet archive
http://web.archive.org/web/20090301170633/http://vbdis4.angelfire.com
I remember looking for Visual Basic decompilers/disassemblers a long time ago to no avail. There may be things out there now though. The most I could come up with was PE Explorer: http://www.heaventools.com/overview.htm
Have you suggested running your application under Windows Compatibility mode: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
Edit: Further Googling: http://www.w7forums.com/visual-basic-3-0-compatible-64-bit-version-t5146.html
I maintain legacy 16-bit VB3 software
that is compatible with Windows 7 and
have done a lot of research in this
area.
16-bit applications will not natively
run in Windows 7 64-bit full stop.
This is because when a 64-bit capable
CPU is started in 64-bit mode, it
cannot change into 'real mode' (the
mode used by 16-bit applications)
without a hard reset. If a processor
is in 32-bit mode, it can swap between
real mode and protected mode at will.
The only workaround here is a virtual
machine- Windows 7 comes with a free
version of Windows XP which is usable
inside a custom version of Microsoft
Virtual PC. Google for "Windows 7
Virtual XP Mode". Once your copy of
Windows 7 has been validated as
authentic, it will allow you to
download Virtual PC and the XP Image.
It's definitely not a pretty solution,
but the only option for my customers
who have gone ahead and bought a
64-bit OS without checking to see if
their installed software is 64-bit
compatible.
Unlike the later versions which used native code and are generally not reliably decompilable, VB3 (and, I think, VB4) could be usually decompiled to almost original code. The keywords you need to search for are "DoDi VB3 decompiler" or "vb3dis". Here's a page that seems to have a copy.
Really? VB3, if it runs fine in XP, should be okay in the Windows compatibility box.
What I would do is to say that you couldn't find anything suitable (which is almost certainly true) but that you may be able to fix their problem for a moderate fee. Then, hopefully it's just a matter of setting a flag on the application (you may want to check this first to ensure it won't be too much work).
Money for Jam.
The other option is that you can offer to rewrite it for them in a more modern setting, using your vast knowledge of the application.
However, I'm surprised you don't have a copy lying around. I keep just about every piece of software I've ever written just in case (with permission for work-for-hire stuff of course), even down to the Fortran assignments I did at Uni back in the early 80s.
That's a good habit to get into, although I'm starting to wonder whether I should perhaps free up some space by ditching the Fortran :-)
There are a number of things you can do to help them without the source code. You could apply an external manifest if the application will only work when it is elevated. You could advise them to install the application somewhere other than Program Files (generally an awful idea, but might work in this case.) You could apply a compatibility setting or teach them how to install it into "XP mode" so it runs in an XP virtual machine.
Failing all of those, you could offer to rewrite it in VB.NET so they would get a more modern ui, Windows 7 features (not just capabilities) and would actually own the source code for their app. That might have value for them.
And yes, you should have kept the code. I have CDs burned from my old projects going back to the dawn of time (at some point I copied things from 3.5" backups to CDs while I still had some machines that could do both) and I have made more than one previous client happy by sending them the CD. It is a really cheap marketing investment, really.
It sounds like this is an application that is sold to customers, and is having trouble or doesn't work under Windows 7.
Consider advising the customer that the application should be:
modernized, thereby easing the ability to add features/maintained
otherwise run in XP Compatibility mode for their Windows 7 customers. Surely that number will only grow, and would become a support issue. Goto previous bullet.
Seriously though; your customer should realize that their software needs to be modernized. Hopefully you can persuade them of that long term goal; perhaps they already know that.
Related
We're looking for a way to run someone with experience with ILMN's NextSeq platform. We're currently trying to convert native bcl files to fastq, but the platform doesn't provide that option by default.
ILMN offers this through the BaseSpace community website/appstore, but this is problematic for us b/c running bcl2fastq through BS doesn't allow us to specify any parameters.
There's a converter tool ILMN offers through their website, which runs on Linux. This is problematic for us, too, as we're essentially a highly regulated (think FDA-level, 21CFR.11 and all those things) Windows environment, so "just" putting a Linux box on-prem is not as simple as it sounds.
So we looked into running bcl2fastq through a VirtualBox VM on top of Windows, but that was rather disappointing; it takes roughly 2 days to run bcl2fastq on a VM, versus under one hour on a "native" Linux setup.
I don't think we've exhausted all of our options yet though to get bcl2fastq to work somehow in a Windows environment. Amongst others, the source code of bcl2fastq is actually publicly available, so perhaps we could re-compile the whole thing for a Windows architecture as well.
I was recently fixing some IAT on MoleBox packed executable and saw that it links with kernel32 functions: '_lopen', '_lwrite' and '_lread'. This site states that those API's are provided for compatibility with 16-bit versions of Windows. I undesrtand that 'Win16' applications can't be executed in long mode (yes - I'm running Win8.1 x64) - so what is the purpose those to be still included in 'kernel32.dll'?
By the way those functions aren't even included in the 'msdn' library.
EDIT: It also seems that those function aren't actually 16-bit! They're taking 32-bit parameters on the stack.
It's not that the functions can be called by 16 bit applications. Clearly they cannot because they live in 32 bit and 64 bit modules. The point is (was) to make it easier for developers to compile old programs without having to re-write them.
Now, in 2015 there's no real need to cater for developers that have 16 bit programs that they wish to re-compile. That is probably not happening any more to any significant level. But if you roll back the clock 20 years then this was a real concern. And hence MS included these compat crutches. And once they had been included, then MS probably decided to leave them there so as not to break binary compatibility. MS does go to great lengths to avoid breaking old programs. Were these functions to be removed, any programs that rely on them would break.
Microsoft doesn't remove functions "just because" they're old. They will remove these functions as soon as they would require a reimplementation, but for now it takes less work to keep them.
I have a program written in CA-Clipper 5.2 and linked with Blinker 7. I recently learned how to compile it into protected mode in place of real mode. Now the real mode debugger won't work with the program. So now I need a way to debug my code. The documentation for Blinker says to use "NuMega SoftICE" or "Periscope". I'm not family with those debuggers, and can't find much on them from Google. It sounds like SofeICE was turn into some type of hacking tool. Any suggestion on a way to debug my program?
NuMega was bought out, and SoftICE was killed (something like five years ago, if memory serves). It was a kernel debugger, which is a kind of tool some hackers (in either sense of the word) find useful, but wasn't really a hacking tool as such. (Silly trivia of the day: people who beta-tested the original version of SoftICE for Windows NT got a T-shirt that read: "...and they said it couldn't be done!").
Periscope is (was) an in-circuit emulator. It was a board with a plug to fit into your CPU socket, and a socket where you put the original CPU. It would then monitor all the traffic over the CPU bus, providing a lot of debugging capability that most software debuggers can't even hope to match. As CPU buses got faster, however, it got extremely expensive, and eventually got to the point that there was no market left. There was definitely a version for the 486 (I've used it), but I don't think there was ever a version for the Pentium or newer.
As to what you would use: the HX DOS Extender is probably the only DOS Extender still maintained. Their page lists debuggers that can be used with it. I certainly can't guarantee compatibility with the DOS extender you're using, but there's at least a chance one of them might work.
try watcom debugger with commandline startup: wd /tr=rsi
trap for rational systems dos extender
be sure to get latest version: open-watcom-c-dos-1.9.7z
it has problems doing search
but earlier versions do not work well
I'm trying/thinking of making CppCMS - C++ Web Framework project little bit more cross platform.
Today I can easily support Linux, OpenSolaris, FreeBSD and even Cygwin. But when it comes to Native Windows it becomes really painful:
The overview of the situation:
I'm POSIX/Linux developer and I'm barely familiar with Native Windows development tools like Visual Studio and Win32 API. However I do some work for this platform so I understand the limitations and the fact that Windows is totally different world.
This is web project that uses APIs that popular in Unix world, like: CGI, FastCGI and SCGI that implemented in most UNIX web servers; but I understand that I would not be able to use it with IIS because it does not support FastCGI over TCP/IP (only Windows pipes).
So even when it would work it would probably run only with Windows port of Apache.
I relay heavily on POSIX API:
Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
I use some file-locking facilities (but I can probably give them up without forking)
I have intensive use of native pthreads, even I can replace them with Boost.Thread
I probably would never be able to support Visual Studio (maybe 2010 with C++0x support), because I relay on C++0x decltype/auto feature or typeof/__typeof__ extension that is supported by most compilers I worked with: gcc, intel, sun studio. (To be honest: I can work without them but it makes the life much easier to framework user.
I relay heavily on autotools and I can't replace them with CMake, bjam or friends, because when it comes to support of internationalization, cross copiling, package management, they just does not give me a solution.
There are many annoying points like missing gmtime_r, or localtime_r under windows and many others that just require from me to rewrite them or replace them with 3rd part libraries.
There are still many "UNIX like" libraries that ported to Win32 like: iconv, gcrypt and some others that are barely ported like libdbi that have many limitations on windows.
Bottom line:
There is lots of non-trivial work to do, and even when it would be complete, it would probably work only with MingW tools and not "native" tools that Windows programmers are
familiar with.
So, my questions are:
Does such MingW port worth an effort? Would this help to build bigger community?
Does anybody have experience on how painful porting big projects from POSIX environment to
Win32 API is?
Would it be useful for Windows developers at all?
Edit:
It is also important for me to understand, how many of windows developers prefer to use
Open source development tools, MingW over Microsoft development solutions like VS.
Edit #2: Clearification about "native" windows solusions and IIS.
In fact, running framework with IIS is really hard problem. I explain:
The project relates to standard web server API as FastCGI or SCGI that allows to accept many requests over sinlge socket. Thus, on application side, I accept new request proceed it and returns the answer. Sometimes several threads process several requests.
Thus, implementing one or two standard protocols I open communication with any existing server: Apache, lighttpd, nginx, cherokee... or any other servers; with small exception of IIS
IIS has implementation of FastCGI, but... It supports only 1 connection per local process only that controlled by web server...
So... there is absolutely no standard way to connect my application to IIS.
Please note, I implement standard Web server API, I do not implement Neither IIS proprietary ISAPI nor Apache proprietary API, even the second is more important as for targeting UNIX world.
So, just Windows IIS Web world is just not really ready for cooperation for such project, so if anybody would use it under Windows it would use it with more open web servers.
You should base your decision on user demand. Have users ever requested using the framework on Windows? If so, did they explain why they wanted to use Windows (e.g. what additional constraints they had, what webserver they wanted to use, etc.)?
Typically, Windows users do expect that things work the Windows way. That means Visual Studio support, IIS support, MSI installer, and so on. If something still feels like being Unix, I would rather use Unix proper, instead of fighting with a half-working port.
As a windows client app developer it sort of hurts me that the development environment division currently is essentially Win32 and everything else and that they are mostly incompatible. That's why I'm preparing to move to MinGW for my personal windows app projects and to try to make them cross-platform.
I would suggest gradually moving to more cross-platform libraries like, as you suggested, refactoring pthreads to boost::thread, or going from fork() to multi-process with IPC, probably also using boost's facilities. Date/time stuff can be dealt with Boost libs as well. As for database support, there are
Microsoft compiler support is not that important I think, as MinGW provides a decent build environment with all the IDEs that support it, Eclipse CDT and Dev-C++ being among the most popular. But if you are going to make your project msvc-compatible, make sure users will be able to use Express editions of Visual Studio 2010 (as soon as thay come out) - that way no one will have to fork out for a Visual Studio 2010 (upgrade) just to use your project and there will be no problem for you to require the latest in Microsoft technology.
Most likely you won't avoid some amount of ifdefs for a code base of your project's size, but surely the effort might be worth it, if not only for gaining valuable experience and expanding the community with a few new happy and grateful members.
Your saying that you can support Cygwin quite easily reminds me that I've seen commercial Windows software that simply bundled in cygwin1.dll to support some originally-Unix code. If adding cygwin1.dll to your installer is all it takes, try it out.
I think you only have to look at the questions asked on SO to work out that MinGW users on Windows (of which I am one) are in a minority in the development community - the vast majority of Windows developers are using MS tools. Anyway, the compiler is only half (or less) of the issue - if your architecture depends on forking lots of processes, using MinGW is not going to help you. My advice is, if you really want to do cross platform development:
look at how Apache do it
consider using the Apache libraries as your base
don't use very new or compiler-specific language features
use multi-threading rather than multi-process
Does such MingW port worth an effort? Would this help to build bigger community?
I am still working myself on this issue with my own large POSIX project and my conclusion is that if you need to later interface with Microsoft products, then its worth while, however then I would only use MingW if project is medium small, if it is very large, then I would go all the way with MSDN Microsoft development tools - Huge amount of help will be available there - however it will cost
Does anybody have experience on how painful porting big projects from POSIX environment to Win32 API is?
sofar my own conversion of my POSIX project have been constantly put on hold, because of the amount of time each issue takes to handle is enormous - not finished converting yet - If I ever will be
Would it be useful for Windows developers at all?
Sure working inside the Microsoft IDE using tools from MSDN will definately decrease development time, however it will increase your dependence on Microsoft libraries - something you need to decide from beginning if that is an issue
**
Actually you could just add the necessary cygwin dlls to your projects make and then you would beable to run it in windows
I managed to make my POSIX project run when I added following dlls
cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll
Probably your project will have different dependencies, however if you think conversion is not worth it, then perhaps this is a solution for you
You could also add your libs as static, then you would end up with only having to provide the last cygwin1.dll
For software applications like games, does this mean software companies have a lot of extra coding to maintain 3 branches of certain libraries?
I know this is hard to say, but for game development in general, are there specific areas in the software where they will have to write 3 times in order to work in all 3 flavors of windows?
I'm guessing the core software will be untouched, but maybe some drivers will need to be version specific?
It depends how close to the OS you are. If you're just using the .NET framework or DirectX, probably not much changes between operating systems. If you're writing drivers or relying on the Win32 API then there definitely could be subtle or not so subtle changes.
If your code is written correctly in the first place, there should not be a huge investment into supporting an OS upgrade. Using something like the .NET framework helps guarantee this even more.
Also, why would games have 'drivers'?
Not really. If you use DirectX 9, you are fine on all 3 Windows Versions. The extra maintenance evolves around stuff like the Installer/Uninstaller, about the Games-Tab that was new in Vista (if you want to use it) etc., but as said, DirectX 9 is a stable API on all 3.
You will get into some fun with DirectX 10 (not on WinXP) and with OpenGL (Support in Vista is weird).
Even if you use "portable" interfaces like DirectX or .Net or whatever that are supposed to provide the same functionality, a responsible software developer will have to do QA and testing on each supported platform.
(Note that I don't claim to be a responsible software developer. :-))
Many game develoeprs, including the studio I work for, use engines that manage cross platform issues. We are using Unreal for our game and it ports to the PS3, Xbox, and PC with no issues other than performance differences between them. The engine typically handles the differences in platforms.
As a .Net developer, most of the issues I saw when running applications built with XP as the original target were things we were doing incorrectly that just happened to work in XP (most were using the system colors that looked ok on XP but were wrong for Vista -- e.g., the default Vista theme caused a black font on black background).
It was coding by coincidence at its finest (we were naive enough to not know it was wrong). However, once we started testing on both Vista and XP, we started to produce a better Windows product.