I am trying to develop a simple windows GUI in go (first attempt).
After considering a few packages to get me started, I landed on this https://github.com/lxn/walk and it seemed ideal. I cross-compiled from my ubuntu laptop and the provided demo worked on all target platforms (win7/8/10)
The problems came when I tried to start developing from my linux laptop - initially in atom, but I've since tried with sublime, emacs and phpstorm and noticed an issue with go get (so I'm guessing it's the underlying go tooling that's failing)
The first error I'm seeing is:
/../github.com/lxn/walk/tooltiperrorpresenter.go:8: undefined: ToolTip
This affects development across all affected IDEs tested:
disables autocomplete
halts linting
cant test
gofmt worked in some (perhaps tool ordering)
affecting any file referencing this lib.
And this is the first of many errors which seem to be due to the library importing its internal win package which contains files which are marked with the flag:
// +build windows
I cunningly decided to start ripping out these tags from the lib - hoping that would at least allow me to get on with development, but then I started seeing new errors regarding too many arguments being passed to syscalls in the win package - presumably because the different platforms (win/nix) have different numbers of parameters in those syscalls.
I then tried marking everything with the //+build windows flag, but the parade of errors remained unchanged.
I found some issues on the project github which are related:
https://github.com/lxn/win/issues/26 : no buildable Go source files
and there are solutions for "go getting" the files but none so far for my IDE woes.
I've also seen this type of issue in some other windows specific go libraries so I don't think it's an issue for the package author. But I would be interested to hear any solutions from a code architecture perspective if they exist
I haven't actually tried doing this from a windows VM yet (I presume that would solve the issue from my end) - but its a bit of a jarring solution as I'm already juggling vms to test the app so I'm keen to find another way.
TLDR:
Do I have to work from Windows machine / vm in order to have a fully
functional IDE when developing for windows from linux or is there a way to satisfy the go tooling
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
I'm trying to get started with Node.js on a Windows machine. Yes, I found the installer on their site. That worked just fine and I can run it. However, after that there's no instructions or requirements. Some issues I ran into:
I learned that most of these cool modules need to be built locally.
I was told I needed Git installed
I found I needed Python to build modules
I discovered I needed Visual Studio to compile
Once things are built they should be executable. However, they are not natively found in the path. I discovered them under %APPDATA%\npm, but there's no mention of adding that to the PATH.
What else am I going to discover? Is there a guide to this anywhere?
Altough I might suggest you to develope node on a unix based os (Ubuntu 12.04+WebStorm is my favorite combination for many reasons I can mention) I found my self in your situation at work when Windows 7 is a must.
I found this video really helpful
Once youe have node installed on your machine (window or any other) I (and most community) would recommend you to use WebStorm as IDEA it contains every inch of support to make your development process easy and clean, mange your global and local modules and build/debug your code easily.
It sounds like you've actually installed Node.js fine, but are having problems with the packages built by people in the community, some of which use Python or a native C compiler. Git shouldn't be necessary unless you're perhaps cloning projects from a remote repository? Or maybe the packages have dependencies on projects hosted in GitHub?
Keep in mind that Node is separate from all the modules and packages available in the community, accessed through the npm registry. Node provides you the ability to execute JavaScript locally, additional APIs, and an ecosystem to build additional packages which can do, as you've said, really cool things. But each of these packages can have unique installation requirements.
Most packages have dependencies of their own, and are often installed using the npm install command. This (usually) downloads other packages from https://www.npmjs.org/, and in some cases requires compiling additional files. This might have been the issue you hit.
The other thing to keep in mind is that a lot of people might assume things are installed and available since they have it installed for them, or are running a different operating system than you. I've often found that folks will hard code / somewhere in their scripts, which cause problems on Windows based systems. This can lead to problems with the executables that are created as part of the node packages created by the community.
To better understand what Node has and what's available, I'd recommend the nodeschool.io projects. These cover some of the main areas provided by the base Node platform, and get you used to playing around with things from GitHub and npm. Maybe if you run into specific issues there folks can help more directly.
I have been a long-time visual studio developer, and I am trying to switch over to using mono so I can port my applications to Ubuntu. I have been trying to get some of my VS2010 C++ projects (.vcxproj file types) to load into MD on my Ubunutu 12.04 machine. According to the documentation I have read online this should work, however, every time I try and load a project I get the error shown below. Is there something else I need to be installing in order to be able to load C++ projects in monodevelop? I have done some searching, but have not yet found anything related to this particular question.
VC2010Test.sln(4): Unsupported or unrecognized project : '/home/me/Projects/Test/VC2010Test/VC2010Test.vcxproj'.
Thanks
MonoDevelop has a C/C++ binding, called CBinding.
But:
Beware, it's not meant to target managed C++.
AFAIK, it only works in Unix-like platforms.
So, if you still target non-managed C++ and are not using MonoDevelop for Windows, two questions:
Did you make sure that the binding (addin) is installed and enabled?
If the answer to the above question is yes, you may want to try this: the binding creates projects with the extension ".proj" by default, I think, so maybe you can change this to ".vcxproj", recompile, and test again. If it works, then it should be easy to create a pull request to include this extension of possible file types that this addin can handle?
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I'm trying to investigate why would my app, written in VC 2008, crash on bare Windows XP with c0000005. It works great on any windows vista and 7. On XP it would crash with no additional info. Below are the details and the result of a few days worth of my headaches, eliminating one reason after another. Here's the details:
I have Win7 ultimate with XP Mode with iexplore 6 and presumably no patches whatsoever.
I install my program and nothing else, since it is supposed to be install-and-run thing with no additional packages needed.
My app has compiled-in VC2008 runtime (using /MT, as opposed to /MD compiler switch)
I'm using firebird embedded, which needs VC2005 (edited, i wrote VC2008 before) libs for itself anyway, so i put them in my app's working dir
when i install VC++ 2008 on this XP Mode machine, it doesn't crash anymore, so debugging this way is impossible
I've narrowed this error's occurence down to the VC2005 runtime - right after i install it my app stops crashing. But i don't know what could be using it's components. When running the release version under VC2008 IDE, nothing shows any vc2005 libs being loaded (weird, if i say so myself).
My app's linker's dependencies lists these (i added only the first two, the rest was there courtesy of VisualStudio): jpeg.lib, gdiplus.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib, comctl32.lib, %(AdditionalDependencies)
I am also using IBPP firebird interface, which loads these dynamically, so they are present in my app's dir (they need msvc?80.dlls):
fbembed.dll, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll, msvcp80.dll, msvcr80.dll
Please advise why would vc2005 runtime be a remedy for my app to not crash on a bare Win XP. Or how could i debug that one without installing vc 2008 on target machine. I'm starting to blame windows xp's components. Ultimately i want my app to not require any additional packages, such as VC2008 or 2005, especially when no component of my app requires the latter.
I am also using IBPP firebird interface ... msvcp80.dll, msvcr80.dll
The answer is in your question, these DLLs are VS2005 runtime support DLLs. They cannot be stored in your exe directory, they must be registered in the side-by-side cache. This does not typically cause an AV, but it isn't impossible if the code doesn't check the return value of LoadLibrary(). You can download an installer for them from Microsoft. It doesn't otherwise have anything to do with Windows XP, you just happened to try to run this program on machines that already had the DLLs installed. Very common on a dev machine for example.
If you don't want a dependency on them then you'll have to rebuild those DLLs that require it. Which is a good idea, having a dependency on more than one version of the CRT is pretty unhealthy.
If you are wondering why you are having to deal with this: it was Microsoft's attempt to put DLL Hell in the developer's lap instead of the user's. They've since withdrawn this, VS2010 again makes it a user problem. That was a pretty big party in Bangalore, I'd imagine.