You said that qtparted gives you a floating point error, and implied that the reason could be that its not taking notice of previously-installed dependencies.

Assuming that is the reason qtparted fails to run (which I don't know if it is, but we have to start troubleshooting somewhere), I was commenting that all of the distributions listed in the Distribution section of your profile, and under which you might be installing qtparted (since you have not specified which distribution you're actually using for this operation), and excepting SmoothWall and Enguarde, one of which I know to be a firewall/router distribution, and the other which I assume to be similar, so presumably you're not installing software under one of those--- offer package management with dependency resolution.

Because of this, normally qtparted (or any program installed by such a package manager) should pull in dependencies when installing the program-- if you installed the program with the package manager, and didn't previously install one or more of the dependencies via some other means.

So what I was saying was that the system you are installing on is relevant (but unknown), and your manner of installing qtparted may have been at fault (also unknown), which is one of the possible reasons it doesn't work.

Ops. Very sorry. I'm using Fedora Core 2. However, everything is okay. One thing I have noticed is the package manager program in Fedora Core 2 seems to be very buggy. This of course may be due to the ISO I burned, but none the less, not all programs install correctly. This in turn may have some relevance toward my problems with qtparted. I want to give Fedora Core 4 a few more months before I try it out, because as good as Fedora Core 3 is, it has some flaws of its own which I don't like.

I was able to get a VFAT and Linux Swap Partitions made, formatted and mounted to Linux. After taking notice of the problems happening with the GUI interfaces, I had to consider a change of scope and do some heavy research on FDISK through command line. After running some tests on my lap top, I was confident enough to use FDISK on my system. I created all partitions with FDISK, change there type with it as well. I used mkfs /dev/hda2 and mkfs /dev/hda3 to format the VFAT partitions. I used mkswap /dev/hda4 to format the SWAP partition. I then mounted the VFAT partitions like any other partition and mounted the SWAP partition by using swapon /dev/hda4. I then used VI to edit my FSTAB and boom, everything is done.

Now I have a new problem. I decided to use VFAT so I can use Transgaming's Cedega (WineX remake), to install programs on the VFAT partitions. This way, when I go back to Windows, I can simply edit the registry to enter the value of the program and use the same program for both operating systems without violating the EULA. This also helps me with keeping track of maps, saved files and profiles within the game. If I do something in Linux and tomorrow, use the same program in Windows, I don't have to see a difference. My problem here is this works fine as ROOT. But VFAT does not carry over the rights and policies that Linux uses, so only root can WRITE to VFAT which causes Cedega to fail in any other user.

I researched some possible solutions and found that SAMBA seems very promising to resolving this problem, but I can only get SAMBA to work on remote computers. I never got it to work on the same computer and I'm very week on the command line experience of using SAMBA.

Anyways, this changes the topic completely, so I'm going to post the samba request on a separate topic and wanted to let everyone know that the problem was fixed and I am very grateful for the help I received in trying to resolve the problem. Thank you.