A question of procedure

Discussion in 'General Questions' started by Hudsonguy, Sep 18, 2007.

  1. Hudsonguy

    Hudsonguy Junior Member

    Messages:
    11
    What is the safest and best practice for ending a Parallels session? I assume it's best to close any Windows applications, but should I shut down Windows before quitting Parallels? Or is this a waste of time?

    Similarly, is it best to quit Parallels when putting my Mac to sleep?

    I am running build 3214 with WinXP on a Macbook Core 2 Duo with 2 gb RAM. Many thanks for any advice!
     
  2. David5000

    David5000 Pro

    Messages:
    312
    I have the same setup as you except 3 GB RAM, with 512 given to XP Pro.

    Usually I just quit Parallels without closing Windows applications and have had no ill effects. (In Preferences I have "On application quit: Suspend" selected.)

    Sometimes I put the Mac to sleep with Parallels running and haven't notice any ill effects from that, either, although I have seen others report that it causes a kernel panic on awakening from sleep.

    David
     
  3. Eru Ithildur

    Eru Ithildur Forum Maven

    Messages:
    1,954
    I make sure that my VM is suspended or shut down prior to shutting down or putting my computer to sleep, but other than that it really doesn't matter. Just remember that Windows works best if it is restarted every couple days. Technically, I forget why, I just know it does because of the 'cause effect' procedure.
     
  4. David5000

    David5000 Pro

    Messages:
    312
    What is that?

    David
     
  5. Eru Ithildur

    Eru Ithildur Forum Maven

    Messages:
    1,954
    What is what? The cause effect? You just find a result and then trace back to what causes it, basic troubleshooting with a formal logical term slapped on.
     
  6. David5000

    David5000 Pro

    Messages:
    312
    Thanks--now I understand what you meant. (I thought you might be talking about some special Parallels procedure that I hadn't heard of before.)

    David
     
  7. Eru Ithildur

    Eru Ithildur Forum Maven

    Messages:
    1,954
    Hehe, isn't that all of our greatest nightmares? The one thread or post that we missed that has the solution to our problems.
     
  8. mike montagne

    mike montagne Member

    Messages:
    25
    I don't know that this qualifies as identifying cause, because nothing associates the effect with a cause. You simply seem not to experience unexpressed undesirable ramifications if you restart Windows. But you will notice why if you study many Microsoft applications, because you will notice that if you set something here or there, the data in each different interface may not concur, or different sessions of the same application may not respond to the setting as intended unless you restart the application, or, in the case of the operating system (which is an application), unless you restart the operating system.

    Understanding software design, you can readily determine the cause: 1) either different processes are reading the volatile state of the data from RAM or the retentive state of the data from media when one or the other should be the standard location of the present state... or 2) configuration of the data does not trigger reconfiguration of the application to the intended state (as by invoking the usual processes of startup).

    It is more accurate and useful to say for all such instances then that Windows requires restart because processes which wake from a sleep state too fail to run the necessary processes because no event so triggers them; but this must exist from a pre-existent condition of fault already unless there are further faults in the wake from sleep process.

    imho, the real issue is that a long history of unrectified flaws establish a pattern for which it is wiser to make it a regular practice to start Windows fresh each time you open it. Most skilled users in fact reboot as soon as they notice anomalous behavior.

    Microsoft itself has admitted to substantial philosophical flaws. Vista wouldn't be evidence that they either are identifying or addressing the causes as they need to be addressed.

    For instance, if you suffer type mismatches or buffer overruns, is it a better idea to devise and impose rock solid type (and data type/instance) matching, or is it a better idea to isolate those faults in an outer, further operating environment, where really, they can still impose the problems they will, and OS engineers will still be [as] prone to such faults in the principal operating environment?

    We can easily foresee the latter is not only a huge waste; it doesn't solve anything.

    The real issue is that because no MS guru is given charge of perfecting the outer philosophies of design, and/or because no process exists to manifest in the ostensible perfected philosophy, you regularly need to refresh not only the operating system, but the applications running within it. Many applications will seed RAM or paged VM with faults which will therefore bite you if you don't regularly start Windows software freshly.

    But to wake such faulted wares from sleep is to subject them to the further threat of potential faults introduced by the wake process. If your work is important, you don't dare do that. If you are just playing games, what the heck -- maybe you'll inadvertently achieve an otherwise impossible score.
     

Share This Page