Menu
▾
▴
basilisk-devel
|
From: emddd <em...@ch...> - 2011-09-10 17:04:52
|
Hi
I know this is a desperate action, being how old Basilisk 2
is. I have found one of the greatest games and was shot down instantly for
one reason. It was a Mac version of the game. The game is Call The
Journeyman Project, I got it for a steel at a Goodwill store. It's in
excellent condition and it is still works. However being that it's the Mac
version, I need to find an emulator for it. That's when I finally found one
that works, Basilisk 2. However, after I got it running I encountered an in
game problem. The controls don't work and my keyboard doesn't register any
commands to the game. I have tried to figure out what was wrong with the
settings but to no luck. I was running it on my mom's 32-bit windows-7
computer ?(being that my computer is 64-bit).
Am asking if you know of any fixes to Basilisk 2 that will
solve this problem, and is there a 64-bit compatible version for my
computer or DILL files that will make it compatible with a 64-bit computer?
If you can help me in any way, please send me an email at
ale...@ch...
Sincerely
Bastien A. Auxer
|
|
From: Ronald P. R. <ron...@xs...> - 2011-09-12 10:05:48
|
There is no regular development of BasiliskII going on. You could try if other BasiliskII users have a solution. See the BasiliskII forum at Emaculation.com: <http://www.emaculation.com/forum/> Ronald P. Regenburg. -------------- Op 10 sep 2011, om 18:30, schreef emddd: Hi I know this is a desperate action, being how old Basilisk 2 is. I have found one of the greatest games and was shot down instantly for one reason. It was a Mac version of the game. The game is Call The Journeyman Project, I got it for a steel at a Goodwill store. It’s in excellent condition and it is still works. However being that it’s the Mac version, I need to find an emulator for it. That’s when I finally found one that works, Basilisk 2. However, after I got it running I encountered an in game problem. The controls don’t work and my keyboard doesn’t register any commands to the game. I have tried to figure out what was wrong with the settings but to no luck. I was running it on my mom’s 32-bit windows-7 computer ?(being that my computer is 64-bit). Am asking if you know of any fixes to Basilisk 2 that will solve this problem, and is there a 64-bit compatible version for my computer or DILL files that will make it compatible with a 64-bit computer? If you can help me in any way, please send me an email at ale...@ch... Sincerely Bastien A. Auxer ------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/_______________________________________________ basilisk-devel mailing list bas...@li... https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Frank T. <fra...@gm...> - 2011-09-12 14:40:30
|
Providing specifics about the error might be helpful. Also, for what your time is worth, you probably come out ahead by purchasing the Windows or DOS version of the game and running it in wine or dosbox. Which version of Journeyman Project are you attempting to run? I would check that the computer is in fact running in 32-bit mode. That is rather uncommon for computers shipping with Windows 7. Basilisk 2 and SheepShaver are okay so long as they are running on 32-bit operating systems since pointers are 32 bits in length . There is a rather pervasive problem in the code base of casting pointers to 32-bit integers, which causes a number of problems on 64-bit architectures, like refusal to compile in most cases and total failure at run-time when one gets that far. There are two possible long-term solutions that seemed plausible a few years ago. One is to preallocate memory for the emulated machine at a full 64-bit address and then to keep 32-bit pointers as internal off-sets in the allocated range. The other is to construct some method for translating between the virtual 32-bit pointers of the guest operating system and the 64-bit pointers of the host, possibly through a look-up table . Both options are extremely costly in terms of time investment. I started working on the first option but became too busy. At some point after that, one of the maintainers made some magical modification that allowed SheepShaver to compile and to run on 64-bit Linux and Mac OS. I have not had an opportunity to review the code, but I assumed that it patched the problem for Windows as well. On Sat, Sep 10, 2011 at 11:30 AM, emddd <em...@ch...> wrote: > Hi**** > > ** ** > > I know this is a desperate action, being how old Basilisk 2 > is. I have found one of the greatest games and was shot down instantly for > one reason. It was a Mac version of the game. The game is Call The > Journeyman Project, I got it for a steel at a Goodwill store. It’s in > excellent condition and it is still works. However being that it’s the Mac > version, I need to find an emulator for it. That’s when I finally found one > that works, Basilisk 2. However, after I got it running I encountered an in > game problem. The controls don’t work and my keyboard doesn’t register any > commands to the game. I have tried to figure out what was wrong with the > settings but to no luck. I was running it on my mom’s 32-bit windows-7 > computer ?(being that my computer is 64-bit). **** > > ** ** > > Am asking if you know of any fixes to Basilisk 2 that will > solve this problem, and is there a 64-bit compatible version for my > computer or DILL files that will make it compatible with a 64-bit computer? > **** > > ** ** > > If you can help me in any way, please send me an email at > ale...@ch...**** > > ** ** > > Sincerely**** > > ** ** > > Bastien A. Auxer**** > > > ------------------------------------------------------------------------------ > Using storage to extend the benefits of virtualization and iSCSI > Virtualization increases hardware utilization and delivers a new level of > agility. Learn what those decisions are and how to modernize your storage > and backup environments for virtualization. > http://www.accelacomm.com/jaw/sfnl/114/51434361/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > |
|
From: Joshua J. <jj...@gm...> - 2011-09-15 08:09:36
|
On Sep 12, 2011, at 7:40 AM, Frank Trampe wrote: > There is a rather pervasive problem in the code base of casting > pointers to 32-bit integers, which causes a number of problems on > 64-bit architectures, like refusal to compile in most cases and > total failure at run-time when one gets that far. Also problematic is the premise of storing host OS pointers in the guest OS's memory space. It opens the door for arbitrary native code execution on behalf of an emulated program. Putting aside the idea that someone would write a malicious classic Mac OS program to pwn your Intel box (which I admit is far-fetched), it's still plausible that misbehaving emulated code could crash the emulator itself. > There are two possible long-term solutions that seemed plausible a > few years ago. One is to preallocate memory for the emulated > machine at a full 64-bit address and then to keep 32-bit pointers > as internal off-sets in the allocated range. The other is to > construct some method for translating between the virtual 32-bit > pointers of the guest operating system and the 64-bit pointers of > the host, possibly through a look-up table . Both options are > extremely costly in terms of time investment. I started working on > the first option but became too busy. I'm writing a new 68K emulator, called v68k. It's not a full-on Mac emulator, but a library that (at least in theory) could be applied toward emulation of any 68K platform. In v68k, memory is modeled in the emulator as base pointer and length. Emulated memory addresses are offsets from the base pointer. The base pointer is compiled however the platform wants; it's never stored in emulated memory and no magic is required. Currently there's only one memory region (although a future version will support many), but even so, the translator (through which all emulated memory accesses are bottlenecked) has some special logic. The system vector table (which includes memory address zero, or NULL) can't be read or written in user mode and can't be executed even in supervisor mode. The important point is that memory errors are caught by the translator and don't leak into the native code. <http://www.metamage.com/code/v68k/> Josh |
|
From: Michael S. <msb...@me...> - 2011-09-16 00:37:03
|
On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote: > > Also problematic is the premise of storing host OS pointers in the > guest OS's memory space. It opens the door for arbitrary native code > execution on behalf of an emulated program. Putting aside the idea > that someone would write a malicious classic Mac OS program to pwn > your Intel box (which I admit is far-fetched), it's still plausible > that misbehaving emulated code could crash the emulator itself. > > I'm writing a new 68K emulator, called v68k. It's not a full-on Mac > emulator, but a library that (at least in theory) could be applied > toward emulation of any 68K platform. In v68k, memory is modeled in > the emulator as base pointer and length. Emulated memory addresses > are offsets from the base pointer. The base pointer is compiled > however the platform wants; it's never stored in emulated memory and > no magic is required. > > Currently there's only one memory region (although a future version > will support many), but even so, the translator (through which all > emulated memory accesses are bottlenecked) has some special logic. > The system vector table (which includes memory address zero, or NULL) > can't be read or written in user mode and can't be executed even in > supervisor mode. The important point is that memory errors are > caught by the translator and don't leak into the native code. Basilisk II supports three types of memory access modes. Which one to use is selected at compile time: REAL: The addresses seen inside the emulated machine are exactly the same as the host memory address. DIRECT: The addresses are shifted by a fixed offset. In Basilisk II the offset is a parameter; in SheepShaver it is pre-calculated and compiled into the program. VIRTUAL: The guest address space is broken down into banks, e.g. the RAM, ROM and frame buffer are handled separately. It uses some kind of address translation logic. 32-bit SheepShaver on OS X normally runs in REAL mode, for performance reasons. I'm suspecting that 64-bit SheepShaver still runs in REAL mode, simply allocating the guest memory down in the 32-bit address space. Since SheepShaver and Basilisk II guests are limited in how much guest memory they could possibly use, being limited to the 4 GB address space isn't a problem if the other memory blocks used by OS X are not in the way. Where does IOKit land in a 64-bit process? Anyway... my point is that Basilisk II is not restricted to running in REAL mode. You just need to compile it with different parms. |
|
From: Frank T. <fra...@gm...> - 2011-09-16 07:41:42
|
On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote: > On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote: > > > Also problematic is the premise of storing host OS pointers in the > guest OS's memory space. It opens the door for arbitrary native code > execution on behalf of an emulated program. Putting aside the idea > that someone would write a malicious classic Mac OS program to pwn > your Intel box (which I admit is far-fetched), it's still plausible > that misbehaving emulated code could crash the emulator itself. > > I'm writing a new 68K emulator, called v68k. It's not a full-on Mac > emulator, but a library that (at least in theory) could be applied > toward emulation of any 68K platform. In v68k, memory is modeled in > the emulator as base pointer and length. Emulated memory addresses > are offsets from the base pointer. The base pointer is compiled > however the platform wants; it's never stored in emulated memory and > no magic is required. > > Currently there's only one memory region (although a future version > will support many), but even so, the translator (through which all > emulated memory accesses are bottlenecked) has some special logic. > The system vector table (which includes memory address zero, or NULL) > can't be read or written in user mode and can't be executed even in > supervisor mode. The important point is that memory errors are > caught by the translator and don't leak into the native code. > > > Basilisk II supports three types of memory access modes. Which one to use > is selected at compile time: > > REAL: The addresses seen inside the emulated machine are exactly the same > as the host memory address. > > DIRECT: The addresses are shifted by a fixed offset. In Basilisk II the > offset is a parameter; in SheepShaver it is pre-calculated and compiled into > the program. > > VIRTUAL: The guest address space is broken down into banks, e.g. the RAM, > ROM and frame buffer are handled separately. It uses some kind of address > translation logic. > > > 32-bit SheepShaver on OS X normally runs in REAL mode, for performance > reasons. I'm suspecting that 64-bit SheepShaver still runs in REAL mode, > simply allocating the guest memory down in the 32-bit address space. > That would explain why so little code changed. This did not occur to me. At the same time, with processors as fast as they are, the added over-head of running in direct mode seems a small price to pay for avoiding all of the pains and woes and sysctl modifications and extra segmentation faults (beyond those intercepted for various reasons) that result from running in real mode. It also seems that it might be feasible, if anybody cared enough and had enough free time, to leverage the virtualization features in modern processors in order to solve the memory windowing problem better than the SEGINT handler. > > Since SheepShaver and Basilisk II guests are limited in how much guest > memory they could possibly use, being limited to the 4 GB address space > isn't a problem *if* the other memory blocks used by OS X are not in the > way. Where does IOKit land in a 64-bit process? > > > Anyway... my point is that Basilisk II is not restricted to running in REAL > mode. You just need to compile it with different parms. > My experience was on the SheepShaver side of things with the awful dyngen stuff, so I never noticed this. I might have saved myself a lot of trouble if I had. On a related note, does anybody know why there are so many good M68K emulators (Basilisk II, Mini vMac, and, seemingly, whatever Joshua is writing) and so few good PowerPC emulators? I would have thought (without actually reading much about the instruction sets) that emulating a RISC machine with a New World ROM and OpenFirmware ought to be much less difficult than emulating a CISC machine with all of the crazy ancient Macintosh stuff. > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > |
|
From: Joshua J. <jj...@gm...> - 2011-09-16 08:55:23
|
On Sep 16, 2011, at 12:41 AM, Frank Trampe wrote: > On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote: > >> On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote: >> >>> Also problematic is the premise of storing host OS pointers in the >>> guest OS's memory space. It opens the door for arbitrary native >>> code >>> execution on behalf of an emulated program. >>> >>> I'm writing a new 68K emulator, called v68k. It's not a full-on Mac >>> emulator, but a library that (at least in theory) could be applied >>> toward emulation of any 68K platform. In v68k, memory is modeled in >>> the emulator as base pointer and length. Emulated memory addresses >>> are offsets from the base pointer. >>> >>> The important point is that memory errors are >>> caught by the translator and don't leak into the native code. >> >> Basilisk II supports three types of memory access modes. Which one >> to use is selected at compile time: >> >> REAL: The addresses seen inside the emulated machine are exactly >> the same as the host memory address. >> >> DIRECT: The addresses are shifted by a fixed offset. In Basilisk >> II the offset is a parameter; in SheepShaver it is pre-calculated >> and compiled into the program. >> >> VIRTUAL: The guest address space is broken down into banks, e.g. >> the RAM, ROM and frame buffer are handled separately. It uses some >> kind of address translation logic. v68k is using a hybrid of DIRECT and VIRTUAL. There's only one bank at the moment, but translation is always bounds-checked and the first 1K is treated specially. >> 32-bit SheepShaver on OS X normally runs in REAL mode, for >> performance reasons. I'm suspecting that 64-bit SheepShaver still >> runs in REAL mode, simply allocating the guest memory down in the >> 32-bit address space. Your performance win is my security hole. :-( Again, not that someone's going to exploit it -- I just don't want the emulator crashing. On the other hand, SheepShaver doesn't handle hardware exceptions anyway, so it's kind of moot. > At the same time, with processors as fast as they are, the added > over-head of running in direct mode seems a small price to pay for > avoiding all of the pains and woes and sysctl modifications and > extra segmentation faults (beyond those intercepted for various > reasons) that result from running in real mode. I concur. As time passes, portability and robustness become more important and optimization less so. > It also seems that it might be feasible, if anybody cared enough > and had enough free time, to leverage the virtualization features > in modern processors in order to solve the memory windowing problem > better than the SEGINT handler. I assume you mean SIGSEGV. I maintain that illegal memory accesses should not be caught but prevented in the first place. >> Anyway... my point is that Basilisk II is not restricted to >> running in REAL mode. You just need to compile it with different >> parms. > > My experience was on the SheepShaver side of things with the awful > dyngen stuff, so I never noticed this. I might have saved myself a > lot of trouble if I had. > > On a related note, does anybody know why there are so many good > M68K emulators (Basilisk II, Mini vMac, and, seemingly, whatever > Joshua is writing) and so few good PowerPC emulators? Let's see: * m68k has been around about 15 years longer, so there's been more time to write emulators for it * m68k has been used for Mac, Atari, Amiga, Sun, Palm, and various other legacy systems, so there's demand for it, whereas PowerPC's only major legacy system is Macs -- and most users had switched to OS X and had little reason to emulate OS 9 and no reason to emulate OS X / PPC. * by the time PowerPC shipped, there were fewer Mac-only programs (since Windows was so dominant) * PowerPC apps are more likely to have been ported at least to Carbon, and therefore runnable in OS X * actual 68K Macs are much slower than PowerPC Macs and therefore more in need of emulators to replace them * personally, I find 68K more fun to work with :-) > I would have thought (without actually reading much about the > instruction sets) that emulating a RISC machine with a New World > ROM and OpenFirmware ought to be much less difficult than emulating > a CISC machine with all of the crazy ancient Macintosh stuff. Well, v68k knows nothing of Mac hardware -- it's just a 68K emulation library. But you could write a v68k-based Mac emulator -- that's just not one of my priorities at the moment. My first v68k client provides a native system call bridge, for running Unix programs. Right now, if you built rot13 for MacRelix (and extracted the code resource into its own file), it would also run in v68k-exec: $ echo Foo bar | v68k-exec rot13.68k Sbb one As for Mac support, I'd be interested in bridging apps directly to the host OS (in the manner of Wine or GrayBox) before I wrote yet another Mac emulator. Josh |
|
From: Michael S. <msb...@me...> - 2011-09-17 21:34:25
|
On Sep 16, 2011, at 3:55 AM, Joshua Juran wrote: > On Sep 16, 2011, at 12:41 AM, Frank Trampe wrote: > >> On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote: >> >>> On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote: >>> >>>> Also problematic is the premise of storing host OS pointers in the >>>> guest OS's memory space. It opens the door for arbitrary native >>>> code >>>> execution on behalf of an emulated program. >>>> >>>> I'm writing a new 68K emulator, called v68k. It's not a full-on Mac >>>> emulator, but a library that (at least in theory) could be applied >>>> toward emulation of any 68K platform. In v68k, memory is modeled in >>>> the emulator as base pointer and length. Emulated memory addresses >>>> are offsets from the base pointer. >>>> >>>> The important point is that memory errors are >>>> caught by the translator and don't leak into the native code. >>> >>> Basilisk II supports three types of memory access modes. Which one >>> to use is selected at compile time: >>> >>> REAL: The addresses seen inside the emulated machine are exactly >>> the same as the host memory address. >>> >>> DIRECT: The addresses are shifted by a fixed offset. In Basilisk >>> II the offset is a parameter; in SheepShaver it is pre-calculated >>> and compiled into the program. >>> >>> VIRTUAL: The guest address space is broken down into banks, e.g. >>> the RAM, ROM and frame buffer are handled separately. It uses some >>> kind of address translation logic. > > v68k is using a hybrid of DIRECT and VIRTUAL. There's only one bank > at the moment, but translation is always bounds-checked and the first > 1K is treated specially. > >>> 32-bit SheepShaver on OS X normally runs in REAL mode, for >>> performance reasons. I'm suspecting that 64-bit SheepShaver still >>> runs in REAL mode, simply allocating the guest memory down in the >>> 32-bit address space. > > Your performance win is my security hole. :-( Again, not that > someone's going to exploit it -- I just don't want the emulator > crashing. On the other hand, SheepShaver doesn't handle hardware > exceptions anyway, so it's kind of moot. I'm not sure there is a security hole. From what I recall, neither Basilisk II nor SheepShaver allow guest addresses that are out of the range of the guest address space (which in turn is limited by how much RAM you are emulating.) In some modes emulator code is being used to map addresses and emulate instructions. In these modes it can simulate seg faults. But even if it is running in REAL mode, virtualized, the guest OS still knows what the address space is supposed to be and it can through seg faults if you attempt to exceed it. So what the malware would need to do in that case is patch the ROM code to bypass those checks. >> At the same time, with processors as fast as they are, the added >> over-head of running in direct mode seems a small price to pay for >> avoiding all of the pains and woes and sysctl modifications and >> extra segmentation faults (beyond those intercepted for various >> reasons) that result from running in real mode. > > I concur. As time passes, portability and robustness become more > important and optimization less so. I would say that the reason SheepShaver doesn't use DIRECT mode is that, inexplicably, it is not as advanced as in Basilisk II. In B2 DIRECT mode works by allocation of the guest memory block anywhere the host can find space, and then B2 calculates the resulting offset. In SS the offset is calculated at compile time. But this only works if each user compiles the code! And, if you apply an upgrade to your machine (thus changing the library address randomization) it invalidates the compiled-in offset. You would need to keep recompiling it. Of course this is completely non-portable. Also, consider that both B2 and SS support running the guest on the same processor type as the host, e.g. SS can run on a PowerPC host and B2 can run on a 68k host. When running in this mode, REAL mode allows it to run virtualized instead of emulated. (Neither program is smart enough to use the host to do the memory address translation in hardware. ) > >> It also seems that it might be feasible, if anybody cared enough >> and had enough free time, to leverage the virtualization features >> in modern processors in order to solve the memory windowing problem >> better than the SEGINT handler. > > I assume you mean SIGSEGV. I maintain that illegal memory accesses > should not be caught but prevented in the first place. And one of SheepShaver's faults is it doesn't emulate the MMC, which does limit what programs it can run. For example that is one of the problems with later versions of QuickTime. >>> Anyway... my point is that Basilisk II is not restricted to >>> running in REAL mode. You just need to compile it with different >>> parms. >> >> My experience was on the SheepShaver side of things with the awful >> dyngen stuff, so I never noticed this. I might have saved myself a >> lot of trouble if I had. >> >> On a related note, does anybody know why there are so many good >> M68K emulators (Basilisk II, Mini vMac, and, seemingly, whatever >> Joshua is writing) and so few good PowerPC emulators? > > Let's see: > > * m68k has been around about 15 years longer, so there's been more > time to write emulators for it > * m68k has been used for Mac, Atari, Amiga, Sun, Palm, and various > other legacy systems, so there's demand for it, whereas PowerPC's > only major legacy system is Macs -- and most users had switched to OS > X and had little reason to emulate OS 9 and no reason to emulate OS > X / PPC. > * by the time PowerPC shipped, there were fewer Mac-only programs > (since Windows was so dominant) > * PowerPC apps are more likely to have been ported at least to > Carbon, and therefore runnable in OS X > * actual 68K Macs are much slower than PowerPC Macs and therefore > more in need of emulators to replace them > * personally, I find 68K more fun to work with :- PowerPC emulation died off as soon as OS X started running on Intel. For example, that immediately put a halt to PearPC development. And as Joshua pointed out, there isn't much else that runs on PowerPC that isn't also available in Intel. For example, while you could compile your favorite Linux distribution for PowerPC, you can also compile for Intel and run natively. By the way, I don't think the problem with SheepShaver is the PowerPC emulation part. It is everything else. A typical PC emulator works by emulating of the complete hardware: CPU, video, network, sound, memory, time controller, interrupts, disk drives, USB, BIOS, etc. Any OS that can run on a real PC with the same hardware (e.g. the same model of Ethernet card) can run, unmodified, on the emulated machine. The emulator then typically provides some kind of "Tools" you can install that will modify the running OS to improve performance. From what I can tell SheepShaver doesn't do that at all. Instead it is all Tools. It works by patching the hell out of the Mac OS. It patches every part of the Mac OS (by hooking the ROM) that deals with hardware, directing it instead to routines in the emulator code. The downside is that to understand what it is doing you must have an extremely in depth knowledge of how classic Mac OS works. And who knows that anymore? > >> I would have thought (without actually reading much about the >> instruction sets) that emulating a RISC machine with a New World >> ROM and OpenFirmware ought to be much less difficult than emulating >> a CISC machine with all of the crazy ancient Macintosh stuff. > > Well, v68k knows nothing of Mac hardware -- it's just a 68K emulation > library. But you could write a v68k-based Mac emulator -- that's > just not one of my priorities at the moment. My first v68k client > provides a native system call bridge, for running Unix programs. > Right now, if you built rot13 for MacRelix (and extracted the code > resource into its own file), it would also run in v68k-exec: > > $ echo Foo bar | v68k-exec rot13.68k > Sbb one > > As for Mac support, I'd be interested in bridging apps directly to > the host OS (in the manner of Wine or GrayBox) before I wrote yet > another Mac emulator. > > Josh > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X