I've got a question for dos & win7 boot process.
Is it possible that dos boot and execute some dos-app before win7 boot without reboot?
I mean boot process like win95 or win3.1.
I'll explain more detail.
dos boot ->
execute some dos app ->
cleanup memory ->
load win7 volume boot record into memory 7c00 ->
win7 boot without reboot
Is this possible?
The scenario you have described is basically a warm reboot, interrupt 0x19 behaves almost like that, with the exception that it always loads the Master Boot Record (with the partition table). Win3.1 or Win95 were started as normal executables from DOS and not from their boot record. Win7 does not have any DOS phase during boot.
However, I think it's possible, but won't be easy. These are a few options:
The easiest solution would be if you can find an appropriate boot manager software that can do this for you. Take a look at GRUB and GRUB4DOS and this question.
If it is enough (the DOS program you want to run does not strictly require 16-bit DOS environment), I'm not sure, but maybe you can tweak Win7's boot.ini to boot in safe mode with command line and start it from there and then reboot.
In the worst case you must manually write a small DOS program that reads the Win7 boot sector to the address 0000:7C00 and executes it. For this to work you must now exactly where the Win7 boot sector is located in the disk. Be aware that on hardware that supports it, Win7 will prefer EFI boot method instead of the old MBR-based one. You must check what method your Win7 installation uses. There may be other difficulties like how to select active partition or that the DOS partition must reside in the beginning of the disk, and so on.
Related
I have an embedded Linux application running on an i.MX51 board. The way I update the kernel is to run an update Kernel.. command during the boot process. There is plenty of output during the boot process that shows up in my serial port terminal.
During the boot process there is an error with my sound but if I search for the string in the kernel I can't find it. This makes me believe that the debugging output I am seeing during the boot process is not coming from the kernel.
So I am not sure if it is possible but what I would like to do is add a print statement in my kernel code that will show up on the serial port terminal to help me with debugging this driver. How might I go about doing that?
My task is to load a program i built separately from the OS (it performs a set of actions on the system files so it must be done before the OS boots) on an embedded system. yea i know...
I chose to place it in a clean winpe.wim (got it from Windows AIK). everything works fine on modern bios computers, but when i try it on the embedded system i get stuck at the ACPI boot check: the bios on this system is non-acpi (standard hal)
restrictions : replacing BIOS / getting other winpe aren't options for now.
can i somehow disable the acpi-compatibility check in the winpe i got? through bcdedit maybe? any advice that will help me with this riddle is very appreciated.
also- the boot is performed form a bootable CD
Figured a workaround, if anyone ever needs this:
shrinked the partition on the embedded system and created a second one
installed another win2000 there and placed my program to run at start up
disabled explorer.exe and all unnecessary components
now this partition serves as PE replacement and can perform actions on the main os files if the user boots into it and runs my program
Is there any BIOS call that can be used in order to obtain the BIOS' boot sequence? The origin of this question was me trying to install Windows 7 on a very old Pentium III machine, where the installer kept insisting that "The computer's hardware may not support booting to this disk", in spite of the 1st HDD being set as the first boot device.
The only mention of programatically getting the boot sequence that I could find was in the DOS API reference, where int 21/AX=3305h in DOS 4.0+ is defined as "Get Boot Drive", with the dl register set on return to the drive the OS was booted from, 1 meaning A: and so on. However, it is obviously very doubtful that this call is used by the Windows 7 installer.
There is no (standard) BIOS call for obtaining the boot sequence, and as you say, DOS calls aren't relevant to Windows. However, it doesn't really matter in the case you're considering, because by convention only one hard drive (drive 0) is bootable.
Some BIOSes do allow you to select a particular hard drive as the boot drive. They do this by rearranging the drive order at boot time so that the selected drive is drive 0.
The warning message you describe was probably due to the size of the hard disk drive. Some older BIOSes can't boot to larger drives, and since the Windows installer had no way to tell whether your machine was one of the exceptions, it gave you the warning. (There are various other similar possibilities, such as the hard drive type.)
Assuming it did in fact boot, you don't really need to worry about it. :-)
I'm trying to develop a dual purpose driver that performs certain tasks at boot time, and other unrelated tasks after Windows has already started. It's developed as a boot start driver. I understand that the proper way to do this may be to develop 2 separate drivers, but I'd prefer to only go through the WinQual process once. There's also the added benefit of performing only one driver install in my app versus two. It needs to work on Vista through Win8 x86 & 64.
So what I'm really looking for is a safe way to determine in DriverInit if the system is in the process of booting, or if it's already up and running. The driver will initially be utilized when Windows has already started, then enabled at boot time after the next reboot. The DriverInit code needs to be different for both scenarios.
Is there a registry key that is or is not present?
Can I determine if a user is logged-in in DriverInit?
Is there a call I can make that will determine if Windows is booting?
I'm not an expert at driver writing, so thanks in advance for any advice.
Technically, glagolig's answer is probably the correct way to solve this.
The solution for my particular issue was a little different. There are 2 mutually exclusive use cases were the driver is either needed as a SERVICE_DEMAND_START driver after Windows is up and running, or as a SERVICE_BOOT_START driver with boot time functionality. The situation never arises were I need the functionality of both cases at the same time in the same Windows session.
The driver is initially installed as a SERVICE_DEMAND_START driver (this is the one that is going to WinQual). It is then changed to SERVICE_BOOT_START in the registry on the new drive that will be booted. All the driver entry points (DriverEntry, AddDevice, etc) that are different for each use case read the 'Start' value in the driver's service registry key to determine how it needs to operate.
It hasn't passed yet, but I'm fairly certain that I can change the start type of the driver in the registry without affecting Window's digital signature enforcement.
At the time boot-start drivers are loaded Windows has not created any user-mode processes yet. Try to acquire a handle to some process that is supposed to be created later on during Windows startup. For example, smss.exe, csrss.exe or wininit.exe . (Processes with these names existed for many years, it is very unlikely that Microdoft abandons them in the future while still allowing existing kernel mode modules to run.) Use ZwOpenProcess with POBJECT_ATTRIBUTES pointing to one of those process' names. If the call fails you are at boot time.
Also you may study Windows startup described in "Windows Internals" by Russinovich and Solomon. Most likely you will get a number of other ideas.
I've answered a similar question elsewhere on SO. The short version is that what you're asking is not normal driver behavior, so no API exists to support this. You can add in heuristics to tell you this, but they'll remain heuristics.
You can use IoGetBootDiskInformation to check if you are loaded post or, during boot. It will return STATUS_TOO_LATE if this API is called post reboot.
my question may seem too weird but i thought about the windows hibernation thing and i was wondering if there is a way to hibernate a specific process or application.
i.e : when windows start up from a normal shutdown/restart it will load all startup programs normally but in addition of that it will load a specific program with it`s previous status before shutting down the computer.
I have though about reserving the memory location and retrieve it back when computer start up , but is there any application that does that in windows environment ?
That cannot work. The state of a process is almost never contained in just the process itself. A gui app creates user32 and gdi objects that are stored in a heap associated with the desktop. It makes calls to Windows that affect the window manager state. It makes I/O calls that cause code inside drivers to run. Which in turn affects allocations inside the kernel pools. Multiply the trouble by every pipe or rpc channel it opens to talk to other processes. And shared resources like the clipboard.
Only making a snapshot of the entire operating system state works.
There are multiple solutions for this now, in Linux OS: CRIU, CryoPID2, BLCR.
I think docker can be used (both for windows & linux), but it requires pre-packaging your app in a docker, which bears some overhead(s).