Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm not going to go into detail on the "media player" part except the fact that it will obviously use plug-ins, which will be a simple dynamic library that is loaded at runtime. Now, I could link those plug-ins dynamically to their dependencies, or I could link them statically. Both have their advantages and disadvantage - I'm not counting Linux here, as that will use shared libraries.
The single advantage I see with using shared libraries is that the library can be updated independently of the program. On Windows, this is rarely an advantage, as the library will be next to the application using it (thanks to no official C++ ABI). On Windows, to help with reducing DLL hell and share the C libaries, I would have to use SxS, which isn't a really nice citizen.
As for static libraries, I see one big advantage: link-time optimizations. Those ave been supported by ICC and VC++ for quite a while now and GCC has a branch for them. Since I will probably be using VC++ on Windows there would be a noticeable performance improvement as the compiler (well, the actual "compiler" just converts C++ to an intermediate language, so the compiler here is the "linker") has perfect knowledge of the code and can optimize lots of stuff this way. This is the option I'm leaning towards.
My question is, which one would be the best in my specific case?
There is no concern of other applications using them as I don't count Linux in this issue (though I have no knowledge of OS X) or multiple instances (who runs the same media player twice anyway?), binary compatibility (as I'll distribute everything with the application) or easy of updating (on Windows I'll use a very efficient binary diff patcher for distributing updates).
I'm not completely sure of what your "specific" case is.
If your "media player" is intended for a well know unique client (or small set of clients) who will update all the media player at once or any given plugin at once under your complete supervision then I'll go for static libraries.
If that's not the case I'll go for dynamic libraries. Optimizations are good but are not as good as customer/user satisfaction. There's nothing worse than updating your xxx library to the latest version and that all the sudden things just stop to work. If you haven't control over when and how updates are made be as flexible as you can.
Response to the comment:
Usually dynamic libraries are backwards compatible for minor release versions while static linking might be dependent on a concrete version and break if you try to link it to another release. With Dynamic Linking your program might even work as long as the calls you use doesn't change while static linking might depend on a change of the function offset in the library.
For example, static libraries might be loaded in runtime into the address space of the process at an static offset. Of course, knowing this offset allows for certain optimizations but if you update the library then either you update ALL the plugins using that library or probably the unupdated plugins won't work (as function offset might very well have changed).
I assume you load them in runtime, although if that can be named static linking is in the air, in any other case you will just have the library on each plugin and there will be no "sharing".
Related
So I'm currently working with a proprietary programming language that is C-like. So while this question wasn't directly inspired by a C program, I think those of you who are familiar with C may be able to offer some good insight.
I'm currently working on a library. This library encompasses some basic features as well as features that require other libraries. I'm running into the problem of 'where do I draw the line for how many dependencies are included in this library?'.
So this seems like it could be a fairly common problem. What methods exist for addressing this issue?
Something I've had in mind. Implement #defines and #ifdefs that allow users to compile the library with only the features they want. So essentially, all of the library functions that require additional libraries would be wrapped in #ifdef guards. The user would be responsible for #define'ing the features they want. Essentially, this method would allow a user to still use parts of the library without needing to have other dependent libraries.
Your thoughts? Again, this is for a C-like language. Thus tools like CMake, etc. aren't available.
Yes. If you take a look at the Linux kernel for instance, it's done the exact same way.
Yes you can and You Should.
I use them whenever i feel the necessity. Also, i have been working on freeRTOS and that's how things are being done over there.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
After some time coding in c in a simple console, I decided I wanted to try and code an actual Win32 application. However, upon selecting the option, the sheer amount of unknown code that surfaced on my IDE (Visual Studio 2013) just to open a blank window was overwhelming, as I don't understand half of it's meaning or even what to do, since, even simple printf commands yield no result... Can someone point me to a way to understand the differences between console and application? Or at least someway I can insert my current coding knowledge in an application environment?
Working with the Windows API can be quite the experience for a newcomer. The act of opening a window does, certainly, involve a lot of boilerplate code. The good news is a lot of that boilerplate rarely changes, and when it does it'll be for very special circumstances that you can go research. That's why Visual Studio spits the whole mess out for you by default.
There are plenty of resources to learn with, including Microsoft itself: https://msdn.microsoft.com/en-us/library/bb384843.aspx
To help situate you, understand that a lot of what you're looking at that's probably confusing are typedefs used on primitive types. This helps maintain backwards compatibility with programs created for older versions of Windows, and adds semantic meanings to types. A lot of the preprocessor stuff you see in header files is actually conditional compilation - it's checking what environment you're compiling in, what version of Windows, etc. and then providing the correct typedefs so that what actually compiles works on the desired Windows platform. Stuff that's greyed out in VS2013 is stuff that Intellisense sees isn't going to be compiled based on the current #defines and a lot of it may be relatively ancient. A big part of the Windows API for a long time was a strong desire to not break backwards compatibility. This was a huge advantage for Windows, because it means my program you wrote for Windows 3.1 isn't going to be hosed by Windows 95 rolling out. Or XP, 2000, Vista, 7, 8, 10, etc. It does mean a lot of stuff makes it into the API and stays there.
They try to hide a lot of that in the headers, but you'll also see deprecated input variables to functions and the like (this parameter should always be NULL...etc), and you just have to read the documentation. Thank the internet.
For example, an LPCSTR is just a const char*, but the LPCSTR signifies that it's a null-terminated constant string. In fact, you may see that's it's not a const char*, but a CONST CHAR* where CONST and CHAR are #defines themselves to make sure the correct keywords and types are used. In your case it'll probably end up being just normal const char*.
My suggestion, rather than diving into about as complicated a C-API as possible, is to look at something like SDL. SDL is a much simpler C API designed to provide an interface to the operating system's windowing, graphics, and input, while hiding the dirty details of the API, be it Windows, Mac, or Linux. https://www.libsdl.org/
It uses openGL for its graphics. If you're making any kind of game you'll be using some kind of graphics API to talk to the video card. The native Windows graphics API is DirectX, but openGL is the very commonly used cross-platform API. Both APIs allow you to make use of a computer's video hardware to render graphics.
Edit: I'll add, since I went off and voiced an opinion on libraries, which is why these types of questions are probably frowned upon, that I think it's fair to say that SDL is the de facto standard for C third-party multimedia libraries. Also commonly mentioned is SFML, which provides much the same functionality but is more object-oriented and written in C++.
In Visual Studio, when you create a win32 app project, click on next, and click on empty project. This will eliminate all the stuff that Visual Studio creates for a win32 app, but then you start with no files. You'll probably want to start with some simple example C program for windows from a book or web site.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've always wanted to learn how to manipulate .DLLs. I looking for tutorials, but I couldn't find a single one that can explain everything to me line-by-line. If there is a chance that I would find something, it wouldn't be in C (I'm looking for C tuts. Not C++ ones.)
I will explain in a general way how they work here. For the whole story, start at the MSDN documentation of DLLs. Also read documentation for your C compiler for the specific details about how to create and use them. And when you have trouble, ask specific questions at SO with supporting code so we can be more helpful.
At the simplest level (and deliberately omitting details) a DLL is a collection of functions that can be loaded into a process's memory space at run time with LoadLibrary() and subsequently called by the process.
The DLL file itself is formatted like a normal Windows executable file, but it does not have WinMain or main and as a result cannot be invoked without a container process. So it is created with the linker, just like any other executable. (This is a small lie. There actually is an entry point called DllMain(), but it is used for advanced features, is called when the DLL is loaded and unloaded, and still doesn't allow a DLL to be invoked directly from the command prompt or "executed" by CreateProcess() or similar API calls.)
DLLs can be loaded automatically at run time. This is the most common form, and allows the C runtime library to be loaded by every program from a single common copy. To do this, you simply link the application with the right libraries and options, and the system takes care of loading the DLL and fixing up all symbols that point into it.
DLLs can also be loaded at run time. This is commonly done to allow extensions to an existing application. One classic example of this is a Windows screen saver. A .SCR file is really just a renamed DLL that exports certain functions that provide the features of the screen saver. The window manager looks up which screen saver is configured at run time, load its .SCR file as a DLL, and calls the functions it provides.
You load a DLL by calling LoadLibrary(), and you find out the addresses of functions it contains with with GetProcAddress(). Note that it is entirely the responsibility of the calling application to know how to call the function, and there are lots of interesting ways that can go wrong. The most obvious case is that you must provide the expected number of parameters of the right types expected by the function in the DLL.
One of the reasons that COM was invented was to provide a framework that would allow the DLL to describe what functions it offers and the application to ask what parameters are expected by any particular function. The .NET framework provides the same sorts of introspective features but in many ways much more successfully. None of that sort of protection is available (another lie, it is, but it is very tricky to implement COM in pure C) to a plain C program and a DLL written in plain C.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
There are websites as collections of python/perl/R libraries. Why there is not an equivalent one for c?
I searched the internet and only found a small website calling itself CCAN. There are only a few libraries in that website.
If I need extra libraries for c programming, where can I find them? Is there an well organized website of the c libraries?
Thanks.
If I need extra libraries for c programming, where can I find them? Is there an well organized website of the c libraries?
No known to me outside of CCAN.
The problem here is that C doesn't have any even loose specification for libraries. Compare that to e.g. packages in Java or Python or Perl.
And even then, C is quite bare bone itself leaving many things for libraries to implement themselves. I/O abstraction, memory management, multi-threading, OS integration - minor differences in how libraries work with any of the resources might make them incompatible, preventing them being used in the same project.
I have seen in past some 3rd party commercial libraries for C, covering quite a lot of functionality, but frankly I can't recommend them and honestly do not even remember their names - for they often were causing more problems than really helping. (OK, I'm lying: they were rarely causing unsolvable problems: it's the numerous workarounds which were causing often the problems later.)
Otherwise, for C you might want to check the Glib and (do not get me wrong) to also check the C standard as in my experience few actually know many of the utilities already in the standard library itself. And well, Google is your friend: lots of public domain code is there for you to simply throw as-is into your project.
I don't know of anybody who's studied this in detail, though I would be curious to see the studies. I'm sure it has to do with the nature of the C programming community itself.
I think a large (maybe the primary?) part of the answer is: before the WWW, there was no such thing as a single resource for obtaining libraries for a particular language. People obtained their libraries, and knowledge of libraries, via many different means: through BBSes, mailing lists, newsgroups, and periodicals. The C community dates from this time, of course, and I've noticed a similar difference in culture regarding other languages from this period and before.
I think another part of the answer has to do with the general decentralization of C culture itself. There's no one C compiler, no one C development community, that serves as a hub and a potential point for projects to attach themselves to. And the C development community is huge, which further drives this decentralization and splintering.
In the case of C libraries, OS distributions actually do a pretty good job of collecting useful C/C++ libraries out there. (With the unfortunate exception of Windows, I believe.) They do a better job in these languages than most others, probably since C and C++ are such important systems languages on these platforms.
As far as CCAN goes, I think what would make a more worthwhile project, given the number of different distributors of C code out there, is to have a single site that links to the various libraries on their own native sites, rather than trying to get them to upload straight to CCAN. I think there's a use for this in and apart from Google, which will give you a lot of noise if you try just browsing for libraries. The question is, would you and the bulk of the C communities out there embrace such a site if it existed?
You might be amused to see how CPAN got its start: http://www.brainbell.com/tutors/Perl/CPAN_History.htm
CPAN evolved just as its community did. So the same thing could happen in the C/C++ world if the leadership and interest is there. But it hasn't happened yet.
use http://www.google.com/codesearch?q=lang:%22C%22 variant of http://www.google.com/codesearch
=> i.e. add lang:"C" in the search query
Use these web-sites:
Debian "Testing": Subsection libs
The Free Country: Free C/C++ Libraries
Free Software Directory: Category/Library
SourceForge Software Map: Software Development/Libraries/C
Upstream Tracker: List of C/C++ Shared Libraries
There is a Maven-like repository and dependency management system called Biicode.
There isn't a huge collection of libraries on there yet, but you can add forks of open source projects yourself or inform original authors about it.
EDIT: the company behind biicode is dead
EDIT2: the spiritual successor seems to be conan.io
There is a C package manager which looks promising called CLib:
github:
https://github.com/clibs/clib
tutorial:
https://dev.to/noah11012/clibs-a-package-manager-for-c-4jmi
Why do you need a website for a collection of C libraries? Just use Google.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I want to create a GUI driven application for a micro-controller (Atmel XMEGA) that is connected to a 128x64 dots graphics LCD (EA DOGL128-6) and 4 buttons for navigation.
Controlling the display itself (e.g. drawing pixels and characters) is no problem but in order to prevent me from reinventing the wheel I was googling for a GUI-Library/-Toolkit that is written in c, includes its source code, will run on a 32 MHz 8-bit micro-controller and provides at least the following controls:
panel (to group elements)
menu (scrollable)
icon
label
button
line-graph (optional)
But I didn't find any thing useful. Does anyone know (or better uses) such a library(preferably for free)?
I would consider rolling your own "immediate mode" GUI. Jari Komppa has a good tutorial about them. It's a lot easier than you may think, and you'll probably find most GUI libraries--even those targeting embedded systems--are a bit heavy-weight for your system.
If you insist on using a third-party library, below are a few I found. I've never used any of them and they are probably fairly expensive.
emWin
C/PEG
easyGUI
I personally used PEG (at work), but it is not for free. You just need to write a small layer of adaptation and use it. You can also look at Qt or minigui.
I also wrote a library which supports nearly any display technology: µGUI
http://www.embeddedlightning.com/ugui/
µGUI is a free and open source graphic library for embedded systems. It is platform-independent and can be easily ported to almost every micro-controller system. As long as the display is capable of showing graphics, µGUI is not restricted to a certain display technology. Therefore display technologies such as LCD, TFT, E-Paper, LED or OLED are supported. The whole module consists of two files: ugui.c and ugui.h.
This might be helpful as well
You should take a look at Contiki [wikipedia.org]
Besides being a small and elegant operating system for many 8/16/32-bit microcontrollers, it also features a GUI toolkit. It runs on the Atmel AVR!
For your convenience, here is a direct link to the The Contiki Toolkit (CTK) source code.
In addition to Judge Maygarden's list RAMTEX provide libraries specifically aimed at small graphic LCDs. Again not free, but is this is for commercial use, remember that if you did it yourself, it may take many man hours to achieve a polished product, so consider that before building your own.
At the rates my company accounts for my time (as opposed to my pay rate), if it took more than five hours, I'd be better off buying the Ramtex library (about two days if you only take my pay rate into account). If however you have the time and inclination, it is not a difficult task, and probably fun.
Rich Quinnell mentions
"... I saw a demonstration of Java applications running on an STM32-F3 MCU..."
http://www.microcontrollercentral.com/author.asp?section_id=1741&doc_id=253618
I guess it is what you are looking for?
Atmel (now owned by Microchip) actually makes a GUI library targeted at their microcontrollers.
This is part of the now called Microchip® Advanced Software Framework.
You may want to have a look at the Nano-X framework (formerly known as Microwindows): http://www.microwindows.org/
It claims to support down to a 16-bit DOS system, so I'm not sure if it's suitable for an 8-bit, but maybe the library can be pared down to just what you need.
I haven't used it, but at one point was considering looking into using it for some simple display UI (though on a 32-bit ARM system). Unfortunately, the project shifted gears before I actually did anything with it. I'd be interested in what your take on it is (or how well it works if you decide to try to use it).
We've started using easyGui and it seems good. You design the screens in a PC app then it generates the source code - making the design stage really easy.
It does most of the things on the list. Line graphs are coming soon. You can make up buttons pretty easily as reusable structures.
It comes with template drivers for lots of displays - depending on how closely the template matches your display (colour depth & interface are the biggest issues) you might be able to use the code unmodified or change it to suit.
I have been working on a similar project. Closest thing I could find are in the following links, but I doubt you will find a library with all the features you desire. These will only setup basic drawing functions, but it's a start. There are also some useful tools for bitmap converting and font creators if you dig around.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/glcd_dcf77/index.html
http://en.radzio.dxp.pl/
Almost everything else I have seen here is way overkill for what the poster seems to be asking for.
The CodeVisionAVR development environment now has graphical libraries for XMEGA.
The CodeVisionAVR C Compiler features a powerful graphic library for
LCDs with resolutions from 84x48 up to 800x480 pixels.
However, it is not free.
You can use the "Microchip Graphics Library" for free.
This includes GUI tool "Graphics Display Designer X" for designing screens and this outputs the "C" files for your designed screen.
I am using this tool which is very user friendly, but some of the widgets what you are looking you may not find.
Here is the link for GUI tool:
Click here!
NuttX is a real-time operating system for microcontrollers. The author has starting a developing some gui primitives for LCD displays for it.