Idea for EasyBCD

[Coolname007]

Hi everyone.

It just recently occured to me that it would certainly make things easier if EasyBCD could automatically copy the boot.ini, ntldr, and ntdetect.com files for XP into the "system" partition, to prevent having to explain this each time someone wants to dual boot XP with Vista to copy over the 3 files into their "system" partition. And also...why not have an option for Linux that can automatically install GNU Grub to a partition of your choosing? And maybe one to detect the location of the Ubuntu (or other Linux distro...) menu.lst, and move it over to the correct location, if its not where its supposed to be?

Or is this too hard to implement this feature in EasyBCD? I don't know anything about programming at the moment, but couldn't Guru accomplish this objective somehow?

Anyhow...just a thought, and you're welcome to either use it or toss it, as you see fit. Just an idea that I had...

-Coolname007

 

[mqudsi]

While the first is possible, the latter two require read/write operations on non-supported (not NTFS or FAT) filesystems, and therefore cannot be done.

EasyBCD currently prompts users to download a copy of NTLDR and NTDETECT from the NST website and copy them to their system drive if it detects they're missing, but unfortunately all that is in vain if boot.ini is not correctly configured, and until now, there is no reliable way to programatically reliably configure boot.ini from within Windows (and thus via EasyBCD).

I could implement a boot.ini configurator that would work 70% of the time (basically for anyone without mixed IDE/SATA/External setups), but then we'd be stuck explaining why we ship EasyBCD with something that doesn't always work.... and people won't know when the EasyBCD output is right and when it's wrong.

 

[Coolname007]

While the first is possible, the latter two require read/write operations on non-supported (not NTFS or FAT) filesystems, and therefore cannot be done.

That's right. :x I forgot about the filesystems aspect. I guess that wouldn't be possible then, without some special software built-in EasyBCD that could read ext3 partitions...and there's probably not any currently free software that can do that, so I guess that idea is dead.

EasyBCD currently prompts users to download a copy of NTLDR and NTDETECT from the NST website and copy them to their system drive if it detects they're missing, but unfortunately all that is in vain if boot.ini is not correctly configured, and until now, there is no reliable way to programatically reliably configure boot.ini from within Windows (and thus via EasyBCD).

Well...that's cool! I didn't know about that feature of EasyBCD. But of course then again, in my case, the XP boot files did exist, and so that is probably why I didn't learn about that option!

I could implement a boot.ini configurator that would work 70% of the time (basically for anyone without mixed IDE/SATA/External setups), but then we'd be stuck explaining why we ship EasyBCD with something that doesn't always work.... and people won't know when the EasyBCD output is right and when it's wrong.

Why 70% of the time? Couldn't there be a way for EasyBCD to detect the BIOS, and read the plugged in drives that way, and adjust boot.ini accordingly? And then every time a particular drive wasn't plugged in, edit the boot.ini again, to display the correct thing? Or would that be too hard?

-Coolname007

 

[JustinW]

Anytime you tell software to write changes to an important file such as that you are taking the chance of bricking the boot. The BIOS and the current OS may see the disks differently regardless of whats plugged-in. EasyBCD if it did have this feature would constantly need to run in the background or auto-start to make these changes, making it a heavier app with the need for additional services. EasyBCD is supposed to fix boots, not break them.

 

[Coolname007]

Anytime you tell software to write changes to an important file such as that you are taking the chance of bricking the boot. The BIOS and the current OS may see the disks differently regardless of whats plugged-in. EasyBCD if it did have this feature would constantly need to run in the background or auto-start to make these changes, making it a heavier app with the need for additional services. EasyBCD is supposed to fix boots, not break them.

Not necessarily... I figure that Guru could maybe implement a small program (that uses up little memory and over-all performance) in the software that could start up the boot-ini configurator at boot, therefore making it unnecessary for EasyBCD itself to be always running in the background...

And maybe I shouldn't have used the term "plugged-in" for the drives...what I actually meant was all drives (whether external or internal...) that the computer detects when first turning it on. And as for the BIOS and the current OS seeing them differently, I'm sure Guru could easily find a workaround for this...perhaps including something in the software that tells the boot.ini configurator to go only by how the BIOS calls the drives, and not by whatever the current OS calls it...

