Since there is this: http://en.wikipedia.org/wiki/Code_page_437 For MSDOS, is there something similar for Linux systems? Is it possible to access that font data via userland program? I would actually just need an access to the actual bit patterns which define the font, and I would do the rendering myself. I'm fairly sure that something like this exists, but I haven't been able to find what exactly is it and how to access it. After all, e.g. text mode console font has to reside somewhere, and I really do hope it is "rawly" accessible somehow for a userland program.
Before I forget, I'm programming my program in C, and have access only to the "standard" linux/posix development headers. The only thing I could came up with myself is to use the fonts in /usr/share/fonts, but having to write my own implementations to extract the data from there doesn't sound really an option; I would really want to achieve this with the least amount of bytes possible, so I feel I'm left with finding a standard way of doing this.
It's not really feasible for me to store my own 8x8 ASCII-compatible font with the program either(it takes some 1024 bytes(128 chars * 8x8 bits) just to store the font, which is definitely unacceptable for the strict size limits(some < 1024 bytes for code+data) which I am working with), so being able to use the font data stored at the system itself would greatly simplify my task.
I had a look at consolechars sources and it looks like there is a whole library for this kind of stuff. On Ubuntu it's named libconsole and header files (like lct/font.h) are in the console-tools-dev package. There are functions to find and load fonts which seems to be exactly what you need. And consolechars source is a nice example of how to use them.
You should use freetype , its commonly installed in all the Linuxes.
Related
How can I get the label of a filesystem using /sys? I know I can get much of the info about a block device by going to /sys/class/block/<device>, e.g. /sys/class/block/sr1 for a cd that I know has the filesystem label config. I hunted through each item, found everything but the label.
I did dig through the lsblk source code, which, in turn, depends on calling udev_device_new_from_subsystem_sysname in libudev, so I went through that. It does appear to populate the property ID_FS_LABEL_ENC, but I cannot figure out where it takes it from in the tree, unless it is tracking it elsewhere?
I would just use libudev, but need to access outside of a C program.
I think that the problem here is that you seem to think that the label of a volume is a kernel thing, as is the size or the free space.
But AFAIK it is not, the kernel doesn't care at all about volume labels, it is just a thing that goes from the in-disk format to user-land: there is no kernel API to get that information. If you need it, you just open the raw binary volume and read the data from there.
But then, there is the big issue that every filesystem is different, so you need special code to manage every single partition type there is. Fortunately, somebody has done the hard work, and you have blkid, part of util-linux available in most Linux distributions. If you need it, you can call the program directly, or link to the library libblkid that does the hard work.
Naturally, to use blkid/libblkid you need read access to the block device, that is, root access. If you think that root access should not be needed to read a label, the people from udev think the same, and that is why there is a udev rule that copies the label when the filesystem is first dectected (running blkid of course). This is the ID_FS_LABEL_ENC you already know about.
I have a general question about finished applications. When I go into the files of a windows computer application, some files make sense as to why they are there, such as the executable, various media files, .dll files, etc. However, what I don't understand is how there's potentially thousands of different files, located in hundreds of different directories (counting hierarchy) with anywhere between dozens and hundreds of different filetypes. Some of the filetypes don't even seem like actual files, the extension could be something completely obscure. How does the application know how to work with that? Are all of those files hand-written and compiled or are many of them supplied automatically upon generating a desktop application (which would vary based on the application, of course)? I've never actually compiled an application in any language, as I've been studying JavaScript as a starting point, and I recognize that JavaScript is not intended for creating standalone applications, it's used to implement inside HTML. This is why I have so many questions about the generation of the application itself.
To provide an example, a few of the file extensions I see contained in the Audacity application folder which I don't recognize are as follows: .lsp .raw .mo .ny .exp
Even that is a very short list compared to the amount of filetypes/extensions I usually encounter which I have no knowledge of. So, all in all, my main question is why there's such a crazy amount of files, folders, and filetypes/extensions being used by an application. Hopefully someone can help me understand.
Extra question, for those who might care to answer it:
What does it mean when you open a file in an application like Notepad++ (or a .plist editor) and it's just a bunch of unreadable characters? I'm assuming that means it's a compiled file, but I could use some clarification. This happens when I try to open an .exe, a .dll, etc. I understand why I can't edit things like that in a text editor of course, yet why all the strange symbols and characters? Why wouldn't it just throw an error upon trying to open it? Are all the strange characters just a way of attempting to interpret already compiled code?
Bear with me, I'm pretty new to programming and I'm trying to get a better understanding of the process behind actually generating a GUI-based desktop application. As I said before, my current knowledge doesn't extend to the point of actually compiling an application.
Thank you for any help, I really appreciate it.
Focusing on your extra question: you have to learn what a binary file and a text file is, but in short: Imagine you have a simple calculator program that stores the result in a file. Lets say the result you want to store is the number 64. You have to options to do it: saving it as text (characteres 6 and 4) or as a binary data.
If you store it as a text, you need two bytes: one for the code of the character 6 and other for the character 4. You can open that file with the notepad and you'll see that two characteres '64'.
If you store it as a binary value, you only need one byte, but if you open it with the notepad, you'll see the character whose code is 64: 'A'
Most of such "strange" files are resources needed by parts of the application. A complex application is constructed very modular, and each component may need to load different additional resources, often depending on conditions decided at runtime.
For example, on startup if a Qt-based application reads it should use German translation, it may load trans/de_DE.qm from a directory also containing other language files. Or a game may load level by level from different files depending on how far you've come.
Your second question is quite simple. Most resource files are read by an application function as stream of bytes. If e.g. such stream contains '005a' as 4 bytes, you'll see strange symbols in notepade.exe since that editor interprets such bytes as ASCII code, which means it prints the symbols it finds at place 0, 0, 5, and a in the ASCII table. But the application actually reads it in as 4 x 8 bits = 32bit value, which may mean a 32bit integer value of a variable in my simple example. So the variable value is set to 0x5a wich is decimal 90.
How would I change a pixel on a display, in C?
Assume NOTHING: I am using a linux machine from console to do this. I do not want to use GUI toolkits or frameworks to draw the pixel. I do not want to draw the pixel in a window. I want to draw the pixel directly to the screen.
EDIT: I have a screen. I'm on a laptop running linux from console. I'd prefer a solution not using X as I'd rather learn how X works than how to use X.
If theres more information, ask, but don't assume. I'm not trying to build a GUI, and that was the main purpose of blocking assumptions as I don't want people to assume I'm doing things the long way when in reality I'm just tinkering.
EDIT 2: You may use any X11 related libraries provided that you can explain how they work.
If we really assume nothing, can we even assume that X is running? For that matter, can we even assume that there is a video card? Perhaps Linux is running headless and we're accessing it over a serial console.
If we are allowed to assume a few things, let's assume that Linux has booted with framebuffer support. (It's been a couple years since I worked with Linux framebuffers, I may get some of the details wrong.) There will be a device created, probably /dev/fb or /dev/fb0. Open that file and start writing RGB values at an offset, and the screen will change, pretty much regardless of anything: text console, graphical console, full-fledged desktop envrionment, etc. If you want to see if framebuffer support is working, do dd if=/dev/zero of=/dev/fb on the command line, and the display should go all black.
C doesnt have any graphics capabilities - you'd need to use a third party library for this.
You cannot assume a display in C. There is literally no way to do what you ask.
Edit: Okay, you have a display, but again, there's not a whole lot you can get from there. The point is that there are a TON of competing standards for graphics displays, and while some of them (VGA interfaces, for example) are standardized, a lot of the others (display driver interfaces, for example) are NOT. Much of what X (and other display device drivers, such as Windows or the like) do, is have specific interface code for how to talk to the display drivers; they abstract out the complexity of dealing with the display drivers. The windowing systems, though, have HUGE libraries of complicated and specific code for dealing with the display drivers; the fact that these things are relatively transparent is an indication of just how much work they've put into these things over time.
Very primitive and making a lot of assumptions:
fd = open("/dev/fb0", O_RDWR);
lseek(fd, 640*y+x, SEEK_SET);
write(fd, "\377\377\377\377", 4);
In reality, you would use mmap rather than write, and use the appropriate ioctl to query the screen mode rather than assuming 640xHHH 32bpp. There are also endian issues, etc.
So in real reality, you might use some sort of library code that handles this kind of thing for you.
I suppose you could paint to the terminal program that you are using as your console. All you have to do is figure out which one that is and look it up.
Whoops I assumed a terminal. :P
I think what you are looking for is information on how to write to the frame buffer. The easiest way would be to use SDL and render to the frame buffer, or else use GTK+ with DirectFB, although that goes against your edict on not using toolkits or frameworks.
I want to read a ttf and draw a text with that font on a buffer. Even though there are libraries such as freetype, gd to do this task, I want to write my own code. Can you advice me on how to accomplish this task?
Unless you're one of the world's top experts on fonts, typography, and writing systems, the answer is simple: DON'T. TrueType/OpenType has a lot of tables you need to support for correct rendering, and even when using FreeType (which is an extremely low-level library), most people get it wrong.
If you need to do low-level, deterministic-across-platforms font handling, then at the very least, you should be using FreeType and libotf. This will provide you with access to the glyphs and outlines which you can then render however you like. In most cases though using your GUI system's text rendering routines will be a lot easier and less error-prone.
Finally, if you insist on ignoring my advice, a good RTFS on FreeType and Microsoft's online resources explaining the tables in TrueType/OpenType fonts are probably the best place to get started.
I would suggest you
Read all the TTF docs you can find
Find all the open source TTF parsers + renderers you can find, in many different languages, such as Freetype (c/c++), Batik (java), and anything else you can google for. Also George Williams' fontforge will likely be very helpful to you on your journey.
Rip apart all the programs you collected in 1. and see how they work. See if you can make a tiny small example program to do something simple, like dump the list of points for the outline of the letter "I".
Work on your rasterization. Start with something very simple, like rasterizing the letter "l".
The problem with TTF is that there is not a simple file format, and freetype handles a lot of crazy details for you. However if you don't care about portability, and you already have a specific TTF file you want to render, and you only care about a small simple alphabet, like Latin or Cyrillic, you might be OK.
Also you might want to check out a list of TTF documentation I linked to from my little project https://github.com/donbright/font_to_svg/
Not impossible, for anyone else tempted to try. I was curious about doing it because I like the DIY graphics approach where I allocate some memory and write into it, then save as a jpg or png. I pirated a bitmap font from giflib but that's strictly 8x8 pixels.
A few links:
`http://stevehanov.ca/blog/index.php?id=143`
`https://www.google.com/search?q=ttf+parser+c&ie=utf-8&oe=utf-8`
as R.. wrote the same time as i did in my comment, i would not to suggest to build another TTF-parser by your own. If you are eager to learn this very "spannende" field of Computer Science I would recommend "The Art of Computer Programming" Vol 2 from Donald E. Knuth. (it is Metafont, not TTF, but proven to be correct:-)
In general, what needs to be done to convert a 16 bit Windows program to Win32? I'm sure I'm not the only person to inherit a codebase and be stunned to find 16-bit code lurking in the corners.
The code in question is C.
The meanings of wParam and lParam have changed in many places. I strongly encourage you to be paranoid and convert as much as possible to use message crackers. They will save you no end of headaches. If there is only one piece of advice I could give you, this would be it.
As long as you're using message crackers, also enable STRICT. It'll help you catch the Win16 code base using int where it should be using HWND, HANDLE, or something else. Converting these will greatly help with #9 on this list.
hPrevInstance is useless. Make sure it's not used.
Make sure you're using Unicode-friendly calls. That doesn't mean you need to convert everything to TCHARs, but means you better replace OpenFile, _lopen, and _lcreat with CreateFile, to name the obvious
LibMain is now DllMain, and the entire library format and export conventions are different
Win16 had no VMM. GlobalAlloc, LocalAlloc, GlobalFree, and LocalFree should be replaced with more modern equivalents. When done, clean up calls to LocalLock, LocalUnlock and friends; they're now useless. Not that I can imagine your app doing this, but make sure you don't depend on WM_COMPACTING while you're there.
Win16 also had no memory protection. Make sure you're not using SendMessage or PostMessage to send pointers to out-of-process windows. You'll need to switch to a more modern IPC mechanism, such as pipes or memory-mapped files.
Win16 also lacked preemptive multitasking. If you wanted a quick answer from another window, it was totally cool to call SendMessage and wait for the message to be processed. That may be a bad idea now. Consider whether PostMessage isn't a better option.
Pointer and integer sizes change. Remember to check carefully anywhere you're reading or writing data to disk—especially if they're Win16 structures. You'll need to manually redo them to handle the shorter values. Again, the least painful way to deal with this will be to use message crackers where possible. Otherwise, you'll need to manually hunt down and convert int to DWORD and so on where applicable.
Finally, when you've nailed the obvious, consider enabling 64-bit compilation checks. A lot of the issues faced with going from 16 to 32 bits are the same as going from 32 to 64, and Visual C++ is actually pretty smart these days. Not only will you catch some lingering issues; you'll get yourself ready for your eventual Win64 migration, too.
EDIT: As #ChrisN points out, the official guide for porting Win16 apps to Win32 is available archived, and both fleshes out and adds to my points above.
Apart from getting your build environment right, Here are few specifics you will need to address:
structs containing ints will need to change to short or widen from 16 to 32 bits. If you change the size of the structure and this is loaded/saved to disk you will need write data file upgrade code.
Per window data is often stored with the window handle using GWL_USERDATA. If you widen some of the data to 32 bits, your offsets will change.
POINT & SIZE structures are 64 bits in Win32. In Win16 they were 32 bits and could be returned as a DWORD (caller would split return value into two 16 bit values). This no longer works in Win32 (i.e. Win32 does not return 64 bit results) and the functions were changed to accept a pointers to store the return values. You will need to edit all of these. APIs like GetTextExtent are affected by this. This same issue also applies to some Windows messages.
The use of INI files is discouraged in Win32 in favour of the registry. While the INI file functions still work you will need to be careful with Vista issues. 16 bit programs often stored their INI file in the Windows system directory.
This is just a few of the issues I can recall. It has been over a decade since I did any Win32 porting. Once you get into it it is quite quick. Each codebase will have its own "feel" when it comes to porting which you will get used to. You will probably even find a few bugs along the way.
There was a definitive guide in the article Porting 16-Bit Code to 32-Bit Windows on MSDN.
The original win32 sdk had a tool that scanned source code and flagged lines that needed to be changed, but I can't remember the name of the tool.
When I've had to do this in the past, I've used a brute force technique - i.e.:
1 - update makefiles or build environment to use 32 bit compiler and linker. Optionally, just create a new project in your IDE (I use Visual Studio), and add the files manually.
2 - build
3 - fix errors
4 - repeat 2&3 until done
The pain of the process depends on the application you are migrating. I've converted 10,000 line programs in an hour, and 75,000 line programs in less than a week. I've also had some small utilities that I just gave up on and rewrote (mostly) from scratch.
I agree with Alan that trial and error is probably the best way.
Here are some good tips.
Agreed that the compiler will probably catch most of the errors. Also, if you are using "near" and "far" pointers you can remove those designations -- a pointer is just a pointer in Win32.