If you read Wikipedia articles about Wine, Cygwin and CrossOver, you will see that this software is classified as "compatibility layer".
I'm trying to understand what compatibility layer is from the point of view of virtualization layers. I mean, does it use:
library-level virtualization; or...
application-level virtualization; or...
some different-level virtualization (which one?)
and does it use virtualization at all?
It does NOT use any virtulization.
The cygwin1.dll provides a C Library and the Posix compatibility layer,
between the program and the underhood Microsoft system
Cygwin programs are special craft Windows programs compiled with ad hoc tools and linked to the cygwin1.dll.
Related
I want to use some methods in the ole32 and gdi32 libraries under Linux, but these two libraries do not exist under Linux, so are there alternatives when using under Linux?
I am using CGO
Use the following way to quote
#cgo LDFLAGS: -lws2_32 -lgdi32 -lole32
No, there are no in-place alternatives for these libraries on Linux as they are part of proprietary Win32 API and facilities they provide are specific to Windows only.
To make your application build on Windows and Linux you will need to abstract parts of application that use Windows specific libraries and implement them again for Linux using relevant replacement libraries (likely with different interface). Typically this is done so that programming interface - such as functions, methods, types, etc. towards your application are same but the underlying implementation is platform specific (using e.g. gdi32 on Windows and your favorite GUI framework on Linux). To achieve this Go provides Build Constraints mechanism that tells compiler to pull-in/ignore only certain files from codebase on each platform.
Go's own os package is good example of doing this.
If your application is heavily dependent on Windows ecosystem and porting does not make sense, perhaps building Windows native binary and running it in Wine emulation layer on Linux might be cost-efficient option.
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 am currently trying to utilize the Unsat Core on Alloy, but my options for solvers are limited to PLingeling and Sat4J. I am also given a warning that JNI-based solvers are not available on my platform (see Alloy Solver Options Capture). I am using Windows 10 with a 64 bit Java JDK.
How do I enable Alloy solvers with Unsat Core?
The comments on the post Alloy - Can't find unsat core suggests that I need to add the native library to LD_LIBRARY_PATH. However, LD_LIBRARY_PATH is a Linux concept, and it leaves enabling JNI on Windows unclear. Is there an equivalent to LD_LIBRARY_PATH in Windows 10? If not, how do I enable JNI in order to use solvers with Unsat Core?
A workaround would be to run Alloy inside the Windows Subsystem for Linux. It then thinks its platform is Linux and gives access to, e.g., Minisat that supports Unsat Core. (On Debian/Ubuntu, you can install minisat with apt.)
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'm currently in a project for a small C++ windows game application and its library.
Recently I found that Enhanced Mitigation Experience Toolkit (EMET) could be used on the client's PC to improve security.
I have toyed with EMET and even an application from Microsoft (e.g. sidebar.exe) hasn't been compatible with it, so it must require several special cares for programs to be compatible with EMET features such as ASLR or EAF.
What should I take into account to make my programs compatible with EMET features?
Is there any options for compilers or restrictions of workflow?
Thanks.
EMET is for legacy software which you cannot get their code utilize unavailable-unless-rebuilded security features.
If you can rebuild your software, refer to this page to enable them.