I am a novice programmer and I just have started to learn InstallShield for a few days. I find something quite confusing that need support form experts:
In InstallScript, I can set the targeting platform/ operating system for the installation in Release wizard.
In basic MSI: I can only find the require operating system in the Project Assistant view.
That leads to my confusion:
Is targeting platform/ operating system and require operating system are the same thing? If not, does that means targeting operating systems are the only systems that my installation can run on; while require operating systems are the prerequisite, but not limited to, for my installation be able to run on?
Is there other ways that I could set the require operating system for my Basic MSI Installation rather than accessing the Project Assistant view?
There is so much I don't know, thus, your detailed explanations are much appreciated. Thank you all for your time.
You'll want to check Operating System properties and use those in conditions in the LaunchCondition table. The method of doing this is defined on this page.
Related
I am trying to learn IBM's basic assembly language and I was wondering if there was a way of assembling BAL code on a Linux guest running on a mainframe?
I have nasm and as installed, but I think these are normally used for Intel processors rather than Z.
There is a tool chain in Linux so that you can write assembler. as as an assembler then link edit and go. However, assembler is just a “language” which depends on a broader eco-system of APIs.
For instance, on z/OS there are a number of manuals that document the interfaces to operating system services, authorization of assembler and other “operating system services” that are going to vary depending on the OS you are developing in.
If you want to code 390x assembler on Linux you can but you are using OS services in Linux which are very different than other OS’ like z/OS.
If you are interested in a compare and contrast of the architectural differences between z/OS and zLinux you will find this presentation enlightening.
Here are a few other possibilities, in no particular order:
IBM offers a commercially licensed HLASM for Linux on Z/LinuxONE. The standalone IBM Program Number for IBM HLASM is 5696-234, but it can also be licensed via other IBM operating systems for Z, such as z/OS. IBM distributes HLASM for Linux as a .rpm file, and it'll be something like asma90-1.6.0-47.rpm (where 47 is a revision level, the most current I see at the moment but subject to change).
Dignus offers a commercially licensed product known as Systems/ASM (or DASM for short).
z390 may be of interest: http://www.z390.org
Please note that z390 apparently hasn't been updated since 2012, so it likely won't include support for recent machine models' instructions.
I don't have any knowledge about Linux/Unix environment. So for some understanding I have put this question in front of all the developers and Unix/Linux technical people.
By applications I target IDE's used by developers, especially:
Visual Studio
IntelliJ Idea Community Version
PyCharm Community Version
Eclipse
And other peripheral apps used by developers, gamer and network engineers
To some experienced Linux users, my question might be baseless. But consider me a beginner with Linux. Thank You in advance.
The term "application" is a very vague, fuzzy one these days. It does not describe some artifact with a certain internal structure and way how to invoke it but merely the general fact that it is something that can be "used".
Different types of applications are in wide spread use on today's systems, that is why I asked for a clarification of your usage of the term "application" in the comments. The examples you then gave are diverse though they appear comparable at first sight.
A correct and general answer to your question would be:
One application can be used in different Linux based environments if that that environment provides the necessary preconditions to do so.
So the core of your question is kind of shifted towards whether different flavors of Linux based systems offer similar execution environments. Actually it makes sense to extend that question to operating systems in general, the difference between today's alternative is relatively small from an applications point of view.
A more detailed answer will have to differ between the different types of applications or better between their different preconditions. Those can be derived from the architectural platform the application is build on The following is a bit simplified, but should express what the situation actually is:
Take for example the IntelliJ IDEA and the Eclipse IDE. Both are java based IDEs. Java can be seen as a kind of abstraction layer that offers a very similar execution environment on different systems. Therefore both IDEs typically can be used on all systems offering such a "java runtime environment", though differences in behavior will exist where necessary. Those differences are either programmed into the IDEs or origin from the fact that certain components (for example file selection dialogs) are not actually part of the application, but the chosen platform. Naturally they may look and behave different on different platforms.
There is however another aspect that is important here especially when regarding Linux based environments: the diversity of what is today referred to as "Linux". Unlike with pure operating systems like MS-Windows or Apple's MaxOSX which both follow a centralized and restrictively controlled approach we find differences in various Linux flavors that far extend things like component versions and that availability. Freedom of choice allows for flexibility, but also holds a slightly more complex reality in the outcome. Here that means different Linux flavors do indeed offer different environments:
different hardware architecture, unlike MS-Windows and MacOSX the system can not only be used on intel x86 based hardware, but on a variety of maybe 120 completely different hardware architectures.
the graphical user interface (GUI or desktop environment, so windows, panels, buttons, ...) is not an integral part of the operating system in the Linux (Unix) world, but a separate add on. That means you can chose.
the amount of base components available in installations of different Linux flavors differs vastly. For example there are "full fledged, fat desktop flavors" like openSUSE, RedHat or Ubuntu, but there are also minimalistic variants like Raspbian, Damn Small Linux, Puppy, Scientific Linux, distributions specialized in certain tasks like firewalling or even variants tailored for embedded devices like washing machines or moon rockets. Obviously they offer a different environment for applications. They only share the same operating system core, the "kernel", which is what the name "Linux" actually only refers to.
...
However, given all that diversity with it's positive and negative aspects, the Linux community has always been extremely clever and active and crafted solutions to handle that specific situations. That is why all modern desktop targeting distributions come with a mighty software management system these days. That controls dependencies between software packages and makes sure that those dependencies are met or resolved when attempting to install some package, like for example an addition IDE as in your example. So the system would take care to install a working java environment if you attempt to install one of the two java based IDE's mentioned above. That mechanism only works however if the package to be installed is correctly prepared for the distribution. That is where the usage of Linux based systems differs dramatically from other operating systems: here comes the introduction of repositories, how to search, select and install available and usable software packages for a system and and and, all a bit to wide a field to be covered here. Basically: if the producer of a package does his homework (or someone else does for him) and correctly "packages" the product, then the dependencies are correctly resolved. If however the producer only dumps the raw bunch of files, maybe as a ZIP archive and insists on a "wild" installation as typically done for example on MS-Windows based systems, so writing files into the local file system by handing administrative rights to some bundled "installer" script that can do whatever it wants (including breaking and ruining or corrupting) the system is executed on, then the systems software management is bypassed and often the outcome is "broken".
However no sane Linux user or administrator would follow such a path and install such a software. That would show a complete lack of understanding how the own system actually works and the consequent abandonment of all the advantages and comfort offered.
To make a complex story simple:
An "application" usually can be used in different Linux based environments if that application is packaged in a suitable way and the requirements like runtime environment posed by the application are offered by that system.
I hope that shed some light on a non trivial situation ;-)
Have fun!
I am looking for design suggestions/documents etc. which contains specifics of system applications management in Linux (Ubuntu, Debian etc.)
Can you please point to a source of information or suggest a design?
I'm not sure to understand what you mean by system applications management (certainly it can mean several different things).
In practice, Linux distributions have some package management system to deal with that issue. init or systemd (etc....) is in charge of starting/stopping/managing daemons and servers. Its configuration is related to packaging.
Read also Ubuntu Packaging Guide and How To Package For Debian and Debian new Maintainer guide etc...
If you are coding some service application, read Advanced Linux Programming and about daemon(3) & syslog(3)
Also, study the source code of relevant system applications (similar to the one you are dreaming of), since Linux is generally (mostly) free software.
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
Note: There is a similar question called 'installing nodejs on windows machine'.
And various answers explaining how by installing cygwin you can get it working there.
now, I don't want to install cygwin.
I just wish I could run nodejs on a windows box.
I want a "nodejs.exe" to kick off.
Can somebody explain to me
1) why nodejs has not been ported on windows - what are the technical reasons for not providing an exe ?
2) are there any plans to have nodejs on windows ?
I really would like to use it but I can't accept that I have to accept cygwin.
That's just not right.
Update:
For optimum node on windows development I recommend you use the Windows Azure powershell for node.js. It's a powershell optimised for using node, npm and the azure APIs. (the azure apis are optional. I would still use this powershell if I didn't use azure).
When : v0.6
Currently you can get a binary file that (kind of) works under windows. Go ask on the node.js IRC channel. They'll hook you up.
Basically if you read up on node.js road plans you will find that proper windows support is planned for 0.6, we are currently on v0.4.7 and the v0.5.x beta is in full storm.
I won't give an ETA but it's soon.
IRC can be found at the Community links
PDF showing v0.6 road plan
July 2011 update:
#nodejs v0.5.1 is the first to ship with an official Windows executable. We're hoping to get some good feedback.
Microsoft has officially gotten involved with joyent in making node.js run natively on windows.
Running Node under Windows presents several technical problems, mostly related to how Windows' internal design differs from that of Linux and the "change in mindset" required to port Unix applications to Windows.
Background
Linux was designed to be a replacement for Unix, a well-known multitasking operating system, so from day one it has been a multi-user/multi-process, server-oriented operating system. The idea of multiple processes sharing system resources is key to its internal design.
Windows was initially designed as a single-user/single-process desktop operating system and so did not support shared access to system resources. In 1993 Microsoft released a newly redesigned version of Windows--called Windows/NT--to better support the shared resource, multitasking model required by servers, but due to its existing installed base of users, Microsoft required NT to also support all the features of its single-user/single-tasking forebearer.
Windows 7 is a direct descendant of NT and Microsoft's need to support legacy users continues to this day (and in the opinion of many, has severely muddled Windows' internal design.)
Further, Microsoft hired a systems architect named Dave Cutler to design NT. Dave is best known for designing a competitor to Unix called VMS, the internal design of which differs significantly from that of Linux, which has caused a lot of problems for developers interested in porting their Unix programs to Windows.
The clearest example of this "impedance mismatch" between the internal design of Windows and Linux is how they handle event-driven, non-blocking input/output (io) on which Node relies to perform its (apparent) multitasking magic in a single thread of operation.
Linux supports two system-level functions called select() and epoll() which can be used to asynchronously inform a process of changes within the operating system that affect it. Node relies heavily on these functions but Windows doesn't support either, relying instead on "Change Notifications" (mostly) to handle event-driven io.