Active Topics

 


Reply
Thread Tools
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#61
Of course someone can; anything can be reverse-engineered and reproduced. But does it make any sense?

You mentioned the GVM; that wasn't the work of "somebody", that was from Access, the owners of Garnet, and is part of their business plan. So they have an easier time (because they have Garnet to start from), and more incentive (to make money). "Somebody" has neither of those advantages, so it's quite unlikely that someone's going to invest the time to do it.

Still, if you think it's really worth it, get started. Whatever investment you may have to put into learning up-front is outweighed by the size of the project, so you're as qualified as the next guy.
 
Posts: 96 | Thanked: 12 times | Joined on Jun 2008
#62
I'm not a programmer so I don't know how much work s involved but it seems like a lot, because if I was I would be interested in making a windows emulator.
__________________
n810.
n900
 
Karel Jansens's Avatar
Posts: 3,220 | Thanked: 326 times | Joined on Oct 2005 @ "Almost there!" (Monte Christo, Count of)
#63
Originally Posted by jackdoor View Post
I'm not a programmer so I don't know how much work s involved but it seems like a lot, because if I was I would be interested in making a windows emulator.
It would probably be easier (although not much) to "port" wine to the ARM architecture.
__________________
Watch out Nokia, Pandora's box has opened (sorta)...
I do love explaining cryptic sigs, but for the impatient: http://www.openpandora.org/
 
BrentDC's Avatar
Posts: 903 | Thanked: 632 times | Joined on Apr 2008
#64
Originally Posted by Karel Jansens View Post
It would probably be easier (although not much) to "port" wine to the ARM architecture.
I imagine that would be harder still...

Originally Posted by Wine Website
Well, it is true that Wine only runs on Intel's x86 processors. Unfortunately it will also require quite a lot of work before it runs on other processor architectures.

But what do we mean by 'running on a non x86 processor'.

First it can mean 'I can compile a Windows application on Sparc, link it with Winelib, and have it run on Solaris'. I know, this is not what you had in mind. This may seem very restrictive and yet would be very useful: it means easy porting of Windows applications to almost any Unix architecture. In any case this is the first step towards allowing Wine to run on other processor architectures. Unfortunately Wine's code is not very portable to other processor architectures, partly because some parts of it have to know a lot about the processor, and partly because most of it makes assumptions like 'sizeof(int)==sizeof(pointer)' and 'byte-sex==little-endian'. This is being worked on though, and progress is being made albeit slowly.

Then we could take it to mean 'Wine on Alpha should be able to run Windows NT Alpha applications'. The prerequisite for this is that Winelib compiles on Alpha (or MIPS, the other defunct Windows NT platform). Now, would it be really useful? I don't think many people have Windows NT applications for the Alpha or MIPS processor. So this is probably not that useful and also rather unlikely to happen since we would need a programmer who has just this combination of hardware and software to work on it.

Then there's what everyone has been waiting for: 'I want to be able to run my x86 Windows applications on any processor architecture I like. That's the most complex one. Again the prerequisite is that Winelib works on this architecture, which will definitely happen someday. Then 'all that is needed' is to integrate an x86 emulator with Wine (and also change Wine's name :-). Ulrich Weigand just did that as an experiment some time ago when he had 'some spare time'. He even managed to get some Win16 applications to run. His code was not in a state where it could be integrated into Wine yet and I don't know how much work has been put into pursuing it. His attempt did spark many discussions on Wine's mailing list though. The result is that we would need a sophisticated emulator including a JIT in order to get something really viable (i.e. not too slow). And developing such an emulator is a whole project in itself.
Does it mean it will never happen? Not sure. Maybe we'll get some motivated developers once the Winelib problems are solved. Of course, it would happen much faster if, for instance, Compaq made its Fx32! Intel x86 emulator Open Source and financed the development of Wine for their Alpha machines. As with all Open Source projects, if enough people are interested and pool their resources together, it will happen.
__________________
-Brent

Author of TouchSearch -- web searching software for Maemo 5.

Mobile Device lineage: Palm Z22 -> Palm TX -> Nokia N800 -> Nokia N900
 

The Following 3 Users Say Thank You to BrentDC For This Useful Post:
Johnx's Avatar
Posts: 643 | Thanked: 628 times | Joined on Mar 2007 @ Seattle (or thereabouts)
#65
Originally Posted by jackdoor View Post
I'm not a programmer so I don't know how much work s involved but it seems like a lot, because if I was I would be interested in making a windows emulator.
"Being a programmer" is not the same as "being a human" or "being a tree:" It's not something you're born with and it's never too late to learn. For this project you're in luck, because "learning how to program" would be pretty easy compared to reverse engineering the whole Windows Mobile API and reimplementing it from scratch in a "clean room" (without using or seeing any of Microsoft's code).

-John
 

The Following 3 Users Say Thank You to Johnx For This Useful Post:
Posts: 58 | Thanked: 9 times | Joined on Jul 2007
#66
Wow, the WINE FAQ hasn't been updated in some time(or whichever part of the website you found it on). Alpha processors and NT4 for Alpha being a significant discussion topic is almost humorous now. Long since that entry was made, people started bolting QEmu to WINE to run Windows x86 apps on non-x86 architectures. See http://bellard.org/qemu/qemu-doc.html#SEC69

It still wouldn't help much, as emulating x86 is slow by itself, then emulating ARM via the Windows Mobile SDK emulator would grind things to a crawl.

However, emulating an entire device, particularly with a dynarec core, would be fairly practical. I stumbled across an emulator for a specific iPaq some time ago, it was meant as debugging tool for ARM Linux on that platform, but was complete enough to boot the Windows Mobile ROM for it. Porting that and optimizing that would be far less intensive than making a full-blown API wrapper, though it'd be of questionable legality (HP has the rights to the ROM, I suppose it'd fall under fair-use if you owned the iPaq in question).

Still a bit too much effort for Age of Empires, Slay and a few other Windows Mobile apps, IMO, though.
 

The Following User Says Thank You to tom61 For This Useful Post:
eliagp's Avatar
Posts: 301 | Thanked: 71 times | Joined on Jul 2008 @ Santiago, Chile
#67
I want an ms-office compatible app. the rest is just padding.
 
qole's Avatar
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#68
yeah, wouldn't openoffice be nice?
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
 
Posts: 1,213 | Thanked: 356 times | Joined on Jan 2008 @ California and Virginia
#69
Oh, but OpenOffice is too bloated. Normal people can't be expected to use that! And you have to do complicated stuff like "dual-boot" and "Deblet" and stuff. Oh no, way to hard.

Or, just install Documents2Go on GarnetVM. Done. (ok, so you have to email it or bluetooth it to yourself, or wait until Access adds memory card support....)
 
Johnx's Avatar
Posts: 643 | Thanked: 628 times | Joined on Mar 2007 @ Seattle (or thereabouts)
#70
Of course the simplest thing of all for something ms-office compatible would be to just finish abiword. It's most of the way there already. Best of all it doesn't involve legal grey areas, CPU emulation or OpenOffice's giant code base...
 
Reply


 
Forum Jump


All times are GMT. The time now is 08:01.