As it looks there is not much feedback. I guess we should start voting wether to include qemu into the trunk (which is a 2.90mb overhead) or not.
I vote for including it into the trunk. Chriss. William Lahti wrote: > PPS: we would still strive for ISO support in the updater, so that we > can return to supporting all of the VMs we have supported up to now. > This isn't an abandbonment of your favorite VMs, but in the end it > will offer another way to (more than ever) easily compile and run > sharpos. > > On Jan 24, 2008 11:25 PM, William Lahti <[EMAIL PROTECTED]> wrote: > >> NOTE: right now the trunk can only be used with an emulator like QEmu >> or Bochs. I explain why here. >> >> So the AOT is now capable of encoding the CIL metadata into the >> kernel, but it increases the size of the kernel to larger than can fit >> on our floppy disk image, so we have to move away from using floppy >> images to test. The logical two choices are CD images and hard drive >> images. Since HDD images require far less code to be written on our >> part, we updated the disk image updater to support writing to hard >> disk images and now that is the default in the trunk. >> >> However, there is a side effect. VMware and Virtual PC both have >> separate proprietary formats for their hard drive images, which makes >> them unusable for SharpOS development with the new images. QEmu works >> great but on Windows due to a QEmu bug, you have to specify the BIOS >> files on the command line using -L. We want to avoid this so that >> Windows users will have a good and painless experience while working >> on SharpOS, so we are leaning toward bundling the Windows edition of >> QEMU into our trunk under References/ and making the nant scripts >> capable of launching it automatically. This will make things a LOT >> more easier for both operating systems, and since Linux doesn't need >> -L (because the BIOS files are always at the default location in the >> filesystem), we dont need to include the Linux binaries. >> >> We're ready to go ahead and start this but there are a lot more >> developers who are working on SharpOS then just the people who were in >> the channel when we discussed it, so do you have any comments or >> issues with us going with this plan? >> >> PS: this will also help us standardize the process for dumping serial >> output, meaning future changes to our text system which dump it all to >> serial will be much more useful for devs without any special digging >> for the option in your emulator. >> >> -- >> fury >> >> long name: William Lahti >> handle :: fury >> freenode :: xfury >> blog :: http://xfurious.blogspot.com/ >> >> > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
