i second your vote On Jan 25, 2008 7:00 PM, Darx Kies <[EMAIL PROTECTED]> wrote: > 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 >
------------------------------------------------------------------------- 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
