Am Sun, 19 Mar 2017 11:35:44 +0100 schrieb tu...@posteo.de: > On 03/19 11:20, Kai Krakow wrote: > > Am Sun, 19 Mar 2017 09:57:22 +0100 > > schrieb tu...@posteo.de: > > > > > On 03/19 09:37, Kai Krakow wrote: > [...] > [...] > [...] > [...] > [...] > > > > > > Hi Kai (that's a rhyme! :) > > > > Yeah, I know that one... If you are from Germany, you'll also get > > why my former nick (some years ago) was "Shark" :-) > > > > > I have installed Virtualbox already and use the Linux Image I > > > installed there for banking purposes only. Feels more secure. > > > > So something like application virtualization... You could maybe run > > in an isolated container, only exposing the xserver or run inside a > > nested xserver. It would probably greatly reduce startup times and > > not waste a complete image. > > > > > I would prefer the WIndows-in-a-(virtual)box-solution) as you > > > do -- if I would own a Windows installation disc. But do not. > > > > Well, you can easily get an image from MS using a Linux browser. > > Just go to the Windows 10 download page. It will show a selection > > form to choose the ISO instead of the nasty downloader they present > > to Windows browsers. Then install this inside the VM. Even if not > > activated, it runs for 1-2 hours before shutting down which should > > be enough for most purposes you'll need it for. > > > > If you already activated a Windows installation with your MS > > account, with some luck your Win10 VM may even become digitally > > activated (this happened to me). No cracks involved. Should be > > legal enough. ;-) > > > But it is good to know, that the wine-workaround would either > > > work or fail too early to damage anything. > > > > I tried some, and all failed because they didn't even find the > > device. The ones that worked where either network based (flashing > > via IP protocol) or using other simple interfaces (COM or LPT). > > > > > Is there anything important to know before doing an emerge > > > of wine (need I more than app-emulation/wine?) -- I have > > > literally no experience with this emulator - the flashing > > > tool is a 32bit gui application...) ??? > > > > Wine = wine is no emulater ;-) > > > > Actually, it's the Windows API implemented as .so files plus an EXE > > loader to enable the kernel to run PE binaries (instead of ELF). So > > nothing is emulated, it's running native. There's also a thin layer > > of drivers implemented to transform API calls to native kernel > > interfaces, like HID (for input devices). So everything connecting > > to simple HID-USB should also work (some custom USB hardware just > > implement a HID interface, it's simple and cheap). > > > > If your applications work depends on if the required parts of the > > API had been implemented (including the bugs that exists between > > different versions of Windows). > > > > So, with this knowledge, you simply emerge wine with the useflags > > that look useful to you. If you don't need graphics (DirectX) or > > don't want to apply your linux GUI theme to Windows apps, you can > > ignore the staging useflag. Wine can be compiled with both 64bit > > and 32bit support. > > > > After installation, get familiar with the winecfg utility. It allows > > mapping unix path to Windows drive letters. And it allows to set > > Windows version per EXE you run (to expose different API bugs and > > behavior to your application). Also, you can set DDL overrides > > (which is what Windows itself uses when you run applications in > > compatibility mode, or when you put DLL overrides manually in the > > registry). Tho, here you can decide between native (native DLL on > > filesystem) or builtin (*.dll.so file from Wine), and the order in > > which they are tried. > > > > You may also run with different WINEDEBUG settings if you want to > > work out problems. There are fixme lines which usually show stub > > implementations of API calls (functions that do nothing, and are > > there just to return success or fail). You can use it like this: > > > > # WINEDEBUG=-all wine your-exe-file.exe > > > > If you'd like to easily manage different Wine prefixes, I'd > > recommend using PlayOnLinux - it's not only useful to games. It > > also has a long list of scripted installers for installing popular > > Windows extensions that you may need (fonts, VB runtimes, C > > runtimes) in different versions. > > > > And then, maybe you want to use winetricks, tho it may be a bit > > tricky to run this with PlayOnLinux because it will default to the > > non-PlayOnLinux wine prefix. Easy work-around: Launch a commandline > > shell from within PlayOnLinux and run winetricks there. > > > > With PlayOnLinux you can easily reset or discard wine prefixes if > > you messed up. Also, you can see each prefix as some sort of > > compatibility profile you individually crafted per Windows > > application you are running. > > > > -- > > Regards, > > Kai > > > > Replies to list-only preferred. > > > > > > Hallo Kai, > > jupp - ich bin aus Deutschland...die Sache mit dem "Shark" > ist ja nett! :) > > Yepp - I am from germany...the "Shark" nickname is nice! :) > > The problem with "secure banking" is two sided: First it has > to be secure from the technical point of view and secondlu > -- in case of being hacked -- the "experts" > from the credit institute has to be convinced, that everything > was done to secure the banking tasks. > In latter case a "complete isolation" via Virtualbox seems > more intuitively to be understood than more advanced > setups with the same technical degree of security. > See here for more: > https://www.heise.de/newsticker/meldung/Hacker-brechen-aus-virtueller-Maschine-aus-3658416.html
Well, according to your setup, your concept should be to stop hackers from breaking into the virtual machine or its communication... ;-) So it only works if you jail all your applications inside of containers or VMs - and do not use the base (outside) system for anything else than starting VMs and containers. To do it right, you should not put the security sensitive actions inside of a VM but the potentially unsecure actions, like surfing the web or reading mails. Your concept is broken by design. ;-) > Back to bussiness: Wine wth a 32bit flashtool is not suitable for me, > since I am running a pure 64bit (no multilib) Gentoo setup. Multilib is pretty easy these days since having ABI useflags. Tho, switching and migrating can be a hassle due to conflicts. I've done that step a while ago to run Steam in linux. If you enable a multilib profile and then emerge wine with ABI32 useflags, it should pull in only those packages for multilib rebuild that are needed. Of course, first compile the kernel to support 32bit user space. > I think I have to send the charger to the vendor > for updateing it...sigh. Then, use VirtualBox and, with a Linux browser, download the Win10 ISO directly from Microsoft. Windows can be run in evaluation mode for up to 180 days (starting with 30 days, you can use a builtin command line tool from MS to maybe extent that period). Just don't enter a product key during installation. German link: https://www.microsoft.com/de-de/software-download/windows10 Do not select the "single language" download: It does not have the German version. You may not even need to install Windows. In the setup screen, select the language, then press Shift+F10 to launch a command line window. Now, attach a USB stick with the flashing tool and firmware, pass it through to the VM using USB-passthrough in VirtualBox, find the correct driver letter, and you should be good to go: If the tool doesn't need any drivers, it should work. COM ports should be available. Otherwise, close the command window and just install Windows for the sole purpose of one-time-flashing. Or try installing the drivers by putting them on the USB stick and running setup.exe: As long as no reboot is required, it should work. I think you cannot run the device manager from there because it is not available in the pre-installation environment. Past the evaluation period, Windows will simply put a black background and shut down every few hours. -- Regards, Kai Replies to list-only preferred.
