[vroemer]

Hey, umm, hi as well.

Well Ive been working with C for a long long long time (almost 4yrs) and all I've ever done is expanded on the same basic Ideas again and again and again (probably through 7-8 books) Yea so Im really getting pissed off at myself for not expanding further.

I want to write real usable applications, not necessarily GUI ones, but something that actually does something low level or over a network.

I've found this one book, Advanced UNIX Programming, would that be relevant to OS X since its kinda UNIX?


IDK, I'm just lost.
BTW, I plan on learning Java during the 2nd half of school and if that would be a better path to go from here I can start sooner.

[Chuckit]

You don't need a book to tell you how to write a "real application." If you know C (which it sounds like you do), figure out what you want to write and just get to it.

[vroemer]

I'm not looking to learn more C but what is necessary to program advanced things (sorry if this doesn't make sense).

I want to learn about Libraries and System calls and all those other "hews y what-chits".

I've skimmed over a few texts over at cocoadevcentral.com which I'm hopping goes into implementing C into cocoa apps.

Hopefully this gives an idea of what I'm looking for.

[Tomchu]

You can't just decide that you want to use some libraries and syscalls and write something going from there -- it works the other way around. You decide you want to write an application that does X, and then you accomplish that by (maybe) using libraries and syscalls.

[vroemer]

hmm, yea thats a good point.

*If thats what chuckit was trying to say I didn't understand you. sry

edit> Hey well that being the case does anyone have some simple ideas that I can try and make?

[Tomchu]

Well, I've always been curious to know how many fragments a particular file on my hard drive is in. You could write a small utility that takes the path of a file and then asks the filesystem subsystem how many fragments said file is in. :-P

[vroemer]

>.> oww, good idea, but it may take me a while >.< anyhow I will try it.


edit: i just thought of something. U don't need to access the file system at all to determine how many blocks because all you would have to do is determine the file size and divide by the block size.

correct me if I'm wrong pls.

[Big Mac]

Yeah, but Tomchu is referring to file fragments. You know, when a file grows past the room it was originally given and has to be split into fragments that are placed elsewhere on the disk.

[numero]

Here's another idea from my school days.

Write a time client. The application will contact a time server (such as time.apple.com) to retrieve the current time. You will have to read about the communication protocol and then figure out how to implement it.

The protocol can be found at: RFC 868 Time Protocol

Once you get the command line version done you could get fancy and do something with a GUI.

