0) The good news: You are trying to separate presentation logic from application logic. That's a very good thing to do. The bad news is, that trying to concentrate all those things in one class is terrible object oriented design. Making this class static will turn the terrible object oriented design in something even worse: Terrible and old fashioned structural design.
1) Making a class static has certain consequences. Look here:
If you make MyClass static, you turn it into a simple collection of globally accessible functions. It will work, you will not have to worry about creating or destroying instances of MyClass and all your forms can access the methods. So far, so good.
- It's a bad design. A class should never serve more than one purpose, no more, no less. Packing all logic into one class creates many possibilities for mix-ups.
- The entire application logic is accessible from everywhere. That's bad. There is no way to guarantee that some Form does not get access to things it is not supposed to. This can introduce all kinds of bugs.
- With all logic in one static class, you give away all further options for abstraction, encapsulation and (as said above) access restrictions.
So, a static 'MyClass' will work, but cannot and should not have any member variables. You would have to treat it as totally stateless. Trying to maintain some static state for the entire application in one static class will be very messy and error prone. Perhaps you may look at some better ways to separate application logic, presentation logic and data access. In that case you might be interested in the MVC (Model View Controller) or MVP (Model View Presenter) patrterns. Just search for them in the articles and you will find enough about both.
3) Forms cannot be static. They are not designed to work that way. For example, you may want to open the same form twice at the same time. A static form could not be used twice, therefore you must be able to create two separate instances, which you can only do with a non-static class.