Apparently, employers are still asking for Windows 95 and Windows 3.1 skills
indeed.com
indeed.com
Perhaps this is an important message to companies attempting to create rapid innovation in the health sector...
This is a good observation, and would probably make a great topic for a much larger discussion/essay.
Stuff takes a long time to come to market!
They may have been copying and pasting the same posting for years.
And these are the ones who glance over resumes to see who is qualified. That's very disturbing and discouraging.
The migration to Access 2003 needs lot of changes and (worse) they don't have a version control tool, schema of the application, any documentation... The code is a mess and written by bad programmers.
So what to do? Start programming for Office 2007 from scratch? This decision took them around 2 years after failing to integrate their access tables with Microsoft SQL (The speed is insanely slow for large corporations).
a) Rewrite as a web-app in platform of choice.
b) Put the entire DB in RAM on a really fast Windows server using SuperVolume. I'm guessing the MDB is less than 16GB in size. Setup Citrix/XenApp on it and deploy MS Access 97 as a standalone Xen application. Users only need to log on to http://citrix.company.com and click the "Access 97" icon. It will launch Access as a local app but it actually runs on the server. You get local disk speeds on the DB with minimal network usage. XenApp licenses are very cheap compared to even new Office licenses, let alone a full rewrite. If users do not need to change the Access 97 code/queries, you can deploy Access runtime instead of the full-access.
c) I'm guessing they already tried to move the tables to MS SQL while just linking it from Access 97. If that isn't possible because the code uses tons of Access specific queries, mirror every table to MS SQL periodically, depending on the frequency of updates. Convert the slowest read-only reports to use the data from SQL while data-entry continues to use Access 97 tables.
d) Break up the single Access DB into multiple DBs if possible. If Finance and Warehouse modules share almost nothing in common, they don't need to be on the same DB. If the 'employee' table is used to authenticate logins, put that table on MS SQL and link it from both Finance.mdb and Warehouse.mdb.
e) Implement a decent ERP system if this application is really core to the company's operation. MS Dynamics NAV would probably be their best bet.
a) They have currently started doing it.
b) Companies don't need it. They aren't really bothered with Access 97 and Windows 2000 or XP. All they need is our application. Low OS/Application means low and cheap hardware.
c) Tried the simple linking in MS Access, no improvement in speed. We need to re-write all the queries from scratch. Many problems showed and since the code base is huge, rewriting from scratch seemed more feasible and easier.
d) The application is huge, it has dozen of DBs
e) I don't know what you are talking about, but will do a little research.
What I meant by (b) was to put the entire database in RAM and let users access it by logging on to the server directly. You can put the MDB files on a file-server network share (like P:\Database\Company.mdb) and 10 people can use it at the same time as long as they all have Access 97 on their local machines and have read/write access to the P:\Database folder. Instead of doing it this way, try this for super speed: setup a fast Windows server with tons of RAM, create/format a 2GB-16GB partition as drive D:, install SuperVolume to load that entire drive D: to RAM. Move the MDB files here.
Don't make users open the MDB files from their PCs directly. Let them log on to a Windows Server as Terminal Server (TS) users and access it from the D: drive. If you have some money, install Citrix so logging on to the TS could be done by just visiting a website and logging in. This would let people from all over the world use the Access MDB at exactly the same speed as anyone physically logged into the server. With Citrix, you'll only need 20-32kb of bandwidth for most users.
So the short term solution was Terminal Server. It worked great and speed was fine, until in some days something happened in the Windows Server that slowed it down (some kind of caching or somewhat), so the illiterate technician just said that Windows Server is bad.
We are now (Ok, I left) reckoning on an advanced/new Web or Desktop platform. They are aiming to finish a part in the software this year. Will see what they do ;)
As a result, some of the old chipsets can only be programmed using old software which only works on 95. For a business that does embedded programming it isn't feasible to switch to a new chipset that would require a complete code rewrite just so that they can use a newer OS.
Interestingly embedded programming is also an extremely high paying job because there aren't that many people who can do it.
Legacy code hell doesn't just apply to codebases.
Actually, it wouldn't surprise me if there are jobs out there that require knowledge of DOS. It seems nothing ever truly dies.
http://www.netmarketshare.com/operating-system-market-share....
I was asking if most of the sites would work with browsers in that day...and I didn't know Opera and Firefox still support them.
Windows 95 had a native implementation of sockets, Winsock2, it also had telnet, and a serial communication utility. I ran Opera, IE and Netscape Navigator Gold on it. Eudora for Email, and Agent for a newsreader. Windows 98 shipped with Internet Explorer and had Active Desktop, the precursor to all the gadgets that you see today. The Windows SDK included even more controls, including MS HTML control that allowed you to embed web views (i.e. html frames) inside your apps. All MS help was converted HTML format as well, and the help compiler could convert HTML documents to CHM. It was, only, 10 years ago :-)
I still use the email account I opened using Windows 95 :-)
We've had a similar need in my lab, although it was Windows 2000. We buy new machines alright, but some instruments can't be easily upgraded due to the computer being integrated with it, the drivers being proprietary and specific to the OS, etc.