Try Cobian Backup (Google for Cobian). Latest version is v10 (I believe). It's free and works very well. It has a number of backup options like: Full, Differential, Incremental. Personally I like to set it for "Differential". The first time it runs it does a Full backup and thereafter it's Differential. You can also set it to use the same folder on each backup (By default it uses separate dated folders). It works fine over shared network folders and allows scheduled backups. Or, if you want simple and you are still using XP you can download one I wrote from Sourceforge (Filebackup). It's simple and works great. It does either scheduled or manual backups and it works in a Differential manner. It does not compress files so all you need is a file browser to inspect/check if backups are working as expected. It has no Restore mechanism so you need to know how to traverse a file system. It does have a status log of it's own and it logs failures to XP's Event Logs. It is based on MS .NET 2.0 and is written in C# (source code available if anybody wants to improve it). The reason it doesn't work under Vista or Windows 7 is because of the way I wrote the Autobackup service: Just never got around to rewriting it to work under Vista/Windows 7. However, if someone has the time... Have a great day!!!

Money Manager Ex (from Sourceforge) is OK. And of course the source is available if you want to make it better. There is also GnuCash, but I don't like it as much as Money manager Ex. Either of these will meet the requirements you cited.

dan neely wrote:

it's a resurrection of the segmented memory model and requires significantly more effort to implement than standard x86.

If your "It" is referring to PAE mode, then you would be incorrect. PAE mode does not use segmentation: It uses Paging. "When the PAE paging mechanism is enabled, the processor supports two sizes of pages: 4-KByte and 2-MByte." (P:3-34 Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A:System Programming Guide, Part 1).

Daniel Grunwald wrote:

PAE just allows a larger physical memory. 64-bit addresses are unrelated to that, I don't think any of the 64-bit processors actually supports 64-bit physical addresses.

You are right as all that is needed is 36 bits. PAE mode provides 36-bit physical addressing (which is enough to allow access up to 64 Gigs). In fact, if you read the Intel manuals you will see that the 64-bit processors also use PAE mode to access memory beyond 4 Gigs. "The physical address extension (PAE) flag in register CR4 enables the PAE mechanism and extends physical addresses from 32 bits to 36 bits (or to MAXPHYADDR bits). Here, the processor provides additional address line pins (4 for 36-bit physical addressing) to accommodate the additional address bits." (Vol3 P:3-34 Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A:System Programming Guide, Part 1). 64-bit processors vary in how many actual physical bits they use, but they have to use at least 36 bits. PAE mode automatically results in Paging being used.

Daniel Grunwald wrote:

64-bit is about virtual memory.

64-bit does not, by itself, have anything to do with virtual memory. Virtual memory is available if Paging is implemented. However, since addressing above 4 Gigs involves using PAE mode (which inherently uses Paging), I guess you could think of it the way you have.

Daniel Grunwald wrote:

32-bit vs. 64-bit refers to the size of addresses. It's mainly '64-bit addressing', not '64-bit processing'.

I don't think you are quite correct here as the Pentium Pro (32-bit) has the capability of addressing up to 64 Gig using PAE (Physical Address Extension) mode. That implies that Intel created 64-bit processors for another reason. If it has nothing (or little) to do with performance, then what might that reason be?

Daniel Grunwald wrote:

Yes, 64-bit has more (and larger) registers. Some programs compiled for 64-bit run faster than their 32-bit counterparts. But on the other hand, pointers are twice as large. They take more memory -> less data fits into the processor cache. Some programs run faster in 32-bit mode.

This maybe the reason that Intel has introduced the use of 3 cache levels, increased cache sizes, and incorporated the memory addressing unit inside the CPU (or at least I think this last point was a recent change).

Daniel Grunwald wrote:

And most software is still 32-bit -> Windows will need to have both 32-bit and 64-bit versions of the system libraries loaded at once. If the machine is low on RAM, this will hurt the performance.

This could be the reason why they choose not to install the 64-bit OS on machines with less than 4 Gig.

There is something missing here that I don't understand. Starting with the Pentium Pro (32-bit CPU), Intel processors have been able to access more than 4 Gigs of RAM. This is handled via PAE (Physical Address Extension) mode (see Intel CPU docs for more info). This being the case, why did Intel start developing 64-bit processors if there is no performance advantage? Seems like a rather expensive road to go down if what you say is true.

John C wrote:

On the other hand I know of no hardware vendor that doesn't offer the *option* of os so I'm not sure why it's a problem, you just specify the OS you want in the end anyway.

I know of several vendors that do not offer the option: HP laptops and desktops that are sold from Futureshop, Best Buy, London Drugs, Walmart and probably others. These guys sell it as is, with no possibility of change. This is not an issue for me, but it might be for other users. Maybe I am belaboring this point as the performance gain may not be that significant.

It seems whether both versions are included or not depends on the vendor. I think the vendors should leave it up to us to decide what we want to run. Any more people wish to comment?

dan neely wrote:

Meanwhile for normal consumer apps there's little to no benefit.

Are you saying that the fact that the O/S can process instructions 64-bits at a time rather than 32-bits at a time is no advantage? I would agree with you that many apps are 32-bit; however, 64-bit processing by the OS must improve performance. Would it not?

I wasn't aware that both versions come on the same media. Maybe they do. If so that is good and my rant is dispelled. What about systems that come with no media, but include a Restore partition? Can someone verify whether this is true?

That is kind of a lame response! If you want to criticize someone you should at least provide one reason.

