UEFI Booting

  • SpinRite v6.1 is Released!
    Guest:
    That's right. SpinRite v6.1 is finished and released. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Announcing “BootAble” – GRC's New Boot-Testing Freeware
    Please see the BootAble page at GRC for the whole story.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


FYI, there is a box set of Infocom games, with 33 of them :) Here's a link to a review.

 
  • Wow
Reactions: Barry Wallis
My favorite DOS game was Descent, with a full 6 axis of motion freedom. You can still get many of the old games on GOG.com :)
 
I know this thread got a little off track with DOS games, but a few people are now asking about UEFI. Seems to have had a renascence! Steve said he would not be looking at this until SR7, so that could be years of yet, given that SQRL took 7.
 
I know this thread got a little off track with DOS games, but a few people are now asking about UEFI. Seems to have had a renascence! Steve said he would not be looking at this until SR7, so that could be years of yet, given that SQRL took 7.
But SQRL was started from scratch. He had to write the architecture and document the protocol before even thinking about the code. SR is a mature product that is evolving with the times. I'm not trying to minimize the work needed to divorce SR from DOS, I'm making the point that it is much les in terms of overall work.
 
I'm not trying to minimize the work needed to divorce SR from DOS, I'm making the point that it is much les in terms of overall work.
Are you a betting man Barry? I would be prepared to offer a spread bet of 3 years for a working version of 7. If I were to offer $100/month either way, how would people take my bet?
I am presuming people know what a spread bet is.
 
I'd not take that bet. @Steve has no experience developing UEFI code that I am aware. It will probably not go quickly... And it's questionable how much existing code can be reused. (Any screen/user I/O may need to be completely redone, for example.)
 
I'd not take that bet. @Steve has no experience developing UEFI code that I am aware. It will probably not go quickly... And it's questionable how much existing code can be reused. (Any screen/user I/O may need to be completely redone, for example.)
So would you bet long or short?
 
I generally only bet when I have a reasonable chance of winning (reasonable >= 90%) [that's why I've never played the lottery]. In this case I have no way of determining with any degree of certainty how long it will take Steve to complete SR V7. Why? Because he himself doesn't put out a schedule so I have nothing to base my bet on. He could get it done in less than three years or it could be more. Also, is that three years after 6.1 or three years from now (not that it would make a difference to me).

In my early programming days I learned structured programming and was trying to introduce it to my company's programming department. I was given a programming task which I broke down into discreet modules. I knew from experience that each module would take an average of one day to code, test, fix and integrate. When I completed my design I told the staff (and my manager) how long it would take me to complete the program. They were amazed when I came in exactly on time. The benefit of this approach was when I was given an unrealistic schedule, I could tell them what a realistic schedule would be and negotiate from there.

The difference between @Steve's work and mine (back then) is that he doesn't have to deliver on a set schedule. However, like him, I too strive for zero defects in my finished project (I stopped calling them bugs a long time ago).
 
I generally only bet when I have a reasonable chance of winning (reasonable >= 90%) [that's why I've never played the lottery]. In this case I have no way of determining with any degree of certainty how long it will take Steve to complete SR V7. Why? Because he himself doesn't put out a schedule so I have nothing to base my bet on. He could get it done in less than three years or it could be more. Also, is that three years after 6.1 or three years from now (not that it would make a difference to me).

In my early programming days I learned structured programming and was trying to introduce it to my company's programming department. I was given a programming task which I broke down into discreet modules. I knew from experience that each module would take an average of one day to code, test, fix and integrate. When I completed my design I told the staff (and my manager) how long it would take me to complete the program. They were amazed when I came in exactly on time. The benefit of this approach was when I was given an unrealistic schedule, I could tell them what a realistic schedule would be and negotiate from there.

The difference between @Steve's work and mine (back then) is that he doesn't have to deliver on a set schedule. However, like him, I too strive for zero defects in my finished project (I stopped calling them bugs a long time ago).
So, +or- 3yr from now. What is your opinion?
 
To put another way guys, forgetting about the betting.
Do you think SR 7 will take less or more than 3 years?
Less.

Seems like SR 6.1 ought to be a reality sometime in 2021. @Steve has said that SR 7.0 development will follow immediately after the SR 6.1 release. So, SR 7.0 could well be a work in progress a year from now. Conceivably it could be a reality a year from now, if things go well. There are, however, far too many unknowns and potential Gotchas to make any meaningful predictions or speculation. It will be when it will be.
 
Last edited:
Less.

Seems like SR 6.1 ought to be a reality sometime in 2021. @Steve has said that SR 7.1 development will follow immediately after the SR 6.1 release. So, SR 7.0 could well be a work in progress a year from now. Conceivably it could be a reality a year from now, if things go well. There are, however, far too many unknowns and potential Gotchas to make any meaningful predictions or speculation. It will be when it will be.
Thank you for your honest opinion.
I think the UEFI coding will take longer, due to Steve's meticulous attention to detail.