64 bit?
Monkey Forums/Monkey Programming/64 bit?
| ||
| Is anyone still using 32 bit windows as a dev platform? Is it OK to 64-bitize all the Monkey tools, on all platforms? I think it's reasonably important for Windows Monkey to at least be able to produce 32 bit apps for the sake of the cheap 'n' cheerful x86 Windows 8 tablets around (and this is easy for Monkey to do) - but most people have surely (ha) moved on to 64 bit OS's by now...? And Linux? I still run 32 bit Linux - but only really because of Monkey. Just installing 64 bit linux right now. I'm thinking the time might be good (ok, overdue!) for going to 64 bit for ted/transcc/mserver etc on all 3 dev platforms (windows/macos/linux) and to start adding options for building 32 bit apps where necessary (default would become 64 bit). |
| ||
| I vote "yes!" for 64bit! |
| ||
| I still use 32 bit windows for development, and that is mainly because I develop exclusively in a VM for portability and dirt simple upgrades to new host hardware when I need it. Seems like that would force me to redo a full dev environment in a fresh install of Windows 64 bit. Not that this is a bad thing, but it just takes days to do. What are the benefits going to be moving everything to 64 bit (ted/transcc/mserver etc...)? I know you will have access to more memory, but what else? It is my impression that 64 bit apps use more memory because of the 64 bit addressing, but that may be too simplistic, and maybe it doesn't matter, but it may mean that I need to allocate more memory to a 64 bit Windows VM versus a 32 bit Windows VM. Wouldn't want to stand in the way of progress though... |
| ||
| I use 64bit. http://store.steampowered.com/hwsurvey is pretty good for stuff like this, 85% of steam windows users use 64bit, and 100% of the (very few) mac and linux users. |
| ||
| > What are the benefits going to be moving everything to 64 bit (ted/transcc/mserver etc...)? Actually, for Windows I guess there are few. But for Linux at least, it's a hassle running 32 bit stuff on a 64 bit OS, as 32 bit libs (and dev stuff if you're developing) has to also be installed. Macos is pretty much 64 bit now, so I just thought it might be nice to bring them all up to date at once. I guess all-in-all, the bigger issue is probably being able to create 64 bit apps on Linux? > mainly because I develop exclusively in a VM I've got 32 bit windows xp and 64 bit window 8 running in vmware under my 64 bit windows 7 host - sure you really need a 32 bit host? > http://store.steampowered.com/hwsurvey is pretty good for stuff like this, Yeah, but it's not really developer oriented - it gives you a good idea of who to target, but I don't esp. mind higher requirements for developers (if it actually makes development easier). |
| ||
| I don't care if you change the tools to 64bit. if it is not working for me anymore, then so it will be. |
| ||
| Good C++ code can be compiled for 32bit and 64bit without changes, so why not provide both? It is usually just a compiler switch for the C++ compiler to switch between x86 and x64 output. Static libs need to be provided for both, but most MX stuff comes as sources anyway. TED is C++, and Trans etc. get translated to C++. Everything should be able to compile to 32bit and 64bit. Personally I'm exclusively using 64bit Windows since XP Pro x64 (9 years ago). Mac OS X is 64bit anyway. Linux only in VMware and VirtualBox, usually 32bit and 64bit versions of the same distro. |
| ||
| > mainly because I develop exclusively in a VM I've got 32 bit windows xp and 64 bit window 8 running in vmware under my 64 bit windows 7 host - sure you really need a 32 bit host? I run a Windows 7 64 bit host not a 32 bit host, (I think you meant 32 bit Guest). One of my requirements for a 32 bit development VM was so I could transfer my VM to a lesser laptop where I could still run the VM while travelling, that laptop had tighter memory constraints and a 64 bit guest running on it just didn't seem feasible. That older laptop rarely gets used, but a move to a 64 bit VM would force me to purchase another laptop for travel purposes that had at least 12GB of memory to run the 64 bit host and 64 bit guest comfortably. It is really more the hassle of creating a new Windows 7 64 bit Guest and then replicating my entire dev environment in that. The process involves deactivating quite a few dev tools and utilities, setting up the 64 bit Windows 7 (or maybe 8, but I would have to purchase that) for the VM, and reinstalling the lot (all my dev tools) with updates, etc... etc... Not that this is a bad thing, I just didn't plan on doing that right now and it would be a bit ironic if it were Monkey that forced my hand. I guess the bottom line is a forced move for me right now from Windows 7 32 bit to Windows 7 64 bit would be of no benefit, but involve a lot of effort with no compelling payoff. I understand the desire to simplify things and go all 64 bit, but if there is any possibility to provide both (for Windows) as Danilo suggested, then I would +1 for that. |
| ||
| I think Monkey development should be more focused on adding new/missing features, or fixing bugs/issues, rather than changing something which doesn't really mean much, IMO. So I'm against such a change at the moment. We have more important things to focus on. |
| ||
| When you do make the move to 64 bit this is an oldie but goodie and may be a useful read http://www.codeproject.com/Articles/18855/issues-of-porting-C-code-on-the-bit-platform |
| ||
| Moving exclusively to 64 bit would be a worry, yes... sometimes I have to run Monkey on machines with WinXP, so although I know this isn't common at all, I would be affected a little bit :( But yeah, the laptop I work on a daily basis is 64 bits. And Linux would benefit a lot being 64 bits - but how many people in here uses Monkey on Linux...? |
| ||
| @Danilo He's not talking about your stuff building as 64-bit. He's talking about the binaries that are supplied with Monkey being pre-compiled for 64-bit - rather than 32-bit which they are now. @64-bit only tools Other than on Linux, I don't see why it should make any difference if your tool binaries are 32-bit, as the stuff they call (like your compilers and whatnot) can be 64-bit even if the tools are not. TDM's MinGW 64 seems to manage fine shipping 32-bit binaries of everything - which can build for both 64-bit and 32-bit targets. |
| ||
| I am happy with 64bit. |
| ||
| Is anyone still using 32 bit windows as a dev platform? Is it OK to 64-bitize all the Monkey tools, on all platforms? I think it's reasonably important for Windows Monkey to at least be able to produce 32 bit apps for the sake of the cheap 'n' cheerful x86 Windows 8 tablets around (and this is easy for Monkey to do) - but most people have surely (ha) moved on to 64 bit OS's by now...? I still use Vista 32 on my laptop. Going 100% 64bit tool wise on Windows while MS is still supporting 32bit OS's would be a bad idea. For compiling projects a better solution would to be modify trans to allow it to use two project files; One for 64bit and the other for 32bit. And Linux? I still run 32 bit Linux - but only really because of Monkey. Just installing 64 bit linux right now. As some software companies haven't gone 64bit with their tools on Linux (Steam is one example), then 32bit on Linux will still be around until they do move every thing over.For Monkey, again as I suggested with Windows, the use of two project/make files and a modified trans would solve the 32bit/64bit build question. I'm thinking the time might be good (ok, overdue!) for going to 64 bit for ted/transcc/mserver etc on all 3 dev platforms (windows/macos/linux) and to start adding options for building 32 bit apps where necessary (default would become 64 bit). . My ideas here. Rewrite the tools that use BlitzMax to use Qt instead. Windows: Leave the tools as 32bit executables until Microsoft finally kill off support for 32bit. OS X: As OSX is now 64bit (is any one still using a 32bit version?). Then I would think that it should be native or a universal build. Linux: If the download size of the zip file for Monkey isn't a problem, then include both 32bit and 64bit executables and use a start up script to execute the correct version of the IDE which in turn runs the correct tools. If download size becomes a problem. Then the download should include the trans c/c++ output for the tools in question that then can be compiled by executing a simple script that can be written to check if the system is 32/64bit, if the tools have already been built for that system (a simple empty file check) and if not run a script to build them. The same script can be used to execute the IDE. When you do make the move to 64 bit this is an oldie but goodie and may be a useful read http://www.codeproject.com/Articles/18855/issues-of-porting-C-code-on-the-bit-platform Yes this must be taken it consideration. But don't be tempted to use some of the new C11 solutions to pointer problems. Earlier version of GCC don't support them. |
| ||
| dawlane wrote: But don't be tempted to use some of the new C11 solutions to pointer problems. Earlier version of GCC don't support them. Just a hint: - http://clang.llvm.org/ * A real-world, production quality compiler * Fast compiles and low memory use * GCC compatibility * Use the LLVM 'BSD' License * A single unified parser for C, Objective C, C++, and Objective C++ - http://clang.llvm.org/cxx_status.html Clang fully implements all published ISO C++ standards including C++11, as well as the upcoming C++14 standard |
| ||
| I think it is a very bad idea because there are still lots of people using 32 bits windows and there are potential sales lost and a bad impression if they get Monkey and it just does not work. That said, I don't see it an issue on Mac or Linux. Could you just provide 32 bits build for windows, and 64 for the others, or it's too much work to maintain two architectures on QT? EDIT: There are several Jungle Ide users that run on 32 bits windows. I know it because when there's a bug report, Jungle Ide also informs on OS version and architecture, so there is actual people that won't be able to use Monkey if you do this, until they update their OS. Also, notice Windows 10 is comming ALSO in 32 bits, so it seems 32 bits is not going anywhere in the near future in the windows land. |
| ||
| My main computers are all 64bit, however when I'm out and about I have a 32bit laptop I sometimes work on. It'd be a shame if Monkey X stopped working on it. |
| ||
| It'd be a shame if Monkey X stopped working on it. Well, you can always recompile the tools - since the source for everything is included. (excepting perhaps the editor? Dunno.. been a while since I used it ;-) |
| ||
| Hi, A 64bit world is inevitable and really it is an issue of maintaining comparability IMHO. I see more potential, value and perhaps respectability going 64bit, For it. - Rich - |
| ||
| All my machines are 64bit. I'm great with all Monkey tools and eveything being 64bit. |
| ||
| Can you already dictate 32 or 64 bit output for c++ target / trans? If not, then maybe add that as a feature first. For iOS has monkey switched to generate universal 32/64 bit arm? Lastly, for monkey and demo distribution I think you should go with 4 platforms and NOT drop x86 Windows support. Windows x86 Windows 64 MacOS (64) Linux (64) |
| ||
| I am ashamed to admit that I am still using winxp sp3. I realise you want to work on 64bit only but if you're willing it would be great to use the tools for 32bit. Perhaps issue an official notice to warn people that 12 months from now you will concentrate on 64bit only, gives people plenty of warning. Wha'dya fink Mr Sibly? |
| ||
| 64 bit is Honkey Dory here. |
| ||
| I still build on both platforms and will do for some while i'm sure. |
| ||
| It's 2014 - so go 64bit ... I guess it still requires Marks time to support both versions (otherwise there'd be no reason to ask) and, given how unstable his business seems I'd say supporting *developer* tools on decades old systems is simply one of the worst ways he could spend his limited time/manpower as well as the least helpful in finding more customers. |
| ||
| +1 to "Rewrite the tools that use BlitzMax to use Qt instead." I've used it some and it is good. If you have questions or want help just ask us. I have been running 64 linux to make 64 and 32 linux game builds for a while now. You all running 32 really need to upgrade. If only for more ram! But that is reality. It would for example be unacceptable to not be able to support 32 for end user binaries just because there are so many people who refuse to upgrade their OS but will still buy what you make otherwise. |
| ||
| Well my main machine was down for a few months(!) earlier this year and I was glad I could run Monkey and compile to HTML5, Windows and Android on my 10'' 2009 mini-laptop running WinXP 32. But if Monkey really has to go 64bits I think I can understand and accept such a change. |
| ||
| I'd say go 64 bit but my cheapo windows 7 laptop that I use almost exclusively for Monkey work when out of the house is 32-bit only. Options in the devchain would be good; I don't mind if they're not updated as frequently, as long as they're updated from time to time (ie: 'stable' builds). Linux and Mac users should already be on 64-bit. |
   |