This has been probably occurring for some time now, but I just became aware of the fact that in Canada, new 64-bit systems are being sold with the 32-bit version of Vista. Is this some kind of scam or what? It seems that if you buy a system with less than 4 Gig they install 32-bit Vista on it. So because I buy a system with less than 4 Gig they choose to reduce the processing power I get. Well, that's really nice!!! NOT!!! Why this is totally ridiculous: If I bought 1 Gig of RAM several months down the road then I have to bare the cost of doing an upgrade to 64-bit Vista assuming I want the extra speed (which I would want regardless). As long as the system vendors are ripping people off like this I certainly will never buy a system from them. I usually build my own. The only reason for considering an off the shelf system is simply to get the O/S with the system for less than what it would be if I built the system and bought the O/S separately.

I found the answer on another forum. All I needed to do was to make the GLOBAL definition static due to the fact that the the method it is called from is static. Very simple as I expected it might be. Code as follows: public class FileOrganizer { private **static** Form1 mainForm; [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); mainForm = new Form1(); Application.Run(mainForm); } It's amazing how much of a run-around I was given on this forum.

Since it is Christmas I would think you would be a little more civil than you have been!!! My research maybe lacking and that is why I came to this forum to get me on the right track, but all I have been greeted with is ARROGANCE!!! I think you should take a couple of long breaths and relax a little. It might help your composure. Merry Xmas!!

It should not be an advanced topic!! This is something ANY programmer would want to do with almost ANY program. Besides before posting here I have done extensive reading in all kinds of C# books and resources and cannot find an answer to my problem. Basically, I am trying to understand why Microsoft would create such a complicated approach to doing what should be incredibly simple. What I want to do is simply use a GLOBAL reference to Form1 so that I can setup an object reference to Form1 so that it can be accessed from another method within the Program class (or in my case the FileOrganizer class). I am forced to use the "Application.Run" method; otherwise, the application will quit after it finishes executing my code. The Microsoft template places the "Run" call within Main. Because Main must be static, it will not let me create a GLOBAL reference to "Form1". I can create an object reference to Form1 within Main; however, it is not GLOBAL and I cannot access it from another method in the FileOrganizer class. I am sure that Microsoft, in their infinite wisdom, provided a mechanism to accomplish this in a simple fashion; however, it is not obvious to me. I had previously written another program (which I started in SharpDevelop). In this program, all of the modifications to the main form are done through events. However, in my current program, there are no events that get fired (i.e., mouse clicks). What I am doing is reading some data from a database trying to use that data to populate a TreeView (which resides on the main form). If I could create a GLOBAL variable, this would be incredibly simple to implement. Because I can't this becomes a major complication. Why it has to be this complicated is beyond me; however, I am willing to spend the time to understand it. If you know of some code I can reference in some book or some web reference that can help me to understand this I would be very grateful.

I have updated my original posting in order to try and make it more clear. Hope this helps.

Maybe I wasn't clear enough. This is not about initialization. This is about modifying controls after initialization. Controls should be able to be modified anywhere within the program and at any time while the program is running.

This sentence was copied from my previous post: "What I want to do (within another method of the FileOrganizer class) is to update a control programmatically." For example, I want to add some nodes to a TreeView control. So, this is what I want to do; however, you will not be able to respond with an appropriate answer unless you read through my previous post entirely.

PROBLEM: The problem I am having is, given the layout of the Microsoft template for developing a Windows App, I need to know what is the best way of implementing a method to make modifications to a control on my main form (Form1). NECESSARY BACKGROUND: A basic Windows program comes up with a Form1.cs and a Program.cs (I have renamed Program.cs to FileOrganizer.cs). In FileOrganizer.cs there is a Main method. Within this Main method is "Application.Run(new Form1());". What I want to do (within another method of the FileOrganizer class) is to update a control programmatically. The fact that Form1 is "run" the way it is (i.e., using "Application.Run"), makes it so there is no reference to an object. Because there is no way to reference the Form1 object I don't know of a way to modify one of the controls on Form1. If I create a global reference to Form1 and then create a "new" instance of Form1 (within Main) I receive an error ("Error 4 An object reference is required for the non-static field, method, or property 'FileOrganizer.FileOrganizer.mainForm'"). My implementation is as follows: namespace FileOrganizer { public class FileOrganizer { private Form1 mainForm; /// /// The main entry point for the application. /// [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); mainForm = new Form1(); Application.Run(mainForm); I understand that this error occurs because the Main method is static although I don't understand why. One way of making this work is by doing the following: public class FileOrganizer { private Form1 mainForm; /// /// The main entry point for the application. /// [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); FileOrganizer fg = new FileOrganizer(); } public FileOrganizer() { mainForm = new Form1(); mainForm.Visible = true;But I am not sure if this is the proper way to do what I need to do (i.e., provide a way to modify a control on Form1 in another method of the FileOrganizer class).

You can try one that I wrote: filebackup.sourceforge.net It is written in C# using .NET 2.0 and the source is available and it's FREE. I am sure it would not be considered the best, but it is very easy to use and it does scheduled backups (which have never failed in my tests). It uses the date change on a file as criteria for backup. As with all software I am sure it could use some improvements. A few limitations: 1. It doesn't remove directories from the backup destination area that are no longer present in the backup source area. 2. It doesn't do compression. 3. It doesn't do incremental backups. 4. If you select a subset of directories in a parent directory (i.e., not all child directories are selected) and then subsequently add a directory to the parent directory, FileBackup currently has no way of knowing that the new directory has been added and therefore will not back it up. A point to keep in mind: The fact that a person would select a sub-set of directories implies that they may not want a newly added directory to be backed up anyway. So, whether this should be automated or not comes into question. Just being aware of this point will ensure that you modify your backup profile as required. 5. It will not backup files that are "locked" by an application. As well, it will not backup things like the registry. This could be handled by taking advantage of the Volume Shadow Copy mechanism that Windows XP can make use of. If these limitations are not a worry to you or if you have some coding skills in C# you can make it do whatever you would like it to do.

modified on Monday, February 18, 2008 1:50 PM