I built SpiderMonkey 60 under Windows (VS2017) according to the documentation, using
../configure --enable-nspr-build followed by mozmake.
In the output folder (dist\bin) I could see 5 DLLs created:
mozglue.dll, mozjs-60.dll, nspr4.dll, plc4.dll, plds4.dll
In order to run the SpiderMonkey Hello World sample I linked my C++ program with mozjs-60.lib and had to copy over to my program location the following DLLs: mozglue.dll, mozjs-60.dll, nspr4.dll
It seems that plc4.dll, plds4.dll are not needed for the program to run and execute scripts.
I could not find any documentation about what is the purpose of each one of the DLLs. Do I need all 5 DLLs? what is the purpose of each one?
Quoting from NSPR archived release notes for an old version I found this:
The plc (Portable Library C) library is a separate library from the
core nspr. You do not need to use plc if you just want to use the core
nspr functions. The plc library currently contains thread-safe string
functions and functions for processing command-line options.
The plds (Portable Library Data Structures) library supports data
structures such as arenas and hash tables. It is important to note
that services of plds are not thread-safe. To use these services in a
multi-threaded environment, clients have to implement their own
thread-safe access, by acquiring locks/monitors, for example.
It sounds like they are unused unless specifically loaded by your application.
It seems it would be safe to not distribute these if you don't need them.
Related
I'm interested in learning about compilers and their creation, so I've been looking into various tools such as LLVM. It seems like a great framework to work with, but I'm a little confused how you can access native APIs with it.
Specifically, I'm interested in creating a language that has GUI or at least a windowing system built in. LLVM doesn't seem to wrap that functionality, so would I manually need to write assembly that called the APIs provided by each system (e.g. Win32)?
For example, the Red language claims to have a "Cross-platform native GUI system" built in. I assume they manually wrote the backend for that which used different system calls depending on the current system, or piggy backed on Rebol which did that instead.
Is such a thing possible or viable when using LLVM, which does a lot of the backend abstraction for you?
LLVM does not have an API geared toward abstraction of the use APIs. What you CAN do is write a runtime library for your language, and then use LLVM to generate runtime calls as needed. I have some experimentation and found that I preferred to write a runtime in C++ and then create some C bindings. The C bindings are necessary because C++ name mangling will make it very difficult to link against your runtime library, whereas with C the name of a symbol in a shared lib will be the same as that of the function.
I am coding for WinAPI in MinGW
One thing I still have not fully understood is the VC redistributable,
I got a whole pack of question to it
Some say that such programs will need the msvcrt.dll
is the same library needed for bot c++ and c compilation?
is this available on all targets of clients?
must I redistribute it? can I redistribute it?
can I easily get rid of this external dependency?
is there other compiler that will allow me not to carry such unpleasant external dependency? (as I vaguely remember hearing that something is wrong with it - it is probably not core system lib, I heard, or it is not free to use and redistribute the library)
I see something wrong is here as I would like to produce no dependency small exes only calling the system WinAPI and if I use
some like C standard library functions functions I would prefer it economically and statically compiled in, not any third-party dependencies
MSVCRT.DLL contains mostly the C runtime, and MinGW can only use the C part. C++ binary code cannot be used across compilers generally.
It depends on your "target". It is available from Windows 2000.
No. No. It is Microsoft-proprietary code, and every Windows version has a slightly different version.
No. I am not aware of a mature alternative C run-time DLL.
You do not need to worry about the dependency, as it is available everywhere. (Do notice that it is not really a great run-time, esp. regarding multi-byte characters.)
Microsoft compilers can link with "static" libraries so that the resulting executable depends only on system DLLs like kernel32.dll, user32.dll, etc. MinGW cannot do this (yet).
EDIT: A concise description of the MSVCRT.DLL problem is here.
According to the MS White-paper here:
http://www.microsoft.com/en-gb/download/details.aspx?id=13350
you can redistribute certain parts of the Visual Studio components.
Some software, such as the Microsoft .NET Framework, can be
distributed. Components of software products included in MSDN
subscriptions that can be distributed (either within an application or
as separate files) without royalty are identified in the REDIST.TXT
file associated with the product. Components that can be distributed
to non-Microsoft platforms are identified in the OTHER-DIST.TXT file
associated with the product. Code identified as distributable that has
the extension .lib cannot be directly distributed; it must be linked
into the application. However, the resulting output can be
distributed.
You may also:
Modify and distribute source code and objects for code marked as “sample” or “Code Snippet”.
Distribute the unmodified output of Microsoft Merge Modules for use with an application's .msi file.
Distribute the MDAC_TYP.EXE file containing core data access components (such as the Microsoft SQL Server OLE DB provider and ODBC
driver).
Distribute the object version of C++ libraries (Microsoft Foundation Classes, Active Template Libraries, and C runtimes).
MS also produces a redistributable package specifically for the purpose of developers: http://www.microsoft.com/en-gb/download/details.aspx?id=40784
So, to answer your questions:
Yes. Although it is "purely C", it contains fundamental functions that are used by the C++ part of C as well, such as file I/O, time and date functions, math functions, and so on.
Within reason. See link above.
No, yes. As described above: You may choose to just say to customers "you need to download an install this package", but the license should allow you to distribute it free of charge with your product.
Depends on what you call "easily" and exactly what parts of the library your code uses. Some functions may be easy to replace, others not so - but it's not easy in the sense of "yes, just go do http://www.example.com/msvcrt.dll-plugin-replacement" - it would require coming up with some replacement code. The reason MinGW DOESN'T come with its own C library is that it's not entirely trivial to write a replacement for ALL of the windows functionality that you may need here...
See above - if it was easy, someone would have done it. There MAY be some compilers out there that come with their own library, but it's probably not a free-of-charge and free to distribute one (I'm not aware of any product that doesn't rely on the MSVCRT.DLL - but it's not impossible that one exists)
I'm in the process of learning VC++ but I wonder why do end-users also need MSVC++?
As far as I can see in MSDN most if not all of the libraries that my programs use (the actual DLL files) already come with the system itself (user32.dll, kernel32.dll, etc).
But how come Paint and Notepad do not need MSVC++, but my software, which is way more simple than Notepad requires this runtime? What does the runtime do? How does it work? Is there a way to make my software work without MSVC++?
The runtime provides all the standard functions and classes, like std::string and std::vector, as well as the support code that runs constructors and destructors of global objects, finds exception handlers, etc. Windows comes with a version of all this, and for a while Visual C++ used it, but it was discovered that there were incompatibilities with the Standard, so newer versions of the compiler come with fixes (Windows can't bundle the new fixes in place of the old DLLs, because it would break existing programs).
Yes you can avoid the need for the runtime redistributable installer. You can use the /MT build option, which bundles all the required library functions right into your executable. After that, you'll only need DLLs that come with Windows.
The setting is in Project Configuration under C/C++ -> Code Generation -> Runtime Library
But note that this will make your executable file somewhat larger, and any bug fixes (especially security fixes distributed via Windows Update) won't affect your program, since you have a particular implementation baked in.
Adding to Ben's answer:
The runtime bundles a lot of features for each respective version of Visual Studio. The main advantage of using the DLL version of the runtime is that you get (security) updates "for free" whenever the system updates the DLLs in question.
Another advantage that some people will point out is that it saves resources to use the DLL version if many processes use the runtime via the DLL. This is because Windows has a mechanism to share DLLs in memory across processes (or the major part of them).
You will notice that bundling the runtime into your binary - also called static linking - will make your binary bigger, because each of your binaries now carries its own version of the runtime (that cannot be replaced without linking the program anew).
Also beware of mixing (your own) DLLs that statically link to either different versions of the runtime (i.e. Debug vs. Release) or that dynamically and statically link to the runtime depending on the DLL. The problem here is allocators. The functions to allocate (malloc, calloc, new) and free memory are incompatible across these. The best method in such a case is to use an independent mechanism such as IMalloc - or carry the deallocator inside your object instances always, ensuring that the call to free/delete doesn't cross module boundaries, even if the instance is handled in another module.
When we create a DLL using Visual studio (VC8 or 9), we get an option as
create Regular DLL
using MFC as shared DLL
or
using MFC as static library
How are they different? Which one is advisable to use?
A static library means the code you use from the library is included in your executable. Because of this, you don't need to ship the library or require the end user to have it on their machine. However this bloats the size of your executable and ties you to that library version, so if you need to update just the library, you have to ship a new executable.
A shared library calls the library at the time it needs it (runtime) to execute the code, but it requires the user to have it (usually a specific or minimum version) installed on their machine. You can also distribute the required version of the library with your application if you need to.
As for which is better, I don't know. I'm not a Windows C++ or MFC programmer so I couldn't say. On my Linux servers, the applications I write are generally server-side and thus use shared libraries.
It depends on how your application is to be used, distributed, updated, how often the MFC library changes, if it's generally available on user's PCs etc.
[I think I got my answer now]
If you use MFC DLL as dynamic linking, your code will need the Microsoft Foundation Library DLL's (specifically the version your code requires) installed along with your application or dll in the user end. So this means your installation package would contain
Your application/DLL and supporting files
All MFC Dlls
This makes the installation package size go bigger and also make take time for user to download your installation setup.
If you link to MFC as static library, you code will work even without MFC DLLs present at the user end . The reason being pretty simple that all the MFC libraries you refererred in your code, will be linked into your application or dll. This means those MFC libraries used in your app/dll becomes the part of the your binary; however, your app/dll will be little bigger.
Another consideration is servicing your application.
If you ship the MSFT redis, dynamically linking against its libraries, and then MSFT later "fixes" some vital flaw in a DLL, they patch the DLL on your customer's machines through Window's Update. If you statically link, you will need to update all your customers directly.
Of course, if you are concerned that a patched DLL might break your application (because you rely on unspecified behavior), you may want to handle the servicing (and testing) directly with your customer.
Please Note: Portable as in portableapps.com, not in the traditional sense of a language that can be used on multiple architectures or operating systems. Whoever coined this usage of the word portable should be whacked. :)
I'm a DBA and sysadmin, mostly for Windows machines running SQL Server. I'm looking for a programming/scripting language for Windows that doesn't require Admin access or an installer, needing no install process other than expanding it into a folder. My intent is to have a language for automation around which I can standardize.
Up to this point, I've been using a combination of batch files and Unix shell, using sh.exe from UnxUtils but it's far from a perfect solution.
I've evaluated a handful of options, all of them have at least one serious shortcoming or another. I have a strong preference for something open source or dual license, but I'm more interested in finding the right tool than anything else. Not interested that anything that relies on Cygwin or Java, but at this point I'd be fine with something that needs .NET.
Requirements:
Manageable footprint (1-100 files, under 30 MB installed)
Run on Windows XP and Server (2003+)
No installer (exe, msi)
No reliance on a JVM or Cygwin install
Works with external pipes, processes, and files
Support for MS SQL Server or ODBC connections
Bonus Points:
Open Source
FFI for calling functions in native DLLs
GUI support (native or gtk, wx, fltk, etc)
Linux, AIX, and/or OS X support
Dynamic, object oriented and/or functional, interpreted or bytecode compiled; interactive development
Able to package or compile scripts into executables
So far I've tried:
Ruby: 148 MB on disk, 23000 files
Portable Python: 54 MB on disk, 2800 files
Strawberry Perl: 123 MB on disk, 3600 files
REBOL: Great, except closed source and no MSSQL or ODBC in free version
Squeak Smalltalk: Great, except poor support for scripting
I urge you to try Lua. Regarding your requirements:
Tiny footprint (56 source files, under 150K compiled)
Runs everywhere (uses only ANSI C)
No installer needed; you compile from source (there's also a "batteries included" package that I haven't explored
Doesn't need JVM and works with any ANSI C compiler, so you can compile with Visual Studio, not Cygwin
Works with external processes and files but only to the extent supported by ANSI C. If POSIX popen is provided then that is supported also.
And your bonus points:
Open source (MIT license)
FFI to C is brilliantly conceived and executed—not quite as simple as Tcl but loads more powerful. Much better integration with C than Python or Ruby.
GUI support is mixed but there are good bindings for wx widgets. QT support was there at one time but I don't know if it has been maintained.
Linux is supported
Language/compiler features:
Dynamic
Functional
Prototype-based objects and inheritance through metamethods (you'll want to see examples in the book below
Fastest bytecode compiler in the West
Interactive read-eval-print loop; load new code dynamically
Able to package scripts into executables; either use Luiz de Figueiredo's srlua, or I can send you a 120-line Lua script that converts Lua source to a .c file that you link in with your app and the interpreter to make an executable.
Additional bonus points:
Very crisp, clean, well-designed language.
Small enough to master in its entirety and to be productive within a day.
Superb book Programming in Lua (check out the previous edition free online)
There are a couple of options for Python that might fit your bill:
The first is IronPython, which can be run without an installer and will play nicely with .net APIs. This gives you access to anything with a .net API or a COM typelib that you could build a PIA for. I've used at as a scripting mechanism for precisely this reason - it could be dropped into a directory within the system and did not need to be explicitly installed..You will have to have an appropriate .Net runtime installed, but .Net 2.0 is installed with SQL Server 2005. SQL Server can be accessed through ADO.net and building GUIs with Winforms is fairly straightforward.
The second is Portable Python which is designed to be run off a USB key. Although I see you've already tried it, you might elaborate on what the shortcomings were. If something isn't available in the basic install you could always look into building a custom version with it included. TkInter (at least) is bundled.You can also use Py2EXE to generate standalone python applications with all superfluous junk stripped out. This will give you about 10 files or so (depending on the number of DLLs) that can be run from a single directory, possibly on a USB key.
Running local python installs on Unix-oid OS's is pretty straightforward, so that's pretty much a no brainer. Also, python comes with most linux distros and is available as 'contributed software' from most if not all trad unix vendors. IIRC it's also bundled with MacOS.
Tclkit is a single-file, self-contained Tcl/Tk system. The mac version I have is about 3.8 megs. You can get a version for just about any modern OS. I carry around a thumb drive that has mac, windows and linux binaries so I can run my scripts on any platform. No install is required, just copy one file wherever you want.
The only thing it's missing from your original spec is MS SQL Server / ODBC support out of the box. I know people use tcl for that but I think you'll have to add an extra library or something. See the Tcl'ers wiki entry on MS SQL Server for more information.
For tcl, apart from Tclkit, freewrap is another small portable, self-contained interpreter for tcl.
Just rename the freewrap executable to something else will convert it to a stand-alone interpreter. Renaming it back to freewrap will convert it to a script wrapper.
Also, freewrapped apps contain a tcl interpreter. In dire emergencies you can try opening the app as a zip file and edit/replace the tcl code contained within (just remember to make a copy first). This has saved me several times when I'm at a client site without development tools but need to troubleshoot something. I just make a copy of one of my deployed app and presto - instant development environment!
Looking at wikipedia's exhaustive list of portable software
There's Tiny C compiler, again on Wikipedia here, and its own homepage here.
To summarize by quoting from wikipedia's list of features:
Small - can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker).
Fast - tcc generates optimized x86 code. No byte code overhead. It compiles, assembles and links about 9 times faster than GCC.
Any C dynamic library can be used directly. TCC is heading towards full ISOC99 compliance. TCC can of course compile itself.
Includes an optional memory and bound checker. Bound checked code can be mixed freely with standard code.
Compile and execute C source directly. No linking or assembly necessary. Full C preprocessor and GNU-like assembler included.
C script is supported: just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
With libtcc, you can use TCC as a backend for dynamic code generation.
Few dependencies. It includes its own hand-written lexer, and it is implemented using a recursive descent parser. Thus, building TCC requires few other libraries.
Its LGPL license permits anyone to use, modify, and/or redistribute the software, and it can be used to develop either open source or proprietary software.
Hope this helps and would be of use,
Best regards,
Tom.
Every somewhat modern Windows version comes pre-installed with both VBScript and JScript. The doesn't meet all your features (compile to an executable comes to mind), but they certainly have an unbeatable advantage with the installation size: it's hard to beat 0.
In addition to the Lua suggestion, there is also Idle. It is basically a superset of Lua 5.1, with both the language (and libraries) and the implementation based on Lua. It was originally created to be a more complete scripting solution for Windows: because Lua is primarly intended for embedding, it has a rather small standard library and it is usually expected that the embedding application provides a rich library to Lua.
This makes sense for an embedded language, because, after all, there isn't much common functionality between, say Adobe Lightroom, Nginx and World of Warcraft, so there simply is nothing you can put in a standard library. But for a more general purpose OS scripting language, one would want a slightly larger library. Thus, Idle bundles a couple of libraries that are third-party (and sometimes hard to get to work on Windows) in Lua in its standard library.
Some of the things that the Idle standard library adds over Lua are tight Win32 integration, SQLite3 support, networking support, a PEG parser generator and archive support.
Also, Idle has support for embedding Perl and C code into your Idle programs.