====== Some news ======

Some of you have been wondering what's happened lately. I will try to summarize rough status and targets in this post.

**An inoperative development platform.** My Antec Aria power supply burned three weeks ago and proprietary PSUs do suck. I have two choices: //(i)// either buy a replacement PSU for 50 EUR, or //(ii)// buy a new bare-bone case that includes a PSU for 80 to 100 EUR. Then, I wonder: if I were to change the case, why not change motherboard, CPU et al.?

There is no interesting desktop CPU available yet so I should wait for AMD Phenom (K10 architecture) or Intel Penryn (Core 2++).

  * On one hand, there is a //"native" quad core CPU// capable to handle misaligned SSE vectors and that provides other interesting architectural changes for e.g. improved virtualization, cache and power management... but with an obsolete manufacturing process (65 nm).

  * On the other hand, there is an //improved Core 2 CPU// with larger caches and [[http://download.intel.com/design/processor/manuals/D91561.pdf|SSE 4.1]] support... but it will soon be obsoleted by Nehalem architecture processors with a few other instructions (SSE 4.2) in late 2008(?). In that case, why would I need a Penryn if I already have a Core 2 CPU?

The K10 processor is very appealing and provides a real advance wrt. the previous generation on the AMD line, so it looks like an interesting "immediate" choice. I would then be tempted to buy a Nehalem CPU in 2009. However, I noticed AMD is preparing a new SIMD extension ([[http://developer.amd.com/sse5.jsp|SSE5]]) which looks very interesting, provided they also implement Intel SSE4.x, and that may be available in 2009 too. Hmm, it could help to make a better choice if I were to know more about the Nehalem CPU architecture... ;-)

I probably should just stop thinking too far away and analyze my immediate needs and solutions available, and just go with them, i.e. get a new PSU and get it now? Oh, I hear a friend telling me: "you should apply this model/reasoning to other situations". Probably, but I am very attached to my current **Al**gorithm.

**Basilisk II.** Current CVS includes universal binaries for MacOS X with the original Cocoa GUI from Nigel Pearson. I have a couple more patches from Michael Alyn Miller to integrate and a few other arrangements to make prior to releasing a new build. BTW, the JIT is now working for any 68020+ emulation model and most instruction semantics have been validated against a real 68040 (thanks to Ray Arachelian!). I would like to rework the MacOS X video back-end but this will only cause further delay in the release process.

**SheepShaver.** There is a more intuitive and native GUI for MacOS X, available in CVS (thanks to Alexei Svitkine). There probably are still problems on Tiger/ppc but I have yet to find such a platform to investigate the issues myself and not waste some user's time. The video back-end rework for MacOS X will be necessary here because I want to get rid of SDL and be able to build universal binaries at once. This means a new SheepShaver release won't happen close enough to a Basilisk II release, as it used to be in the past.

  * //Leopard support.// MacOS X 10.5 completely dropped the Classic environment. However, I don't intend to buy this system because I would like to keep my development platforms baseline enough for testing purposes. This means my PowerBook will stick to MacOS X 10.2 and my MacBook to MacOS X 10.4. This doesn't mean SheepShaver won't run on Leopard, this means I won't be able to test it there. I believe that, if SheepShaver runs correctly on Tiger, there is no reason it wouldn't run on Leopard.\\ \\ BTW, I hope Leopard matured enough to implement ''poll()'' and thread cancellation points correctly. I also wonder if performance now matches Linux wrt. exception delivery, though I doubt it (Mach IPC) but who knows...

  * //Windows Vista support.// I have Windows Vista (64-bit edition) installed on my professional laptop but the lesser I use it, the better I feel. For one, I am mainly developing for Linux platforms. Second, Windows Vista is depressively slow and sub-optimal to use. It would be nice to have Basilisk II ethernet driver for Vista, anyone willing to take this task? I should still have Lauri Pesonen's old sources somewhere for anyone interested... Otherwise, ethernet solutions from a Basilisk II / SheepShaver point of view for Windows Vista will remain the "NAT/Router" and "slirp" network stacks, and "TAP" from OpenVPN. However, I don't think users would want to install the latter.

**NSPluginWrapper.** Thanks to Martin Stransky for still sending me patches, they will be reviewed soon. The next release will be a major version (most likely 0.9.92) because of license and internal changes.

  * //License change.// Some people expressed an interest in integrating nspluginwrapper parts into a browser. I am not against this idea though I have yet to see sort of a reference implementation because nspluginwrapper is "only" an NPAPI bridge, not an NPAPI emulation layer. The plug-in part, i.e. ''npwrapper.so'' and dependent code like RPC/marshalers, is intended to be LGPL. The viewer part and configuration tool are intended to remain under GPL.

  * //Internal changes.// The RPC code is intended to be more portable and flexible (API additions). The windowing system needs to be abstracted too (<del>raw X11</del>, gtk and win32). This means code will be re-organized, not overhauled since it should not really impact the way nspluginwrapper works. The ultimate goal is to provide Windows plug-ins support either under Linux or Windows platforms. Yes, I also thought about MacOS X plug-ins support under MacOS X but, if I remember correctly, NPAPI is undergoing changes on that platform. So, I probably should wait for its finalization?

I hope this clarifies the current situation. I am sure there are more things to work on (including for other projects), but this gives a rough idea of where I am heading to.

{{tag>linux emulation projects nspluginwrapper}}