3 ms·

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,

by 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.
- jrabone 14y ago
  I have to say I don't think Windows' Java situation is any worse than the mess that is gcj / classpath. Install4J is free-as-in-beer BTW, but you do tend to get what you pay for on Windows, especially with virtualisation software. Deleting open files is another different-not-better situation - I've seen Linux server apps resurrect entire paths due to open inodes that looked like they were deleted but weren't. That was fun to debug on a production system doing $millions a month. Have you tried Qt or similar? Perhaps a script isn't the right answer if it needs to Just Work everywhere.
  - rogerbinns 14y ago
    We've not had any Java problems on any of the platforms. Note that the script is used by developers to verify correct integration of an SDK for Android, so they already have Java installed. This is a somewhat different scenario from random end user machines. No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.) The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs. In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution. I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc. For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms. I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still. For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on. That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).

by jrabone 14y ago

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.

jrabone 14y ago
I have to say I don't think Windows' Java situation is any worse than the mess that is gcj / classpath. Install4J is free-as-in-beer BTW, but you do tend to get what you pay for on Windows, especially with virtualisation software. Deleting open files is another different-not-better situation - I've seen Linux server apps resurrect entire paths due to open inodes that looked like they were deleted but weren't. That was fun to debug on a production system doing $millions a month. Have you tried Qt or similar? Perhaps a script isn't the right answer if it needs to Just Work everywhere.
- rogerbinns 14y ago
  We've not had any Java problems on any of the platforms. Note that the script is used by developers to verify correct integration of an SDK for Android, so they already have Java installed. This is a somewhat different scenario from random end user machines. No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.) The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs. In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution. I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc. For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms. I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still. For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on. That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).