Anyway, it was just a thought, and I'm not sure if it could actually be implemented or not, as I don't understand programming as of now.

-Coolname007

 

[mqudsi]

Whether it is EasyBCD sitting in the background or a helper program doesn't really make a difference, it's the principle of it that's the problem.

But the argument is moot because

1. The problem with boot.ini isn't with external/removable drives, it's with mixed SATA/IDE environments. If we read the drive config from the BIOS, we don't need to do it more than the first time.
   
2. If we were trying to solve the external drives problem, the method you're recommending wouldn't work since it would require that you boot into Windows first for EasyBCD to detect your drive numbers, then reboot to be able to use your drive. You can't plug in the drive and go... and what if it's the only drive on your PC? How do you get into Windows to fix the boot if your boot isn't working in the first place?

What I need to implement in EasyBCD is a function to read the drive list from the BIOS. But that's not easy, and involves writing some components of my own OS from scratch and is very error-prone and will take a long time to get right. I still am not 100% convinced that there is no way to get the list of drives that the NT kernel itself grabbed from the BIOS in the same order that it received them (vs. the order Windows uses internally) - that would be my first and best option.

 

[Coolname007]

Whether it is EasyBCD sitting in the background or a helper program doesn't really make a difference, it's the principle of it that's the problem.

But the argument is moot because

1. The problem with boot.ini isn't with external/removable drives, it's with mixed SATA/IDE environments. If we read the drive config from the BIOS, we don't need to do it more than the first time.

Well...doesn't that prove my point then? If it read the drive config straight from the BIOS, then the SATA/IDE issue shouldn't make a difference then, as I understand it, as that only affects how the booted OS calls them, and not how the BIOS itself calls them.

If we were trying to solve the external drives problem, the method you're recommending wouldn't work since it would require that you boot into Windows first for EasyBCD to detect your drive numbers, then reboot to be able to use your drive. You can't plug in the drive and go... and what if it's the only drive on your PC? How do you get into Windows to fix the boot if your boot isn't working in the first place?

Well, obviously the above method of transferring the 3 XP boot files would only work if you could boot into a version of Windows...and besides, how would you be able to use EasyBCD in the first place, without access to a Windows OS? As EasyBCD is for mainly fixing dual-boots, that means that you would normally be trying to fix one of the installed OSes, not both. So if someone wasn't able to at least boot into one version of Windows, then they wouldn't be able to use EasyBCD at all.

And as for needing to boot into Windows first before EasyBCD could detect the drives the BIOS detection program found...that shouldn't make a difference since after all, the objective is to automatically configure boot.ini before booting, based on what the BIOS config is. I figure the BIOS detection (and possibly the boot.ini configurator) program could maybe be installed to the first few blocks of data on the first hard drive in the BIOS, therefore making it unnecessary for it to be actually installed to the Windows partition itself...though, obviously there would need to be a way for it to communicate with EasyBCD, when booted in Windows.

What I need to implement in EasyBCD is a function to read the drive list from the BIOS.

Well...that's what I meant! I was talking about EasyBCD (or some internal program built-in EasyBCD) that would be able to detect the drives directly from the BIOS, and read them that way, instead of the way that Vista or XP calls them.

But anyhow, you're the one creating the software, so basically it is your decision after all that counts...

-Coolname007

 

[mqudsi]

Believe me, Cool, I want these features just as much as you do.. But the main problem is: it's not easy. Like I said, it involves writing my own OS and that's not something I have time for right now.

I figure the BIOS detection (and possibly the boot.ini configurator) program could maybe be installed to the first few blocks of data on the first hard drive in the BIOS, therefore making it unnecessary for it to be actually installed to the Windows partition itself...though, obviously there would need to be a way for it to communicate with EasyBCD, when booted in Windows.

That's not possible. Data needs to be stored on a filesystem.... and there is no benefit to having it somewhere other than Windows partition anyway.


