I have had basic tests for meteor on a Windows7 PC.
But there the application crashed too often.
Before this, I tested meteor on PC running Windows8. There, crashes happened much less often and generally they were recovered when I shutdown and rebooted the meteor.
Is Meteor unstable on windows7?
Or is there any way to avoid this?
The version packaged to the MSI installer that can be found on win.meteor.com is not official. If you want a more stable, try the virtualized option I've described on the site. I've been using that for a month without issues.
Please could you be specific about what problems you are seeing, for example, what do you mean by 'crash'.
You can certainly raise issues on SO, but if they appear to be specific to the windows port, please raise a ticket at: https://github.com/sdarnell/meteor
The only difference between Win7 and Win8 meteor, is that the installer sets the Win7 compatibility mode for the node.exe executable on Windows 8.
There are also relatively few differences between the windows port of meteor and the official linux/mac release. So there is a possibility that the issue is either environmental (e.g. you have different things installed on the two machines), or it may even be a core issue that just happens to appear more often Win7 due to timing issues (there was a case of this in 0.6.3).
Related
This may already have a question somewhere, but I am at a loss as to how to debug IE11 on my Mac.
I currently run a full Win10 instance in a Virtual Box, but it is so bloated that it is nearly impossible to move nimbly between coding and debugging. IE dev-tools are also inaccessible using this method because it just cripples the VM, so I am flying blind with coding.
I have looked up tutorials as to how to run IE on a Mac direct using Wine/Remote Desktop, but these instructions are out of date or the supporting software does not work as intended. Also, Microsoft (being the evil empire that they are) discontinued support for debugging with Azure so that is another option off the table.
If there is anything that actually works without having to shell out $$$ please let me know as it is so painful currently to debug the worst browser that will never die.
From your description, I can see that you had already try to use the Windows 10 VM but it get hangs.
You can try to go to Windows Features on or off inside Control Panel-> Programs-> Programs and Features and try to turn off the features that you are not using may help to reduce the load.
It is possible that you are running your VM in a very less memory that downs the performance of the OS.
If possible for you than try to install a VM with some more memory.
Otherwise you can try to install Windows 7 in your VM and upgrade to IE 11 in that.
It can help you to solve your issue with the OS and you can debug the code on IE 11.
Below are some helpful references that may give you some additional information.
How to test your website with Internet Explorer on a Mac
How to Debug in IE on a Mac
First of all: I know that Windows XP is end of life, insanely insecure, a big risk and that everyone still using it will be doomed for ever.
Nonetheless I have to provide an application that can also run on Windows XP and I do so using Go.
In 1.10 it was announced that XP will no longer be supported and 1.11 confirms this in the release notes:
As announced in the Go 1.10 release notes, Go 1.11 now requires
OpenBSD 6.2 or later, macOS 10.10 Yosemite or later, or Windows 7 or
later; support for previous versions of these operating systems has
been removed.
I compiled my application with 1.11 and tried to execute it on a Windows XP SP3 virtual machine. It could be executed successfully !
Then I thought that the revoked support for Windows XP only applies to the development toolchain but even that can still be executed on Windows XP:
As you can see the main go binary still runs on XP too. Is it already known when it will no longer be possible to run golang compiled exes on Windows XP because of technical limitations or if certain methods will fail because they can no longer work because of missing APIs on XP ?
Issue #23380 is the relevant discussion.
In short:
Note that even if 1.10 is the last version to support XP, you'd get bugfix backports until 1.11 is out, and security backports until 1.12 is out. That means until January 2019 <…>
As to supporting Windows XP, there are both technical and non-technical reasons.
Supporting a platform requires:
Someone who has access to it, and an incentive to work on it
(either paid or unpaid).
The most active Go-on-Windows developer, Alex Brainman,
seems to have no interest in XP anymore.
This platform must be supported on autobuilders which are part of the Go release / QA process.
An autobuilder must be supported by someone.
Bugs specific to a platform must be fixed and tested.
For instance, that issue refers to #23375 which happens only on Windows XP (SP3).
But even if a bug was specific to Windows in general—as opposed
to Windows XP, a fix for it would have to be tested on XP anyway.
Hence, unfortunately, if there is no interest in supported Go on Windows XP coming from some "powerful entities"—such as corporations—the best you can do is to actually work towards still supporting this by yourself, FWIW.
Also note that even after the support is officially ended, you still might have success building newer Go releases from the source (which is reasonably simple since Go 1.5 as Go is now built using (an older release of) Go).
Hence a real show-stopper would be the Go team hitting some roadblock which would just require some kernel feature not present in Windows XP.
A good example was some difficulty with SEH handling on Windows 2000 which eventually led to dropping support for that OS.
My next work project is going to be using the Meteor framework. Our team recently got licensed to use WebStorm IDE, which has been our favorite up until this point. so we were planning on continuing the project with it.
That is, until it was time to install it. Then we found out that the Windows version of Meteor is only partially finished, and all of our development PC's are windows based.
So we were considering as a work-around for this, we may use Cloud9 as our development IDE, as it supports Meteor. The sharing functions may help our team productivity a bit as well.
But this has some problems...
First, we just invested in WebStorm, so we would ideally like to use it as our primary IDE. But I do not know how we would be able to work with WebStorm if we can not run an up to date version of Meteor on our windows systems?
Second, I'm not sure if it's even possible to use Cloud9 as the development IDE, but then move the C9 project over to our Ubuntu server for hosting when it is time to go live?
Third, even if we could deploy to our Ubuntu server after C9, we plan on many updates to our live application after deployment. I'm not sure if there would be issues with this if our development is on C9 and deployment on a completely different server.
So I'm wondering if anyone has a potential solution for these issues? Is there any way for us to work with Meteor on our live Ubuntu server, or Cloud9, from WebStorm on our Windows systems? Or any way we could integrate Cloud9 and WebStorm together for the best of both worlds? Or any way we could use a Linux emulator or something to allow us to use Meteor on our local windows system, without making it difficult for multiple developers to work on the project at the same time?
Thanks in advance!
The Windows port of Meteor actually is working quite well; the only major issue is that mobile development doesn't work. That is going to be fixed in Meteor 1.1 anyway, whose primary goal is to get Windows support up to that of Linux and Mac OS X.
As the user who initially pushed for Webstorm to add Meteor support back in October 2012, I'd recommend starting with Webstorm and Meteor on Windows right away, unless you need mobile development. In that case, you need native *nix machine (an Ubuntu VM on Windows won't be able to run the Android emulator, for example).
WebStorm also supports server-side Meteor debugging, and they're pretty responsive when it comes to fixing bugs you report on YouTrack. See for example https://youtrack.jetbrains.com/issue/WEB-13490
With Cloud9, you cannot currently SSH into a workspace you have, so a hybrid Webstorm/Cloud9 situation might not be doable at this point.
As for deploying your stuff from Cloud9, that is very doable. There's some documentation here about that: https://docs.c9.io/v1.0/docs/deploying-via-the-command-line
Someone smart who I know just mentioned that the idea of downloading Internet Explorer onto a Mac seems counterintuitive, even though it might make sense to do since Safari seems to have problems on a certain site for a project we're working on. I'm just wondering why this is and would greatly appreciate any clarification. In summary:
Why does it not make sense to download Internet Explorer onto a Mac?
Much thanks in advance!
If you're looking for a serious answer:
The best way to test something with IE7 for Windows is to use IE7 for Windows. Just because you have a Mac doesn't mean you can't do that. You can run Windows through BootCamp. Or buy a used $99 Windows box and borrow the Mac's keyboard/mouse/etc. Of course it's much more convenient, and almost certainly good enough, to run Windows in a VM under OS X via Parallels, VMware, etc. Wine will mostly work, but it can be fiddly to configure, and may crash and/or have visual glitches that don't happen with real Windows; if you really want to get serious about that you may want to look at Crossover.
But the next best way to test IE7 for Windows is actually Opera. Of course in the case of bugs and quirks that are still present in later versions of IE, they'll do a perfect job of emulating IE7, but for bugs that were fixed, that's not a particularly important focus. Opera, on the other hand, works hard to be able to emulate the quirks of all of the important browsers. Make sure to enable IE quirks mode, and set the user agent to pretend to be IE7 for Windows, and you should be golden.
But for the question you actually asked, there is no blanket answer to this that could possibly be correct. There are many reasons it may not make sense to download Internet Explorer onto a Mac, and also many reasons why it might.
You can't run IE for Mac on any modern Mac.
If you have an ancient Mac, and it's running 10.2 or 10.3 rather than 10.4, it already has IE (and if you want to reinstall it, it's part of the OS X install), so there's no reason to download IE.
You also can't legally download IE for Mac from anywhere anymore (except as part of old versions of OS X).
And IE for Mac is actually far less like IE7 for Windows than any modern browser is.
You can't run IE for Windows (or Pocket IE for Windows Mobile) on Mac OS X.
But you can run it under wine.
And you can run it in a virtual machine running Windows.
Except that Windows comes with Internet Explorer, so there's no reason to download it.
Unless your Windows comes with an older version and you want to update it.
And a Mac can run Windows instead of OS X if you want (e.g., via BootCamp).
Same caveats as with a VM.
And there may be other reasons to download it other than running it.
If your Mac has access to a fast internet connection and your Windows box doesn't, you might want to download the installer on the Mac to copy it locally to Windows.
Sometimes you just want to use up internet bandwidth.
Maybe you're testing your download speeds.
Maybe you're about to dump your boyfriend, and first you want to run him $300 over his monthly bandwidth limits.
Someone at Microsoft might find it entertaining when they notice in the logs that you've downloaded IE on a Mac, and it's always nice to bring a smile to a stranger's face.
The last version of Internet Explorer for Macintosh was 5.2, out in 2003. It wouldn't even run on a modern machine. The build is just not compatible.
If you want to try a different browser, both Chrome and Firefox run on OSX.
To run internet explorer on the Mac, you'd need to use some sort virtualization, running Windows either through Boot Camp or Parallels.
I had to do it because I'm developing software and the client wants to have it styled for IE 7 (the version they have on all their machines).
If I had my druthers, I'd run it under virtualization (e.g., VMWare), but I've misplaced my old XP CDs, so I settled for Wine (which works 'okay', but crashes from time-to-time).
I suggest using VirtualBox which would enable you to run MSIE on your Mac directly:
https://www.virtualbox.org/
...and here are the VMs for MSIE 6, 7, 8 and 9:
https://github.com/xdissent/ievms
Good luck!
It's definitely not a good idea to install Internet Explorer for Mac. It simply doesn't work properly as it was discontinued by Microsoft in 2005. However, if you have to use it to view certain websites that will only work in IE, this is the easiest way to download and install it for Mac: http://machow2.com/download-internet-explorer-for-mac/
we have a small app that doing trivial stuff, no GUI.
we was using Linux, but the library/framework available for Linux is highly less than that for windows, it was such a pain to develop under Linux.
So we want to use windows, but windows is too big for the trivial app, is there any solution that i can use windows and not losing OS's lightweight?
any advices appreciated.
What kind of applications are you building?
1) some older versions of windows have less bloat, but you wouldn't want these running on public networks because they don't get security updates. Plus, the latest/greatest libraries may not run on them
2) If you're running command-line server utilities, you could try Windows 2008 Server Core, which is a console-only installation
3) You might want to try Wine or Mono to run your windows/.NET framework-based application.
You should try a "Windows PE" (sometimes also called "minint") installation (installation guide here), which is a trimmed-down version based on Windows XP or Vista.
This does not make sense, sorry. If you have a CLI program under Linux why shouldn't you be able to write on CLI program on Windows?