Jump to content

Uda

Active Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by Uda

  1. 'Something' already exists. I've been using u3_tool to flash my 4GB Cruzer drive on Linux.

    You can built it to use different USB access subsytems also; I have been using sg without any issues for over a year (despite it being talked down in the readme). If you want to flash >2GB iso's like bootable DVD iso's for example, compile with -D_FILE_OFFSET_BITS=64 as well. I've only ever flashed my U3 drive on Linux, so I can't say anything on the performance of this tool when built for Windows using spt, or libusb for any OS.

    Another note, I haven't figured out what the exact mark is yet, but for iso's larger than a certain size, I have to partition the optical drive side 1 byte larger than the iso itself or the subsequent loading bombs out at 99%; not a big issue, but worth mentioning.

  2. Better to install GRUB (or any bootloader) and the live OS on the mass storage side from my POV, as there would be wider BIOS support for booting from USB mass storage, than those recognising the CD device emulated in the U3 drive. I've tried 5 different motherboards, and none will recognise the CD device in BIOS, when filled with a bootable ISO (tried BT3 on 3, Xubuntu Hardy on the other 2). However all but one recognised the mass storage and supported booting from it.

    If there was better BIOS support for the USB CD device, it would be handy for ISOs that don't have a USB boot equivalent. Also, if it were the case, the bootable ISO could be made to hold a switchblade starting script etc, so it still serves its purpose on a Windows box.

    Perhaps just the bootloader on the mass storage side could chainboot from the CD side, and the CD side could itself be bootable for those BIOS' that support it. Covering all bases that way; well, you could carry a boot floppy for the PCs that don't support USB booting, then you'd cover all the realistic bases.

  3. Or you could just write NATIVE UNMANAGED code which can be run on any windows machine with no dependencies at all!

    You're completely missing the point... the question was how to "run .NET app's without need to install .NET framework on the host's machine". That implies running precompiled .NET bytecode executables, nothing was said about coding an application, and choice of language.

    You are basically asking why use something like a .NET runtime, when something could be written and compiled as native code. As much as I don't want to argue for .NET (I don't like it a great deal), runtime environments like this and that of Java have some pros over native executables, just as they have some over those requiring a runtime. Perhaps you're not aware that Mono is not Windows exclusive, and so the same executable that can be run under a portable Mono environment on Windows can be run under Mono on Linux without requiring access to the source to make modifications for the different OS. The .NET/Mono platform takes care of it.

    You can go around praising old school coding and unmanaged executables as much as you want, but runtime environments and interpreters exist for a reason, and a portable Mono helps extend the reach of the intended advantages.

    If you wish to continue this track of conversation, I suggest you start an appropriate thread in another section of the forum.

  4. You'll have a hard time making a simple, portable Microsoft .NET runtime, but there are alternatives.

    If it's suitable, you could carry around a VM of some Windows OS with .NET installed, and transfer data in and out. Not ideal, but it's a clean way to run .NET apps for sure. But there is a nice alternative...

    Mono is a free implementation of the .NET runtime for a number of platforms. The Windows version is a cinch to make portable. After installing it (Mono 1.9.1 in this case) to any location of your choosing, make a shortcut in the folder above it pointed at C:\WINDOWS\system32\cmd.exe /k ".\Mono-1.9.1\bin\setmonopath.bat". Although it appears to be an annoyance that a shortcut can't directly use a relative link, it doesn't matter, since we're planning to open a command prompt anyway (with a modified PATH variable). Now we need to modify setmonopath.bat to create our new MWD (Mono Working Directory).:

    @echo off
    echo Mono version 1.9.1 Build 2
    SET MWD=%CD%\Mono-1.9.1
    echo Prepending %MWD%\bin to PATH
    PATH=%MWD%\bin;%PATH%

    Now modify every batch file in the Mono /bin directoy, replacing every path up to and including MONO-1~1.1 with %MWD%.

    If you installed Mono in the default location, cert2spc for example would change as follows:

    Before:

    @"C:\PROGRA~1\MONO-1~1.1\bin\mono.exe" "C:\PROGRA~1\MONO-1~1.1\lib\mono\1.0\cert2spc.exe" %*

    After:

    @"%MWD%\bin\mono.exe" "%MWD%\lib\mono\1.0\cert2spc.exe" %*

    I've taken the liberty of creating a simple graphical demonstration app and running under Microsoft .NET (3.5, not that it mattered any) and Mono (1.9.1). See the results at http://bayimg.com/BAKopaaBH. If you follow this, you'll be able to execute .NET applications using your Mono environment without needing .NET installed. More so, Mono even comes with compilers for C# and VB.NET, and a Boo interpreter or translator by memory.

    Bare in mind that Mono will always be playing catch-up to .NET, but it's quite capable. Certainly worth a look if you prefer free software, and this hackish approach. ;) There is another, free .NET implementation called DotGNU Portable.NET, but to be completely honest, I haven't looked at it at all; I've been following Mono for a long time and I'm more than pleased with it. Just figured I should throw that in for completeness though.

    This is my first post on the forums btw, I only looked at them for the first time a few weeks back, but I've been watching Hak5 eps since the start. Keep up the great work guys. ;)

    -Uda in Australia

×
×
  • Create New...