Things you will get out of this:
1. Reading and understanding a published protocol.
2. TCP/IP experience.
3. Debugging (here's a hint: leap year)

-numero

[vroemer]

Originally Posted by Big Mac 

Yeah, but Tomchu is referring to file fragments. You know, when a file grows past the room it was originally given and has to be split into fragments that are placed elsewhere on the disk.

Thats preaty much what it would do. Lets say the fragment size (block size) is 1024k and you have a file of 512mb.

512000k/1024k = 500

500 parts (or blocks) are occupied.
essentially thats what the "du -k" command seems to output.
But, thats just in general I'm still gonna do it with the system library to get output from the file system just because of the experience Im trying to build.

BTW, thanks numero for the Idea. I'll give it a try as well.

[Chuckit]

Originally Posted by vroemer 

Thats preaty much what it would do. Lets say the fragment size (block size) is 1024k and you have a file of 512mb.

512000k/1024k = 500

500 parts (or blocks) are occupied.

That's not what fragments are. If those 500 blocks are contiguous on disk, it has only one fragment — the disk can just read straight through. If 200 blocks are stored next to each other in one place, 294 blocks are stored next to each other in another place and 6 blocks are stored in a straight line somewhere else, the file has three fragments — the disk has to jump around from one location to another in order to read the whole file. In HFS terms, these are usually called "extents." I believe the first eight extents of a file are stored in the file's record, while the rest (if there are files with more than eight extents) are stored in one massive extents catalog. It's not exactly a beginner-level topic, if you ask me…

[Tomchu]

The descriptors for the extents are stored in a binary tree catalog, not the extents/data themselves. :-P

[Chuckit]

Oh, I did phrase it that way, didn't I? Whoops.

[vroemer]

Oh, whoops I thought that each fragment was the same as each block.. Well scratch what I was looking up earlier. time to start all over.

BTW, It sounds a bit more difficult now.

[smitty825]

Originally Posted by numero 

Here's another idea from my school days.

Write a time client. The application will contact a time server (such as time.apple.com) to retrieve the current time. You will have to read about the communication protocol and then figure out how to implement it.

The protocol can be found at: RFC 868 Time Protocol

Once you get the command line version done you could get fancy and do something with a GUI.

Things you will get out of this:
1. Reading and understanding a published protocol.
2. TCP/IP experience.
3. Debugging (here's a hint: leap year)

-numero

Does time.apple.com support the old Time Protocol? I know that it is primarily used for NTP, which is significantly more complex than the item above.

[smitty825]

Originally Posted by vroemer 

Oh, whoops I thought that each fragment was the same as each block.. Well scratch what I was looking up earlier. time to start all over.

BTW, It sounds a bit more difficult now.

It's not a bad first project to just go in and compute the number of blocks each file takes up. You'll certainly learn quite a bit, and it should be fairly simple to implement quickly. If you enjoy working with that type of stuff, calculating the number of fragments could be a "second" step.

[numero]

I didn't actually look into time.apple.com. It was just the first one I thought of off the top of my head.

I don't know why I am admitting to not researching my answer when I could take the academic way out on this one. "That is left as an exercise for the reader."

Another idea is to visit your favorite university's CS web site and browse the assignments they post for their students.

Good luck with whatever project you choose. You know you can get help here if you get into something you can't figure out.

[vroemer]

Ok, Well I went ahead and created a block counting program anyways and here it is:

Code:
#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <errno.h>

int main(int argc, char *argv[])
{
        int blocks;
        struct stat s;

        if (argc != 2)
        {
            fprintf (stderr,"usage: %s filename\n",argv[0]);
            return 1;
        }

        blocks = stat (argv[1],&s);

        if (!blocks)
        {
             printf("%s uses %d blocks \n", argv[1], (int)s.st_blocks);
        }
        else
        {
             perror(argv[1]);
             return 1;
        }

        return 0;
}

truthfully I had trouble with passing the values to 'stat' but a fellow over at unix.com helped me.
..Anyways, I get the idea on how to interpret the man info on the stuff now so It shouldn't be too bad.


EDIT: I think that I'll "pocket" the file fragment Idea for a while

[arcticmac]

a couple things they do at my school that sound like they'd be interesting are:

-write a virtual machine. it needs to implement things like a stack and basic memory operations IIRC.

-write a learning algorithm that can take a set of a bunch of white and black points and generate boundary lines that efficiently divide them (this is a more CS-major kind of thing to do than a practical thing, although you could then apply it to... I dunno... making your webcam recognize you or something)

-write buffer overflow exploits for published vulnerabilities and/or try to find buffer overflow vulnerabilities in open-source software (presumably looking at an older version that you know has them, but you don't know where). The idea of this is that if you know how buffer overflow exploits work, you'll be better at avoiding them in your code.

The thing about C is that most people don't actually write complete applications in it because it's not a friendly language to work in. It's generally much simpler to use something object oriented, and, in fact, if you try to write much in c, you'll often find yourself starting to write your own object system, at which point it's time to take a step back and say "wait a minute. why am I not just doing this in java or objective-c"

Personally I highly recommend objective-c if you're looking for something to get into. It is, unfortunately, limited to the mac for now, but if the mac is all you're working on, it's got better framework support behind it than java.

[phoenix78]

I recommend learning some 'event driven' principles of design. this will help you write GUI based applications. Finite State Machines or Finite State Automata is a good way to thik about event driven ideas.

It also helps you design interactive applications which you will most definitely need to do if youre writing serious apps.

Its better to focus attention on what you actually want to write a program for. If you just write toy programs that will be useless to you then youll just end up loosing interest.

[Tomchu]

Originally Posted by arcticmac 

in fact, if you try to write much in c, you'll often find yourself starting to write your own object system, at which point it's time to take a step back and say "wait a minute. why am I not just doing this in java or objective-c"

I see you haven't actually done much in C, nor do you understand its purpose or power.

[vroemer]

Thanks for the input . I definitely understand the whole thing about "useless programs" where it gets boring (pretty much why its taken me so long to get moving along.)

I am going to learn a bit about obj-C due to its use in Cocoa.
edit: I also plan on learning Java because its seems to me that it is more profitable (plus there are a bunch of ebooks on it .)

Things are going a little slow programming wise (left Friday and got back today.)