There are cameras that do not support Mass Storage. Notably the Canon cameras for instance (PowerShot, Digital IXUS, et.al.) and others.
Second, Windows has several methods to interface with digital cameras. One of the
is direct filesystem access (works just fine). The second is TWAIN. Originally
just for scanners it is also used for digital cameras. On third, WIA (Windows Imaging Architecture).
WINE already had a TWAIN implementation (written by Corel during WordPerfect 2000 times) but it was only able to use SANE, and not really able to use libgphoto2 in a good way.
So what I did was to just add the lowlevel libgphoto TWAIN driver to WINE, and CodeWeavers provided a gphoto Import GUI for it. My part of work was small compared to the stuff the CodeWeavers people did.
Voila - importing from any kind of cameras into Picasa.
Btw, I think all of this is in regular WINE 0.9.14.
Yes, userspace is 32bit but all of IBM, Redhat and SUSE have worked pretty hard on getting the toolchain (gcc, binutils, glibc) to work and Redhat and SUSE have put significant efforts into making applications work on the ppc64 platform.
Whoever thinks that./configure ; make ; make install is sufficient when a new platform appears is usually mistaken.
Those 3 Linux giants have been working on this for you since mid of 2002, and it just proves the effectiveness of OpenSource that now gentoo can step up and can now freely use the fruits of their labor.:)
And the decision for RH and SUSE not shipping a 64bit distribution is that 64bit PowerPC code is slower than 32bit. However, both include 64bit runtime and development environments.
Ciao, Marcus (actually one of the SUSE PowerPC developers)
Everyone thinking that WINE is slower because it somehow emulates Windows is mistaken to some degree.
WINE just replaces the lowlevel libraries by its own thin replacements which just translate the calls and forward them to the UNIX equivalents.
Btw, it helps if you start thinking of WINE not as some kind of emulator, but that it is just the set of Windows libraries, including libddraw and libdirect3d. All Code is run native and the libraries use all highspeed features available including hardware accelerated OpenGL for the emulation.
There is barely a speed loss for most of the timing critical stuff is implemented in the lowlevel X drivers, not in the wrapper libraries.
Judging from that article, they no longer care about 'other' Linux distributions, but assume market leadership including all negative aspects of it, notably just forcing something down the users throat in their 'best interest'.
They no longer care about compatibility with other Linux distributions (LSB? Whats that?):
Use a development snapshot of gcc, so that C++ programs compiled on RH7 only work on RH7.
Again change their RPM binary format (for the utterly stupid reason that it now supports bzip2 compression), so RH7 RPMs only work on RH7.
Use a glibc2.2 development snapshot, so that again, their RPMs only work on RH7.
All possibilities of 'choice' within Linux being wiped out by them I now nearly agree with the 'RedHat sucks' motto.
*sigh*
The problem with the Sims and the VxD is that the currently available copy protections are too hard to emulate, since they use tricks like VxDs, hardware registers, timing tricks, etc., which WINE just cannot handle easily.
Fortunately there are ways to disable the copy protection, look for 'unsafedisc' or similar on www.gamecopyworld.com. (Heck, it is even legal, since you own a copy:)
That just leaves us (WINE) to implement enough of DirectX7, but this is not a huge problem.
- Marcus
Re:QuickTime in Linux? (off topic)
on
D&D Trailer
·
· Score: 3
I have spent some time to get the QuickTimePlayer Version 4 running under WINE, it plays the trailer now, but only with some tricks (getting it to open the file is rather tricky).
You do know that Caldera has a Technology Preview out right now, with Linux 2.4.0-test3 kernel, KDE 1.91 Beta, XF 4.0.1, gcc-2.95.2, as much USB support as possible right now, etc.?
Seems noone has noticed that there is a bootloader that is more flexible than LILO... The Grand Unified Boot Loader aka GRUB.
Only a very limited set of realmode code, mostly used to switch to protected mode. GRUB understands the common filesystems, ext2, one of the BSDs, vfat in seperated protected mode modules. No more rerunning lilo after recompiling a kernel. Boot menu support. readline compatible commandline editing capability in case you need it. Much cleaner code inside.
Shipped by NetBSD (not sure) and OpenLinux eDesktop 2.4.
I've actually seen it running side by side with LinDVD 2000 on the CeBit computer fair in March. The speed was satisfying and the same for both Windows and Linux. A demo copy was not available.
Check out the homepage of the AVT working group of the IETF at http://www.ietf.org/html.charters/avt-charter.html and also check out the set of tools (video conferencing, audio etc.) already available on http://www-mice.cs.ucl.ac.uk/multimedia/software /.
We already do have streaming video and audio on UNIX.
Lizard autodetects the graphics card (if it is PCI) and assigns the correct X Server. The monitor currently cannot be autodetected.
There are three different partitioning dialogs, from very easy (whole disk), prepared (by Partiting Magic) and a full featured partitioner.
And you do not need to type 'mount/floppy' or something in OpenLinux, you just do cd/auto/floppy or cd/auto/cdrom and the floppy/cdrom will be automounted for you. Including icons on the desktop that will do this and pop up a kfm.
You have a point, QT does not do much of it, the magic lies within Lizard and the rest of OpenLinux;)
Slashdot Mirror
Second, Windows has several methods to interface with digital cameras. One of the is direct filesystem access (works just fine). The second is TWAIN. Originally just for scanners it is also used for digital cameras. On third, WIA (Windows Imaging Architecture).
WINE already had a TWAIN implementation (written by Corel during WordPerfect 2000 times) but it was only able to use SANE, and not really able to use libgphoto2 in a good way.
So what I did was to just add the lowlevel libgphoto TWAIN driver to WINE, and CodeWeavers provided a gphoto Import GUI for it. My part of work was small compared to the stuff the CodeWeavers people did.
Voila - importing from any kind of cameras into Picasa.
Btw, I think all of this is in regular WINE 0.9.14.
Ciao, Marcus
Pretty old news, it will be around 10% or 600 jobs
Ciao, Marcus
SUSE is i586 optimized for 2 years now...
Ciao, Marcus (SUSE developer)
Yes, userspace is 32bit but all of IBM, Redhat and SUSE have worked pretty hard on getting the toolchain (gcc, binutils, glibc) to work and Redhat and SUSE have put significant efforts into making applications work on the ppc64 platform.
./configure ; make ; make install is sufficient when a new platform appears is usually mistaken.
:)
Whoever thinks that
Those 3 Linux giants have been working on this for you since mid of 2002, and it just proves
the effectiveness of OpenSource that now gentoo can step up and can now freely use the fruits of their labor.
And the decision for RH and SUSE not shipping
a 64bit distribution is that 64bit PowerPC code is slower than 32bit. However, both include
64bit runtime and development environments.
Ciao, Marcus (actually one of the SUSE PowerPC developers)
gcc already does this, using processor pipeline models.
Ciao, Marcus
ACLs have been in SuSEs Enterprise Server since end of last year, so they are barely news.
Well, most of the distributions already have.
But it is not just recompiling, there is a lot of work done for the compiler, binutils and the kernel.
For AMD Hammer most of this has been done by SuSE already, so there is not much work left.
Ciao, Marcus
WINE just replaces the lowlevel libraries by its own thin replacements which just translate the calls and forward them to the UNIX equivalents.
Btw, it helps if you start thinking of WINE not as some kind of emulator, but that it is just the set of Windows libraries, including libddraw and libdirect3d. All Code is run native and the libraries use all highspeed features available including hardware accelerated OpenGL for the emulation.
There is barely a speed loss for most of the timing critical stuff is implemented in the lowlevel X drivers, not in the wrapper libraries.
Ciao, Marcus
They no longer care about compatibility with other Linux distributions (LSB? Whats that?):
- Use a development snapshot of gcc, so that C++ programs compiled on RH7 only work on RH7.
- Again change their RPM binary format (for the utterly stupid reason that it now supports bzip2 compression), so RH7 RPMs only work on RH7.
- Use a glibc2.2 development snapshot, so that again, their RPMs only work on RH7.
All possibilities of 'choice' within Linux being wiped out by them I now nearly agree with the 'RedHat sucks' motto. *sigh*The problem with the Sims and the VxD is that the currently available copy protections are too hard to emulate, since they use tricks like VxDs, hardware registers, timing tricks, etc., which WINE just cannot handle easily.
:)
Fortunately there are ways to disable the copy protection, look for 'unsafedisc' or similar on www.gamecopyworld.com. (Heck, it is even legal, since you own a copy
That just leaves us (WINE) to implement enough of DirectX7, but this is not a huge problem.
- Marcus
I have spent some time to get the QuickTimePlayer Version 4 running under WINE, it plays the trailer now, but only with some tricks (getting it to open the file is rather tricky).
;)
Don't worry, I'll pursue this further
You need Diablo 2 pre installed and the NoCD crack from gamecopyworld (WINE is not able to emulate the copyprotection).
But then it will run Diablo 2 just fine. I have tested and played Single Player and TCP/IP Multiplayer Modus. I was not able to get battle.net to run.
Check out their website and their ftp site for the ISO image.
We have implemented: DirectDraw, DirectSound, DirectInput and small portions of Direct3D already.
Games that are running include:
- Half Life
- Wing Commander Prophecy
- Monkey Island 3
- StarCraft
- Diablo 1 (Diablo 2 not yet, I did not get a copy yet)
- much more I haven't personally tested.
Check out LinuxGames on WINE.Ciao, Marcus (one of the WINE DirectX implementors)
Only a very limited set of realmode code, mostly used to switch to protected mode.
GRUB understands the common filesystems, ext2, one of the BSDs, vfat in seperated protected mode modules.
No more rerunning lilo after recompiling a kernel.
Boot menu support.
readline compatible commandline editing capability in case you need it.
Much cleaner code inside.
Shipped by NetBSD (not sure) and OpenLinux eDesktop 2.4.
Well, Caldera already has a good product. Have you tried Caldera OpenLinux aka eDesktop lately?
And you can even download the whole thing from their ftp site including the source code.
I've actually seen it running side by side with LinDVD 2000 on the CeBit computer fair in March. The speed was satisfying and the same for both Windows and Linux.
A demo copy was not available.
Reminds me of Max Headroom, when the Zic-Zac coperation schedules their yearly satellite burndown ;)
There already is a set of standards!
l e /.
Check out the homepage of the AVT working group of the IETF at http://www.ietf.org/html.charters/avt-charter.htm
and also check out the set of tools (video conferencing, audio etc.) already available on
http://www-mice.cs.ucl.ac.uk/multimedia/softwar
We already do have streaming video and audio on UNIX.
Lizard autodetects the graphics card (if it is PCI) and assigns the correct X Server.
/floppy' or something in OpenLinux, you just do cd /auto/floppy or cd /auto/cdrom and the floppy/cdrom will be automounted for you. Including icons on the desktop that will do this and pop up a kfm.
;)
The monitor currently cannot be autodetected.
There are three different partitioning dialogs,
from very easy (whole disk), prepared (by Partiting Magic) and a full featured partitioner.
And you do not need to type 'mount
You have a point, QT does not do much of it, the magic lies within Lizard and the rest of OpenLinux