I want to use Inetsim and that too, only on windows. Can I use it with help of cygwin?
Inetsim is a linux tool for simulating internet services.
I have this same question.
The following excerpt is the requirements for INetSim:
For using INetSim you need a system which meets the following
prerequisites:
POSIX compatible and System V IPC capable operating system (e.g. Linux)
Perl version 5.006 or more recent
Perl library Net::Server (available from http://metacpan.org/pod/Net::Server)
Perl library Net::DNS (available from http://metacpan.org/pod/Net::DNS)
Perl library IPC::Shareable (available from http://metacpan.org/pod/IPC::Shareable)
Perl library Digest::SHA (available from http://metacpan.org/pod/Digest::SHA)
Perl library IO::Socket::SSL (available from http://metacpan.org/pod/IO::Socket::SSL)
additionally, for IP-based connection redirection (only supported on Linux platforms with kernel support for packet queueing): Perl library Perlipq (available from https://metacpan.org/release/perlipq)
While Cygwin strives to be POSIX compatible, there is the question of what System V is and whether or not it's supported. This unhelpful message from the mailing list for the Cygwin project directs us to this entry from the user guide. Reading into the post suggests that System V is for IPC shared memory and message queues. Thankfully, the following excerpt from the guide suggests that running cygserver will provide the necessary services for System V to function:
-m, --no-sharedmem
Don't start XSI IPC Shared Memory support. If you don't need XSI IPC
Shared Memory support, you can switch it off here. Configuration file
option: kern.srv.sharedmem
-q, --no-msgqueues
Don't start XSI IPC Message Queues. Configuration file option:
kern.srv.msgqueues
Cygwin version 2.844 is current as of this post, and it provides Perl 5.14.4-1, which satisfies the second requirement.
The 3rd to 7th bullets surround particular perl libraries and are left as an exercise to the reader.
The final bullet, may be the nail in the coffin, however, as I can find no evidence that Perlipq is available for Cygwin (note: this requires kernel support as well, which can easily become too big of a problem for Cygwin to bother with).
Unless something changes, I believe the answer to your question is: No, INetSim cannot be used with cygwin.
Related
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
Will it be able to take input and print output to console?
A program that runs directly on hardware, pure machine code as this should be possible in theory
edit:
Ok, file formats are different, system calls are different
But how hard or is it possible for kernel developers to introduce another executable format called raw for fun and science? Maybe raw program wont be able to report back but it should be able to inflict heavy load on cpu and raise its temperature as evidence of running for example
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
in practice, no !
Levine's book Linkers and loaders explain why it is not possible in practice.
On recent Linux, an executable has the elf(5) format.
On Windows, it has some PE format.
The very first bytes of executables are different. And these two OSes have different system calls. The Linux ones are listed in syscalls(2).
And even on Linux, in practice, an executable is usually dynamically linked and depends on shared objects (and they are different from one distribution to the next one, so it is likely that an executable built for Debian/Testing won't run on Redhat). You could use the objdump(1), readelf(1), ldd(1) commands to inspect it, and strace(1) with gdb(1) to observe its runtime behavior.
Portability of software is often achieved by publishing it (in source form) with some open source license. The burden of recompilation is then on the shoulders of users.
In practice, real software (in particular those with a graphical user interface) depends on lots of OS specific and computer specific resources (e.g. fonts, screen size, colors) and user preferences.
A possible approach could be to have a small OS specific software base which generate machine code at runtime, like e.g. SBCL or LuaJit does. You could also consider using asmjit. Another approach is to generate opaque or obfuscated C or C++ code at runtime, compile it (with the system compiler), and load it -at runtime- as a plugin. On Linux, use dlopen(3) with dlsym(3).
Pitrat's book: Artificial Beings, the conscience of a conscious machine describes a software system (some artificial mathematician) which generates all of its C source code (half a million lines). Contact me by email to basile#starynkevitch.net for more.
The Wine emulator allows you to run some (but not all) simple Windows executables on Linux. The WSL layer is rumored to enable you to run some Linux executable on Windows.
PS. Even open source projects like RefPerSys or GCC or Qt may be (and often are) difficult to build.
No, mainly because executable formats are different, but...
With some care, you can use mostly the same code to create different executables, one for Linux and another one for windows. Depending on what you consider an interpreter Java also runs on both Windows and Linux (in a Java Virtual Machine though).
Also, it is possible to create scripts that can be interpreted both by PowerShell and by the Bash shell, such that running one of these scripts could launch a proper application compiled for the OS of the user.
You might require the windows user to run on WSL, which is maybe an ugly workaround but allows you to have the same executable for both Windows and Linux users.
For the task of creating a temporary directory in /tmp,
how would one choose between mkdtemp, mkstemp, etc., for portable code?
I presume you need to create a temporary directory inside a directory where other users may have write permission.
As an administrator, you should set things up so that each user has its own TMPDIR (e.g. with pam-tmpdir — or even better with per-process namespaces, but that takes more setup). As an application writer, however, you can't assume this, so you need to cope with a world-writable /tmp.
The right function here is mkdtemp, since mkstemp can only create regular files. mkdtemp was only introduced in POSIX.1 2008, so in principle it might not be available on all POSIX platforms yet. However, it has been available on major platforms for a long time:
on OpenBSD since 2.2 (1997)
on FreeBSD since 2.2.7 (1998)
on NetBSD since 1.4 (1998)
on OSX since… 10.0?
on Linux (with Glibc) since Glibc 2.2 (1999)
in dietlibc since at least 2001
in uClibc since its beginning, I think
in MINIX 3
on Solaris only since Solaris 10
So in practice, you can safely go with mkdtemp. If you need a fallback, include the OpenBSD implementation in your source.
i've downloaded "openjdk-6-src-b23-05_jul_2011" to have a look at the native implementations for the methods in sun.misc.Unsafe. e.g. compareAndSwapInt(...) but i am not able find anything in the downloaded sources of openjdk. i want to get an idea how these methods look like (i was interested in the atomic stuff the jdk provides).
could anybody point me to the right location(s)?
$ ls jdk/src/
linux share solaris windows
$ ls hotspot/src/os/
linux posix solaris windows
any help appreciated
marcel
Implementation of unsafe methods itself is not OS-specific, therefore it can be found in hotspot/src/share/vm/prims/unsafe.cpp. It delegates to hotspot/src/share/vm/runtime/atomic.cpp, which includes OS and CPU specific files, such as hotspot/src/os_cpu/windows_x86/atomic_windows_x86.inline.hpp.
Gcc atomic builtins as provided like java
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
But problem is there is no standard, as you move to solaris, you will need something else. So you have to use different system call as you change your platform.
The question is how to execute aout-format binary (I mean old format which for example used on FreeBSD before it has migrated to ELF) on Linux system. Is there a possibility to do so without extra coding (is there some existing solution)? Probably it should be in form of kernel module or patch for the Linux kernel. Another solution could be user-space launcher (may be even run-time linker). I have searched for something similar but was unable to found something. I have not yet checked difference in system calls interfaces, if you have some comments about that, you are welcome to provide them.
P.S. I know that writing user-space launcher for aout static binary is quite trivial but the question is about some existing solution.
Check for CONFIG_BINFMT_AOUT in your kernel config.
If your kernel has /proc/config.gz:
zgrep CONFIG_BINFMT_AOUT /proc/config.gz
On Ubuntu and the like:
grep CONFIG_BINFMT_AOUT /boot/config-$(uname -r)
Kernel option was CONFIG_BINFMT_AOUT, not sure if it's still around or necessary.
As all Linux distributions use the same kernel, is there any difference between their executable binary files?
If yes, what are the main differences? Or does that mean we can build a universal linux executable file?
All Linux distributions use the same binary format ELF, but there is still some differences:
different cpu arch use different instruction set.
the same cpu arch may use different ABI, ABI defines how to use the register file, how to call/return a routine. Different ABI can not work together.
Even on same arch, same ABI, this still does not mean we can copy one binary file in a distribution to another. Since most binary files are not statically linked, so they depends on the libraries under the distribution, which means different distribution may use different versions or different compilation configuration of libraries.
So if you want your program to run on all distribution, you may have to statically link a version that depends on the kernel's syscall only, even this you can only run a specified arch.
If you really want to run a program on any arch, then you have to compile binaries for all arches, and use a shell script to start up the right one.
All Linux ports (that is, the Linux kernel on different processors) use ELF as the file format for executables and libraries. A specific ELF binary is labeled with a single architecture/OS on which it can run (although some OSes have compatibility to run ELF binaries from other OSes).
Most ports have support for the older a.out format. (Some processors are new enough that there have never existed any a.out executables for them.)
Some ports support other executable file formats as well; for example, the PA-RISC port has support for HP-UX's old SOM executables, and the μcLinux (nonmmu) ports support their own FLAT format.
Linux also has binfmt_misc, which allows userspace to register handlers for arbitrary binary formats. Some distributions take advantage of this to be able to execute Windows, .NET, or Java applications -- it's really still launching an interpreter, but it's completely transparent to the user.
Linux on Alpha has support for loading Intel binaries, which are run via the em86 emulator.
It's possible to register binfmt_misc for executables of other architectures, to be run with qemu-user.
In theory, one could create a new format -- perhaps register a new "architecture" in ELF -- for fat binaries. Then the kernel binfmt loader would have to be taught about this new format, and you wouldn't want to miss the ld-linux.so dynamic linker and the whole build toolchain. There's been little interest in such a feature, and as far as I know, nobody is working on anything like it.
Almost all linux program files use the ELF standard.
Old Unixes also used COFF format. You may still find executables from times of yore in this format. Linux still has support for it (I don't know if it's compiled in current distros, though).
If you want to create a program that runs an all Linux distributions, you can consider using scripting languages (like Python and Perl) or a platform independent programming language like Java.
Programs written in scripting languages are complied at execution time, which means they are always compiled to match the platform they are executed on, and, hence, should always work (given that the libraries are set up properly).
Programs written in Java, on the other hand, are compiled before distributing them, but can be executed on any Linux distribution as long as it has a Java VM installed.
Furthermore, programs written in Java can be run on other operating systems like MS Windows and Mac OS.
The same is true for many programs written in Python and Perl; however, whether a Python or Perl program will work on another operating system depends on what libraries are used by that program and whether these libraries are available on the other operating systems.