About 2 weeks ago I installed the new 2016 version of the GNAT GPL Ada/SPARK compiler and associated software tools.
But the damn thing won't work right.
Running existing projects on it, it just won't compile and shows some errors with Python files.
Anyone else experience this problem ?
I'm (still) using Win XP as the platform for the GNAT GPL dev tools.
EDIT
Just saw this on a ReadMe file : This version of GNAT GPL is officially supported on the following hosts. Please see the "Special Notes" section immediately following the targets section for special instructions relevant to specific platforms. PC/x86 and x86_64 - Windows Vista Business, 7, 8, 8.1, and 10 So it looks like GNAT 2016 won't run any longer on Win XP machines.
The errors seem to be in the jedi library, part of python.
Did you install in a new directory, or over an existing install ? I would recommend the former, so you likely should redo the install from scratch, and in a new directory.
I simply disable "jedi support" plugin inside Tools/Plugins and everything works perfectly. This plugin is completion for python editor, maybe you don't need it for ada.
Related
On our PC (under Windows XP there is MiKTeX, and it have been working well for many years. However, several month ago, after installing the latest version (setup from 09/16/2017), dvipdfmx stopped working reporting something like 'it is not win32 application'. It has been appeared that the problem is arisen by mgs.exe (ghostscript for MiKTeX). The first thought was that a 64-bit version of mgs.exe was mistakenly included into 32-bit MiKteX. However, it is appeared not the bug: MiKTeX team says that it is worked under 32-bit Windows 7.
I do know that officially MiKTeX now requires Windows 7 or higher (so, XP is not supported). However. it was perfectly well until the latest update, and even now latex.exe, yap.exe and others still work. So, the question: is it possible to go the problem around within XP?
Without knowing what the actual problem is, its impossible to offer any advice. When quoting errors it is important to quote the exact error message.
"Something like 'it is not win32 application'" is not precise enough.
This is also not a Ghostscript question, because 'mgs.exe' isn't Ghostscript, its clearly a fork of some kind.
My guess is that its the fact you are using an ancient version of Windows, most likely the application is no longer compatible with such an old version, possibly because whoever built it is using a newer version of Visual Studio.
In order to build Ghostscript for Windows XP I think you need to use Visual Studio 2005 or earlier, a more recent version will create an executable that will not run on Windows XP.
The only solution to this would be to build 'mgs.exe' with an older version of Visual Studio, or try the pre-built executable 'gswin32.exe' which is available from the ghostscript.com website in the downloads section. Obviously that's not the same as mgs.exe, but I can't help you with a fork since I have no clue what's been done.
The first thing to try is running 'mgs.exe' from the command line, if that fails to work then its almost certainly because the developer who built it used too recent a version of Visual Studio.
If this is the case then no, you can't fix it within Windows XP, you need to do one of:
1) Upgrade to a newer OS
2) Downgrade your MikTeX and live with the older version until you are prepared to upgrade your OS.
3) Rebuild 'mgs.exe' yourself using an old version of Visual Studio. This could be challenging because I can't find anywhere on the MikTeX website where they make the source files available. I've been to their Github repository and I can't find anything from Ghostscript there either. I'm going to have to contact the developers, they are not using a stock version of Ghostscript, they do not appear to make their revisions available, ansd although they correctly reference Ghostscript as AGPL I cannot see anywhere in the install or their Github repository which lists Artifex as the owner or points to the Artifex website. They also don't copy the Licence or readme files (slapped wrists for them).
I was going to try using the regular Ghostscript instead of the modified version, but I don't have know anything about MikTeX so I have no way of testing whether that works. It looks to me like it probably would, since it appears that MikTeX forks Ghostscript as a process. So copying and renaming the 64-bit Windows version of Ghostscript's binaries would probably work.
As you note, the developers state themselves that they no longer support Windows XP.
Short version:
When I moved to Win7, I manually removed the MDAC 2.7 lines from my .ISM module, built it, and installed my software. It seems to work. Can I trust it?
Longer version:
We have just gone from XP to Windows 7. The software we deliver is C# (.NET 4 framework), targeting XP and Windows 7. It contains a few older COM modules, one of which is written in VB6. (Yes, I would love to rewrite this in a modern technology, but that's not an option at this point.)
I use InstallShield 2010 to build the installer for this package. Building this installer on XP worked with no problems. When I try on Windows 7, it wants MDAC 2.7 as a prerequisite merge module. Microsoft doesn't allow you to download 2.7 anymore, and I'm not going to get it from "Sharewarez R'us" sites.
The error InstallShield gave me when it couldn't find the merge module was: File not found. An error occured merging Module 'MDAC27ENU...'
From what I've read on the web, Windows 7 has the latest-greatest MDAC (now renamed WDAC) already installed. On a whim, I manually deleted the MDAC dependencies from the .ISM, built and installed, and my software seemed to run just fine.
What I think is happening is Win7 is noticing that something in VB6 is using MDAC and the OS is supplying the latest-greatest and it just works. I no longer need the merge module because Windows 7 has WDAC built in. (Can it really be that simple?)
My main question is: can I trust it?
My secondary question is: What about XP deployments? They will still need MDAC 2.7... Does that indicate I can't build on Windows 7 to target XP if I require MDAC 2.7? Please point me in the right direction. Thanks.
You need a comprehensive review (dependency analysis) of your installer. The VB6 runtime and MDAC/WDAC components are all built into windows these days. This is also the case with Windows XP and the latest service pack.
Either your ISM is referencing the MDAC merge module or it's referencing another merge module that has a dependency on the MDAC merge module. Hence why I suggest a complete review.
Without looking at your application I can't give you a 100% answer but odds are that if you implement a setup condition (launch condition) to check for XP latest service pack or newer that you will likely work without installing a bunch of stuff you don't need to be installing.
Considering to develop a desktop application with Qt for Windows. It will be a free download application, but for a commecial SERVICE. (need an account with our commercial service to work).
I think we could use the Qt for Windows from Nokia (LGLP version) because its free app. But the lastest one version of Qt needs a C++ complier from Microsoft.
Which one?
Do I need to pay for an C++ compiler from Microsoft, or do they have a free version to use with Qt?
Reading info docs, googling and we still cann't understand what tools do I need.
If you want to use the Visual Studio compilers, you can download the free Windows SDK. The following link takes you to the SDK for Visual Studio 2008:
Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1
This includes all the C++ compilers and tools you need. (There is a more recent version available, but Visual Studio 2010 is not yet a "level 1 supported" platform for Qt.) We are using this on standalone build machines and it works fine.
Just a personal opinion, but we have found that using anything other than MSVC on Windows (for example, MinGW) causes a lot of problems. It is not that the other toolchains are bad, it is just that they are all treated as second-class citizens. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
For the most part (static linking), you cannot mix and match. You need to pick one toolchain and stick with it. If I were starting from scratch, I'd definitely go with MSVC.
Just our experience (we started with MinGW); your mileage may vary.
No, you do not need to pay for anything.
The Microsoft toolchain is available for free as part of the Microsoft Windows Software Development Kit.
Additionally, the following article may also be of interest to you:
Developing Windows Applications in C++: The tools you need
The alternative supported by Qt is MinGW. The runtime libraries are free from copyright, so you can do whatever you want with them.
It is basically the Windows counterpart of the GNU Compiler Collection (GCC) under Unix.
Can someone give me a link where i can download a gtkmm 3.0 library for development without need to build it by myself?
thanks
http://live.gnome.org/gtkmm/MSWindows
That is the best I could find. It stops at 2.8, tough.
http://mail.gnome.org/archives/gtkmm-list/2011-April/msg00077.html
That is an email to the gtkmm mailing list from the windows installer developer. It seems that the dev doesn't have much time for it right now (or at least didn't on April 28, 2011).
Not much help, but that seems to be the state of gtk+ and gtkmm on windows right now.
The original question is old, but I post here for future visitors.
Apparently the link specified in senshikaze's answer is broken.
Windows installer (for both runtime and development stuff) is available from ftp.gnome.org
32-bit
64-bit
I built the gtkmm binaries over official gtk 3.6.4 binaries.
For 32 bit version you can download the binaries that I created, and there is also the (simple) procedure to create them yourself if you need 64 bit, everything on http://www.giuspen.com/2014/02/build-gtkmm-3-6-0-windows-binaries-on-official-gtk-3-6-4-bundle/
Gtk 3.0 library for windows is at hand from http://www.gtk.org/download/win32.php/
And you could find more optional dependence on http://win32builder.gnome.org/
But Gtkmm 3.0 hasn't have an official release, but some volunteer make it, I find a good one, http://sourceforge.net/projects/tview/files/gtkmm_bin_3_6.7z/download
I created a blog on how to install latest gtkmm on Windows (step by step) here:
http://gtkmm-installation.blogspot.com/
UPDATE:
I have just compiled everything with Visual Studio, You can download my gtkmm3 development binaries for Windows x64 from my GitHub page, I also made a wiki entry on how to compile everything on your own with Visual Studio.
All of the Visual Studio projects to compile everything can also be found on GitHub.
You can install it with vcpkg.
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try