I’ve been working very hard on WorldBankBBS lately.  I’ve added a lot of features, and a lot more are coming soon.

Right now, you can use these features:

  1. Subboards with full screen editor
  2. IRC Gateway
  3. BBS Gateway
  4. Question & Answer FAQ System
  5. Full system search engine

To connection, simply navigate to http://www.altiworld.com and select the terminal emulation you prefer!

I’ve spent the last few weeks laid up with knee surgery.  In that time I’ve revisited some hobby stuff including WorldBankBBS.  Testing with Synchterm normally goes well, but when testing at 2400 baud it’s not entirely accurate.

The solution is to use WinVICE (the Versatile Commodore Emulator) to actually emulate a Commodore 64 connecting to the BBS.  To make that work, you need another program called TCPSER.  This program is a GNU/Linux native app and requires Cygwin to run on Windows.  There is a Java port called TCPSER4J, and it works fine, but you get all of the problems of having Java installed on your system.

One of the things that is a big bonus of porting TCPSER4J to C# is that it allows the application to be run as a Windows Service which ensures you always have it running.

You can check out the code at https://github.com/sharpninja/tcpsersharp and you can check out the project at http://thesharp.ninja/tcpsersharp where you can download the installer.


I have been working on a very interesting project lately for work. It’s a set of plugins for IE and Chrome to capture visited URLs and report them to a central server so that a remote service can be paused while the user is visiting a page in a blacklist.

To accomplish this, there is a browser helper object written Visual C++. BHO component should not be written in .net code despite the examples on the web. This is because the browser liberally shuts down COM containers which can leave the CLR in an unstable state. Trust me on this one, just bite the bullet and write your BHOs in C++.

For Chrome, things are even more convoluted. You must create a plugin in JavaScript. The manifest must declare both a background page/js and an event js file. The event js has access to the DOM, so any manipulation must be done there. The event then uses internal messaging to talk to the background js. Finally, the background js uses native messaging to talk to a command line app written in C# that accepts communications via standard in. The C# app then calls a WCF service that aggregates all of the data collected by the IE and Chrome plugins.

Did I mention that the BHO hosts its own CLR to communicate with the WCF service, too?

The WCF service is hosted in a Windows Service which also contains a cache that the WCF service populates. Once a page transaction is comple, the cache attempts to send the page data to a webapi on a central server.


INTRODUCTION: Today I got a call from a recruiter looking to fix a big problem that a client is having with bad decisions being made with about code, deployment, testing… you name it.  I expressed to the executive that called me for an interview that nothing was going to get fixed without culture change, to which he said not to worry about that because he was ordering culture change and it would happen.  Well, a pack of developers can be like a pack of teenagers… They will see any change to the way they do things as an attack on their self-worth, which then leads into a ton of passive-aggressive behavior on the part of the group that will either lead to mass firings or an organizational change near the top. 

If you want culture change in a development group, it takes time, patience and a leader with a vision that the pack will buy into.  It takes someone with the background in the new techniques that the pack can hang their hat on.  It takes concrete examples of how to accomplish the new techniques.  Finally, it takes someone willing to teach the new techniques in a way that the developers take ownership in the learning and not just being lectured to.

CONCLUSION: I politely turned down the position.  I don’t want to waste their time because the pack would just see me as part of the problem of the forced changes and I don’t care to spend my time fighting a battle like that.

INTRODUCTION: There are a lot of reasons to use real apps on the desktop:

  • Chrome can use over 1GB of RAM and runs continuously.  Universal apps typically do not.
  • Over 70% of the web is written in PHP.  Of those, 81% are vulnerable to attack.  Universal apps are almost impossible to attack without physical access to your desktop.
  • Tabbed browsers are like poor window managers trying to co-opt good window managers.
  • Universal apps don’t need a bloated javascript engine to get 1/10th of the performance of compiled code.

CONCLUSION:  For many applications, the web is the way to go.  Think corporate presence, branding, publishing, etc.  Written in a responsible manner these can be good netizens.  We’ve already seen in the phone segment that people prefer apps that are tailored to their application, not just another bootstrap website running in a browser that depends on a far-away server for everything.  It’s time for a Desktop Renaissance and Universal Apps can get us there.

Long, long ago, in a time far away, I wrote a blog for IT Toolbox where I talked about development and the life of a developer.  It’s been quite a while, but I feel the need to start blogging again.

To that end, I’ve set up this website, the home of the Sharp Ninja.  Why the Sharp Ninja?  Why not!  OK, well, because I’ve been developing with C# for about 15 years now and I feel like I have some things to share about it.

Some things to look forward to are articles about Windows 10 Universal apps, moving from ASP.Net Web Forms to ASP.Net MVC, WPF and WinForms development, and much more.