| << May >> | ||||||
| S | M | T | W | T | F | S |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Mac Native
10/5/2008
I know that it's been a long time between drinks regarding Mac releases. And thats mostly because I've been very busy with other projects. But the last few weeks I've been working more and more on the Mac codebase. I've spent a lot of time re-working the drag and drop support. Which apart from not looking any different is becoming more reliable and flexible. Secondly I'm working on compatibility with standard Mac key bindings, for instance hiding a window. And now I'm playing with the native Mac file open dialogs. I've got a basic implementation working. Now it's a case of mapping all the parameters to the various Mac APIs. As for the various apps I've ported, I've got i.Mage working quite well on Mac and i.Hex has been ported as well. The Scribe port is undergoing day to day testing. I've changed some things in the receive code to log all the accesses to the mail transfer status variable which has been getting corrupted by something. So far so good. I'm also planning to play with some of the native controls inside the context of an Lgi application. Which hopefully will make the app look and feel more native. I'm wondering if I can make the toolbars extend the title bar down over the buttons. Hmmmm.
I know that it's been a long time between drinks regarding Mac releases. And thats mostly because I've been very busy with other projects. But the last few weeks I've been working more and more on the Mac codebase. I've spent a lot of time re-working the drag and drop support. Which apart from not looking any different is becoming more reliable and flexible. Secondly I'm working on compatibility with standard Mac key bindings, for instance hiding a window. And now I'm playing with the native Mac file open dialogs. I've got a basic implementation working. Now it's a case of mapping all the parameters to the various Mac APIs. As for the various apps I've ported, I've got i.Mage working quite well on Mac and i.Hex has been ported as well. The Scribe port is undergoing day to day testing. I've changed some things in the receive code to log all the accesses to the mail transfer status variable which has been getting corrupted by something. So far so good. I'm also planning to play with some of the native controls inside the context of an Lgi application. Which hopefully will make the app look and feel more native. I'm wondering if I can make the toolbars extend the title bar down over the buttons. Hmmmm.
(0) Comments | Add Comment
Scribe Progress
5/5/2008
After this debarcle I've had to spend some serious time extending and fixing the FolderDump utility that can re-build badly broken folders. This tool scans the folders.mail2 file and extract all the usable information out of it and writes a "good" version of it to export.mail2. This is a somewhat difficult thing to do depending on the type of damage the file has received. In this case, every object had lost it's hierarchy and had to be re-connection to the tree in some meaningful way. Some other folders have millions of false positive objects and duplicate object pointers. Other have random corruptions and broken links. So anyway if you've been wondering where I'd disappeared to, well thats where. Oh and writing/recording music. I do more than code apps.
After this debarcle I've had to spend some serious time extending and fixing the FolderDump utility that can re-build badly broken folders. This tool scans the folders.mail2 file and extract all the usable information out of it and writes a "good" version of it to export.mail2. This is a somewhat difficult thing to do depending on the type of damage the file has received. In this case, every object had lost it's hierarchy and had to be re-connection to the tree in some meaningful way. Some other folders have millions of false positive objects and duplicate object pointers. Other have random corruptions and broken links. So anyway if you've been wondering where I'd disappeared to, well thats where. Oh and writing/recording music. I do more than code apps.
(0) Comments | Add Comment
More Visual C++ 2005 Keyboard Idiocy
21/4/2008
After the previous keyboard related debarcle it should come as no surprise that Visual C++ 2005 can shoot itself in the foot with macros. The situation I found myself in today is that theCtrl +F7 shortcut that is used to kick off a compile stopped working. I tried closing Visual C++ and restarting it and resetting the keyboard bindings to their default (Visual C++ 6 of course) and nothing worked. The only thing out of the ordinary that I'd done recently was to record and use a temporary macro. So I thought that could be related to the compile keyboard shortcut not working. Experimental I open the Macro explorer (Tools -> Macros -> Macro Explorer) and there was a section in that called "Recording Module" and under that "Temporary Macro". So I deleted the temporary macro and tried the compile shortcut again. Lo and behold... it works again!
Words fail me...
After the previous keyboard related debarcle it should come as no surprise that Visual C++ 2005 can shoot itself in the foot with macros. The situation I found myself in today is that the
(0) Comments | Add Comment
Leopard Support
19/3/2008
X-Mailer: InScribe v1.90 (Test3, MacOSX v10.5.2, Debug, en)Yes I'm working on Leopard support. So far the major issue seems to be a slow down somewhere in the startup code. So I've built the codebase on Leopard and fixed the project files. And I'm not seeing any slowness on a Leopard based build. So maybe it's because the current release is built on Tiger that it's having issues. Leopard isn't really stable enough for everyday usage IMHO so I'd like to be able to work out what is borking up Tiger based builds of Scribe on Leopard. Most of the other issues appear to be similar to Tiger. Still there seems to be so much work to do and so little time. One issue I'm looking at is that I can't load libPng in Leopard (works in Tiger). When I dlopen(libPng.dylib) I get "image not found" but a spotlight search turns it up in the frameworks tree. What gives? I have fixed some other non-Leopard issues while I'm here. Unfortunately not "the" issue, which is the hang in the receive mail code due to memory corruption. It's hard to reproduce and harder to debug.
Scribe v2 Progress
17/3/2008
I've ported the existing v2 to both Linux and Mac, although I have no immediate plans to make releases on those platforms I like having a working svn. The linux build is particularly useful for checking under valgrind and the mac port is useful for when I'm working on a laptop away from my PC. As for v2 itself I've been implementing the foundations for a basic Maildir backend which I can reuse for IMAP. I know its not the "proper" way you should do IMAP but I can move towards that once I've got something working. I'm putting in place methods of converting mail between different backends and making that fairly seemless. Today I've implemented an attachment class for the IMAP code and I'm using the GMime class that I wrote a zillion years ago. Because the new internal API's are now well designed I can change implementation details like exactly how the IMAP cache works without effecting the main app in any significant way. This gives me a lot of freedom that I didn't have before. Some of the work I've been doing this week is going towards adding multiple simultaneous folder support. Which is a stepping stone to good import and export functionality too. I could do something crazy like write a MAPI backend... thing about that. Scribe could be corrupted by the dark side! If I wrote a backend for all the mail import/export formats I can read/write, and then rewrite the import/export code to replicate between any 2 backend mail stores... hmmmmm. The possibilities are endless. So far the whole architecture is holding up well in day to day use. I can't wait to write a faster "native" backend to replace mail2 files.
I've ported the existing v2 to both Linux and Mac, although I have no immediate plans to make releases on those platforms I like having a working svn. The linux build is particularly useful for checking under valgrind and the mac port is useful for when I'm working on a laptop away from my PC. As for v2 itself I've been implementing the foundations for a basic Maildir backend which I can reuse for IMAP. I know its not the "proper" way you should do IMAP but I can move towards that once I've got something working. I'm putting in place methods of converting mail between different backends and making that fairly seemless. Today I've implemented an attachment class for the IMAP code and I'm using the GMime class that I wrote a zillion years ago. Because the new internal API's are now well designed I can change implementation details like exactly how the IMAP cache works without effecting the main app in any significant way. This gives me a lot of freedom that I didn't have before. Some of the work I've been doing this week is going towards adding multiple simultaneous folder support. Which is a stepping stone to good import and export functionality too. I could do something crazy like write a MAPI backend... thing about that. Scribe could be corrupted by the dark side! If I wrote a backend for all the mail import/export formats I can read/write, and then rewrite the import/export code to replicate between any 2 backend mail stores... hmmmmm. The possibilities are endless. So far the whole architecture is holding up well in day to day use. I can't wait to write a faster "native" backend to replace mail2 files.
v2 Where For Art Thou?
5/3/2008
So I guess people are wondering where v2 has gone? Well works continues, abet at a slower pace due to life's interruptions. Currently I'm ripping out the old cruddy IMAP full implementation and making a new one based on the new API's that I've made. This is currently looking a lot like a MAILDIR implementation where all folders and email are read from disk. Basically my idea is to cache email and folders on the IMAP server on disk in a sub-folder under the Scribe location such that you always have an offline database you can access. The IMAP network thread then attempts to keep the folders in sync with whats on the server. I haven't got to that yet, because I'm still building the MAILDIR functionality up. However I get a free MAILDIR implementation at the end as well. Anyway I might make the implementation of the caching/offline part different later as I build more optimal backends but MAILDIR is way easy and fast to implement (at the expense of runtime performance) so it'll get me a working IMAP implementation faster. And I think everyone would prefer working IMAP sooner even if it's a little slower than it could be. I'm not planning to complicate the MAILDIR stuff with indexing but that would probably fix the speed issues at the cost of extra complexity and implementation time. This will hopefully make the Scribe v2 upgrade worth it.
So I guess people are wondering where v2 has gone? Well works continues, abet at a slower pace due to life's interruptions. Currently I'm ripping out the old cruddy IMAP full implementation and making a new one based on the new API's that I've made. This is currently looking a lot like a MAILDIR implementation where all folders and email are read from disk. Basically my idea is to cache email and folders on the IMAP server on disk in a sub-folder under the Scribe location such that you always have an offline database you can access. The IMAP network thread then attempts to keep the folders in sync with whats on the server. I haven't got to that yet, because I'm still building the MAILDIR functionality up. However I get a free MAILDIR implementation at the end as well. Anyway I might make the implementation of the caching/offline part different later as I build more optimal backends but MAILDIR is way easy and fast to implement (at the expense of runtime performance) so it'll get me a working IMAP implementation faster. And I think everyone would prefer working IMAP sooner even if it's a little slower than it could be. I'm not planning to complicate the MAILDIR stuff with indexing but that would probably fix the speed issues at the cost of extra complexity and implementation time. This will hopefully make the Scribe v2 upgrade worth it.
The evils of cidaemon.exe
22/2/2008
I have been regularly having issues writing to files. The symptoms would basically be, try and open a file, OpenFileW would hang for about 2 minutes and then return a valid handle to the file. This causes havoc in my applications as you can imagine. So I fired up the wonderful SysInternals process explorer and looked for what had that file open and some dinky little process called 'cidaemon.exe' has it open. Dear Google, what is 'cidaemon.exe'? Dear Matt, 'cidaemon.exe' is the Microsoft indexing service. Riiiiight. Ok well it's indexing my drive for "searching" which btw sucks on windows. So I'm going to turn it off. You can do that on XP by clicking Start->Search->Files/Folders and then in the Search Options clicking the "Indexing Service" field and it'll give you an option to disable it. I consider a process regularly holding a non-sharable lock on MY file for 2 minutes severely broken. So I'm going to see what life is like with the indexing service. I suspect that life will be sweeter, my machine faster and my files will open easily. But this IS windows were talking about... *sigh*
I have been regularly having issues writing to files. The symptoms would basically be, try and open a file, OpenFileW would hang for about 2 minutes and then return a valid handle to the file. This causes havoc in my applications as you can imagine. So I fired up the wonderful SysInternals process explorer and looked for what had that file open and some dinky little process called 'cidaemon.exe' has it open. Dear Google, what is 'cidaemon.exe'? Dear Matt, 'cidaemon.exe' is the Microsoft indexing service. Riiiiight. Ok well it's indexing my drive for "searching" which btw sucks on windows. So I'm going to turn it off. You can do that on XP by clicking Start->Search->Files/Folders and then in the Search Options clicking the "Indexing Service" field and it'll give you an option to disable it. I consider a process regularly holding a non-sharable lock on MY file for 2 minutes severely broken. So I'm going to see what life is like with the indexing service. I suspect that life will be sweeter, my machine faster and my files will open easily. But this IS windows were talking about... *sigh*
Scribe v2 Beta?
17/2/2008
Well due to some timely feedback on the v2.00 alphas we might be approaching beta (as in all the functionality working again) sometime in the next week. I've crossed off all the bugs reported against alpha3 and made a release for alpha4. Do what do you think? Any good?
Well due to some timely feedback on the v2.00 alphas we might be approaching beta (as in all the functionality working again) sometime in the next week. I've crossed off all the bugs reported against alpha3 and made a release for alpha4. Do what do you think? Any good?
MiserySoft's Finest
15/2/2008
Re: Visual C++ .NET Can't Find Squat. Well guess what, the bug is still there in Visual C++ 2005. 2 Major releases and 1 service pack later. And the fix still works as well. Unbelievable. So it appears I have to use Visual C++ 2008 now. F. I guess that means I'm looking for a new job. F.
Re: Visual C++ .NET Can't Find Squat. Well guess what, the bug is still there in Visual C++ 2005. 2 Major releases and 1 service pack later. And the fix still works as well. Unbelievable. So it appears I have to use Visual C++ 2008 now. F. I guess that means I'm looking for a new job. F.
(0) Comments | Add Comment
The Big Scribe Re-write
8/2/2008
Yes. I'm in rewrite number 4 of Scribe. I've taken an extremely pessimistic view of what I can achieve and aimed low. Let me explain, in all the previous efforts I was trying to replace the backend at the same time as changing the API between the objects in memory and the disk storage interface. This was always problematic because there is too much going on at any one time and it unravels and I lose momentum and the rewrite dies... So this time, a new idea. Don't re-write the backend, just use the existing mail2 code BUT fix the object's so that they have a clean interface to the storage code. The system I've built on for the last n years has been one with a less than ideal architecture. And now I'm finally ripping that up and replacing it with the new. The in memory objects for Mail, Folders, Calendars, Contacts etc all derive from the "Thing" class (yes I know... original) and they include all sorts of data members that get written to disk. This meant that the "Thing" objects were the only code that knew how to read and write themselves to the mail2 file. The mail2 code didn't know what it was storing. So for me that meant I couldn't read/write the objects to a different back end easily. Now I've separated out the serialization code from the "Thing" objects into a pure virtual API that glues the Things to their mail2 backend. But of course can be replaced with any other backend that implements the glue API. So that could be a Sqlite database, an MBOX store... or a MAILDIR folder. Or a caching IMAP implementation. Anyway, currently the app boots, loads a folder and shows email. It's not sending or receiving yet, but I think I'm close to getting that working. Receiving should be easy, sending... uh less so. Because in the object hierarchy shuffle the Mail object lost it's "MailMessage" parent which the sending code uses to encode the outgoing mail. That means more mucking around for me when preparing a message for SMTP. But no doubt I'll have that licked in short order. One of the releases in the next few weeks will be off this new architecture. And it'll suck. Seriously it'll be a big backward step compared to the latest v1.90 test2 release. Because lots and lots of code has changed... challenging, application wide refactoring. And I won't get that right first go... it'll need lots of field testing, and it won't even do any new tricks to start with either. It'll be the same old UI and feature set... just with more bugs, missing features and crashes. You like? Well it had to be done, and I'm giving the beta testers fair warning that all hell will break loose in the following releases. So there. More updates to follow.
Yes. I'm in rewrite number 4 of Scribe. I've taken an extremely pessimistic view of what I can achieve and aimed low. Let me explain, in all the previous efforts I was trying to replace the backend at the same time as changing the API between the objects in memory and the disk storage interface. This was always problematic because there is too much going on at any one time and it unravels and I lose momentum and the rewrite dies... So this time, a new idea. Don't re-write the backend, just use the existing mail2 code BUT fix the object's so that they have a clean interface to the storage code. The system I've built on for the last n years has been one with a less than ideal architecture. And now I'm finally ripping that up and replacing it with the new. The in memory objects for Mail, Folders, Calendars, Contacts etc all derive from the "Thing" class (yes I know... original) and they include all sorts of data members that get written to disk. This meant that the "Thing" objects were the only code that knew how to read and write themselves to the mail2 file. The mail2 code didn't know what it was storing. So for me that meant I couldn't read/write the objects to a different back end easily. Now I've separated out the serialization code from the "Thing" objects into a pure virtual API that glues the Things to their mail2 backend. But of course can be replaced with any other backend that implements the glue API. So that could be a Sqlite database, an MBOX store... or a MAILDIR folder. Or a caching IMAP implementation. Anyway, currently the app boots, loads a folder and shows email. It's not sending or receiving yet, but I think I'm close to getting that working. Receiving should be easy, sending... uh less so. Because in the object hierarchy shuffle the Mail object lost it's "MailMessage" parent which the sending code uses to encode the outgoing mail. That means more mucking around for me when preparing a message for SMTP. But no doubt I'll have that licked in short order. One of the releases in the next few weeks will be off this new architecture. And it'll suck. Seriously it'll be a big backward step compared to the latest v1.90 test2 release. Because lots and lots of code has changed... challenging, application wide refactoring. And I won't get that right first go... it'll need lots of field testing, and it won't even do any new tricks to start with either. It'll be the same old UI and feature set... just with more bugs, missing features and crashes. You like? Well it had to be done, and I'm giving the beta testers fair warning that all hell will break loose in the following releases. So there. More updates to follow.
Update
2/2/2008
Lots of things going on. Firstly I made a triple platform release of Scribe this week. I think thats the 2nd one I've ever done. *pats self on back* Hopefully it's a reasonable release quality wise too. Let me know if you have issue (of course). Secondly I came off my scooter 2 days ago and twisted my ankle and knocked a chip off a bone in my foot. They put on a cast of sorts to stop me moving it around and I'll see the specialist next week to get the full rundown. Not so much fun that. Worst case is 6 weeks in a cast, but I'm prayin that doesn't happen and it's more like 2 weeks for the soft tissues to heal. I've only been riding a year and I grabbed too much front brake in an emergency braking situation, locked the front and it buckled under the bike, over she went. The bike is ok, scratched up a bit but ridable. Thirdly I've been "production" testing my revamped SMTP client/server which will probably make it's way into the Scribe email client down the track as an end to end SMTP solution (i.e. not reliant on the ISP's SMTP server). It has most of the kinks worked out of it.
Lots of things going on. Firstly I made a triple platform release of Scribe this week. I think thats the 2nd one I've ever done. *pats self on back* Hopefully it's a reasonable release quality wise too. Let me know if you have issue (of course). Secondly I came off my scooter 2 days ago and twisted my ankle and knocked a chip off a bone in my foot. They put on a cast of sorts to stop me moving it around and I'll see the specialist next week to get the full rundown. Not so much fun that. Worst case is 6 weeks in a cast, but I'm prayin that doesn't happen and it's more like 2 weeks for the soft tissues to heal. I've only been riding a year and I grabbed too much front brake in an emergency braking situation, locked the front and it buckled under the bike, over she went. The bike is ok, scratched up a bit but ridable. Thirdly I've been "production" testing my revamped SMTP client/server which will probably make it's way into the Scribe email client down the track as an end to end SMTP solution (i.e. not reliant on the ISP's SMTP server). It has most of the kinks worked out of it.
Compiling With Windows Media Format SDK
29/1/2008
This article is purely to document a fix for Google to index. If you are trying to compile code that uses the Windows Media Format SDK and you are getting these sorts of errors:
This article is purely to document a fix for Google to index. If you are trying to compile code that uses the Windows Media Format SDK and you are getting these sorts of errors:
2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C2146: syntax error : missing ';' before identifier 'SHCOLUMNID' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C2143: syntax error : missing ';' before '*' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C2378: 'SHCOLUMNID' : redefinition; symbol cannot be overloaded with a typedef 2> d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : see declaration of 'SHCOLUMNID' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\propsys.h(438) : error C2061: syntax error : identifier 'REFPROPVARIANT' 2>d:\program files\wmsdk\wmfsdk11\include\propsys.h(564) : error C2061: syntax error : identifier 'REFPROPVARIANT'Then you'll find that re-ordering the include paths in your Visual C++ settings will help. Your path to the WMF SDK (???\WMSDK\WMFSDK11\include) needs to be before the ???\PlatformSDK\include line. However you still get warnings about macros redefinitions.
(0) Comments | Add Comment