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

Reply via email to