Anyway, thanks for all the input everyone. I think fixing the IDE/SATA problem for once and for all is a very worthwhile investment.... i just need to get the time to do such a thing.

 

[Coolname007]

Believe me, Cool, I want these features just as much as you do.. But the main problem is: it's not easy. Like I said, it involves writing my own OS and that's not something I have time for right now.

Alright...I understand. No hurry. I was just wanting to introduce my idea, and see if it would sell...

That's not possible. Data needs to be stored on a filesystem.... and there is no benefit to having it somewhere other than Windows partition anyway.

Alright...so how about storing the data on the Windows partition, and then pointing back to it with some kind of boot-loader-like program? If a bootloader can be installed to the MBR, then I would think a program similar to a bootloader, would be able to, as well...

Anyway, thanks for all the input everyone. I think fixing the IDE/SATA problem for once and for all is a very worthwhile investment.... i just need to get the time to do such a thing.

I agree. That issue should certainly be fixed...but I understand that you may not have time to do it right now, what with all the tasks you are no doubt involved in. I hope though that this issue remains foremost in everyone's minds, and that they don't forget about it, and more than two years go by without hearing any more about it...as did with the program that can change dates and time.

-Coolname007

EDIT: Guru just gave me the link to the program, so I guess it was finished after all, despite no reply being posted since July of 2006...

 

[mqudsi]

Cool, I still don't understand why you want it to store data somewhere and what it has to do with the bootloader during boot time.... I'm rather lost.

I write the software when I get the time - especially seeing as I'm not paid to do anything in the first place and everything I make is freeware. When I'm free I get things done, when I'm not, I don't. If something takes 3 years it means its not high on my list of priorities... though TimeTweaker took only a month or two.

 

[Coolname007]

Cool, I still don't understand why you want it to store data somewhere and what it has to do with the bootloader during boot time.... I'm rather lost.

I was speaking about storing the data for the boot.ini configurator, the XP boot files mover, and the BIOS detector, on the Vista (or XP) partition...and as for the bootloader part, I was only using that as an example. My theory is this: if the bootloader can be installed to the MBR, then why not something similar to a bootloader (in terms of size and configuration) that can start the boot.ini configurator, and the BIOS detector, automatically at time of boot? It could be a small program that can be stored within the MBR, next to the bootloader.

I write the software when I get the time - especially seeing as I'm not paid to do anything in the first place and everything I make is freeware. When I'm free I get things done, when I'm not, I don't. If something takes 3 years it means its not high on my list of priorities... though TimeTweaker took only a month or two.

Alright...I understand all of that. And I already corrected the comment that I made about TimeTweaker, after reading your post in the other thread, where you gave me the link to it...I just thought that it had never been completed, due to no more comments being made in that thread for nearly 3 years.

Anyway, I'm not even sure if all this stuff can actually be implemented or not, in reality. I just thought these features would certainly make EasyBCD even more EasyBCD! :brows:

-Coolname007

 

[JustinW]

Whats the point of storing data if the program's purpose is to detect and modify exisiting boot files? The proposed data the program uses would grow inaccurate with changes like the boot.ini it would aim to fix.

 

[Coolname007]

Whats the point of storing data if the program's purpose is to detect and modify exisiting boot files? The proposed data the program uses would grow inaccurate with changes like the boot.ini it would aim to fix.

I meant the "data" (code name for "program files") of the programs themselves! :lol: That is all that I meant when I used the term "data".

-Coolname007

 

[xterra]

I dont know if this has been explored or not by you guys, but what about using a bootable usb like slax from slax.org, If I bootup with that I can access windows files and save them onto an external drive. (NTFS/Fat32/EXT2,EXT3) Read/write. What about putting the linux version of easybcd on a slax usb from slax.org like a linux live script, have it check for all the files, replace whatever's missing ntldr, ntdetect.com, and have that 70% boot.ini script that checks the boot.ini settings, maybe even include a library of different sata textmode drivers so the user can pick indivually according to the hardware he/she knows they have. Does that make any sense? The library would have to be handmade of course. textmode driver - hardware name/model

 

[JustinW]

There is no linux version of EasyBCD, it is a program to configure the Windows BCD store.