5 ms·

An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is

An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is in the path). That script had to be runnable by outsiders so I had to make it run on Windows too and had to do all sorts of grovelling through the registry (it is possible to have Java installed but not registered for jar files, and we need to supply parameters to the java command). Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards. When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile. Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM. It all adds up to a death by a 1,000 cuts.

asveikau 14y ago
If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
- rogerbinns 14y ago
  > If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).
jrabone 14y ago
One of them needs to run a jar... Exe4J / Install4J; works everywhere. Some status information is saved in an ini file... Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ? ...open the browser on a local copy of the documentation... Don't, use CHM on Windows (although I think this changed AGAIN recently). Some of our stuff does intensive file I/O. This is a lot slower in a VM VMWare Workstation? Software development is death by 1000 cuts. That's the nature of the game. If you get into x-platform dev without thinking too hard about it you'll suffer, but none of the platforms is "right" - just better or worse for something.
- rogerbinns 14y ago
  So lets see - on Linux and Mac the script just works. It requires no installation. On Windows I have to jump through hoops. > Exe4J / Install4J; works everywhere So to run a jar that produces command line output and is consumed by the script and is one line to run on Linux/Mac (java -blah -blah -jar foo.jar blah blah) requires me to purchase a 3rd party wrapper/installer app. That there is a hoop to jump. Finding the java binary via the registry worked just fine, didn't require installation or wrapping or anything else. > Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ? I used the Python configfile module which does ini style files. At the moment I save exactly one value. It is trivial and works really well. Doing more than that is more hoop jumping. > Don't, use CHM on Windows (although I think this changed AGAIN recently). So I need to convert perfectly good documentation that works in any browser on any platform into another format just because Windows strips the anchor when opening a URL? More hoops. Incidentally I do actually generate CHM files for one of my open source projects. I had to give up because the help compiler refuses to install now (I believe the setup program is doing 32 bit arithmetic on free disk space and wrapping around to negative numbers). > VMWare Workstation I've yet to use any virtualization solution where guest disk access is at the same performance level as on the host. (I prefer virtualbox.) > If you get into x-platform dev without thinking too hard about it I never said I wasn't a x-platform dev. All my open source projects for well over a decade work on all 3 platforms. But that is because I'm diligent and don't want there to be any impediments to others being able to use the software. Windows is usually what causes the highest amount of work for least results, although there are exceptions (eg printing support has always been easiest to add support for on Windows). But when we do our internal stuff there is no value to being cross platform to Windows. It wouldn't be a big deal if it didn't require so much additional effort. Consider something as trivial as deleting a file. If you just had it open (can't delete open files on Windows, more hoops) then closing it and deleting will often fail. You have to add delay/retry loops because tagalongs like virus scanners and backup agents opened the file after you closed it. So as a result the only thing we have that runs on all platforms is one script because it is run by outsiders, and that required extra effort for Windows. It could require even more if I did everything "properly" although the people running the script wouldn't know any different which is why I didn't expend even more effort.

asveikau 14y ago

If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.

rogerbinns 14y ago
> If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).

jrabone 14y ago

One of them needs to run a jar... Exe4J / Install4J; works everywhere. Some status information is saved in an ini file... Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ? ...open the browser on a local copy of the documentation... Don't, use CHM on Windows (although I think this changed AGAIN recently). Some of our stuff does intensive file I/O. This is a lot slower in a VM VMWare Workstation? Software development is death by 1000 cuts. That's the nature of the game. If you get into x-platform dev without thinking too hard about it you'll suffer, but none of the platforms is "right" - just better or worse for something.

rogerbinns 14y ago
So lets see - on Linux and Mac the script just works. It requires no installation. On Windows I have to jump through hoops. > Exe4J / Install4J; works everywhere So to run a jar that produces command line output and is consumed by the script and is one line to run on Linux/Mac (java -blah -blah -jar foo.jar blah blah) requires me to purchase a 3rd party wrapper/installer app. That there is a hoop to jump. Finding the java binary via the registry worked just fine, didn't require installation or wrapping or anything else. > Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ? I used the Python configfile module which does ini style files. At the moment I save exactly one value. It is trivial and works really well. Doing more than that is more hoop jumping. > Don't, use CHM on Windows (although I think this changed AGAIN recently). So I need to convert perfectly good documentation that works in any browser on any platform into another format just because Windows strips the anchor when opening a URL? More hoops. Incidentally I do actually generate CHM files for one of my open source projects. I had to give up because the help compiler refuses to install now (I believe the setup program is doing 32 bit arithmetic on free disk space and wrapping around to negative numbers). > VMWare Workstation I've yet to use any virtualization solution where guest disk access is at the same performance level as on the host. (I prefer virtualbox.) > If you get into x-platform dev without thinking too hard about it I never said I wasn't a x-platform dev. All my open source projects for well over a decade work on all 3 platforms. But that is because I'm diligent and don't want there to be any impediments to others being able to use the software. Windows is usually what causes the highest amount of work for least results, although there are exceptions (eg printing support has always been easiest to add support for on Windows). But when we do our internal stuff there is no value to being cross platform to Windows. It wouldn't be a big deal if it didn't require so much additional effort. Consider something as trivial as deleting a file. If you just had it open (can't delete open files on Windows, more hoops) then closing it and deleting will often fail. You have to add delay/retry loops because tagalongs like virus scanners and backup agents opened the file after you closed it. So as a result the only thing we have that runs on all platforms is one script because it is run by outsiders, and that required extra effort for Windows. It could require even more if I did everything "properly" although the people running the script wouldn't know any different which is why I didn't expend even more effort.