Hi,
I was trying to create my own structures and typedefs for the bitmap file and info headers. I have written a 'console' program to display all of the specs for a selected bitmap (.bmp) file. However, the size of the file header for my program ends up at 16 bytes. When I comment out my header file and place #include <windows.h> everything is okay. I am trying to do this without reference to windows.h for my learning experience.
So...why is this file header structure missing two bytes? By the way, I am getting this 16 bytes by doing this command....
sizeof header;
Code:
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
typedef struct _BITMAPFILEHEADER
{
WORD bfType; //2 bytes
DWORD bfSize; //4 bytes
WORD bfReserved1; //2 bytes
WORD bfReserved2; //2 bytes
DWORD bfOffBits; //4 bytes
} BITMAPFILEHEADER;
I get 14 bytes. Any explanation or thoughts would be appreciated.
Hi,
I may have mistated this description.
I am attaching the project and files. Please take a look if you get time and tell me if you see the problem with my code. The problem is I cannot get the 32x32 out of this with my "bitmap_def.h" file,but windows.h works okay.
After this, each piece of the color info is loaded into an array.
So I have built these structures and even defined the various 'typedefs' and get results different from what 'windows.h' provides. Sooo...I think there is something else that must be done. I will spend much of today trying to work this out.
I haven't ever meddled with those windows structures, but am capable of to read bmp-files the hard way
But, as far as I know, the bmp-header is 54 bytes large, and if there's a color palette, it will be another 1024 bytes.
It's quite easy to find out, when you draw a bitmap (actually a whole lot) yourself, and look at it in a hex viewer.
Anyways, i do have a text file with some info (don't know where I got it from). I'll attach it, maybe it will help.
Hi Riis,
I have seen the zipped file before. Of course, it didn't make much sense then. I am now able to read a bitmap file and use it as a texture for a polygon. Whew!
Of course, I got myself confused. I tried reading a BMP so I can display it to the screen...somewhere in between I started working with texture stuff in OpenGL...then I realized I was trying to solve two different problems. Started from scratch and now can load texture. Of course I am using windows.h for now. However, I will build some structures based upon the BMP spec....then again I thought I had done that so I must dig some more.
Nice, Chuck =). I have the easiest texture format in the world =). Raw pixel data. Just find the file length, divide by 4, and take the square root to get the height and width (since hardware textures can only be square powers of two...), then just read the data =).
Z,
Divide by 4? I guess that means 4 bytes per pixel...RGBA. Yes?
I can buid a bitmap editor for stuff like 32x32, 64x64, etc. and save as raw bytes. However, I have built my own paintbrush program in the past...I could modify it so it reads the pixels from the drawing area and load that into a file...with alpha defaulting to 1.
Originally posted by Zaei Nice, Chuck =). I have the easiest texture format in the world =). Raw pixel data. Just find the file length, divide by 4, and take the square root to get the height and width (since hardware textures can only be square powers of two...), then just read the data =).
Z.
How to get the correct file size? Does windows tell u the exact number of bytes?
If this method works, I think I'm going to write my own simple bitmap editor.
Hi,
This struct stat has really got my attention. I looked up the stat.h file to see what other elements were available for stat. I wrote a short routine. Here is the output excerpt.
Any idea on how to convert the date/time into meaningful info? I thought I could do a binary AND with mode to find out file stats but it didn't like ... a.st_mode & 0x0001
Any help would be appreciated. My books and ebooks are not helping.
HI,
I'll look into that. I think that is a Windows function, isn't it? I am trying to stay 100% ANSI C++. So, it requires that I figure out how Windows does it and then write a C++ function.
Hi,
Parksie, DevC++ doesn't recognize FileTimeToSystemTime(). I don't think that this is a ANSI C++ function...meaning a linux or mac compiler would not recognize it....I think that is what ANSI C++ means...though I have been wrong several times before.
Hi Parksie, Win32, MFC, STL, ANSI...it is a bit mind numbing getting this stuff straight in my head. I am curious....
Is this correct? The Win32 API is a huge library of functions written by Microsoft to support its operating system and/or VC++ development software.....or is it an industry standard library supported by all other operating systems? Sorry to be so dense, but just when I think I get some particular thing figured out...bam! My world crumbles. ;-) If you say Win32 is supported by Linux and other OS's then I say I can use the API...just like I do GLUT and OpenGL...and still maintain software that is easily ported to another OS.
Incidently, I can get the date info with 'cout' formatted correctly with...
Win32 is essentially the Windows Runtime. It is ONLY suported on Windows. Linux has its own runtimes, etc. That is why, if portability is a big deal, you wont find and system specific calls scattered through a program, they will simply be wrapped, so they can be modified in as little time as possible.
Soory I caused this mess. Those times are time_t values.
time_t is ANSI standard. But, what time_t is, may be different.
I told you it was a 64 bit number, which in Windows it is.
For TURBO C under DOS it's a long (32 bit), for HPUX 11.0 it's either depending on whether 32 or 64 bit is implemented.
BUT. localtime() and other ANSI calls take a time_t variable and create a struct tm as a result
- ie, months, years, days, seconds.
asctime(localtime(time_t )) takes time_t and turns it into what you see with the unix date command (date & time).
There are two base time data structures:
time_t - some kind of big number
struct tm -
Code:
struct tm {
int tm_sec; /* second (0-61, allows for leap seconds) */
int tm_min; /* minute (0-59) */
int tm_hour; /* hour (0-23) */
int tm_mday; /* day of the month (1-31) */
int tm_mon; /* month (0-11) */
int tm_year; /* years since 1900 */
int tm_wday; /* day of the week (0-6) */
int tm_yday; /* day of the year (0-365) */
int tm_isdst; /* non-0 if daylight savings time is in effect */
};
Whether the values are int, long, or short depends on the system & compiler you develop under. Each one work correctly with the same code. If you don't make assumptions about struct tm datatypes.
Originally posted by ChuckB Hi Parksie, Win32, MFC, STL, ANSI...it is a bit mind numbing getting this stuff straight in my head. I am curious....
Win32: The API for Microsoft Windows 9x/NT. It's basically the base layer for those OSs, and can be more efficient if you're not planning on porting it.
MFC: Microsoft's almost-OO wrapper around the Win32 API, again only Windows, and betrays a lot of its heritage. I don't like it because it's bloated and platform-dependent. However, I will admit that for Windows development, there's no faster way.
STL: Standard Template Library. Now merged into the Standard C++ Library; it's one of the most powerful tools a C++ programmer has, and there's not much that they don't do. The Standard Library is pretty much an extension of the Standard C Library (which is included within the C++ Library).
ANSI: American National Standards Institute. Their working groups decide on the general, and accepted, standards for all sorts of things, character sets, OS APIs, languages, you name it. ISO (International Standards Organisation) is the international equivalent.
In a semi-equivalent capacity to Win32, there's the POSIX (portable operating system) APIs, which basically means any Unix system (Irix, Solaris, BSD, Linux, etc.). Very useful to know, and large proportions of it are included in the Standard C Library (POSIX is entirely C -- see the history of Unix for more details on why).
Wow, long post. Hopefully it's been helpful Jim, anything I've missed?
I refuse to tie my hands behind my back and hear somebody say "Bend Over, Boy, Because You Have It Coming To You". -- Linus Torvalds
In extension to parksie's post:
CRT (if you come across it): The C runtime library, it is the collection of all these functions that we know so well, the functions in stdlib.h, stdio.h, ctype.h, math.h, all those things. The CRT is standardized by ANSI.
ANSI C: Your code is ANSI C-compliant if it only uses features of the core C language as standardized by the ANSI C standard. This means no compiler-specific language extensions, only functions of the ANSI CRT etc.
ANSI C++: like ANSI C, but with C++.
Note: to be ANSI C++, you need to use the .h-less headers like <vector>
See the GNU C library docs (http://www.gnu.org) for information on how to decipher the file attributes and modes. But watch out that you don't confuse POSIX and ANSI, they are not seperated well in the manual.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
Hi,
Thank you everyone. You confirmed what I needed to know to keep things straight. Here is my big picture reason to learn ANSI C++ as well as possible, including this STL stuff.
Let's say I apply for a position as a C++ programmer and I know Win32 stuff really well. I show up, find out that Windows is out and that Linux is in...then the question becomes "Do I know enough ANSI C++ well enough to program without dependency upon Win32?
I think from what I read that C++ is far more powerful and flexible then most introductory college courses or books on the market reveal. After reading "The C++ Standard Library", I realize I could spend several years learning to utilize all of its functionality and features.
I think it is possible to be good at C++ and Win32 like most of you guys. But for a newbie, I want to focus on ANSI C++. Frankly, the Win32 API makes a lot of stuff very easy to do...which is why it exists...but it does take away from C++ knowledge.
So, that is why I was looking for a pure ANSI C++ alternative to FileTimeToSystemTime().
I hope this makes sense. Feel free to tell me how ridiculous it is. I am always willing to entertain a different perspective.
As always, I really appreciate your input.
Regards,
ChuckB